From jcholast at redhat.com Mon Nov 2 05:10:09 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 2 Nov 2015 06:10:09 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628A1F1.8050602@redhat.com> References: <5628A1F1.8050602@redhat.com> Message-ID: <5636F031.4000901@redhat.com> Hi, On 22.10.2015 10:44, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5181 This should be handled by a separate object plugin: $ ipa servercomponent-find master.ipa.test --------------------------- 6 server components matched --------------------------- Component name: CA Enabled: TRUE Start order: 50 Component name: KDC Enabled: TRUE Start order: 10 Component name: KPASSWD Enabled: TRUE Start order: 20 Component name: MEMCACHE Enabled: TRUE Start order: 39 Component name: OTPD Enabled: TRUE Start order: 80 Component name: HTTP Enabled: TRUE Start order: 40 ---------------------------- Number of entries returned 6 ---------------------------- This will allow us to consolidate all the ad-hoc component-related code scattered throughout IPA (search for enabled component, enable/disable component, ...) into IPA command calls. I'm not opposed to showing a summary in server-show (although we don't do anything like this for any other hierarchical objects), but it should be done just for the users' sake, not for internal use (the ticket suggests to use this for topology visualisation). BTW as far as the scalability of the current solution goes, you should have a list of all the *non*-optional components and display everything else. Honza -- Jan Cholasta From mbasti at redhat.com Mon Nov 2 09:39:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 10:39:26 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <5632584A.7070607@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> <5632584A.7070607@redhat.com> Message-ID: <56372F4E.9060805@redhat.com> On 29.10.2015 18:32, Martin Basti wrote: > > > On 29.10.2015 18:31, Martin Basti wrote: >> NACK >> >> 1) >> DO NOT use tabs in code to indent >> >> 2) >> Replica uninstallation does not work, uninstallation works different >> with domain level 0 and 1 (currently uninstallation with domain 1 >> level will not work, it is known issue, but still the patch should >> solve the uninstallation) This is not valid, my bad, I was confused with new behaviour of replica uninstallation, but it is bug not a feature. So replica uninstallation is the same for level 0 and 1 Sorry. >> >> 3) >> apply_common_fixes(host) >> Method for domain_level 1 is called twice, first time in replica >> install, second time in client install >> >> 4) >> during testing this patch I used test_simple_replication and I found >> 4 bugs: > 3 bugs -----------------^^^ >> #5419, #5420, #5421 >> IMO it is related only to this one test case and to pass this test >> case #5419 or #5421 must be fixed. >> >> >> On 27.10.2015 16:34, Oleg Fayans wrote: >>> Hi Martin, >>> >>> The updated patch is attached >>> >>> On 10/27/2015 01:58 PM, Martin Basti wrote: >>>> >>>> >>>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>>> >>>>> >>>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>>>> comments >>>>>>>>>> below >>>>>>>>> My comments inline, I may be completely wrong in how the test >>>>>>>>> suite >>>>>>>>> work, so feel free to correct me. >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>> please remove the added empty lines, they are unrelated to >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>> >>>>>>>>>>>>>> done >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>> setup_kra=False): >>>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will >>>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>>> >>>>>>>>>>>>>> done >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So you have to find out way how to pass the domain >>>>>>>>>>>>>>>> level for >>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>>>>>>>> directive >>>>>>>>>>>>>> domain_level >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies which >>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>>> >>>>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>>>> require it. >>>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>>> How about topology CI test? This can be executed only with >>>>>>>>>>>>> domain >>>>>>>>>>>>> level >>>>>>>>>>>> >>>>>>>>>>>> That's right. The topology test was updated. Patch is attached >>>>>>>>>>>> together with a proper version of 11-th patch (not a swap >>>>>>>>>>>> file, >>>>>>>>>>>> sorry >>>>>>>>>>>> about that). >>>>>>>>>>>> >>>>>>>>>>>>> 1, right? >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 6) >>>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>>>>>>>> function >>>>>>>>>>>>>>> call) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>> host.config.domain_level) >>>>>>>>>>> >>>>>>>>>>> always use: variable *is not None* >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>>> that the >>>>>>>>>>> default level is the one which is default in tested package. >>>>>>>>>>> These should be None and "": >>>>>>>>>>> + "domain_level": "1" >>>>>>>>>>> >>>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>>> >>>>>>>>>>> 3) >>>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>>> pytest.fixture >>>>>>>>>>> needs >>>>>>>>>>> to know the value of domain level before we can do any dynamic >>>>>>>>>>> detection >>>>>>>>>>> on master. >>>>>>>>>>> >>>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>>>> for 2) >>>>>>>>>> Done >>>>>>>>>>> >>>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this >>>>>>>>>>> part >>>>>>>>>>> you >>>>>>>>>>> need default value, or the fixture will not work as expected. >>>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>> >>>>>>>>>> This won't work in cases when domainlevel is explicitly set >>>>>>>>>> to 0 in >>>>>>>>>> config.yaml. This default value will always override the >>>>>>>>>> explicit >>>>>>>>>> one. >>>>>>>>> wat? in case that kwargs is dict containing values from config >>>>>>>>> file: >>>>>>>>> >>>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>>> >>>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>>> Out[2]: 0 >>>>>>> >>>>>>> Yep, right you are, it works as expected. Now the line looks like: >>>>>>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>> >>>>>>>>> >>>>>>>> Respectively you should use this: >>>>>>>> >>>>>>>> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL >>>>>>> Now that would definitely not work in case of domain_level is 0: >>>>>>> 0 or 1 is always 1 >>>>>> Oh right. >>>>>> >>>>>> I had discussion with Tomas, and we should add there check if it >>>>>> is not >>>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>>> does not >>>>>> know with test when the None value appears there) >>>>> >>>>> I do not get this. If we do not specify domain_level in config.yaml, >>>>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. >>>>> That >>>>> means domain_level will never ever possibly be None. >>>> I do not know how pytest works inside, if you are 100% sure, that the >>>> case written above cannot happen, I'm fine with it. >>>> Martin >>>>> >>>>>> >>>>>> self.domain_level = kwargs.get('domain_level') >>>>>> if self.domain_level is None: >>>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>>> >>>>>> As we cannot user 'or' expression with integers, so this is the >>>>>> right >>>>>> way. >>>>>>> >>>>>>>> >>>>>>>> because kwargs IMO contains undefined config values as None >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>>> should be >>>>>>>>>>> available in tests. >>>>>>>>>>> >>>>>>>>>>> So then you also need update this line >>>>>>>>>>> >>>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>> host.config.domain_level) >>>>>>>>>> >>>>>>>>>> This would not work if domainlevel is not set in config.yaml, in >>>>>>>>>> which case the host.config.domain_level is None. >>>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 4) >>>>>>>>>>> Please add comment to function +def domainlevel(host): that >>>>>>>>>>> it is >>>>>>>>>>> useful >>>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>>> otherwise it >>>>>>>>>>> may >>>>>>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>>>>>> unneeded >>>>>>>>>>> and replace it with config dict. >>>>>>>>>> Done >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>>> >>>>>>>>>>> Martin^2 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From ofayans at redhat.com Mon Nov 2 10:54:57 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 2 Nov 2015 11:54:57 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <56372F4E.9060805@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> <5632584A.7070607@redhat.com> <56372F4E.9060805@redhat.com> Message-ID: <56374101.7000102@redhat.com> Hi Martin, On 11/02/2015 10:39 AM, Martin Basti wrote: > > > On 29.10.2015 18:32, Martin Basti wrote: >> >> >> On 29.10.2015 18:31, Martin Basti wrote: >>> NACK >>> >>> 1) >>> DO NOT use tabs in code to indent Fixed >>> >>> 2) >>> Replica uninstallation does not work, uninstallation works different >>> with domain level 0 and 1 (currently uninstallation with domain 1 >>> level will not work, it is known issue, but still the patch should >>> solve the uninstallation) > This is not valid, my bad, I was confused with new behaviour of replica > uninstallation, but it is bug not a feature. > So replica uninstallation is the same for level 0 and 1 > Sorry. >>> >>> 3) >>> apply_common_fixes(host) >>> Method for domain_level 1 is called twice, first time in replica >>> install, second time in client install Fixed >>> >>> 4) >>> during testing this patch I used test_simple_replication and I found >>> 4 bugs: >> 3 bugs -----------------^^^ >>> #5419, #5420, #5421 Bug #5419 fixed, see patch N 15 >>> IMO it is related only to this one test case and to pass this test >>> case #5419 or #5421 must be fixed. >>> >>> >>> On 27.10.2015 16:34, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> The updated patch is attached >>>> >>>> On 10/27/2015 01:58 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>>>> >>>>>> >>>>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>>>>> comments >>>>>>>>>>> below >>>>>>>>>> My comments inline, I may be completely wrong in how the test >>>>>>>>>> suite >>>>>>>>>> work, so feel free to correct me. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>> please remove the added empty lines, they are unrelated to >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> done >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>> setup_kra=False): >>>>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will >>>>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> done >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So you have to find out way how to pass the domain >>>>>>>>>>>>>>>>> level for >>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>>>>>>>>> directive >>>>>>>>>>>>>>> domain_level >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies which >>>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>>>>> require it. >>>>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>>>> How about topology CI test? This can be executed only with >>>>>>>>>>>>>> domain >>>>>>>>>>>>>> level >>>>>>>>>>>>> >>>>>>>>>>>>> That's right. The topology test was updated. Patch is attached >>>>>>>>>>>>> together with a proper version of 11-th patch (not a swap >>>>>>>>>>>>> file, >>>>>>>>>>>>> sorry >>>>>>>>>>>>> about that). >>>>>>>>>>>>> >>>>>>>>>>>>>> 1, right? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 6) >>>>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>> call) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1) >>>>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>> >>>>>>>>>>>> always use: variable *is not None* >>>>>>>>>>>> >>>>>>>>>>>> 2) >>>>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>>>> that the >>>>>>>>>>>> default level is the one which is default in tested package. >>>>>>>>>>>> These should be None and "": >>>>>>>>>>>> + "domain_level": "1" >>>>>>>>>>>> >>>>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>>>> >>>>>>>>>>>> 3) >>>>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>>>> pytest.fixture >>>>>>>>>>>> needs >>>>>>>>>>>> to know the value of domain level before we can do any dynamic >>>>>>>>>>>> detection >>>>>>>>>>>> on master. >>>>>>>>>>>> >>>>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>>>>> for 2) >>>>>>>>>>> Done >>>>>>>>>>>> >>>>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this >>>>>>>>>>>> part >>>>>>>>>>>> you >>>>>>>>>>>> need default value, or the fixture will not work as expected. >>>>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>> >>>>>>>>>>> This won't work in cases when domainlevel is explicitly set >>>>>>>>>>> to 0 in >>>>>>>>>>> config.yaml. This default value will always override the >>>>>>>>>>> explicit >>>>>>>>>>> one. >>>>>>>>>> wat? in case that kwargs is dict containing values from config >>>>>>>>>> file: >>>>>>>>>> >>>>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>>>> >>>>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>>>> Out[2]: 0 >>>>>>>> >>>>>>>> Yep, right you are, it works as expected. Now the line looks like: >>>>>>>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>> >>>>>>>>>> >>>>>>>>> Respectively you should use this: >>>>>>>>> >>>>>>>>> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL >>>>>>>> Now that would definitely not work in case of domain_level is 0: >>>>>>>> 0 or 1 is always 1 >>>>>>> Oh right. >>>>>>> >>>>>>> I had discussion with Tomas, and we should add there check if it >>>>>>> is not >>>>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>>>> does not >>>>>>> know with test when the None value appears there) >>>>>> >>>>>> I do not get this. If we do not specify domain_level in config.yaml, >>>>>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. >>>>>> That >>>>>> means domain_level will never ever possibly be None. >>>>> I do not know how pytest works inside, if you are 100% sure, that the >>>>> case written above cannot happen, I'm fine with it. >>>>> Martin >>>>>> >>>>>>> >>>>>>> self.domain_level = kwargs.get('domain_level') >>>>>>> if self.domain_level is None: >>>>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>>>> >>>>>>> As we cannot user 'or' expression with integers, so this is the >>>>>>> right >>>>>>> way. >>>>>>>> >>>>>>>>> >>>>>>>>> because kwargs IMO contains undefined config values as None >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>>>> should be >>>>>>>>>>>> available in tests. >>>>>>>>>>>> >>>>>>>>>>>> So then you also need update this line >>>>>>>>>>>> >>>>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>> >>>>>>>>>>> This would not work if domainlevel is not set in config.yaml, in >>>>>>>>>>> which case the host.config.domain_level is None. >>>>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 4) >>>>>>>>>>>> Please add comment to function +def domainlevel(host): that >>>>>>>>>>>> it is >>>>>>>>>>>> useful >>>>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>>>> otherwise it >>>>>>>>>>>> may >>>>>>>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>>>>>>> unneeded >>>>>>>>>>>> and replace it with config dict. >>>>>>>>>>> Done >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>>>> >>>>>>>>>>>> Martin^2 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0011.5-replica-promotion-changes-in-tests.patch Type: text/x-patch Size: 6486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0015-Fixed-A-record-creation-bug.patch Type: text/x-patch Size: 1149 bytes Desc: not available URL: From pvoborni at redhat.com Mon Nov 2 11:30:38 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 Nov 2015 12:30:38 +0100 Subject: [Freeipa-devel] [PATCH] 925 Update .po files Message-ID: <5637495E.8010900@redhat.com> For 4.2.3 release https://fedorahosted.org/freeipa/ticket/5427 target branches: master, ipa-4-2 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0925-Update-.po-files.patch Type: text/x-patch Size: 177713 bytes Desc: not available URL: From mkosek at redhat.com Mon Nov 2 11:37:17 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 2 Nov 2015 12:37:17 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5636F031.4000901@redhat.com> References: <5628A1F1.8050602@redhat.com> <5636F031.4000901@redhat.com> Message-ID: <56374AED.7030002@redhat.com> On 11/02/2015 06:10 AM, Jan Cholasta wrote: > Hi, > > On 22.10.2015 10:44, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5181 > > This should be handled by a separate object plugin: > > $ ipa servercomponent-find master.ipa.test > --------------------------- > 6 server components matched > --------------------------- > Component name: CA > Enabled: TRUE > Start order: 50 > > Component name: KDC > Enabled: TRUE > Start order: 10 > > Component name: KPASSWD > Enabled: TRUE > Start order: 20 > > Component name: MEMCACHE > Enabled: TRUE > Start order: 39 > > Component name: OTPD > Enabled: TRUE > Start order: 80 > > Component name: HTTP > Enabled: TRUE > Start order: 40 > ---------------------------- > Number of entries returned 6 > ---------------------------- > > This will allow us to consolidate all the ad-hoc component-related code > scattered throughout IPA (search for enabled component, enable/disable > component, ...) into IPA command calls. > > I'm not opposed to showing a summary in server-show (although we don't do > anything like this for any other hierarchical objects), but it should be done > just for the users' sake, not for internal use (the ticket suggests to use this > for topology visualisation). > > BTW as far as the scalability of the current solution goes, you should have a > list of all the *non*-optional components and display everything else. > > Honza > The API proposal should be in line with our future extensions of the API. We for example want to move "ipa-csreplica-manage" set-renewal-master command to API call. Or DNSSEC generation master. Or we may want to change some other flag/role of a master via this interface. So we will need something like $ ipa server-add-role ipa.example.com --role "ca-renewal-master" or $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master Martin From mbasti at redhat.com Mon Nov 2 11:52:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 12:52:54 +0100 Subject: [Freeipa-devel] [PATCH 0011, 0012, 0015] Replica promotion related changes in integration tests In-Reply-To: <56374101.7000102@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> <5632584A.7070607@redhat.com> <56372F4E.9060805@redhat.com> <56374101.7000102@redhat.com> Message-ID: <56374E96.1080403@redhat.com> On 02.11.2015 11:54, Oleg Fayans wrote: > Hi Martin, > > On 11/02/2015 10:39 AM, Martin Basti wrote: >> >> >> On 29.10.2015 18:32, Martin Basti wrote: >>> >>> >>> On 29.10.2015 18:31, Martin Basti wrote: >>>> NACK >>>> >>>> 1) >>>> DO NOT use tabs in code to indent > Fixed >>>> >>>> 2) >>>> Replica uninstallation does not work, uninstallation works different >>>> with domain level 0 and 1 (currently uninstallation with domain 1 >>>> level will not work, it is known issue, but still the patch should >>>> solve the uninstallation) >> This is not valid, my bad, I was confused with new behaviour of replica >> uninstallation, but it is bug not a feature. >> So replica uninstallation is the same for level 0 and 1 >> Sorry. >>>> >>>> 3) >>>> apply_common_fixes(host) >>>> Method for domain_level 1 is called twice, first time in replica >>>> install, second time in client install > Fixed >>>> >>>> 4) >>>> during testing this patch I used test_simple_replication and I found >>>> 4 bugs: >>> 3 bugs -----------------^^^ >>>> #5419, #5420, #5421 > Bug #5419 fixed, see patch N 15 patch 0015 NACK 1) You fixed just half of the issue, there is also wrong dnsrecord-add 2) I do not think that your solution is the right, it can result in failures when the domain 'my.ipa.domain' is used. I prefer to add '.' to record name and use it as absolute name, dnsrecord-* command will handle it. if not host.hostname.endswith('.'): host.hostname += '{}.'.format(host.hostname) And I would replace dnsrecord-find with dnsrecord-show patches 11, 12 LGTM, I will test them later Martin^2 > >>>> IMO it is related only to this one test case and to pass this test >>>> case #5419 or #5421 must be fixed. >>>> >>>> >>>> On 27.10.2015 16:34, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> The updated patch is attached >>>>> >>>>> On 10/27/2015 01:58 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>>>>> >>>>>>> >>>>>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>>>>>> comments >>>>>>>>>>>> below >>>>>>>>>>> My comments inline, I may be completely wrong in how the test >>>>>>>>>>> suite >>>>>>>>>>> work, so feel free to correct me. >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>> please remove the added empty lines, they are >>>>>>>>>>>>>>>>>> unrelated to >>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>> setup_kra=False): >>>>>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>> setup_kra=False, >>>>>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will >>>>>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So you have to find out way how to pass the domain >>>>>>>>>>>>>>>>>> level for >>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> directive >>>>>>>>>>>>>>>> domain_level >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies >>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>>>>>> require it. >>>>>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>>>>> How about topology CI test? This can be executed only with >>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>> level >>>>>>>>>>>>>> >>>>>>>>>>>>>> That's right. The topology test was updated. Patch is >>>>>>>>>>>>>> attached >>>>>>>>>>>>>> together with a proper version of 11-th patch (not a swap >>>>>>>>>>>>>> file, >>>>>>>>>>>>>> sorry >>>>>>>>>>>>>> about that). >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1, right? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 6) >>>>>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument >>>>>>>>>>>>>>>>> 'raiseonerr' in >>>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>>> call) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1) >>>>>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>> >>>>>>>>>>>>> always use: variable *is not None* >>>>>>>>>>>>> >>>>>>>>>>>>> 2) >>>>>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>>>>> that the >>>>>>>>>>>>> default level is the one which is default in tested package. >>>>>>>>>>>>> These should be None and "": >>>>>>>>>>>>> + "domain_level": "1" >>>>>>>>>>>>> >>>>>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>>>>> >>>>>>>>>>>>> 3) >>>>>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>>>>> pytest.fixture >>>>>>>>>>>>> needs >>>>>>>>>>>>> to know the value of domain level before we can do any >>>>>>>>>>>>> dynamic >>>>>>>>>>>>> detection >>>>>>>>>>>>> on master. >>>>>>>>>>>>> >>>>>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>>>>>> for 2) >>>>>>>>>>>> Done >>>>>>>>>>>>> >>>>>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this >>>>>>>>>>>>> part >>>>>>>>>>>>> you >>>>>>>>>>>>> need default value, or the fixture will not work as expected. >>>>>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>>> >>>>>>>>>>>> This won't work in cases when domainlevel is explicitly set >>>>>>>>>>>> to 0 in >>>>>>>>>>>> config.yaml. This default value will always override the >>>>>>>>>>>> explicit >>>>>>>>>>>> one. >>>>>>>>>>> wat? in case that kwargs is dict containing values from config >>>>>>>>>>> file: >>>>>>>>>>> >>>>>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>>>>> >>>>>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>>>>> Out[2]: 0 >>>>>>>>> >>>>>>>>> Yep, right you are, it works as expected. Now the line looks >>>>>>>>> like: >>>>>>>>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Respectively you should use this: >>>>>>>>>> >>>>>>>>>> self.domain_level = kwargs.get('domain_level')or >>>>>>>>>> MAX_DOMAIN_LEVEL >>>>>>>>> Now that would definitely not work in case of domain_level is 0: >>>>>>>>> 0 or 1 is always 1 >>>>>>>> Oh right. >>>>>>>> >>>>>>>> I had discussion with Tomas, and we should add there check if it >>>>>>>> is not >>>>>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>>>>> does not >>>>>>>> know with test when the None value appears there) >>>>>>> >>>>>>> I do not get this. If we do not specify domain_level in >>>>>>> config.yaml, >>>>>>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. >>>>>>> That >>>>>>> means domain_level will never ever possibly be None. >>>>>> I do not know how pytest works inside, if you are 100% sure, that >>>>>> the >>>>>> case written above cannot happen, I'm fine with it. >>>>>> Martin >>>>>>> >>>>>>>> >>>>>>>> self.domain_level = kwargs.get('domain_level') >>>>>>>> if self.domain_level is None: >>>>>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>>>>> >>>>>>>> As we cannot user 'or' expression with integers, so this is the >>>>>>>> right >>>>>>>> way. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> because kwargs IMO contains undefined config values as None >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>>>>> should be >>>>>>>>>>>>> available in tests. >>>>>>>>>>>>> >>>>>>>>>>>>> So then you also need update this line >>>>>>>>>>>>> >>>>>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>> >>>>>>>>>>>> This would not work if domainlevel is not set in >>>>>>>>>>>> config.yaml, in >>>>>>>>>>>> which case the host.config.domain_level is None. >>>>>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 4) >>>>>>>>>>>>> Please add comment to function +def domainlevel(host): that >>>>>>>>>>>>> it is >>>>>>>>>>>>> useful >>>>>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>>>>> otherwise it >>>>>>>>>>>>> may >>>>>>>>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>>>>>>>> unneeded >>>>>>>>>>>>> and replace it with config dict. >>>>>>>>>>>> Done >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>>>>> >>>>>>>>>>>>> Martin^2 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mbabinsk at redhat.com Mon Nov 2 11:56:20 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 2 Nov 2015 12:56:20 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <56334C29.5070305@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <562E1F8A.8030202@redhat.com> <56334C29.5070305@redhat.com> Message-ID: <56374F64.2040109@redhat.com> On 10/30/2015 11:53 AM, Martin Babinsky wrote: > On 10/26/2015 01:41 PM, Martin Babinsky wrote: >> On 10/22/2015 04:13 PM, Martin Basti wrote: >>> >>> >>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5181 >>>> >>>> >>>> >>> >>> Thank you for the patch. >>> >>> 1) >>> +OPTIONAL_SERVICES = { >>> + 'DNS', >>> + 'CA', >>> + 'KRA', >>> + 'ADTRUST', >>> + 'EXTID', >>> + 'DNSKeyExporter', >>> + 'DNSSEC', >>> + 'DNSKeySync', >>> +} >>> >>> This did not scale well, maybe we should improve it to use some general >>> solution for whole IPA to distinct mandratory and optionl service, but I >>> do not know how (or if it is possible) >>> >> Yes this does not scale well. After some playing around with relocating >> the SERVICE_LIST object in 'ipaserver/install/service.py' I found out >> that more refactoring would be needed to improve the layout and >> availability of LDAP service names to both server and client code. I >> have put the list of core services to ipalib/constants.py for now, and I >> suggest to open a separate ticket for more general solution. >> >>> 2) >>> + search_filter=('(&(objectclass=ipaConfigObject)' >>> + '(ipaConfigString=enabledService))') >>> >>> Common user cannot read ipaConfigString, so this will work only for >>> admins, I do not see any limitations of access in code for other users. >>> >> >> I think that you agreed with Petr^2 that this filter is OK. I left it as >> it is but I have rewritten it as a call to ldap.make_filter to improve >> readability and/or potential extensibility a bit. >> >>> 3) >>> + opt_components = [ >>> + r['cn'][0] for r in result if r['cn'][0] in >>> OPTIONAL_SERVICES >>> + ] >>> Probably instead of indexing, you may use result.single_value['cn'] >>> >>> Martin^2 >> >> Attaching updated patch. >> >> >> > Self-NACK, I found a bug in the patch during work on topology management > stuff. > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0090.2-show-optionally-configured-components-in-server-find.patch Type: text/x-patch Size: 3506 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 2 12:32:24 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 13:32:24 +0100 Subject: [Freeipa-devel] [PATCH 0339] ipa-csreplica-manage: disable connect/disconnect/del subcommands In-Reply-To: <5633837E.9010100@redhat.com> References: <56336C1B.6070807@redhat.com> <5633756E.50609@redhat.com> <5633831B.7010007@redhat.com> <5633837E.9010100@redhat.com> Message-ID: <563757D8.2070909@redhat.com> On 30.10.2015 15:49, Martin Babinsky wrote: > On 10/30/2015 03:47 PM, Martin Basti wrote: >> >> >> On 30.10.2015 14:49, Martin Babinsky wrote: >>> On 10/30/2015 02:09 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5405 >>>> >>>> >>>> Patch attached >>>> >>>> >>> Hi Martin, >>> >>> NACK since I'm not a big fan of having (nearly) the same function >>> defined in multiple modules: >>> >>> """ >>> $ git grep -n 'def exit_on_managed_topology' >>> install/tools/ipa-csreplica-manage:397:def >>> exit_on_managed_topology(what, hint="topologysegment"): >>> install/tools/ipa-replica-manage:1386:def >>> exit_on_managed_topology(what): >>> """ >>> >>> Otherwise the patch works fine. >>> >> I tried to do that, but I could not find any suitable module for that, >> and the method do just exit() with proper error message, thus it can be >> just copy paste (as ipa-csreplica-manage is full of it). > Yes it is a nice plate of copypasta anyway. > > ACK then. > Pushed to master: 6119dbb9a915283434f718b38a70017e3ad00840 From mbasti at redhat.com Mon Nov 2 12:38:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 13:38:42 +0100 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <56122516.3090402@redhat.com> References: <55D0AC54.6040401@redhat.com> <55D44A4E.7080805@redhat.com> <55D57CDF.6070709@redhat.com> <55DE502E.3030200@redhat.com> <560E8559.2060107@redhat.com> <56122516.3090402@redhat.com> Message-ID: <56375952.9050304@redhat.com> On 05.10.2015 09:21, Jan Cholasta wrote: > On 2.10.2015 15:23, Martin Basti wrote: >> >> >> On 08/27/2015 01:47 AM, Endi Sukma Dewata wrote: >>> On 8/20/2015 2:08 AM, Endi Sukma Dewata wrote: >>>> On 8/19/2015 4:20 AM, Martin Basti wrote: >>>>> On 08/16/2015 05:29 PM, Endi Sukma Dewata wrote: >>>>>> The vault-add and vault-archive commands have been modified to >>>>>> optionally retrieve a secret from a source vault, then re-archive >>>>>> the secret into the new/existing target vault. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5223 >>>>>> >>>>>> >>>>>> >>>>> I cannot apply this patch. >>>> >>>> Rebased. It depends on patch #371-2. >>> >>> Rebased due to other changes in vault. >>> >> >> Code works for me, but wouldn't be better to create a new command, >> Endi what do you think? >> something like vault-copy, instead of adding new options to existing >> command? > > +1 > Endi, what do you think about the proposed change? From abokovoy at redhat.com Mon Nov 2 12:50:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Nov 2015 14:50:56 +0200 Subject: [Freeipa-devel] [PATCH] 925 Update .po files In-Reply-To: <5637495E.8010900@redhat.com> References: <5637495E.8010900@redhat.com> Message-ID: <20151102125056.GG8374@redhat.com> On Mon, 02 Nov 2015, Petr Vobornik wrote: >For 4.2.3 release > >https://fedorahosted.org/freeipa/ticket/5427 > >target branches: master, ipa-4-2 >-- >Petr Vobornik >From 07e0ceff02932f1c8db1591be560a2b1745335d8 Mon Sep 17 00:00:00 2001 >From: Petr Vobornik >Date: Mon, 2 Nov 2015 12:24:58 +0100 >Subject: [PATCH] Update .po files > >https://fedorahosted.org/freeipa/ticket/5427 >--- > install/po/bn_IN.po | 2 +- > install/po/ca.po | 2 +- > install/po/cs.po | 2 +- > install/po/de.po | 1129 ++++++++++++++++++++++++++++++++- > install/po/es.po | 2 +- > install/po/eu.po | 2 +- > install/po/fr.po | 1731 ++++++++++++++++++++++++++++++++++++++++++++++----- > install/po/hi.po | 2 +- > install/po/hu.po | 2 +- > install/po/id.po | 2 +- > install/po/ja.po | 2 +- > install/po/kn.po | 2 +- > install/po/nl.po | 2 +- > install/po/pl.po | 2 +- > install/po/ru.po | 779 ++++++++++++++++++++++- > install/po/tg.po | 2 +- > install/po/uk.po | 4 +- > install/po/zh_CN.po | 2 +- > 18 files changed, 3499 insertions(+), 172 deletions(-) ACK. -- / Alexander Bokovoy From ofayans at redhat.com Mon Nov 2 13:45:07 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 2 Nov 2015 14:45:07 +0100 Subject: [Freeipa-devel] [PATCH 0011, 0012, 0015] Replica promotion related changes in integration tests In-Reply-To: <56374E96.1080403@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> <5632584A.7070607@redhat.com> <56372F4E.9060805@redhat.com> <56374101.7000102@redhat.com> <56374E96.1080403@redhat.com> Message-ID: <563768E3.3020204@redhat.com> Hi Martin, On 11/02/2015 12:52 PM, Martin Basti wrote: > > > On 02.11.2015 11:54, Oleg Fayans wrote: >> Hi Martin, >> >> On 11/02/2015 10:39 AM, Martin Basti wrote: >>> >>> >>> On 29.10.2015 18:32, Martin Basti wrote: >>>> >>>> >>>> On 29.10.2015 18:31, Martin Basti wrote: >>>>> NACK >>>>> >>>>> 1) >>>>> DO NOT use tabs in code to indent >> Fixed >>>>> >>>>> 2) >>>>> Replica uninstallation does not work, uninstallation works different >>>>> with domain level 0 and 1 (currently uninstallation with domain 1 >>>>> level will not work, it is known issue, but still the patch should >>>>> solve the uninstallation) >>> This is not valid, my bad, I was confused with new behaviour of replica >>> uninstallation, but it is bug not a feature. >>> So replica uninstallation is the same for level 0 and 1 >>> Sorry. >>>>> >>>>> 3) >>>>> apply_common_fixes(host) >>>>> Method for domain_level 1 is called twice, first time in replica >>>>> install, second time in client install >> Fixed >>>>> >>>>> 4) >>>>> during testing this patch I used test_simple_replication and I found >>>>> 4 bugs: >>>> 3 bugs -----------------^^^ >>>>> #5419, #5420, #5421 >> Bug #5419 fixed, see patch N 15 > > patch 0015 NACK > > 1) > You fixed just half of the issue, there is also wrong dnsrecord-add > > 2) > I do not think that your solution is the right, it can result in > failures when the domain 'my.ipa.domain' is used. > > I prefer to add '.' to record name and use it as absolute name, > dnsrecord-* command will handle it. That's a good point. The problem though, is that dnsrecord-add handles it correctly, while dnsrecord-find - does not. $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com. vm-002.idm.lab.eng.brq.redhat.com. --a-rec 192.168.254.2 Record name: vm-002 A record: 192.168.254.2 $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. vm-001.idm.lab.eng.brq.redhat.com. ---------------------------- Number of entries returned 0 ---------------------------- $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. vm-001 Record name: vm-001 A record: 192.168.254.1 ---------------------------- Number of entries returned 1 ---------------------------- Should I file a ticket against it? > > if not host.hostname.endswith('.'): > host.hostname += '{}.'.format(host.hostname) > > And I would replace dnsrecord-find with dnsrecord-show > > patches 11, 12 LGTM, I will test them later > > Martin^2 >> >>>>> IMO it is related only to this one test case and to pass this test >>>>> case #5419 or #5421 must be fixed. >>>>> >>>>> >>>>> On 27.10.2015 16:34, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> The updated patch is attached >>>>>> >>>>>> On 10/27/2015 01:58 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>>>>>>> comments >>>>>>>>>>>>> below >>>>>>>>>>>> My comments inline, I may be completely wrong in how the test >>>>>>>>>>>> suite >>>>>>>>>>>> work, so feel free to correct me. >>>>>>>>>>>> >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>>> please remove the added empty lines, they are >>>>>>>>>>>>>>>>>>> unrelated to >>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>> setup_kra=False): >>>>>>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>> setup_kra=False, >>>>>>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will >>>>>>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So you have to find out way how to pass the domain >>>>>>>>>>>>>>>>>>> level for >>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> directive >>>>>>>>>>>>>>>>> domain_level >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies >>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>>>>>>> require it. >>>>>>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>>>>>> How about topology CI test? This can be executed only with >>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That's right. The topology test was updated. Patch is >>>>>>>>>>>>>>> attached >>>>>>>>>>>>>>> together with a proper version of 11-th patch (not a swap >>>>>>>>>>>>>>> file, >>>>>>>>>>>>>>> sorry >>>>>>>>>>>>>>> about that). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1, right? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 6) >>>>>>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument >>>>>>>>>>>>>>>>>> 'raiseonerr' in >>>>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>>>> call) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>>> >>>>>>>>>>>>>> always use: variable *is not None* >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) >>>>>>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>>>>>> that the >>>>>>>>>>>>>> default level is the one which is default in tested package. >>>>>>>>>>>>>> These should be None and "": >>>>>>>>>>>>>> + "domain_level": "1" >>>>>>>>>>>>>> >>>>>>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) >>>>>>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>>>>>> pytest.fixture >>>>>>>>>>>>>> needs >>>>>>>>>>>>>> to know the value of domain level before we can do any >>>>>>>>>>>>>> dynamic >>>>>>>>>>>>>> detection >>>>>>>>>>>>>> on master. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>>>>>>> for 2) >>>>>>>>>>>>> Done >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this >>>>>>>>>>>>>> part >>>>>>>>>>>>>> you >>>>>>>>>>>>>> need default value, or the fixture will not work as expected. >>>>>>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>>>> >>>>>>>>>>>>> This won't work in cases when domainlevel is explicitly set >>>>>>>>>>>>> to 0 in >>>>>>>>>>>>> config.yaml. This default value will always override the >>>>>>>>>>>>> explicit >>>>>>>>>>>>> one. >>>>>>>>>>>> wat? in case that kwargs is dict containing values from config >>>>>>>>>>>> file: >>>>>>>>>>>> >>>>>>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>>>>>> >>>>>>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>>>>>> Out[2]: 0 >>>>>>>>>> >>>>>>>>>> Yep, right you are, it works as expected. Now the line looks >>>>>>>>>> like: >>>>>>>>>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Respectively you should use this: >>>>>>>>>>> >>>>>>>>>>> self.domain_level = kwargs.get('domain_level')or >>>>>>>>>>> MAX_DOMAIN_LEVEL >>>>>>>>>> Now that would definitely not work in case of domain_level is 0: >>>>>>>>>> 0 or 1 is always 1 >>>>>>>>> Oh right. >>>>>>>>> >>>>>>>>> I had discussion with Tomas, and we should add there check if it >>>>>>>>> is not >>>>>>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>>>>>> does not >>>>>>>>> know with test when the None value appears there) >>>>>>>> >>>>>>>> I do not get this. If we do not specify domain_level in >>>>>>>> config.yaml, >>>>>>>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. >>>>>>>> That >>>>>>>> means domain_level will never ever possibly be None. >>>>>>> I do not know how pytest works inside, if you are 100% sure, that >>>>>>> the >>>>>>> case written above cannot happen, I'm fine with it. >>>>>>> Martin >>>>>>>> >>>>>>>>> >>>>>>>>> self.domain_level = kwargs.get('domain_level') >>>>>>>>> if self.domain_level is None: >>>>>>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>>>>>> >>>>>>>>> As we cannot user 'or' expression with integers, so this is the >>>>>>>>> right >>>>>>>>> way. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> because kwargs IMO contains undefined config values as None >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> available in tests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So then you also need update this line >>>>>>>>>>>>>> >>>>>>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>> >>>>>>>>>>>>> This would not work if domainlevel is not set in >>>>>>>>>>>>> config.yaml, in >>>>>>>>>>>>> which case the host.config.domain_level is None. >>>>>>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4) >>>>>>>>>>>>>> Please add comment to function +def domainlevel(host): that >>>>>>>>>>>>>> it is >>>>>>>>>>>>>> useful >>>>>>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>>>>>> otherwise it >>>>>>>>>>>>>> may >>>>>>>>>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>>>>>>>>> unneeded >>>>>>>>>>>>>> and replace it with config dict. >>>>>>>>>>>>> Done >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From edewata at redhat.com Mon Nov 2 14:39:18 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 2 Nov 2015 08:39:18 -0600 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <56375952.9050304@redhat.com> References: <55D0AC54.6040401@redhat.com> <55D44A4E.7080805@redhat.com> <55D57CDF.6070709@redhat.com> <55DE502E.3030200@redhat.com> <560E8559.2060107@redhat.com> <56122516.3090402@redhat.com> <56375952.9050304@redhat.com> Message-ID: <56377596.1020603@redhat.com> On 11/2/2015 6:38 AM, Martin Basti wrote: >>>>>>> The vault-add and vault-archive commands have been modified to >>>>>>> optionally retrieve a secret from a source vault, then re-archive >>>>>>> the secret into the new/existing target vault. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5223 >>>>>>> >>>>>>> >>>>>>> >>>>>> I cannot apply this patch. >>>>> >>>>> Rebased. It depends on patch #371-2. >>>> >>>> Rebased due to other changes in vault. >>>> >>> >>> Code works for me, but wouldn't be better to create a new command, >>> Endi what do you think? >>> something like vault-copy, instead of adding new options to existing >>> command? >> >> +1 >> > Endi, what do you think about the proposed change? Sorry, I'm still handling an IPA customer issue. The vault-copy is fine. I think ideally a copy command should look like this: $ ipa vault-copy But since generally the IPA command arguments are used to specify an object hierarchy (e.g. ), I'm not sure if the above format would be consistent with other IPA commands. -- Endi S. Dewata From mbasti at redhat.com Mon Nov 2 14:45:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 15:45:10 +0100 Subject: [Freeipa-devel] [PATCH 0011, 0012, 0015] Replica promotion related changes in integration tests In-Reply-To: <563768E3.3020204@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> <5632584A.7070607@redhat.com> <56372F4E.9060805@redhat.com> <56374101.7000102@redhat.com> <56374E96.1080403@redhat.com> <563768E3.3020204@redhat.com> Message-ID: <563776F6.6070804@redhat.com> On 02.11.2015 14:45, Oleg Fayans wrote: > Hi Martin, > > On 11/02/2015 12:52 PM, Martin Basti wrote: >> >> >> On 02.11.2015 11:54, Oleg Fayans wrote: >>> Hi Martin, >>> >>> On 11/02/2015 10:39 AM, Martin Basti wrote: >>>> >>>> >>>> On 29.10.2015 18:32, Martin Basti wrote: >>>>> >>>>> >>>>> On 29.10.2015 18:31, Martin Basti wrote: >>>>>> NACK >>>>>> >>>>>> 1) >>>>>> DO NOT use tabs in code to indent >>> Fixed >>>>>> >>>>>> 2) >>>>>> Replica uninstallation does not work, uninstallation works different >>>>>> with domain level 0 and 1 (currently uninstallation with domain 1 >>>>>> level will not work, it is known issue, but still the patch should >>>>>> solve the uninstallation) >>>> This is not valid, my bad, I was confused with new behaviour of >>>> replica >>>> uninstallation, but it is bug not a feature. >>>> So replica uninstallation is the same for level 0 and 1 >>>> Sorry. >>>>>> >>>>>> 3) >>>>>> apply_common_fixes(host) >>>>>> Method for domain_level 1 is called twice, first time in replica >>>>>> install, second time in client install >>> Fixed >>>>>> >>>>>> 4) >>>>>> during testing this patch I used test_simple_replication and I found >>>>>> 4 bugs: >>>>> 3 bugs -----------------^^^ >>>>>> #5419, #5420, #5421 >>> Bug #5419 fixed, see patch N 15 >> >> patch 0015 NACK >> >> 1) >> You fixed just half of the issue, there is also wrong dnsrecord-add >> >> 2) >> I do not think that your solution is the right, it can result in >> failures when the domain 'my.ipa.domain' is used. >> >> I prefer to add '.' to record name and use it as absolute name, >> dnsrecord-* command will handle it. > That's a good point. The problem though, is that dnsrecord-add handles > it correctly, while dnsrecord-find - does not. > > $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com. > vm-002.idm.lab.eng.brq.redhat.com. --a-rec 192.168.254.2 > Record name: vm-002 > A record: 192.168.254.2 > > $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. > vm-001.idm.lab.eng.brq.redhat.com. > ---------------------------- > Number of entries returned 0 > ---------------------------- > > $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. vm-001 > Record name: vm-001 > A record: 192.168.254.1 > ---------------------------- > Number of entries returned 1 > ---------------------------- > > Should I file a ticket against it? > I do not think that this is a bug, dnsrecord-find does search in multiple attributes not only in record names I suggest to use dnsrecord-show instead of dnsrecord-find > >> >> if not host.hostname.endswith('.'): >> host.hostname += '{}.'.format(host.hostname) >> >> And I would replace dnsrecord-find with dnsrecord-show >> >> patches 11, 12 LGTM, I will test them later >> >> Martin^2 >>> >>>>>> IMO it is related only to this one test case and to pass this test >>>>>> case #5419 or #5421 must be fixed. >>>>>> >>>>>> >>>>>> On 27.10.2015 16:34, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> The updated patch is attached >>>>>>> >>>>>>> On 10/27/2015 01:58 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>>>>>>>> comments >>>>>>>>>>>>>> below >>>>>>>>>>>>> My comments inline, I may be completely wrong in how the test >>>>>>>>>>>>> suite >>>>>>>>>>>>> work, so feel free to correct me. >>>>>>>>>>>>> >>>>>>>>>>>>> Martin >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>>>> please remove the added empty lines, they are >>>>>>>>>>>>>>>>>>>> unrelated to >>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>>> setup_kra=False): >>>>>>>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>>> setup_kra=False, >>>>>>>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will >>>>>>>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA >>>>>>>>>>>>>>>>>>>> 4.3, >>>>>>>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>>>>>> independent on IPA version, only admin can raise it >>>>>>>>>>>>>>>>>>>> up. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So you have to find out way how to pass the domain >>>>>>>>>>>>>>>>>>>> level for >>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>> test will be running, we were talking about using >>>>>>>>>>>>>>>>>>>> config >>>>>>>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> directive >>>>>>>>>>>>>>>>>> domain_level >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies >>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>>>>>>>> require it. >>>>>>>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>>>>>>> How about topology CI test? This can be executed only >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That's right. The topology test was updated. Patch is >>>>>>>>>>>>>>>> attached >>>>>>>>>>>>>>>> together with a proper version of 11-th patch (not a swap >>>>>>>>>>>>>>>> file, >>>>>>>>>>>>>>>> sorry >>>>>>>>>>>>>>>> about that). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1, right? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 6) >>>>>>>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument >>>>>>>>>>>>>>>>>>> 'raiseonerr' in >>>>>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>>>>> call) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> always use: variable *is not None* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>> default level is the one which is default in tested >>>>>>>>>>>>>>> package. >>>>>>>>>>>>>>> These should be None and "": >>>>>>>>>>>>>>> + "domain_level": "1" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>>>>>>> pytest.fixture >>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>> to know the value of domain level before we can do any >>>>>>>>>>>>>>> dynamic >>>>>>>>>>>>>>> detection >>>>>>>>>>>>>>> on master. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>>>>>>>> for 2) >>>>>>>>>>>>>> Done >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this >>>>>>>>>>>>>>> part >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>> need default value, or the fixture will not work as >>>>>>>>>>>>>>> expected. >>>>>>>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>>>>> >>>>>>>>>>>>>> This won't work in cases when domainlevel is explicitly set >>>>>>>>>>>>>> to 0 in >>>>>>>>>>>>>> config.yaml. This default value will always override the >>>>>>>>>>>>>> explicit >>>>>>>>>>>>>> one. >>>>>>>>>>>>> wat? in case that kwargs is dict containing values from >>>>>>>>>>>>> config >>>>>>>>>>>>> file: >>>>>>>>>>>>> >>>>>>>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>>>>>>> >>>>>>>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>>>>>>> Out[2]: 0 >>>>>>>>>>> >>>>>>>>>>> Yep, right you are, it works as expected. Now the line looks >>>>>>>>>>> like: >>>>>>>>>>> self.domain_level = kwargs.get('domain_level', >>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Respectively you should use this: >>>>>>>>>>>> >>>>>>>>>>>> self.domain_level = kwargs.get('domain_level')or >>>>>>>>>>>> MAX_DOMAIN_LEVEL >>>>>>>>>>> Now that would definitely not work in case of domain_level >>>>>>>>>>> is 0: >>>>>>>>>>> 0 or 1 is always 1 >>>>>>>>>> Oh right. >>>>>>>>>> >>>>>>>>>> I had discussion with Tomas, and we should add there check if it >>>>>>>>>> is not >>>>>>>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>>>>>>> does not >>>>>>>>>> know with test when the None value appears there) >>>>>>>>> >>>>>>>>> I do not get this. If we do not specify domain_level in >>>>>>>>> config.yaml, >>>>>>>>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. >>>>>>>>> That >>>>>>>>> means domain_level will never ever possibly be None. >>>>>>>> I do not know how pytest works inside, if you are 100% sure, that >>>>>>>> the >>>>>>>> case written above cannot happen, I'm fine with it. >>>>>>>> Martin >>>>>>>>> >>>>>>>>>> >>>>>>>>>> self.domain_level = kwargs.get('domain_level') >>>>>>>>>> if self.domain_level is None: >>>>>>>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>>>>>>> >>>>>>>>>> As we cannot user 'or' expression with integers, so this is the >>>>>>>>>> right >>>>>>>>>> way. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> because kwargs IMO contains undefined config values as None >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>> available in tests. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So then you also need update this line >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>>> >>>>>>>>>>>>>> This would not work if domainlevel is not set in >>>>>>>>>>>>>> config.yaml, in >>>>>>>>>>>>>> which case the host.config.domain_level is None. >>>>>>>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>> Please add comment to function +def domainlevel(host): that >>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>> useful >>>>>>>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>>>>>>> otherwise it >>>>>>>>>>>>>>> may >>>>>>>>>>>>>>> be lost after test refactoring as somebody may consider >>>>>>>>>>>>>>> it as >>>>>>>>>>>>>>> unneeded >>>>>>>>>>>>>>> and replace it with config dict. >>>>>>>>>>>>>> Done >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From abokovoy at redhat.com Mon Nov 2 14:46:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Nov 2015 16:46:32 +0200 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <56377596.1020603@redhat.com> References: <55D0AC54.6040401@redhat.com> <55D44A4E.7080805@redhat.com> <55D57CDF.6070709@redhat.com> <55DE502E.3030200@redhat.com> <560E8559.2060107@redhat.com> <56122516.3090402@redhat.com> <56375952.9050304@redhat.com> <56377596.1020603@redhat.com> Message-ID: <20151102144632.GK8374@redhat.com> On Mon, 02 Nov 2015, Endi Sukma Dewata wrote: >On 11/2/2015 6:38 AM, Martin Basti wrote: >>>>>>>>The vault-add and vault-archive commands have been modified to >>>>>>>>optionally retrieve a secret from a source vault, then re-archive >>>>>>>>the secret into the new/existing target vault. >>>>>>>> >>>>>>>>https://fedorahosted.org/freeipa/ticket/5223 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>I cannot apply this patch. >>>>>> >>>>>>Rebased. It depends on patch #371-2. >>>>> >>>>>Rebased due to other changes in vault. >>>>> >>>> >>>>Code works for me, but wouldn't be better to create a new command, >>>>Endi what do you think? >>>>something like vault-copy, instead of adding new options to existing >>>>command? >>> >>>+1 >>> >>Endi, what do you think about the proposed change? > >Sorry, I'm still handling an IPA customer issue. The vault-copy is >fine. I think ideally a copy command should look like this: > > $ ipa vault-copy > >But since generally the IPA command arguments are used to specify an >object hierarchy (e.g. ), I'm >not sure if the above format would be consistent with other IPA >commands. It is not really enforced and 'ipa vault-copy source destination' is reasonable and logical, so it makes sense to implement the command this way. -- / Alexander Bokovoy From ofayans at redhat.com Mon Nov 2 15:05:20 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 2 Nov 2015 16:05:20 +0100 Subject: [Freeipa-devel] [PATCH 0011, 0012, 0015] Replica promotion related changes in integration tests In-Reply-To: <563776F6.6070804@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> <5632584A.7070607@redhat.com> <56372F4E.9060805@redhat.com> <56374101.7000102@redhat.com> <56374E96.1080403@redhat.com> <563768E3.3020204@redhat.com> <563776F6.6070804@redhat.com> Message-ID: <56377BB0.7000209@redhat.com> On 11/02/2015 03:45 PM, Martin Basti wrote: > > > On 02.11.2015 14:45, Oleg Fayans wrote: >> Hi Martin, >> >> On 11/02/2015 12:52 PM, Martin Basti wrote: >>> >>> >>> On 02.11.2015 11:54, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> On 11/02/2015 10:39 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 29.10.2015 18:32, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 29.10.2015 18:31, Martin Basti wrote: >>>>>>> NACK >>>>>>> >>>>>>> 1) >>>>>>> DO NOT use tabs in code to indent >>>> Fixed >>>>>>> >>>>>>> 2) >>>>>>> Replica uninstallation does not work, uninstallation works different >>>>>>> with domain level 0 and 1 (currently uninstallation with domain 1 >>>>>>> level will not work, it is known issue, but still the patch should >>>>>>> solve the uninstallation) >>>>> This is not valid, my bad, I was confused with new behaviour of >>>>> replica >>>>> uninstallation, but it is bug not a feature. >>>>> So replica uninstallation is the same for level 0 and 1 >>>>> Sorry. >>>>>>> >>>>>>> 3) >>>>>>> apply_common_fixes(host) >>>>>>> Method for domain_level 1 is called twice, first time in replica >>>>>>> install, second time in client install >>>> Fixed >>>>>>> >>>>>>> 4) >>>>>>> during testing this patch I used test_simple_replication and I found >>>>>>> 4 bugs: >>>>>> 3 bugs -----------------^^^ >>>>>>> #5419, #5420, #5421 >>>> Bug #5419 fixed, see patch N 15 >>> >>> patch 0015 NACK >>> >>> 1) >>> You fixed just half of the issue, there is also wrong dnsrecord-add >>> >>> 2) >>> I do not think that your solution is the right, it can result in >>> failures when the domain 'my.ipa.domain' is used. >>> >>> I prefer to add '.' to record name and use it as absolute name, >>> dnsrecord-* command will handle it. Done >> That's a good point. The problem though, is that dnsrecord-add handles >> it correctly, while dnsrecord-find - does not. >> >> $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com. >> vm-002.idm.lab.eng.brq.redhat.com. --a-rec 192.168.254.2 >> Record name: vm-002 >> A record: 192.168.254.2 >> >> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. >> vm-001.idm.lab.eng.brq.redhat.com. >> ---------------------------- >> Number of entries returned 0 >> ---------------------------- >> >> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. vm-001 >> Record name: vm-001 >> A record: 192.168.254.1 >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> Should I file a ticket against it? >> > I do not think that this is a bug, dnsrecord-find does search in > multiple attributes not only in record names > > I suggest to use dnsrecord-show instead of dnsrecord-find >> >>> >>> if not host.hostname.endswith('.'): >>> host.hostname += '{}.'.format(host.hostname) >>> >>> And I would replace dnsrecord-find with dnsrecord-show >>> >>> patches 11, 12 LGTM, I will test them later >>> >>> Martin^2 >>>> >>>>>>> IMO it is related only to this one test case and to pass this test >>>>>>> case #5419 or #5421 must be fixed. >>>>>>> >>>>>>> >>>>>>> On 27.10.2015 16:34, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> The updated patch is attached >>>>>>>> >>>>>>>> On 10/27/2015 01:58 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>>>>>>>>> comments >>>>>>>>>>>>>>> below >>>>>>>>>>>>>> My comments inline, I may be completely wrong in how the test >>>>>>>>>>>>>> suite >>>>>>>>>>>>>> work, so feel free to correct me. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Martin >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>>>>> please remove the added empty lines, they are >>>>>>>>>>>>>>>>>>>>> unrelated to >>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>>>> setup_kra=False): >>>>>>>>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>>>> setup_kra=False, >>>>>>>>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will >>>>>>>>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA >>>>>>>>>>>>>>>>>>>>> 4.3, >>>>>>>>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>>>>>>> independent on IPA version, only admin can raise it >>>>>>>>>>>>>>>>>>>>> up. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> So you have to find out way how to pass the domain >>>>>>>>>>>>>>>>>>>>> level for >>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>> test will be running, we were talking about using >>>>>>>>>>>>>>>>>>>>> config >>>>>>>>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> directive >>>>>>>>>>>>>>>>>>> domain_level >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies >>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>>>>>>>>> require it. >>>>>>>>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>>>>>>>> How about topology CI test? This can be executed only >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That's right. The topology test was updated. Patch is >>>>>>>>>>>>>>>>> attached >>>>>>>>>>>>>>>>> together with a proper version of 11-th patch (not a swap >>>>>>>>>>>>>>>>> file, >>>>>>>>>>>>>>>>> sorry >>>>>>>>>>>>>>>>> about that). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1, right? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 6) >>>>>>>>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument >>>>>>>>>>>>>>>>>>>> 'raiseonerr' in >>>>>>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>>>>>> call) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> always use: variable *is not None* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>> default level is the one which is default in tested >>>>>>>>>>>>>>>> package. >>>>>>>>>>>>>>>> These should be None and "": >>>>>>>>>>>>>>>> + "domain_level": "1" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>>>>>>>> pytest.fixture >>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>> to know the value of domain level before we can do any >>>>>>>>>>>>>>>> dynamic >>>>>>>>>>>>>>>> detection >>>>>>>>>>>>>>>> on master. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>>>>>>>>> for 2) >>>>>>>>>>>>>>> Done >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this >>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>> need default value, or the fixture will not work as >>>>>>>>>>>>>>>> expected. >>>>>>>>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This won't work in cases when domainlevel is explicitly set >>>>>>>>>>>>>>> to 0 in >>>>>>>>>>>>>>> config.yaml. This default value will always override the >>>>>>>>>>>>>>> explicit >>>>>>>>>>>>>>> one. >>>>>>>>>>>>>> wat? in case that kwargs is dict containing values from >>>>>>>>>>>>>> config >>>>>>>>>>>>>> file: >>>>>>>>>>>>>> >>>>>>>>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>>>>>>>> >>>>>>>>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>>>>>>>> Out[2]: 0 >>>>>>>>>>>> >>>>>>>>>>>> Yep, right you are, it works as expected. Now the line looks >>>>>>>>>>>> like: >>>>>>>>>>>> self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Respectively you should use this: >>>>>>>>>>>>> >>>>>>>>>>>>> self.domain_level = kwargs.get('domain_level')or >>>>>>>>>>>>> MAX_DOMAIN_LEVEL >>>>>>>>>>>> Now that would definitely not work in case of domain_level >>>>>>>>>>>> is 0: >>>>>>>>>>>> 0 or 1 is always 1 >>>>>>>>>>> Oh right. >>>>>>>>>>> >>>>>>>>>>> I had discussion with Tomas, and we should add there check if it >>>>>>>>>>> is not >>>>>>>>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>>>>>>>> does not >>>>>>>>>>> know with test when the None value appears there) >>>>>>>>>> >>>>>>>>>> I do not get this. If we do not specify domain_level in >>>>>>>>>> config.yaml, >>>>>>>>>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. >>>>>>>>>> That >>>>>>>>>> means domain_level will never ever possibly be None. >>>>>>>>> I do not know how pytest works inside, if you are 100% sure, that >>>>>>>>> the >>>>>>>>> case written above cannot happen, I'm fine with it. >>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> self.domain_level = kwargs.get('domain_level') >>>>>>>>>>> if self.domain_level is None: >>>>>>>>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>>>>>>>> >>>>>>>>>>> As we cannot user 'or' expression with integers, so this is the >>>>>>>>>>> right >>>>>>>>>>> way. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> because kwargs IMO contains undefined config values as None >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>>> available in tests. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So then you also need update this line >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This would not work if domainlevel is not set in >>>>>>>>>>>>>>> config.yaml, in >>>>>>>>>>>>>>> which case the host.config.domain_level is None. >>>>>>>>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>> Please add comment to function +def domainlevel(host): that >>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>> useful >>>>>>>>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>>>>>>>> otherwise it >>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>> be lost after test refactoring as somebody may consider >>>>>>>>>>>>>>>> it as >>>>>>>>>>>>>>>> unneeded >>>>>>>>>>>>>>>> and replace it with config dict. >>>>>>>>>>>>>>> Done >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0015.1-Fixed-A-record-creation-bug.patch Type: text/x-patch Size: 1654 bytes Desc: not available URL: From abokovoy at redhat.com Mon Nov 2 17:09:31 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Nov 2015 19:09:31 +0200 Subject: [Freeipa-devel] [PATCH] 0198 depend on dogtag 10.2.6-12 for tomcat 8 upgrades Message-ID: <20151102170931.GP8374@redhat.com> See details in the patch. -- / Alexander Bokovoy -------------- next part -------------- From ee434967dfc1613bf7575a92ed66881aab663da3 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 2 Nov 2015 19:06:24 +0200 Subject: [PATCH] spec file: depend on Dogtag 10.2.6-12 for tomcat 8 upgrade Dogtag 10.2.6-12 includes automatic upgrade from Tomcat 7 to Tomcat 8. Otherwise FreeIPA is broken after upgrades. This affects Fedora 22 to Fedora 23 upgrades. https://bugzilla.redhat.com/show_bug.cgi?id=1274915 --- freeipa.spec.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6a99308..56c5a4d 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -141,8 +141,8 @@ Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base >= %{selinux_policy_version} Requires: slapi-nis >= 0.54.2-1 -Requires: pki-ca >= 10.2.6-10 -Requires: pki-kra >= 10.2.6-10 +Requires: pki-ca >= 10.2.6-12 +Requires: pki-kra >= 10.2.6-12 Requires(preun): python systemd-units Requires(postun): python systemd-units Requires: python-dns >= 1.11.1 -- 2.5.0 From abokovoy at redhat.com Mon Nov 2 17:49:37 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Nov 2015 19:49:37 +0200 Subject: [Freeipa-devel] [PATCH] 925 Update .po files In-Reply-To: <20151102125056.GG8374@redhat.com> References: <5637495E.8010900@redhat.com> <20151102125056.GG8374@redhat.com> Message-ID: <20151102174937.GQ8374@redhat.com> On Mon, 02 Nov 2015, Alexander Bokovoy wrote: >On Mon, 02 Nov 2015, Petr Vobornik wrote: >>For 4.2.3 release >> >>https://fedorahosted.org/freeipa/ticket/5427 >> >>target branches: master, ipa-4-2 >>-- >>Petr Vobornik > >>From 07e0ceff02932f1c8db1591be560a2b1745335d8 Mon Sep 17 00:00:00 2001 >>From: Petr Vobornik >>Date: Mon, 2 Nov 2015 12:24:58 +0100 >>Subject: [PATCH] Update .po files >> >>https://fedorahosted.org/freeipa/ticket/5427 >>--- >>install/po/bn_IN.po | 2 +- >>install/po/ca.po | 2 +- >>install/po/cs.po | 2 +- >>install/po/de.po | 1129 ++++++++++++++++++++++++++++++++- >>install/po/es.po | 2 +- >>install/po/eu.po | 2 +- >>install/po/fr.po | 1731 ++++++++++++++++++++++++++++++++++++++++++++++----- >>install/po/hi.po | 2 +- >>install/po/hu.po | 2 +- >>install/po/id.po | 2 +- >>install/po/ja.po | 2 +- >>install/po/kn.po | 2 +- >>install/po/nl.po | 2 +- >>install/po/pl.po | 2 +- >>install/po/ru.po | 779 ++++++++++++++++++++++- >>install/po/tg.po | 2 +- >>install/po/uk.po | 4 +- >>install/po/zh_CN.po | 2 +- >>18 files changed, 3499 insertions(+), 172 deletions(-) >ACK. Attached is the fix for French translation where format specifier for Python strings was broken in ID overrides translations. -- / Alexander Bokovoy -------------- next part -------------- From 21569b4e66e277fb040416e4823aef6a2c0fcea0 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 2 Nov 2015 19:47:24 +0200 Subject: [PATCH] translations: fix broken French translation Formatting specifiers were missing in the French translation of ID overrides. --- install/po/fr.po | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/install/po/fr.po b/install/po/fr.po index cf0e647..e5f943d 100644 --- a/install/po/fr.po +++ b/install/po/fr.po @@ -3961,7 +3961,6 @@ msgstr "" " * Zone redirig?e : les zones transf?r?es ne contiennent aucune donn?e \n" " faisant autorit?. BIND transmet les requ?tes qui ne peuvent ?tre \n" " servies par son cache local aux serveurs de redirection configur?s.\n" -" " msgid "" "\n" @@ -7389,21 +7388,21 @@ msgstr "Ajouter une nouvelle surcharge d'identifiant." #, python-format msgid "Added ID override \"%(value)s\"" -msgstr "Surcharge d'identifiants ??%(value)?? ajout?e" +msgstr "Surcharge d'identifiants ??%(value)s?? ajout?e" msgid "Delete an ID override." msgstr "Supprimer une surcharge d'identifiants." #, python-format msgid "Deleted ID override \"%(value)s\"" -msgstr "Surcharge d'identifiants ? %(value) ? supprim?e" +msgstr "Surcharge d'identifiants ? %(value)s ? supprim?e" msgid "Modify an ID override." msgstr "Modifier une surcharge d'identifiants." #, python-format msgid "Modified an ID override \"%(value)s\"" -msgstr "Surcharge d'identifiants ? %(value) ? modifi?e" +msgstr "Surcharge d'identifiants ? %(value)s ? modifi?e" msgid "ID override" msgstr "Surcharge d'identifiants" -- 2.5.0 From pvoborni at redhat.com Mon Nov 2 18:02:38 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 Nov 2015 19:02:38 +0100 Subject: [Freeipa-devel] [PATCH] 925 Update .po files In-Reply-To: <20151102174937.GQ8374@redhat.com> References: <5637495E.8010900@redhat.com> <20151102125056.GG8374@redhat.com> <20151102174937.GQ8374@redhat.com> Message-ID: <5637A53E.4080701@redhat.com> On 11/02/2015 06:49 PM, Alexander Bokovoy wrote: > On Mon, 02 Nov 2015, Alexander Bokovoy wrote: >> On Mon, 02 Nov 2015, Petr Vobornik wrote: >>> For 4.2.3 release >>> >>> https://fedorahosted.org/freeipa/ticket/5427 >>> >>> target branches: master, ipa-4-2 >>> -- >>> Petr Vobornik >> >>> From 07e0ceff02932f1c8db1591be560a2b1745335d8 Mon Sep 17 00:00:00 2001 >>> From: Petr Vobornik >>> Date: Mon, 2 Nov 2015 12:24:58 +0100 >>> Subject: [PATCH] Update .po files >>> >>> https://fedorahosted.org/freeipa/ticket/5427 >>> --- >>> install/po/bn_IN.po | 2 +- >>> install/po/ca.po | 2 +- >>> install/po/cs.po | 2 +- >>> install/po/de.po | 1129 ++++++++++++++++++++++++++++++++- >>> install/po/es.po | 2 +- >>> install/po/eu.po | 2 +- >>> install/po/fr.po | 1731 >>> ++++++++++++++++++++++++++++++++++++++++++++++----- >>> install/po/hi.po | 2 +- >>> install/po/hu.po | 2 +- >>> install/po/id.po | 2 +- >>> install/po/ja.po | 2 +- >>> install/po/kn.po | 2 +- >>> install/po/nl.po | 2 +- >>> install/po/pl.po | 2 +- >>> install/po/ru.po | 779 ++++++++++++++++++++++- >>> install/po/tg.po | 2 +- >>> install/po/uk.po | 4 +- >>> install/po/zh_CN.po | 2 +- >>> 18 files changed, 3499 insertions(+), 172 deletions(-) >> ACK. > Attached is the fix for French translation where format specifier for > Python strings was broken in ID overrides translations. > The changes in fr.po are ok, but several are missing, attaching different patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0926-fix-broken-translations-after-last-po-update.patch Type: text/x-patch Size: 3985 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 2 18:17:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 19:17:33 +0100 Subject: [Freeipa-devel] [PATCH] 925 Update .po files In-Reply-To: <5637A53E.4080701@redhat.com> References: <5637495E.8010900@redhat.com> <20151102125056.GG8374@redhat.com> <20151102174937.GQ8374@redhat.com> <5637A53E.4080701@redhat.com> Message-ID: <5637A8BD.1060003@redhat.com> On 02.11.2015 19:02, Petr Vobornik wrote: > On 11/02/2015 06:49 PM, Alexander Bokovoy wrote: >> On Mon, 02 Nov 2015, Alexander Bokovoy wrote: >>> On Mon, 02 Nov 2015, Petr Vobornik wrote: >>>> For 4.2.3 release >>>> >>>> https://fedorahosted.org/freeipa/ticket/5427 >>>> >>>> target branches: master, ipa-4-2 >>>> -- >>>> Petr Vobornik >>> >>>> From 07e0ceff02932f1c8db1591be560a2b1745335d8 Mon Sep 17 00:00:00 2001 >>>> From: Petr Vobornik >>>> Date: Mon, 2 Nov 2015 12:24:58 +0100 >>>> Subject: [PATCH] Update .po files >>>> >>>> https://fedorahosted.org/freeipa/ticket/5427 >>>> --- >>>> install/po/bn_IN.po | 2 +- >>>> install/po/ca.po | 2 +- >>>> install/po/cs.po | 2 +- >>>> install/po/de.po | 1129 ++++++++++++++++++++++++++++++++- >>>> install/po/es.po | 2 +- >>>> install/po/eu.po | 2 +- >>>> install/po/fr.po | 1731 >>>> ++++++++++++++++++++++++++++++++++++++++++++++----- >>>> install/po/hi.po | 2 +- >>>> install/po/hu.po | 2 +- >>>> install/po/id.po | 2 +- >>>> install/po/ja.po | 2 +- >>>> install/po/kn.po | 2 +- >>>> install/po/nl.po | 2 +- >>>> install/po/pl.po | 2 +- >>>> install/po/ru.po | 779 ++++++++++++++++++++++- >>>> install/po/tg.po | 2 +- >>>> install/po/uk.po | 4 +- >>>> install/po/zh_CN.po | 2 +- >>>> 18 files changed, 3499 insertions(+), 172 deletions(-) >>> ACK. >> Attached is the fix for French translation where format specifier for >> Python strings was broken in ID overrides translations. >> > > The changes in fr.po are ok, but several are missing, attaching > different patch. > 926 ACK From pvoborni at redhat.com Mon Nov 2 18:31:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 Nov 2015 19:31:26 +0100 Subject: [Freeipa-devel] [PATCH] 0198 depend on dogtag 10.2.6-12 for tomcat 8 upgrades In-Reply-To: <20151102170931.GP8374@redhat.com> References: <20151102170931.GP8374@redhat.com> Message-ID: <5637ABFE.7030502@redhat.com> On 11/02/2015 06:09 PM, Alexander Bokovoy wrote: > See details in the patch. > > > ACK Pushed to master: abf34d99d9300417a7c067926250d7fd2e0e8a4 Pushed to ipa-4-2: 0c4342ce385ddcb57fceddbfef2dd2106e587f85 -- Petr Vobornik From pvoborni at redhat.com Mon Nov 2 18:33:52 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 Nov 2015 19:33:52 +0100 Subject: [Freeipa-devel] [PATCH] 925 Update .po files In-Reply-To: <5637A8BD.1060003@redhat.com> References: <5637495E.8010900@redhat.com> <20151102125056.GG8374@redhat.com> <20151102174937.GQ8374@redhat.com> <5637A53E.4080701@redhat.com> <5637A8BD.1060003@redhat.com> Message-ID: <5637AC90.6050108@redhat.com> On 11/02/2015 07:17 PM, Martin Basti wrote: > > > On 02.11.2015 19:02, Petr Vobornik wrote: >> On 11/02/2015 06:49 PM, Alexander Bokovoy wrote: >>> On Mon, 02 Nov 2015, Alexander Bokovoy wrote: >>>> On Mon, 02 Nov 2015, Petr Vobornik wrote: >>>>> For 4.2.3 release >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5427 >>>>> >>>>> target branches: master, ipa-4-2 >>>>> -- >>>>> Petr Vobornik >>>> >>>>> From 07e0ceff02932f1c8db1591be560a2b1745335d8 Mon Sep 17 00:00:00 2001 >>>>> From: Petr Vobornik >>>>> Date: Mon, 2 Nov 2015 12:24:58 +0100 >>>>> Subject: [PATCH] Update .po files >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5427 >>>>> --- >>>>> install/po/bn_IN.po | 2 +- >>>>> install/po/ca.po | 2 +- >>>>> install/po/cs.po | 2 +- >>>>> install/po/de.po | 1129 ++++++++++++++++++++++++++++++++- >>>>> install/po/es.po | 2 +- >>>>> install/po/eu.po | 2 +- >>>>> install/po/fr.po | 1731 >>>>> ++++++++++++++++++++++++++++++++++++++++++++++----- >>>>> install/po/hi.po | 2 +- >>>>> install/po/hu.po | 2 +- >>>>> install/po/id.po | 2 +- >>>>> install/po/ja.po | 2 +- >>>>> install/po/kn.po | 2 +- >>>>> install/po/nl.po | 2 +- >>>>> install/po/pl.po | 2 +- >>>>> install/po/ru.po | 779 ++++++++++++++++++++++- >>>>> install/po/tg.po | 2 +- >>>>> install/po/uk.po | 4 +- >>>>> install/po/zh_CN.po | 2 +- >>>>> 18 files changed, 3499 insertions(+), 172 deletions(-) >>>> ACK. >>> Attached is the fix for French translation where format specifier for >>> Python strings was broken in ID overrides translations. >>> >> >> The changes in fr.po are ok, but several are missing, attaching >> different patch. >> > > 926 ACK For order (forgot to send mail) 925 pushed to: master: * bae97f5138e8ce784a4c87f1fc0a5fee53095f37 Update .po files ipa-4-2: * a5833442f76462057e4f94254244549a69dddc0e Update .po files 926 pushed to: master: 818634ed4d10130991edd2c8db3e6b53fa9d55b7 ipa-4-2: f6f1a21a6a07879028d58700a5887b4d6cf72912 -- Petr Vobornik From mbasti at redhat.com Mon Nov 2 19:21:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 2 Nov 2015 20:21:04 +0100 Subject: [Freeipa-devel] [PATCH 0340 - 0341] DNSSEC restore state fixes in uninstall Message-ID: <5637B7A0.7020800@redhat.com> Attached patches removes the sysrestore states that has been left in sysrestore.state file after uninstall -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0340-Fix-typo-in-ods-exporter-uninstall-to-restore-state.patch Type: text/x-patch Size: 1037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0341-DNSSEC-remove-sysrestore-state-after-uninstall.patch Type: text/x-patch Size: 893 bytes Desc: not available URL: From pvoborni at redhat.com Mon Nov 2 21:01:11 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 2 Nov 2015 22:01:11 +0100 Subject: [Freeipa-devel] Announcing FreeIPA 4.2.3 Message-ID: <5637CF17.8010700@redhat.com> The FreeIPA team would like to announce FreeIPA v4.2.3 bug fixing release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora 23 and rawhide. Builds for Fedora 22 are available in the official COPR repository . Fedora update: and related pki-core update: == Highlights in 4.2.3 == FreeIPA 4.2.3 is a bugfix release to improve upgrade experience from FreeIPA 4.1 for Fedora 23 where Tomcat 8 was introduced. === Bug fixes === * fixed upgrade failures #5359, #5360 and * fixed regression in automember Web UI - disappearing expression === Enhancements === * new French and German translations * improved validation of Realm Domains, * ipa-adtrust-install prints complete SRV records so that they are suitable for copy&pasting to zone files == Upgrading == Upgrade instructions are available on upgrade page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.2.2 == === David Kupka (1) === * comment: Add Documentation string to deduplicate function === Gabe Alford (2) === * Remove bind configuration detected question * Warn if no installation found when running ipa-server-install --uninstall === Jan Cholasta (3) === * schema: do not derive ipaVaultPublicKey from ipaPublicKey * upgrade: make sure ldap2 is connected in export_kra_agent_pem * vault: fix private service vault creation === Martin Babinsky (4) === * remove ID overrides when deleting a user * execute user-del pre-callback also during user preservation * fix class teardown in user plugin tests * always ask the resolver for the reverse zone when manipulating PTR records === Martin Ba?ti (7) === * CI TEST: Vault * CI Test: add setup_kra options into install scripts * Replace tab with space in test_user_plugin.py * DNSSEC CI: wait until DS records is replicated * DNSSEC: Remove service containers from LDAP after uninstalling * DNSSEC: warn user if DNSSEC key master is not installed * KRA: fix check that CA is installed === Milan Kub?k (6) === * ipatests: add fuzzy instances for CA ACL DN and RDN * ipatests: Add initial CAACLTracker implementation * tests: add test to check the default ACL * ipatests: CA ACL - added config templates * ipatests: added unlock_principal_password and change_principal * ipatests: CA ACL and cert profile functional test === Oleg Fayans (1) === * Fixed a timing issue with drill returning non-zero exitcode === Petr Voborn?k (2) === * Update .po files * Become IPA 4.2.3 === Petr ?pa?ek (1) === * ipa-adtrust-install: Print complete SRV records === Stanislav Laznicka (1) === * Fixes disappearing automember expressions === Tom?? Babej (10) === * util: Add detect_dns_zone_realm_type helper * realmdomains: Minor style and wording improvements * realmdomains: Add validation that realmdomain being added is indeed from our realm * realmdomains: Issue a warning when automated management of realmdomains failed * realmdomains: Do not fail due the ValidationError when adding _kerberos TXT record * tests: Amend result assertions in realmdomains tests * idoverride: Ignore ValidationErrors when converting the anchor * tests: Add tests for idoverride object integrity * trusts: Make trust_show.get_dn raise properly formatted NotFound * trustdomain: Perform validation of the trust domain first -- Petr Vobornik From lslebodn at redhat.com Tue Nov 3 07:44:03 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 3 Nov 2015 08:44:03 +0100 Subject: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires Message-ID: <20151103074402.GB4962@mail.corp.redhat.com> ehlo, it happened many times that freeipa rpms could not be build in mock because there was build requirement for very new sssd. Even though it was not necessary to have new sssd among build dependencies. I've manged to build FreeIPA rpms on rawhide without sssd in build root. So it means it is not required. In teory you might need some sssd sub-pacakges for test in build root e.g. python-sss_nss_idmap, python-sss, python-sssdconfig But I cannot see a "make test" in upstream spec file. LS -------------- next part -------------- >From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Mon, 2 Nov 2015 19:52:57 +0000 Subject: [PATCH] SPEC: Drop sssd from BuildRequires Packaging of sssd was changed and more sub-packages are build from sssd.src.rpm. Especially python bindings and development packages are already in sub-packages. As a result of this change the meta package sssd can be removed from BuildRequires without any problem. FreeIPA spec file contained build requirement for latest version of sssd even though the latest sssd was not required for building FreeIPA rpms. In many cases, it was sufficient just to change requirements for FreeIPA packages instead of build requirements. --- freeipa.spec.in | 1 - 1 file changed, 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6a99308..2221712 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -74,7 +74,6 @@ BuildRequires: pylint >= 1.0 BuildRequires: python-polib BuildRequires: python-libipa_hbac BuildRequires: python-memcached -BuildRequires: sssd >= 1.13.1 BuildRequires: python-lxml BuildRequires: python-pyasn1 >= 0.0.9a BuildRequires: python-qrcode-core >= 5.0.0 -- 2.6.2 From jcholast at redhat.com Tue Nov 3 08:41:41 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 3 Nov 2015 09:41:41 +0100 Subject: [Freeipa-devel] [PATCH 505] install: fix command line option validation Message-ID: <56387345.1040200@redhat.com> Hi, the attached patch fixes: Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-505-install-fix-command-line-option-validation.patch Type: text/x-patch Size: 2675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-505.0.4_2-install-fix-command-line-option-validation.patch Type: text/x-patch Size: 2649 bytes Desc: not available URL: From martinjo84 at gmail.com Tue Nov 3 08:42:34 2015 From: martinjo84 at gmail.com (=?UTF-8?Q?Martin_J=C3=B8rgensen?=) Date: Tue, 3 Nov 2015 09:42:34 +0100 Subject: [Freeipa-devel] Open ports for client can auth over wan Message-ID: Hi Loves freeipa, using it on all of my machines, i have som vm in the cloud, which port do i have to open out for these client can auth? Mvh Martin J?rgensen TLF: 28738893 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Nov 3 08:55:03 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 Nov 2015 09:55:03 +0100 Subject: [Freeipa-devel] Open ports for client can auth over wan In-Reply-To: References: Message-ID: <56387667.5070700@redhat.com> On 3.11.2015 09:42, Martin J?rgensen wrote: > Hi > > Loves freeipa, using it on all of my machines, i have som vm in the cloud, > which port do i have to open out for these client can auth? ipa-server-install prints list of ports you need to open. For full functionality you need to open all of them. -- Petr^2 Spacek From pspacek at redhat.com Tue Nov 3 09:19:17 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 3 Nov 2015 10:19:17 +0100 Subject: [Freeipa-devel] [PATCH 0340 - 0341] DNSSEC restore state fixes in uninstall In-Reply-To: <5637B7A0.7020800@redhat.com> References: <5637B7A0.7020800@redhat.com> Message-ID: <56387C15.3050309@redhat.com> On 2.11.2015 20:21, Martin Basti wrote: > Attached patches removes the sysrestore states that has been left in > sysrestore.state file after uninstall ACK -- Petr^2 Spacek From mbasti at redhat.com Tue Nov 3 09:45:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 Nov 2015 10:45:57 +0100 Subject: [Freeipa-devel] [PATCH 0342] Use domain level constants in topology plugin Message-ID: <56388255.6010007@redhat.com> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0342-Use-domain-level-constants-in-topology-plugin.patch Type: text/x-patch Size: 1350 bytes Desc: not available URL: From ldoudova at redhat.com Tue Nov 3 11:32:34 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 3 Nov 2015 12:32:34 +0100 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker In-Reply-To: <562E5D60.4040102@redhat.com> References: <5624C63D.5020000@redhat.com> <5624DF10.4060000@redhat.com> <56264753.1000405@redhat.com> <562669F8.3060502@redhat.com> <56271A5E.3010608@redhat.com> <562DDDD9.1060503@redhat.com> <562E5D60.4040102@redhat.com> Message-ID: <56389B52.9000108@redhat.com> On 10/26/2015 06:05 PM, Martin Basti wrote: > > > On 26.10.2015 09:01, Lenka Doudova wrote: >> >> >> On 10/21/2015 06:53 AM, Lenka Doudova wrote: >>> >>> >>> On 10/20/2015 06:21 PM, Martin Basti wrote: >>>> >>>> >>>> On 20.10.2015 15:53, Martin Basti wrote: >>>>> >>>>> >>>>> On 19.10.2015 14:16, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 19.10.2015 12:30, Martin Basti wrote: >>>>>>> Attribute nsaccountlock has not been processed correctly >>>>>>> >>>>>>> Patch attached. >>>>>>> >>>>>>> >>>>>> >>>>>> Self-NACK, more fixes required >>>>>> >>>>>> >>>>>> >>>>> Updated patch attached, but it still needs to improve because >>>>> tests in my patch 331 are still failing. >>>>> >>>> >>>> Eternal self-NACK for this patch >>>> >>>> I'm not able to fix UserTracker, I need help from somebody with >>>> higher view of how this tracker is supposed to work. >>>> Follow my patch 0331 >>> >>> Hi, I'll take a look at it today. >>> Lenka >>> >>> >> Hi, >> >> I fixed the trackers and tests, rebased patch attached. >> Lenka >> >> > > Thank you, > > 1) > ************* Module ipatests.test_xmlrpc.test_stageuser_plugin > ipatests/test_xmlrpc/test_stageuser_plugin.py:938: > [E0102(function-redefined), TestMultipleManagers] class already > defined line 913) > > 2) > Because the patch contains tests too, I suggest to rename patch to > Multiple manager per user tests. > Also you should change commiter of patch to you. > > Martin^2 Fixed patch attached. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0005.2-Multiple-manager-per-user-tests.patch Type: text/x-patch Size: 11398 bytes Desc: not available URL: From pviktori at redhat.com Tue Nov 3 13:39:05 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 3 Nov 2015 14:39:05 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run Message-ID: <5638B8F9.6010703@redhat.com> Hello, Python 3's strings are Unicode, so data coming to or leaving a Python program needs to be decoded/encoded if it's to be handled as a string. One of the boundaries where encoding is necessary is external programs, specifically, ipautil.run. Unfortunately there's no one set of options that would work for all run() invocations, so I went through them all and specified the stdin/stdout/stderr encoding where necessary. I've also updated the call sites to make it clearer if the return values are used or not. If an encoding is not set, run() will accept/return bytes. (This is a fail-safe setting, since it can't raise errors, and using bytes where strings are expected generally fails loudly in py3.) Note that the changes are not effective under Python 2. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0748-Handle-encoding-for-ipautil.run.patch Type: text/x-patch Size: 53601 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Nov 3 14:03:45 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 3 Nov 2015 15:03:45 +0100 Subject: [Freeipa-devel] [PATCH 505] install: fix command line option validation In-Reply-To: <56387345.1040200@redhat.com> References: <56387345.1040200@redhat.com> Message-ID: <5638BEC1.6000405@redhat.com> On 11/03/2015 09:41 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes: > > > > > Honza > > > Once more for the whole list, ACK. -- Martin^3 Babinsky From mbasti at redhat.com Tue Nov 3 15:15:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 Nov 2015 16:15:16 +0100 Subject: [Freeipa-devel] [PATCH 0011, 0012, 0015] Replica promotion related changes in integration tests In-Reply-To: <56377BB0.7000209@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> <5632584A.7070607@redhat.com> <56372F4E.9060805@redhat.com> <56374101.7000102@redhat.com> <56374E96.1080403@redhat.com> <563768E3.3020204@redhat.com> <563776F6.6070804@redhat.com> <56377BB0.7000209@redhat.com> Message-ID: <5638CF84.2080205@redhat.com> On 02.11.2015 16:05, Oleg Fayans wrote: > > > On 11/02/2015 03:45 PM, Martin Basti wrote: >> >> >> On 02.11.2015 14:45, Oleg Fayans wrote: >>> Hi Martin, >>> >>> On 11/02/2015 12:52 PM, Martin Basti wrote: >>>> >>>> >>>> On 02.11.2015 11:54, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> On 11/02/2015 10:39 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 29.10.2015 18:32, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 29.10.2015 18:31, Martin Basti wrote: >>>>>>>> NACK >>>>>>>> >>>>>>>> 1) >>>>>>>> DO NOT use tabs in code to indent >>>>> Fixed >>>>>>>> >>>>>>>> 2) >>>>>>>> Replica uninstallation does not work, uninstallation works >>>>>>>> different >>>>>>>> with domain level 0 and 1 (currently uninstallation with domain 1 >>>>>>>> level will not work, it is known issue, but still the patch should >>>>>>>> solve the uninstallation) >>>>>> This is not valid, my bad, I was confused with new behaviour of >>>>>> replica >>>>>> uninstallation, but it is bug not a feature. >>>>>> So replica uninstallation is the same for level 0 and 1 >>>>>> Sorry. >>>>>>>> >>>>>>>> 3) >>>>>>>> apply_common_fixes(host) >>>>>>>> Method for domain_level 1 is called twice, first time in replica >>>>>>>> install, second time in client install >>>>> Fixed >>>>>>>> >>>>>>>> 4) >>>>>>>> during testing this patch I used test_simple_replication and I >>>>>>>> found >>>>>>>> 4 bugs: >>>>>>> 3 bugs -----------------^^^ >>>>>>>> #5419, #5420, #5421 >>>>> Bug #5419 fixed, see patch N 15 >>>> >>>> patch 0015 NACK >>>> >>>> 1) >>>> You fixed just half of the issue, there is also wrong dnsrecord-add >>>> >>>> 2) >>>> I do not think that your solution is the right, it can result in >>>> failures when the domain 'my.ipa.domain' is used. >>>> >>>> I prefer to add '.' to record name and use it as absolute name, >>>> dnsrecord-* command will handle it. > > Done > >>> That's a good point. The problem though, is that dnsrecord-add handles >>> it correctly, while dnsrecord-find - does not. >>> >>> $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com. >>> vm-002.idm.lab.eng.brq.redhat.com. --a-rec 192.168.254.2 >>> Record name: vm-002 >>> A record: 192.168.254.2 >>> >>> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. >>> vm-001.idm.lab.eng.brq.redhat.com. >>> ---------------------------- >>> Number of entries returned 0 >>> ---------------------------- >>> >>> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com. vm-001 >>> Record name: vm-001 >>> A record: 192.168.254.1 >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> Should I file a ticket against it? >>> >> I do not think that this is a bug, dnsrecord-find does search in >> multiple attributes not only in record names >> >> I suggest to use dnsrecord-show instead of dnsrecord-find >>> >>>> >>>> if not host.hostname.endswith('.'): >>>> host.hostname += '{}.'.format(host.hostname) >>>> >>>> And I would replace dnsrecord-find with dnsrecord-show >>>> >>>> patches 11, 12 LGTM, I will test them later >>>> >>>> Martin^2 >>>>> >>>>>>>> IMO it is related only to this one test case and to pass this test >>>>>>>> case #5419 or #5421 must be fixed. >>>>>>>> >>>>>>>> >>>>>>>> On 27.10.2015 16:34, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> The updated patch is attached >>>>>>>>> >>>>>>>>> On 10/27/2015 01:58 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The updated version of the patch is attached. Please, >>>>>>>>>>>>>>>> see my >>>>>>>>>>>>>>>> comments >>>>>>>>>>>>>>>> below >>>>>>>>>>>>>>> My comments inline, I may be completely wrong in how the >>>>>>>>>>>>>>> test >>>>>>>>>>>>>>> suite >>>>>>>>>>>>>>> work, so feel free to correct me. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Martin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>>>>>> please remove the added empty lines, they are >>>>>>>>>>>>>>>>>>>>>> unrelated to >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>>>>> setup_kra=False): >>>>>>>>>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, >>>>>>>>>>>>>>>>>>>>>> setup_kra=False, >>>>>>>>>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which >>>>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA >>>>>>>>>>>>>>>>>>>>>> 4.3, >>>>>>>>>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>>>>>>>> independent on IPA version, only admin can raise it >>>>>>>>>>>>>>>>>>>>>> up. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So you have to find out way how to pass the domain >>>>>>>>>>>>>>>>>>>>>> level for >>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>> test will be running, we were talking about using >>>>>>>>>>>>>>>>>>>>>> config >>>>>>>>>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml >>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> directive >>>>>>>>>>>>>>>>>>>> domain_level >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies >>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In fact, we do not seem to have any tests yet that >>>>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>> require it. >>>>>>>>>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>>>>>>>>> How about topology CI test? This can be executed only >>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> That's right. The topology test was updated. Patch is >>>>>>>>>>>>>>>>>> attached >>>>>>>>>>>>>>>>>> together with a proper version of 11-th patch (not a >>>>>>>>>>>>>>>>>> swap >>>>>>>>>>>>>>>>>> file, >>>>>>>>>>>>>>>>>> sorry >>>>>>>>>>>>>>>>>> about that). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 1, right? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 6) >>>>>>>>>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument >>>>>>>>>>>>>>>>>>>>> 'raiseonerr' in >>>>>>>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>>>>>>> call) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> always use: variable *is not None* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>> default level is the one which is default in tested >>>>>>>>>>>>>>>>> package. >>>>>>>>>>>>>>>>> These should be None and "": >>>>>>>>>>>>>>>>> + "domain_level": "1" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>>>>>>>>> pytest.fixture >>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>> to know the value of domain level before we can do any >>>>>>>>>>>>>>>>> dynamic >>>>>>>>>>>>>>>>> detection >>>>>>>>>>>>>>>>> on master. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as >>>>>>>>>>>>>>>>> default, >>>>>>>>>>>>>>>>> for 2) >>>>>>>>>>>>>>>> Done >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>> need default value, or the fixture will not work as >>>>>>>>>>>>>>>>> expected. >>>>>>>>>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This won't work in cases when domainlevel is explicitly >>>>>>>>>>>>>>>> set >>>>>>>>>>>>>>>> to 0 in >>>>>>>>>>>>>>>> config.yaml. This default value will always override the >>>>>>>>>>>>>>>> explicit >>>>>>>>>>>>>>>> one. >>>>>>>>>>>>>>> wat? in case that kwargs is dict containing values from >>>>>>>>>>>>>>> config >>>>>>>>>>>>>>> file: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>>>>>>>>> Out[2]: 0 >>>>>>>>>>>>> >>>>>>>>>>>>> Yep, right you are, it works as expected. Now the line looks >>>>>>>>>>>>> like: >>>>>>>>>>>>> self.domain_level = kwargs.get('domain_level', >>>>>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Respectively you should use this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> self.domain_level = kwargs.get('domain_level')or >>>>>>>>>>>>>> MAX_DOMAIN_LEVEL >>>>>>>>>>>>> Now that would definitely not work in case of domain_level >>>>>>>>>>>>> is 0: >>>>>>>>>>>>> 0 or 1 is always 1 >>>>>>>>>>>> Oh right. >>>>>>>>>>>> >>>>>>>>>>>> I had discussion with Tomas, and we should add there check >>>>>>>>>>>> if it >>>>>>>>>>>> is not >>>>>>>>>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>>>>>>>>> does not >>>>>>>>>>>> know with test when the None value appears there) >>>>>>>>>>> >>>>>>>>>>> I do not get this. If we do not specify domain_level in >>>>>>>>>>> config.yaml, >>>>>>>>>>> it will automatically be populated with a MAX_DOMAIN_LEVEL >>>>>>>>>>> value. >>>>>>>>>>> That >>>>>>>>>>> means domain_level will never ever possibly be None. >>>>>>>>>> I do not know how pytest works inside, if you are 100% sure, >>>>>>>>>> that >>>>>>>>>> the >>>>>>>>>> case written above cannot happen, I'm fine with it. >>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> self.domain_level = kwargs.get('domain_level') >>>>>>>>>>>> if self.domain_level is None: >>>>>>>>>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>>>>>>>>> >>>>>>>>>>>> As we cannot user 'or' expression with integers, so this is >>>>>>>>>>>> the >>>>>>>>>>>> right >>>>>>>>>>>> way. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> because kwargs IMO contains undefined config values as None >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>>>> available in tests. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So then you also need update this line >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>>>>>>>>> host.config.domain_level) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This would not work if domainlevel is not set in >>>>>>>>>>>>>>>> config.yaml, in >>>>>>>>>>>>>>>> which case the host.config.domain_level is None. >>>>>>>>>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>>>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>> Please add comment to function +def domainlevel(host): >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>>> useful >>>>>>>>>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>>>>>>>>> otherwise it >>>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>>> be lost after test refactoring as somebody may consider >>>>>>>>>>>>>>>>> it as >>>>>>>>>>>>>>>>> unneeded >>>>>>>>>>>>>>>>> and replace it with config dict. >>>>>>>>>>>>>>>> Done >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > Patches 11, 12 ACK Pushed to master: f9bbfade29657a6274afcdbc7dba5d5417ad4b69 Patch 15 ACK Pushed to master: 511ace9a4fd0bbb1234662e580492366b2b96537 > From mbasti at redhat.com Tue Nov 3 15:25:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 Nov 2015 16:25:21 +0100 Subject: [Freeipa-devel] [PATCH 0340 - 0341] DNSSEC restore state fixes in uninstall In-Reply-To: <56387C15.3050309@redhat.com> References: <5637B7A0.7020800@redhat.com> <56387C15.3050309@redhat.com> Message-ID: <5638D1E1.1010609@redhat.com> On 03.11.2015 10:19, Petr Spacek wrote: > On 2.11.2015 20:21, Martin Basti wrote: >> Attached patches removes the sysrestore states that has been left in >> sysrestore.state file after uninstall > ACK > Pushed to master: 0d66026d220dd675e9b017db37127b822815cf4a From mbasti at redhat.com Tue Nov 3 18:18:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 3 Nov 2015 19:18:08 +0100 Subject: [Freeipa-devel] [PATCH 0343] Upgrade: enable custodia service during upgrade Message-ID: <5638FA60.9030603@redhat.com> https://fedorahosted.org/freeipa/ticket/5429 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0343-Upgrade-enable-custodia-service-during-upgrade.patch Type: text/x-patch Size: 2179 bytes Desc: not available URL: From ftweedal at redhat.com Wed Nov 4 05:14:17 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 4 Nov 2015 15:14:17 +1000 Subject: [Freeipa-devel] [BLOG] FreeIPA PKI: current plans and a future vision Message-ID: <20151104051417.GY20018@dhcp-40-8.bne.redhat.com> I have been alluding for a while about my ideas for future FreeIPA/Dogtag PKI integration; I finally put the ideas down in a blog post. If you are interested in this aspect of IdM please read it; all feedback is welcome! http://blog-ftweedal.rhcloud.com/2015/11/freeipa-pki-current-plans-and-a-future-vision/ Thanks, Fraser From ofayans at redhat.com Wed Nov 4 10:25:47 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 4 Nov 2015 11:25:47 +0100 Subject: [Freeipa-devel] misleading error message? Message-ID: <5639DD2B.7000705@redhat.com> Hi all, Is there a way to switch back to the old (based on ipa-replica-prepare) replica installation workflow having domain level=1? The following error message suggests that it is possible: $ ipa-replica-install --setup-ca --setup-dns --forwarder=10.38.5.26 -P testuser Password for testuser at IDM.LAB.ENG.BRQ.REDHAT.COM: ipa : ERROR The Replication Managers group is not available in the domain. Replica promotion requires the use of Replication Managers to be able to replicate data. Upgrade the peer master or use the ipa-replica-prepare command on the master and use a prep file to install this replica. ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information It it is not possible (and it is not, AFAIU) we should probably remove the ipa-replica-prepare part from this error message. The second issue with this error message is that adding an unprivileged user just to admins group fixes the promotion, i. e. no neeed in any special "Replication Managers" group. Thus the message is totally misleading. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Wed Nov 4 10:37:39 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 4 Nov 2015 11:37:39 +0100 Subject: [Freeipa-devel] misleading error message? In-Reply-To: <5639DD2B.7000705@redhat.com> References: <5639DD2B.7000705@redhat.com> Message-ID: <5639DFF3.201@redhat.com> On 04.11.2015 11:25, Oleg Fayans wrote: > Hi all, > > Is there a way to switch back to the old (based on > ipa-replica-prepare) replica installation workflow having domain level=1? > > The following error message suggests that it is possible: > > $ ipa-replica-install --setup-ca --setup-dns --forwarder=10.38.5.26 -P > testuser > Password for testuser at IDM.LAB.ENG.BRQ.REDHAT.COM: > ipa : ERROR The Replication Managers group is not available > in the domain. Replica promotion requires the use of Replication > Managers to be able to replicate data. Upgrade the peer master or use > the ipa-replica-prepare command on the master and use a prep file to > install this replica. > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > It it is not possible (and it is not, AFAIU) we should probably remove > the ipa-replica-prepare part from this error message. > > The second issue with this error message is that adding an > unprivileged user just to admins group fixes the promotion, i. e. no > neeed in any special "Replication Managers" group. Thus the message is > totally misleading. > https://fedorahosted.org/freeipa/ticket/5400 https://fedorahosted.org/freeipa/ticket/5399 https://fedorahosted.org/freeipa/ticket/5401 From mbabinsk at redhat.com Wed Nov 4 10:56:08 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 4 Nov 2015 11:56:08 +0100 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <56290176.5030303@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <5627B576.9060003@redhat.com> <56290176.5030303@redhat.com> Message-ID: <5639E448.5080302@redhat.com> On 10/22/2015 05:32 PM, Petr Spacek wrote: > On 21.10.2015 17:55, Martin Babinsky wrote: >> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>> >>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>> associated credentials cache during its uninstall >>>> >>>> https://fedorahosted.org/freeipa/ticket/5243 >>> >>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>> during *install* so problems caused by failing uninstallation will be fixed on >>> repeated install. This is yet another step towards idempotent installer. >>> >>> To me this makes more sense than doing so on uninstall. Does it make sense to >>> you, too? >>> >> >> Attaching updated patch that does cleanup also before each instance creation. >> It is a bit ugly I admit, but I couldn't think of a better way to do it and >> didn't want to poke into service/instance code more than neccesary. > > NACK, but we are almost there! > > * kdestroy -A is too aggressive and wipes root's keyring after each run of > ipa-*-install utils. > > * There are some scattered leftovers of ipautil.run['kdestroy'...] in the > tree. Please get rid of them. > > Thank you! > Attaching updated patch. It got lost somewhere in the list. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0082.2-remove-Kerberos-authenticators-when-installing-unins.patch Type: text/x-patch Size: 8317 bytes Desc: not available URL: From tbabej at redhat.com Wed Nov 4 11:58:44 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 4 Nov 2015 12:58:44 +0100 Subject: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions In-Reply-To: <5627B7C1.2060303@ubuntu.com> References: <561419BC.5080707@ubuntu.com> <20151007105110.GA27006@redhat.com> <56152B84.2020503@redhat.com> <5627B7C1.2060303@ubuntu.com> Message-ID: <5639F2F4.8090302@redhat.com> On 10/21/2015 06:05 PM, Timo Aaltonen wrote: > On 07.10.2015 17:26, Martin Basti wrote: >> thanks comments inline > > Hey, > > I hope these versions address the issues in the first batch.. > Hi Timo, this patchset works fine, thanks. Seems you generated it in a non-standard way, it could not be applied directly, as the patch format wasn't detected. It also required a rebase, but I've solved both issues. ACK. Tomas From tbabej at redhat.com Wed Nov 4 12:14:56 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 4 Nov 2015 13:14:56 +0100 Subject: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions In-Reply-To: <5639F2F4.8090302@redhat.com> References: <561419BC.5080707@ubuntu.com> <20151007105110.GA27006@redhat.com> <56152B84.2020503@redhat.com> <5627B7C1.2060303@ubuntu.com> <5639F2F4.8090302@redhat.com> Message-ID: <5639F6C0.9060203@redhat.com> On 11/04/2015 12:58 PM, Tomas Babej wrote: > On 10/21/2015 06:05 PM, Timo Aaltonen wrote: >> On 07.10.2015 17:26, Martin Basti wrote: >>> thanks comments inline >> >> Hey, >> >> I hope these versions address the issues in the first batch.. >> > > Hi Timo, > > this patchset works fine, thanks. > > Seems you generated it in a non-standard way, it could not be applied > directly, as the patch format wasn't detected. It also required a > rebase, but I've solved both issues. > > ACK. > > Tomas > Pushed to master: 43654c973c5977ae55250a30b5652f160b11d590 From mbabinsk at redhat.com Wed Nov 4 12:30:47 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 4 Nov 2015 13:30:47 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <56339585.7020505@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> Message-ID: <5639FA77.3090907@redhat.com> On 10/30/2015 05:06 PM, Martin Babinsky wrote: > On 10/30/2015 03:38 PM, Petr Vobornik wrote: >> On 10/30/2015 03:26 PM, Martin Babinsky wrote: >>> patch for https://fedorahosted.org/freeipa/ticket/5309 >>> >>> The ticket itself is about connectivity checks in topology suffixes, but >>> there is a code (install/tools/ipa-replica-manage starting at line 788 >>> after applying my patch) which monitors whether the segments pointing >>> to/from the deleted host are already deleted. >>> >>> These checks are currently hardcoded for 'realm' prefix, should we >>> generalize them as well or is it a part of other effort? >>> >> >> Could be separate patch but yes. > Ok I have included it in the attached patch so that both of these > operations are performed for all suffixes. > > > Hmm, I'm thinking whether the 'check_last_link_managed' and 'check_deleted_segments' should not be called per-suffix, but should themselves check all suffixes available. This could make the fix for https://fedorahosted.org/freeipa/ticket/5409 also easier. -- Martin^3 Babinsky From slaznick at redhat.com Wed Nov 4 12:46:31 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 4 Nov 2015 13:46:31 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies Message-ID: <5639FE27.1040605@redhat.com> Hi, The fixed patches to Martin^2's and Jakub's reviews are almost ready, there are just a few things left. Martin B. mentioned in his review that '~' might not be the best delimiter for range values in the HBAC time policies language as it is not commonly used for that purpose. I started using it when the negative values were introduced (instead of '-'). The question here is, then, which delimiter would you rather use for ranges? Some choices are ':', '..', and, obviously, '~' but you are free to come up with your own. The delimiters '-' and ',' are not suitable as their use is different here. However small this might seem to be, lets be rigorous here and design it properly. Also, with some time, I got uncertain about one thing with the 'repeat' keyword. What behaviour would you expect when 'repeat' is on yearly repetition and 'dayofweek' is the only other thing set? RFC5545 (iCal) says: " Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time ("DTSTART") component attribute. For example, "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the month or a time. This information would be the same as what is specified for "DTSTART". " and also in an example "... if the BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY, or BYMONTH rule part were missing, the appropriate minute, hour, day, or month would have been retrieved from the "DTSTART" property.", but an example with BYDAY alone set with a day of week without numerical specifier is missing so it is not clear if this would apply to all specified weekdays of a certain month or the whole year. Currently, I am using only the months' weekdays. -- Standa L?zni?ka -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 4 14:20:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 4 Nov 2015 15:20:18 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5639FE27.1040605@redhat.com> References: <5639FE27.1040605@redhat.com> Message-ID: <563A1422.6020906@redhat.com> On 04.11.2015 13:46, Stanislav Laznicka wrote: > Hi, > > The fixed patches to Martin^2's and Jakub's reviews are almost ready, > there are just a few things left. Martin B. mentioned in his review > that '~' might not be the best delimiter for range values in the HBAC > time policies language as it is not commonly used for that purpose. I > started using it when the negative values were introduced (instead of > '-'). > > The question here is, then, which delimiter would you rather use for > ranges? Some choices are ':', '..', and, obviously, '~' but you are > free to come up with your own. The delimiters '-' and ',' are not > suitable as their use is different here. However small this might seem > to be, lets be rigorous here and design it properly. > > Also, with some time, I got uncertain about one thing with the > 'repeat' keyword. What behaviour would you expect when 'repeat' is on > yearly repetition and 'dayofweek' is the only other thing set? RFC5545 > (iCal) says: > " > Information, not contained in the rule, necessary to determine the > various recurrence instance start time and dates are derived from > the Start Time ("DTSTART") component attribute. For example, > "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the > month or a time. This information would be the same as what is > specified for "DTSTART". > " > and also in an example > > "... if the BYMINUTE, BYHOUR, BYDAY, > BYMONTHDAY, or BYMONTH rule part were missing, the appropriate > minute, hour, day, or month would have been retrieved from the > "DTSTART" property.", > > but an example with BYDAY alone set with a day of week without > numerical specifier is missing so it is not clear if this would apply > to all specified weekdays of a certain month or the whole year. > Currently, I am using only the months' weekdays. > > -- > Standa L?zni?ka Hello, we (Standa and I) had offline discussion and I proposed following idea: 1) create new entry in LDAP for "time rule" instead of adding the time rule string directly into HBACRule. This will allow to reuse time rules among various HBAC Rules (and maybe in future with sudo rules, etc.) HBACrule gets only reference to time rule entry stored in LDAP db. 2) Do not create a new time format, just reuse iCal (parts of iCal we need), to store time rule in LDAP in "time rule" entry (Or is possible to not store the values just as one string, we can use different attributes to store separate values, iCal can be used as export and import format) 3) We may provide nice CLI and webUI to construct/show "time rule", this may be more user friendly than just passing the string containing time data to HBAC rule. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 4 15:16:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 4 Nov 2015 16:16:40 +0100 Subject: [Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records Message-ID: <563A2158.80009@redhat.com> Patch attached. https://fedorahosted.org/freeipa/ticket/5421 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0344-Use-absolute-domain-in-detection-of-A-AAAA-records.patch Type: text/x-patch Size: 1133 bytes Desc: not available URL: From abokovoy at redhat.com Wed Nov 4 16:12:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Nov 2015 18:12:52 +0200 Subject: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires In-Reply-To: <20151103074402.GB4962@mail.corp.redhat.com> References: <20151103074402.GB4962@mail.corp.redhat.com> Message-ID: <20151104161252.GF8374@redhat.com> On Tue, 03 Nov 2015, Lukas Slebodnik wrote: >>From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 >From: Lukas Slebodnik >Date: Mon, 2 Nov 2015 19:52:57 +0000 >Subject: [PATCH] SPEC: Drop sssd from BuildRequires > >Packaging of sssd was changed and more sub-packages are build >from sssd.src.rpm. Especially python bindings and development packages >are already in sub-packages. As a result of this change the meta package >sssd can be removed from BuildRequires without any problem. > >FreeIPA spec file contained build requirement for latest version of >sssd even though the latest sssd was not required for building >FreeIPA rpms. In many cases, it was sufficient just to change requirements >for FreeIPA packages instead of build requirements. ACK -- we have explicit requirements to separate SSSD components (libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). Perhaps, telling that your goal is to build without SSSD is somewhat misleading -- SSSD subpackages will be installed anyway and at least 1.12.1 will be required. -- / Alexander Bokovoy From pvoborni at redhat.com Wed Nov 4 17:50:34 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 4 Nov 2015 18:50:34 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <5639FA77.3090907@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> <5639FA77.3090907@redhat.com> Message-ID: <563A456A.2070101@redhat.com> On 11/04/2015 01:30 PM, Martin Babinsky wrote: > On 10/30/2015 05:06 PM, Martin Babinsky wrote: >> On 10/30/2015 03:38 PM, Petr Vobornik wrote: >>> On 10/30/2015 03:26 PM, Martin Babinsky wrote: >>>> patch for https://fedorahosted.org/freeipa/ticket/5309 >>>> >>>> The ticket itself is about connectivity checks in topology suffixes, >>>> but >>>> there is a code (install/tools/ipa-replica-manage starting at line 788 >>>> after applying my patch) which monitors whether the segments pointing >>>> to/from the deleted host are already deleted. >>>> >>>> These checks are currently hardcoded for 'realm' prefix, should we >>>> generalize them as well or is it a part of other effort? >>>> >>> >>> Could be separate patch but yes. >> Ok I have included it in the attached patch so that both of these >> operations are performed for all suffixes. >> >> >> > Hmm, I'm thinking whether the 'check_last_link_managed' and > 'check_deleted_segments' should not be called per-suffix, but should > themselves check all suffixes available. This could make the fix for > https://fedorahosted.org/freeipa/ticket/5409 also easier. > Depends if the output is reusable. If so then why not. check_last_link_managed basically adds text to several get_topology_connection_errors calls. -- Petr Vobornik From redhatrises at gmail.com Thu Nov 5 02:48:01 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 4 Nov 2015 19:48:01 -0700 Subject: [Freeipa-devel] [PATCH 0062] custodia: ipa-upgrade failed on replica Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5374. I could reproduce it as the Custodia update file was missing from the updates Makefile which in turn was not being packaged into the rpms. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0062-custodia-ipa-upgrade-failed-on-replica.patch Type: text/x-patch Size: 820 bytes Desc: not available URL: From akasurde at redhat.com Thu Nov 5 06:58:54 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 5 Nov 2015 12:28:54 +0530 Subject: [Freeipa-devel] [PATCH] Normalize manager name in user-add Message-ID: <563AFE2E.8050700@redhat.com> Hi All, Please find the patch for https://fedorahosted.org/freeipa/ticket/5387 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-1-Added-fix-to-normalize-manager-name-in-user-add.patch Type: text/x-patch Size: 1084 bytes Desc: not available URL: From lslebodn at redhat.com Thu Nov 5 07:13:38 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 5 Nov 2015 08:13:38 +0100 Subject: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires In-Reply-To: <20151104161252.GF8374@redhat.com> References: <20151103074402.GB4962@mail.corp.redhat.com> <20151104161252.GF8374@redhat.com> Message-ID: <20151105071337.GA10853@mail.corp.redhat.com> On (04/11/15 18:12), Alexander Bokovoy wrote: >On Tue, 03 Nov 2015, Lukas Slebodnik wrote: >>>From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 >>From: Lukas Slebodnik >>Date: Mon, 2 Nov 2015 19:52:57 +0000 >>Subject: [PATCH] SPEC: Drop sssd from BuildRequires >> >>Packaging of sssd was changed and more sub-packages are build >>from sssd.src.rpm. Especially python bindings and development packages >>are already in sub-packages. As a result of this change the meta package >>sssd can be removed from BuildRequires without any problem. >> >>FreeIPA spec file contained build requirement for latest version of >>sssd even though the latest sssd was not required for building >>FreeIPA rpms. In many cases, it was sufficient just to change requirements >>for FreeIPA packages instead of build requirements. >ACK -- we have explicit requirements to separate SSSD components >(libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). > Thank you very much for review. >Perhaps, telling that your goal is to build without SSSD is somewhat >misleading -- SSSD subpackages will be installed anyway and at least >1.12.1 will be required. > Did we test the same patch? I cannot see installed sssd in build root on rawhide http://paste.fedoraproject.org/287115/46707060 [build at 526468c6ceac rpms]$ grep sssd root.log [build at 526468c6ceac rpms]$ grep 1.13.1-4.fc24 root.log DEBUG util.py:393: libipa_hbac x86_64 1.13.1-4.fc24 fedora 73 k DEBUG util.py:393: libsss_idmap x86_64 1.13.1-4.fc24 fedora 77 k DEBUG util.py:393: libsss_idmap-devel x86_64 1.13.1-4.fc24 fedora 140 k DEBUG util.py:393: libsss_nss_idmap x86_64 1.13.1-4.fc24 fedora 77 k DEBUG util.py:393: libsss_nss_idmap-devel x86_64 1.13.1-4.fc24 fedora 125 k DEBUG util.py:393: python-libipa_hbac x86_64 1.13.1-4.fc24 fedora 68 k DEBUG util.py:393: [SKIPPED] python-libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_idmap-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: Installing : libsss_nss_idmap-1.13.1-4.fc24.x86_64 91/241 DEBUG util.py:393: Installing : libsss_idmap-1.13.1-4.fc24.x86_64 92/241 DEBUG util.py:393: Installing : libipa_hbac-1.13.1-4.fc24.x86_64 195/241 DEBUG util.py:393: Installing : python-libipa_hbac-1.13.1-4.fc24.x86_64 212/241 DEBUG util.py:393: Installing : libsss_idmap-devel-1.13.1-4.fc24.x86_64 224/241 DEBUG util.py:393: Installing : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 225/241 DEBUG util.py:393: Verifying : python-libipa_hbac-1.13.1-4.fc24.x86_64 19/241 DEBUG util.py:393: Verifying : libipa_hbac-1.13.1-4.fc24.x86_64 77/241 DEBUG util.py:393: Verifying : libsss_idmap-devel-1.13.1-4.fc24.x86_64 187/241 DEBUG util.py:393: Verifying : libsss_idmap-1.13.1-4.fc24.x86_64 188/241 DEBUG util.py:393: Verifying : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 189/241 DEBUG util.py:393: Verifying : libsss_nss_idmap-1.13.1-4.fc24.x86_64 190/241 DEBUG util.py:393: libipa_hbac.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_idmap.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_idmap-devel.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_nss_idmap.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_nss_idmap-devel.x86_64 1.13.1-4.fc24 DEBUG util.py:393: python-libipa_hbac.x86_64 1.13.1-4.fc24 and freeipa packages were successfully built. http://paste.fedoraproject.org/287118/07222144 LS From abokovoy at redhat.com Thu Nov 5 07:24:13 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Nov 2015 09:24:13 +0200 Subject: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires In-Reply-To: <20151105071337.GA10853@mail.corp.redhat.com> References: <20151103074402.GB4962@mail.corp.redhat.com> <20151104161252.GF8374@redhat.com> <20151105071337.GA10853@mail.corp.redhat.com> Message-ID: <20151105072413.GL8374@redhat.com> On Thu, 05 Nov 2015, Lukas Slebodnik wrote: >On (04/11/15 18:12), Alexander Bokovoy wrote: >>On Tue, 03 Nov 2015, Lukas Slebodnik wrote: >>>>From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 >>>From: Lukas Slebodnik >>>Date: Mon, 2 Nov 2015 19:52:57 +0000 >>>Subject: [PATCH] SPEC: Drop sssd from BuildRequires >>> >>>Packaging of sssd was changed and more sub-packages are build >>>from sssd.src.rpm. Especially python bindings and development packages >>>are already in sub-packages. As a result of this change the meta package >>>sssd can be removed from BuildRequires without any problem. >>> >>>FreeIPA spec file contained build requirement for latest version of >>>sssd even though the latest sssd was not required for building >>>FreeIPA rpms. In many cases, it was sufficient just to change requirements >>>for FreeIPA packages instead of build requirements. >>ACK -- we have explicit requirements to separate SSSD components >>(libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). >> >Thank you very much for review. > >>Perhaps, telling that your goal is to build without SSSD is somewhat >>misleading -- SSSD subpackages will be installed anyway and at least >>1.12.1 will be required. >> >Did we test the same patch? > >I cannot see installed sssd in build root on rawhide >http://paste.fedoraproject.org/287115/46707060 > >[build at 526468c6ceac rpms]$ grep sssd root.log >[build at 526468c6ceac rpms]$ grep 1.13.1-4.fc24 root.log >DEBUG util.py:393: libipa_hbac x86_64 1.13.1-4.fc24 >fedora 73 k >DEBUG util.py:393: libsss_idmap x86_64 1.13.1-4.fc24 >fedora 77 k >DEBUG util.py:393: libsss_idmap-devel x86_64 1.13.1-4.fc24 >fedora 140 k >DEBUG util.py:393: libsss_nss_idmap x86_64 1.13.1-4.fc24 >fedora 77 k >DEBUG util.py:393: libsss_nss_idmap-devel x86_64 1.13.1-4.fc24 >fedora 125 k >DEBUG util.py:393: python-libipa_hbac x86_64 1.13.1-4.fc24 >fedora 68 k >DEBUG util.py:393: [SKIPPED] python-libipa_hbac-1.13.1-4.fc24.x86_64.rpm: >Already downloaded >DEBUG util.py:393: [SKIPPED] libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already >downloaded >DEBUG util.py:393: [SKIPPED] libsss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >Already downloaded >DEBUG util.py:393: [SKIPPED] libsss_idmap-1.13.1-4.fc24.x86_64.rpm: Already >downloaded >DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >Already downloaded >DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-1.13.1-4.fc24.x86_64.rpm: >Already downloaded >DEBUG util.py:393: Installing : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >91/241 >DEBUG util.py:393: Installing : libsss_idmap-1.13.1-4.fc24.x86_64 >92/241 >DEBUG util.py:393: Installing : libipa_hbac-1.13.1-4.fc24.x86_64 >195/241 >DEBUG util.py:393: Installing : python-libipa_hbac-1.13.1-4.fc24.x86_64 >212/241 >DEBUG util.py:393: Installing : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >224/241 >DEBUG util.py:393: Installing : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >225/241 >DEBUG util.py:393: Verifying : python-libipa_hbac-1.13.1-4.fc24.x86_64 >19/241 >DEBUG util.py:393: Verifying : libipa_hbac-1.13.1-4.fc24.x86_64 >77/241 >DEBUG util.py:393: Verifying : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >187/241 >DEBUG util.py:393: Verifying : libsss_idmap-1.13.1-4.fc24.x86_64 >188/241 >DEBUG util.py:393: Verifying : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >189/241 >DEBUG util.py:393: Verifying : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >190/241 >DEBUG util.py:393: libipa_hbac.x86_64 1.13.1-4.fc24 >DEBUG util.py:393: libsss_idmap.x86_64 1.13.1-4.fc24 >DEBUG util.py:393: libsss_idmap-devel.x86_64 1.13.1-4.fc24 >DEBUG util.py:393: libsss_nss_idmap.x86_64 1.13.1-4.fc24 >DEBUG util.py:393: libsss_nss_idmap-devel.x86_64 1.13.1-4.fc24 >DEBUG util.py:393: python-libipa_hbac.x86_64 1.13.1-4.fc24 > >and freeipa packages were successfully built. >http://paste.fedoraproject.org/287118/07222144 Right and as I said, SSSD subpackages are installed. You listed them above. That's all we needed. -- / Alexander Bokovoy From lslebodn at redhat.com Thu Nov 5 07:40:13 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 5 Nov 2015 08:40:13 +0100 Subject: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires In-Reply-To: <20151105072413.GL8374@redhat.com> References: <20151103074402.GB4962@mail.corp.redhat.com> <20151104161252.GF8374@redhat.com> <20151105071337.GA10853@mail.corp.redhat.com> <20151105072413.GL8374@redhat.com> Message-ID: <20151105074012.GB10853@mail.corp.redhat.com> On (05/11/15 09:24), Alexander Bokovoy wrote: >On Thu, 05 Nov 2015, Lukas Slebodnik wrote: >>On (04/11/15 18:12), Alexander Bokovoy wrote: >>>On Tue, 03 Nov 2015, Lukas Slebodnik wrote: >>>>>From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 >>>>From: Lukas Slebodnik >>>>Date: Mon, 2 Nov 2015 19:52:57 +0000 >>>>Subject: [PATCH] SPEC: Drop sssd from BuildRequires >>>> >>>>Packaging of sssd was changed and more sub-packages are build >>>>from sssd.src.rpm. Especially python bindings and development packages >>>>are already in sub-packages. As a result of this change the meta package >>>>sssd can be removed from BuildRequires without any problem. >>>> >>>>FreeIPA spec file contained build requirement for latest version of >>>>sssd even though the latest sssd was not required for building >>>>FreeIPA rpms. In many cases, it was sufficient just to change requirements >>>>for FreeIPA packages instead of build requirements. >>>ACK -- we have explicit requirements to separate SSSD components >>>(libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). >>> >>Thank you very much for review. >> >>>Perhaps, telling that your goal is to build without SSSD is somewhat >>>misleading -- SSSD subpackages will be installed anyway and at least >>>1.12.1 will be required. >>> >>Did we test the same patch? >> >>I cannot see installed sssd in build root on rawhide >>http://paste.fedoraproject.org/287115/46707060 >> >>[build at 526468c6ceac rpms]$ grep sssd root.log >>[build at 526468c6ceac rpms]$ grep 1.13.1-4.fc24 root.log >>DEBUG util.py:393: libipa_hbac x86_64 1.13.1-4.fc24 >>fedora 73 k >>DEBUG util.py:393: libsss_idmap x86_64 1.13.1-4.fc24 >>fedora 77 k >>DEBUG util.py:393: libsss_idmap-devel x86_64 1.13.1-4.fc24 >>fedora 140 k >>DEBUG util.py:393: libsss_nss_idmap x86_64 1.13.1-4.fc24 >>fedora 77 k >>DEBUG util.py:393: libsss_nss_idmap-devel x86_64 1.13.1-4.fc24 >>fedora 125 k >>DEBUG util.py:393: python-libipa_hbac x86_64 1.13.1-4.fc24 >>fedora 68 k >>DEBUG util.py:393: [SKIPPED] python-libipa_hbac-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: [SKIPPED] libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already >>downloaded >>DEBUG util.py:393: [SKIPPED] libsss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: [SKIPPED] libsss_idmap-1.13.1-4.fc24.x86_64.rpm: Already >>downloaded >>DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: Installing : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >>91/241 >>DEBUG util.py:393: Installing : libsss_idmap-1.13.1-4.fc24.x86_64 >>92/241 >>DEBUG util.py:393: Installing : libipa_hbac-1.13.1-4.fc24.x86_64 >>195/241 >>DEBUG util.py:393: Installing : python-libipa_hbac-1.13.1-4.fc24.x86_64 >>212/241 >>DEBUG util.py:393: Installing : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >>224/241 >>DEBUG util.py:393: Installing : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >>225/241 >>DEBUG util.py:393: Verifying : python-libipa_hbac-1.13.1-4.fc24.x86_64 >>19/241 >>DEBUG util.py:393: Verifying : libipa_hbac-1.13.1-4.fc24.x86_64 >>77/241 >>DEBUG util.py:393: Verifying : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >>187/241 >>DEBUG util.py:393: Verifying : libsss_idmap-1.13.1-4.fc24.x86_64 >>188/241 >>DEBUG util.py:393: Verifying : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >>189/241 >>DEBUG util.py:393: Verifying : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >>190/241 >>DEBUG util.py:393: libipa_hbac.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_idmap.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_idmap-devel.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_nss_idmap.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_nss_idmap-devel.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: python-libipa_hbac.x86_64 1.13.1-4.fc24 >> >>and freeipa packages were successfully built. >>http://paste.fedoraproject.org/287118/07222144 >Right and as I said, SSSD subpackages are installed. You listed them >above. That's all we needed. Ahh, I'm sorry. I misread the sentense. I saw "sssd pacakge" instead of "sssd subpackages" LS From ofayans at redhat.com Thu Nov 5 07:45:31 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 5 Nov 2015 08:45:31 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC In-Reply-To: <56337745.109@redhat.com> References: <56337745.109@redhat.com> Message-ID: <563B091B.3010501@redhat.com> Hi Jan, Could you take a look at these, whenever you are free? On 10/30/2015 02:57 PM, Oleg Fayans wrote: > Hi, > > The following patches contain updates to ca-less integration tests. > It's still a proof of concept: 2 tests still fail seemingly due to the > change in target system logic (marked as xfail with "ask jcholast comment") > > The test output looks like this: > > $ ipa-run-tests test_integration/test_caless.py --pdb > ==================================================================================== > test session starts > ===================================================================================== > > platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 > plugins: multihost, sourceorder > collected 88 items > > test_integration/test_caless.py > ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. > > > ==================================================================== 53 > passed, 29 skipped, 6 xfailed in 5620.17 seconds > ===================================================================== > > Numerous skips correspond to the tests related to ipa-replica-prepare > (unsupported under domain level 1) > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From jcholast at redhat.com Thu Nov 5 09:34:03 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 5 Nov 2015 10:34:03 +0100 Subject: [Freeipa-devel] [PATCH 505] install: fix command line option validation In-Reply-To: <5638BEC1.6000405@redhat.com> References: <56387345.1040200@redhat.com> <5638BEC1.6000405@redhat.com> Message-ID: <563B228B.7050202@redhat.com> On 3.11.2015 15:03, Martin Babinsky wrote: > On 11/03/2015 09:41 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes: >> >> >> >> >> Honza >> >> >> > Once more for the whole list, ACK. Thanks. Pushed to: master: 6a55174bb6c24632bbd46c8421399343e1282ce0 ipa-4-2: 09d47c44986e8f0daad374f8adcfee70fad38a3a -- Jan Cholasta From mbasti at redhat.com Thu Nov 5 09:55:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 Nov 2015 10:55:23 +0100 Subject: [Freeipa-devel] [PATCH] Normalize manager name in user-add In-Reply-To: <563AFE2E.8050700@redhat.com> References: <563AFE2E.8050700@redhat.com> Message-ID: <563B278B.9020406@redhat.com> On 05.11.2015 07:58, Abhijeet Kasurde wrote: > Hi All, > > Please find the patch for https://fedorahosted.org/freeipa/ticket/5387 > > Thanks, > Abhijeet Kasurde > > Hello, I'm sorry I forgot to mark "patch posted for review", but the ticket is marked as assigned, that means the somebody (me in this case) is working on it. I posted patch 332. Due the ticket https://fedorahosted.org/freeipa/ticket/5344 I will change multiple parts of user plugin code, and the normalization of manager will be done in different way. So even my patch 332 is not valid anymore. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Nov 5 10:10:39 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 5 Nov 2015 11:10:39 +0100 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust In-Reply-To: <20151031103813.GW8374@redhat.com> References: <20151030065431.GI8374@redhat.com> <563327F3.7090703@redhat.com> <20151030101029.GN8374@redhat.com> <5633429C.7090401@redhat.com> <20151031103813.GW8374@redhat.com> Message-ID: <563B2B1F.7080301@redhat.com> On 10/31/2015 11:38 AM, Alexander Bokovoy wrote: > On Fri, 30 Oct 2015, Gabe Alford wrote: >> Okay. Added the port range to ipa-adtrust-install and updated the man >> page >> to reflect firewall requirements. >> The firewall section seems a little rough, so let me know what you >> think it >> would need to be smoothed over (if anything). > Thanks, this is a good start. I'm sure we can improve it later, when > Samba adds configurable setup for the ports. > > ACK Pushed to master: a566657f9d73a01b08017d251c4a0776d46265e2 Pushed to ipa-4-2: e76e86656ae5c8f5e59a340e1ab4f9d107af7916 From akasurde at redhat.com Thu Nov 5 10:18:52 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 5 Nov 2015 15:48:52 +0530 Subject: [Freeipa-devel] [PATCH] Normalize manager name in user-add In-Reply-To: <563B278B.9020406@redhat.com> References: <563AFE2E.8050700@redhat.com> <563B278B.9020406@redhat.com> Message-ID: <563B2D0C.8060706@redhat.com> On 11/05/2015 03:25 PM, Martin Basti wrote: > > > On 05.11.2015 07:58, Abhijeet Kasurde wrote: >> Hi All, >> >> Please find the patch for https://fedorahosted.org/freeipa/ticket/5387 >> >> Thanks, >> Abhijeet Kasurde >> >> > Hello, > > I'm sorry I forgot to mark "patch posted for review", but the ticket > is marked as assigned, that means the somebody (me in this case) is > working on it. > I posted patch 332. > > Due the ticket https://fedorahosted.org/freeipa/ticket/5344 I will > change multiple parts of user plugin code, and the normalization of > manager will be done in different way. So even my patch 332 is not > valid anymore. No issues. Thanks for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Thu Nov 5 10:20:39 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 5 Nov 2015 11:20:39 +0100 Subject: [Freeipa-devel] [patch 0023] Applied tier0 and tier1 marks on unit tests and xmlrpc tests Message-ID: <563B2D77.8040701@redhat.com> Hi list, these patches introduce the tier categorization into the tests using pytest's mark mechanism. It is a step towards a change in our CI with which we hope to get more usefull/readable results as well as allow us to structure our CI in more logical way. Because of technical reasons, all tests that are subclasses of `Declarative` class are marked as tier1 tests. In these tests, if one suite is marked, all of the Declarative tests will be run as a big blob. The marks are not set in stone, please provide some feedback if you think some of the tests shoult go elsewhere. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0023-Applied-tier0-and-tier1-marks-on-unit-tests-and-xmlr.patch Type: text/x-patch Size: 89164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0023-Applied-tier0-and-tier1-marks-on-unit-tests-and-xmlr.patch Type: text/x-patch Size: 88608 bytes Desc: not available URL: From ofayans at redhat.com Thu Nov 5 10:28:55 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 5 Nov 2015 11:28:55 +0100 Subject: [Freeipa-devel] is installation broken in upstream? Message-ID: <563B2F67.9060300@redhat.com> Hi all, Having built the latest upstream code locally I am getting the following weird messages at the attempt to install the bits: $ dnf install freeipa-* -y Last metadata expiration check performed 1 day, 4:09:14 ago on Wed Nov 4 07:13:28 2015. Error: nothing provides installed needed by freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64. nothing provides installed needed by freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64. nothing provides installed needed by freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages) -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Nov 5 10:34:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 Nov 2015 11:34:18 +0100 Subject: [Freeipa-devel] [PATCH 0062] custodia: ipa-upgrade failed on replica In-Reply-To: References: Message-ID: <563B30AA.8040701@redhat.com> On 05.11.2015 03:48, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5374. I could > reproduce it as the Custodia update file was missing from the updates > Makefile which in turn was not being packaged into the rpms. > > Thanks, > > Gabe > > Thank you! ACK I synced my local files directly to server, so that was the reason why I cannot be able to reproduce it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 5 10:36:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 Nov 2015 11:36:46 +0100 Subject: [Freeipa-devel] is installation broken in upstream? In-Reply-To: <563B2F67.9060300@redhat.com> References: <563B2F67.9060300@redhat.com> Message-ID: <563B313E.1070903@redhat.com> On 05.11.2015 11:28, Oleg Fayans wrote: > Hi all, > > > Having built the latest upstream code locally I am getting the > following weird messages at the attempt to install the bits: > > $ dnf install freeipa-* -y > Last metadata expiration check performed 1 day, 4:09:14 ago on Wed Nov > 4 07:13:28 2015. > Error: nothing provides installed needed by > freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64. > nothing provides installed needed by > freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64. > nothing provides installed needed by > freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64 > (try to add '--allowerasing' to command line to replace conflicting > packages) > Can it be caused with dogtag? We changed depndencies pki-ca from 10.2.7 to 10.2.6-10, 10.2.7 is not released and is not available in repos. Which package is erased with option '--allowerasing' ? Martin From ofayans at redhat.com Thu Nov 5 10:43:54 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 5 Nov 2015 11:43:54 +0100 Subject: [Freeipa-devel] is installation broken in upstream? In-Reply-To: <563B313E.1070903@redhat.com> References: <563B2F67.9060300@redhat.com> <563B313E.1070903@redhat.com> Message-ID: <563B32EA.9020601@redhat.com> Hi Martin, On 11/05/2015 11:36 AM, Martin Basti wrote: > > > On 05.11.2015 11:28, Oleg Fayans wrote: >> Hi all, >> >> >> Having built the latest upstream code locally I am getting the >> following weird messages at the attempt to install the bits: >> >> $ dnf install freeipa-* -y >> Last metadata expiration check performed 1 day, 4:09:14 ago on Wed Nov >> 4 07:13:28 2015. >> Error: nothing provides installed needed by >> freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64. >> nothing provides installed needed by >> freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64. >> nothing provides installed needed by >> freeipa-server-4.2.90.201511051010GITa566657-0.fc22.x86_64 >> (try to add '--allowerasing' to command line to replace conflicting >> packages) >> > Can it be caused with dogtag? We changed depndencies pki-ca from 10.2.7 > to 10.2.6-10, 10.2.7 is not released and is not available in repos. > > Which package is erased with option '--allowerasing' ? > > Martin I just fetched the packages built in jeknins and they were successfully installed with --allowerasing option. The packages erased were: pki-ca-10.2.7-0.2.fc22.noarch pki-server-10.2.7-0.2.fc22.noarch pki-tools-10.2.7-0.2.fc22.x86_64 pki-base-10.2.7-0.2.fc22.noarch my initial problem was seemingly caused by something else, non-related to the upstream code. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Nov 5 10:47:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 Nov 2015 11:47:42 +0100 Subject: [Freeipa-devel] [PATCH 0062] custodia: ipa-upgrade failed on replica In-Reply-To: <563B30AA.8040701@redhat.com> References: <563B30AA.8040701@redhat.com> Message-ID: <563B33CE.8010305@redhat.com> On 05.11.2015 11:34, Martin Basti wrote: > > > On 05.11.2015 03:48, Gabe Alford wrote: >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5374. I could >> reproduce it as the Custodia update file was missing from the updates >> Makefile which in turn was not being packaged into the rpms. >> >> Thanks, >> >> Gabe >> >> > > Thank you! ACK > > I synced my local files directly to server, so that was the reason why > I cannot be able to reproduce it. > > > Pushed to master: 1e91ef33b522c3b316c7917379e56c168b1e2d52 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Thu Nov 5 11:20:29 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 5 Nov 2015 12:20:29 +0100 Subject: [Freeipa-devel] [patch 0023] Applied tier0 and tier1 marks on unit tests and xmlrpc tests In-Reply-To: <563B2D77.8040701@redhat.com> References: <563B2D77.8040701@redhat.com> Message-ID: <563B3B7D.3000103@redhat.com> On 11/05/2015 11:20 AM, Milan Kub?k wrote: > Hi list, > > these patches introduce the tier categorization into the tests using > pytest's mark mechanism. It is a step towards a change in our CI > with which we hope to get more usefull/readable results as well as > allow us to structure our CI in more logical way. > > Because of technical reasons, all tests that are subclasses of > `Declarative` > class are marked as tier1 tests. In these tests, if one suite is > marked, all of > the Declarative tests will be run as a big blob. > > The marks are not set in stone, please provide some feedback if you think > some of the tests shoult go elsewhere. > > > Self NACK after irc nitpick. Fixed pep8 complaints. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0023-2-Applied-tier0-and-tier1-marks-on-unit-tests-and-xmlr.patch Type: text/x-patch Size: 89149 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0023-2-Applied-tier0-and-tier1-marks-on-unit-tests-and-xmlr.patch Type: text/x-patch Size: 88590 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 5 12:38:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 5 Nov 2015 13:38:14 +0100 Subject: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires In-Reply-To: <20151105074012.GB10853@mail.corp.redhat.com> References: <20151103074402.GB4962@mail.corp.redhat.com> <20151104161252.GF8374@redhat.com> <20151105071337.GA10853@mail.corp.redhat.com> <20151105072413.GL8374@redhat.com> <20151105074012.GB10853@mail.corp.redhat.com> Message-ID: <563B4DB6.10105@redhat.com> On 05.11.2015 08:40, Lukas Slebodnik wrote: > On (05/11/15 09:24), Alexander Bokovoy wrote: >> On Thu, 05 Nov 2015, Lukas Slebodnik wrote: >>> On (04/11/15 18:12), Alexander Bokovoy wrote: >>>> On Tue, 03 Nov 2015, Lukas Slebodnik wrote: >>>>> >From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 >>>>> From: Lukas Slebodnik >>>>> Date: Mon, 2 Nov 2015 19:52:57 +0000 >>>>> Subject: [PATCH] SPEC: Drop sssd from BuildRequires >>>>> >>>>> Packaging of sssd was changed and more sub-packages are build >>>> >from sssd.src.rpm. Especially python bindings and development packages >>>>> are already in sub-packages. As a result of this change the meta package >>>>> sssd can be removed from BuildRequires without any problem. >>>>> >>>>> FreeIPA spec file contained build requirement for latest version of >>>>> sssd even though the latest sssd was not required for building >>>>> FreeIPA rpms. In many cases, it was sufficient just to change requirements >>>>> for FreeIPA packages instead of build requirements. >>>> ACK -- we have explicit requirements to separate SSSD components >>>> (libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). >>>> >>> Thank you very much for review. >>> >>>> Perhaps, telling that your goal is to build without SSSD is somewhat >>>> misleading -- SSSD subpackages will be installed anyway and at least >>>> 1.12.1 will be required. >>>> >>> Did we test the same patch? >>> >>> I cannot see installed sssd in build root on rawhide >>> http://paste.fedoraproject.org/287115/46707060 >>> >>> [build at 526468c6ceac rpms]$ grep sssd root.log >>> [build at 526468c6ceac rpms]$ grep 1.13.1-4.fc24 root.log >>> DEBUG util.py:393: libipa_hbac x86_64 1.13.1-4.fc24 >>> fedora 73 k >>> DEBUG util.py:393: libsss_idmap x86_64 1.13.1-4.fc24 >>> fedora 77 k >>> DEBUG util.py:393: libsss_idmap-devel x86_64 1.13.1-4.fc24 >>> fedora 140 k >>> DEBUG util.py:393: libsss_nss_idmap x86_64 1.13.1-4.fc24 >>> fedora 77 k >>> DEBUG util.py:393: libsss_nss_idmap-devel x86_64 1.13.1-4.fc24 >>> fedora 125 k >>> DEBUG util.py:393: python-libipa_hbac x86_64 1.13.1-4.fc24 >>> fedora 68 k >>> DEBUG util.py:393: [SKIPPED] python-libipa_hbac-1.13.1-4.fc24.x86_64.rpm: >>> Already downloaded >>> DEBUG util.py:393: [SKIPPED] libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already >>> downloaded >>> DEBUG util.py:393: [SKIPPED] libsss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >>> Already downloaded >>> DEBUG util.py:393: [SKIPPED] libsss_idmap-1.13.1-4.fc24.x86_64.rpm: Already >>> downloaded >>> DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >>> Already downloaded >>> DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-1.13.1-4.fc24.x86_64.rpm: >>> Already downloaded >>> DEBUG util.py:393: Installing : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >>> 91/241 >>> DEBUG util.py:393: Installing : libsss_idmap-1.13.1-4.fc24.x86_64 >>> 92/241 >>> DEBUG util.py:393: Installing : libipa_hbac-1.13.1-4.fc24.x86_64 >>> 195/241 >>> DEBUG util.py:393: Installing : python-libipa_hbac-1.13.1-4.fc24.x86_64 >>> 212/241 >>> DEBUG util.py:393: Installing : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >>> 224/241 >>> DEBUG util.py:393: Installing : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >>> 225/241 >>> DEBUG util.py:393: Verifying : python-libipa_hbac-1.13.1-4.fc24.x86_64 >>> 19/241 >>> DEBUG util.py:393: Verifying : libipa_hbac-1.13.1-4.fc24.x86_64 >>> 77/241 >>> DEBUG util.py:393: Verifying : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >>> 187/241 >>> DEBUG util.py:393: Verifying : libsss_idmap-1.13.1-4.fc24.x86_64 >>> 188/241 >>> DEBUG util.py:393: Verifying : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >>> 189/241 >>> DEBUG util.py:393: Verifying : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >>> 190/241 >>> DEBUG util.py:393: libipa_hbac.x86_64 1.13.1-4.fc24 >>> DEBUG util.py:393: libsss_idmap.x86_64 1.13.1-4.fc24 >>> DEBUG util.py:393: libsss_idmap-devel.x86_64 1.13.1-4.fc24 >>> DEBUG util.py:393: libsss_nss_idmap.x86_64 1.13.1-4.fc24 >>> DEBUG util.py:393: libsss_nss_idmap-devel.x86_64 1.13.1-4.fc24 >>> DEBUG util.py:393: python-libipa_hbac.x86_64 1.13.1-4.fc24 >>> >>> and freeipa packages were successfully built. >>> http://paste.fedoraproject.org/287118/07222144 >> Right and as I said, SSSD subpackages are installed. You listed them >> above. That's all we needed. > Ahh, > > I'm sorry. > > I misread the sentense. I saw "sssd pacakge" instead of "sssd subpackages" > > LS > Pushed to master: 85253b9c40d2b2734a5ed761f324c6177d1a74bc From simo at redhat.com Thu Nov 5 14:41:21 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 5 Nov 2015 09:41:21 -0500 Subject: [Freeipa-devel] [BLOG] FreeIPA PKI: current plans and a future vision In-Reply-To: <20151104051417.GY20018@dhcp-40-8.bne.redhat.com> References: <20151104051417.GY20018@dhcp-40-8.bne.redhat.com> Message-ID: <563B6A91.2060202@redhat.com> On 04/11/15 00:14, Fraser Tweedale wrote: > I have been alluding for a while about my ideas for future > FreeIPA/Dogtag PKI integration; I finally put the ideas down in a > blog post. If you are interested in this aspect of IdM please read > it; all feedback is welcome! > > http://blog-ftweedal.rhcloud.com/2015/11/freeipa-pki-current-plans-and-a-future-vision/ Great post Fraser! Simo -- Simo Sorce * Red Hat, Inc * New York From ofayans at redhat.com Thu Nov 5 14:41:26 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 5 Nov 2015 15:41:26 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC In-Reply-To: <563B091B.3010501@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> Message-ID: <563B6A96.8090606@redhat.com> Wait a bit, the patch has problems with pylint: it does not build :) The updated version (without the setupmaster nonsense) is being tested now. On 11/05/2015 08:45 AM, Oleg Fayans wrote: > Hi Jan, > > Could you take a look at these, whenever you are free? > > On 10/30/2015 02:57 PM, Oleg Fayans wrote: >> Hi, >> >> The following patches contain updates to ca-less integration tests. >> It's still a proof of concept: 2 tests still fail seemingly due to the >> change in target system logic (marked as xfail with "ask jcholast >> comment") >> >> The test output looks like this: >> >> $ ipa-run-tests test_integration/test_caless.py --pdb >> ==================================================================================== >> >> test session starts >> ===================================================================================== >> >> >> platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 >> plugins: multihost, sourceorder >> collected 88 items >> >> test_integration/test_caless.py >> ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. >> >> >> >> ==================================================================== 53 >> passed, 29 skipped, 6 xfailed in 5620.17 seconds >> ===================================================================== >> >> Numerous skips correspond to the tests related to ipa-replica-prepare >> (unsupported under domain level 1) >> >> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From amarecek at redhat.com Thu Nov 5 16:18:08 2015 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Thu, 5 Nov 2015 11:18:08 -0500 (EST) Subject: [Freeipa-devel] [patch 0023] Applied tier0 and tier1 marks on unit tests and xmlrpc tests In-Reply-To: <563B3B7D.3000103@redhat.com> References: <563B2D77.8040701@redhat.com> <563B3B7D.3000103@redhat.com> Message-ID: <2132789766.3606122.1446740288271.JavaMail.zimbra@redhat.com> Looks good, ACK. ----- Original Message ----- > From: "Milan Kub?k" > To: freeipa-devel at redhat.com > Sent: Thursday, November 5, 2015 12:20:29 PM > Subject: Re: [Freeipa-devel] [patch 0023] Applied tier0 and tier1 marks on unit tests and xmlrpc tests > > On 11/05/2015 11:20 AM, Milan Kub?k wrote: > > > Hi list, > > these patches introduce the tier categorization into the tests using > pytest's mark mechanism. It is a step towards a change in our CI > with which we hope to get more usefull/readable results as well as > allow us to structure our CI in more logical way. > > Because of technical reasons, all tests that are subclasses of `Declarative` > class are marked as tier1 tests. In these tests, if one suite is marked, all > of > the Declarative tests will be run as a big blob. > > The marks are not set in stone, please provide some feedback if you think > some of the tests shoult go elsewhere. > > > > Self NACK after irc nitpick. Fixed pep8 complaints. > > -- > Milan Kubik > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From pvoborni at redhat.com Thu Nov 5 16:51:32 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 5 Nov 2015 17:51:32 +0100 Subject: [Freeipa-devel] [PATCH 0092] ipa-replica-prepare: more robust and concise check for supported domain level In-Reply-To: <563226A5.30808@redhat.com> References: <5631F2C6.8010802@redhat.com> <56320C9A.4020109@redhat.com> <563210D3.8020209@redhat.com> <563226A5.30808@redhat.com> Message-ID: <563B8914.5090806@redhat.com> On 10/29/2015 03:01 PM, Martin Babinsky wrote: > On 10/29/2015 01:28 PM, Tomas Babej wrote: >> >> >> On 10/29/2015 01:10 PM, Petr Vobornik wrote: >>> On 10/29/2015 11:19 AM, Martin Babinsky wrote: >>>> Petr^2 and Tomas were not happy by the way >>>> https://fedorahosted.org/freeipa/ticket/5175 was handled initially, so >>>> here is a patch that tries to amend some of the issues. >>>> >>>> >>>> >>> >>> IMHO the original text was good. >>> >>> Tomas, why is the huge blob thing in exception bad? >>> >>> Issues with new code/text. >>> >>> 1. it is supported but not for domain level != 0: >>> self.log.error("Using replica files to set up IPA replicas is not " >>> + "supported." >>> + ) >>> >>> 2. format() is not needed: >>> + self.log.info( >>> + "To create a replica, you must promote an existing " >>> + "IPA client.".format(domain_level=domain_level) >>> + ) >>> >>> 3. I don't like that the exception text says 'requires', which might >>> imply something to be done - lower domain level - which is not possible. >>> "allowed only" might be better. >>> >>> >>> Just changing RuntimeError to InvalidDomainLevelError would be fine with >>> me since the MIN_DOMAIN_LEVEL was already changed to DOMAIN_LEVEL_0. >> >> >> I was fine with the old text too. In my opinion exceptions should not be >> used to handle detailed instructions to the user, they should be used to >> briefly summarize the gist of the error that occurred. >> >> If not bad practice, it's at least quite unconventional. There are >> better mechanisms to handle the detailed instructions spanning over >> multiple lines (with newlines hardcoded) down to the user, such as using >> the logger with sufficient level. >> >> So I would approach this issue by just dumping the formatted >> UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE down the logger at the error level and >> then raising the InvalidDomainLevelError exception with the brief >> reasoning. >> >> Tomas >> > OK i seemed to misunderstand your concerns. Attaching updated patch. > ACK Pushed to master: 4d94367006287ed0a04c092a7b86096518cf5b8c -- Petr Vobornik From pspacek at redhat.com Thu Nov 5 17:17:53 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 5 Nov 2015 18:17:53 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <563A1422.6020906@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> Message-ID: <563B8F41.8090902@redhat.com> On 4.11.2015 15:20, Martin Basti wrote: > > > On 04.11.2015 13:46, Stanislav Laznicka wrote: >> Hi, >> >> The fixed patches to Martin^2's and Jakub's reviews are almost ready, there >> are just a few things left. Martin B. mentioned in his review that '~' might >> not be the best delimiter for range values in the HBAC time policies >> language as it is not commonly used for that purpose. I started using it >> when the negative values were introduced (instead of '-'). >> >> The question here is, then, which delimiter would you rather use for ranges? >> Some choices are ':', '..', and, obviously, '~' but you are free to come up >> with your own. The delimiters '-' and ',' are not suitable as their use is >> different here. However small this might seem to be, lets be rigorous here >> and design it properly. >> >> Also, with some time, I got uncertain about one thing with the 'repeat' >> keyword. What behaviour would you expect when 'repeat' is on yearly >> repetition and 'dayofweek' is the only other thing set? RFC5545 (iCal) says: >> " >> Information, not contained in the rule, necessary to determine the >> various recurrence instance start time and dates are derived from >> the Start Time ("DTSTART") component attribute. For example, >> "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the >> month or a time. This information would be the same as what is >> specified for "DTSTART". >> " >> and also in an example >> >> "... if the BYMINUTE, BYHOUR, BYDAY, >> BYMONTHDAY, or BYMONTH rule part were missing, the appropriate >> minute, hour, day, or month would have been retrieved from the >> "DTSTART" property.", >> >> but an example with BYDAY alone set with a day of week without numerical >> specifier is missing so it is not clear if this would apply to all specified >> weekdays of a certain month or the whole year. Currently, I am using only >> the months' weekdays. >> >> -- >> Standa L?zni?ka > > Hello, > > we (Standa and I) had offline discussion and I proposed following idea: > > 1) create new entry in LDAP for "time rule" instead of adding the time rule > string directly into HBACRule. > This will allow to reuse time rules among various HBAC Rules (and maybe in > future with sudo rules, etc.) > HBACrule gets only reference to time rule entry stored in LDAP db. Good idea! I can see time rule entry 'working hours in Brno office' which is linked to relevant HBAC rules. > 2) Do not create a new time format, just reuse iCal (parts of iCal we need), > to store time rule in LDAP in "time rule" entry > (Or is possible to not store the values just as one string, we can use > different attributes to store separate values, iCal can be used as export and > import format) I very much agree with re-using iCal! We have sufficient number of custom parsers already ;-) Speaking about custom LDAP format, I do not think that it is a good idea. It would prevent us from using iCal parsers and generators and we would risk that our custom LDAP format will not be flexible enough. For these reasons I would go with 1 iCal string which can be fed into any standard-compliant iCal library. > 3) We may provide nice CLI and webUI to construct/show "time rule", this may > be more user friendly than just passing the string containing time data to > HBAC rule. This is going to be the same as in any calendaring system. Just look to Thunderbird "New Event" dialog. -- Petr^2 Spacek From pvoborni at redhat.com Thu Nov 5 17:27:33 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 5 Nov 2015 18:27:33 +0100 Subject: [Freeipa-devel] [PATCH 0338] Drop configure.jar file In-Reply-To: <56332AFF.8050904@redhat.com> References: <56332AFF.8050904@redhat.com> Message-ID: <563B9185.1050207@redhat.com> On 10/30/2015 09:31 AM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5144 > > Patch attached. > > configure.jar is basically a signed zip which contains preferences.html therefore also all references to preferences.html should be removed. ssbrowser.html: Also whole section "Automatic Configuration of older versions" should be removed. and list item: """
  • Import CA certificate. Make sure you checked all three checkboxes.
    • """ should be moved as a first item in the list in section

    Firefox

    -- Petr Vobornik From pvoborni at redhat.com Thu Nov 5 18:02:29 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 5 Nov 2015 19:02:29 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <56374AED.7030002@redhat.com> References: <5628A1F1.8050602@redhat.com> <5636F031.4000901@redhat.com> <56374AED.7030002@redhat.com> Message-ID: <563B99B5.8010205@redhat.com> On 11/02/2015 12:37 PM, Martin Kosek wrote: > On 11/02/2015 06:10 AM, Jan Cholasta wrote: >> Hi, >> >> On 22.10.2015 10:44, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5181 >> >> This should be handled by a separate object plugin: >> >> $ ipa servercomponent-find master.ipa.test >> --------------------------- >> 6 server components matched >> --------------------------- >> Component name: CA >> Enabled: TRUE >> Start order: 50 >> >> Component name: KDC >> Enabled: TRUE >> Start order: 10 >> >> Component name: KPASSWD >> Enabled: TRUE >> Start order: 20 >> >> Component name: MEMCACHE >> Enabled: TRUE >> Start order: 39 >> >> Component name: OTPD >> Enabled: TRUE >> Start order: 80 >> >> Component name: HTTP >> Enabled: TRUE >> Start order: 40 >> ---------------------------- >> Number of entries returned 6 >> ---------------------------- >> >> This will allow us to consolidate all the ad-hoc component-related code >> scattered throughout IPA (search for enable component, enable/disable >> component, ...) into IPA command calls. >> >> I'm not opposed to showing a summary in server-show (although we don't do >> anything like this for any other hierarchical objects), but it should be done >> just for the users' sake, not for internal use (the ticket suggests to use this >> for topology visualisation). >> >> BTW as far as the scalability of the current solution goes, you should have a >> list of all the *non*-optional components and display everything else. > > The API proposal should be in line with our future extensions of the API. We > for example want to move "ipa-csreplica-manage" set-renewal-master command to > API call. Or DNSSEC generation master. Or we may want to change some other > flag/role of a master via this interface. > > So we will need something like > $ ipa server-add-role ipa.example.com --role "ca-renewal-master" > or > $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master Depends on usage. If we want to internally unify manipulation with configs for component we can create low-level commands which won't be exposed to CLI. E.g. ipa servercomponent-find ipa.example.com Component name: ADTRUST Config: enabledService, startOrder 60 This is all what Web UI needs. From user perspective, for CLI, something different is better. Martin used term 'role', lets go with that. Idea 1: $ ipa server-show ipa.example.com --roles Server name: vm-073.idm.lab.eng.brq.redhat.com Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Role: dns-server, cs-server, ca-renewal-master, trust-controller --all would imply --roles $ ipa server-add-role ipa.example.com --roles=ca-renewal-master This is not good because this add operation will also remove a role from different master which could be unexpected. I.e. set-renewal-master might be a separate command. Same would apply to DNSSec generation masters. Idea 2: $ ipa serverrole-add ipa.example.com ca-renewal-master $ ipa serverrole-find ipa.example.com Role: dns-server Role: cs-server Role: ca-renewal-master Role: trust-controller All variants alone are fine for Web UI. -- Petr Vobornik From ofayans at redhat.com Thu Nov 5 19:20:12 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 5 Nov 2015 20:20:12 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC In-Reply-To: <563B6A96.8090606@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> Message-ID: <563BABEC.8080304@redhat.com> Patch 0014 updated and passes lint On 11/05/2015 03:41 PM, Oleg Fayans wrote: > Wait a bit, the patch has problems with pylint: it does not build :) > The updated version (without the setupmaster nonsense) is being tested now. > > On 11/05/2015 08:45 AM, Oleg Fayans wrote: >> Hi Jan, >> >> Could you take a look at these, whenever you are free? >> >> On 10/30/2015 02:57 PM, Oleg Fayans wrote: >>> Hi, >>> >>> The following patches contain updates to ca-less integration tests. >>> It's still a proof of concept: 2 tests still fail seemingly due to the >>> change in target system logic (marked as xfail with "ask jcholast >>> comment") >>> >>> The test output looks like this: >>> >>> $ ipa-run-tests test_integration/test_caless.py --pdb >>> ==================================================================================== >>> >>> >>> test session starts >>> ===================================================================================== >>> >>> >>> >>> platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 >>> plugins: multihost, sourceorder >>> collected 88 items >>> >>> test_integration/test_caless.py >>> ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. >>> >>> >>> >>> >>> ==================================================================== 53 >>> passed, 29 skipped, 6 xfailed in 5620.17 seconds >>> ===================================================================== >>> >>> Numerous skips correspond to the tests related to ipa-replica-prepare >>> (unsupported under domain level 1) >>> >>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0014.1-Updated-ca-less-tests.patch Type: text/x-patch Size: 28979 bytes Desc: not available URL: From jcholast at redhat.com Fri Nov 6 07:47:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 6 Nov 2015 08:47:38 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC In-Reply-To: <563BABEC.8080304@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> Message-ID: <563C5B1A.1090803@redhat.com> Hi Oleg, I think you can just remove TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are imported correctly in this case and I didn't see anything break. Honza On 5.11.2015 20:20, Oleg Fayans wrote: > Patch 0014 updated and passes lint > > On 11/05/2015 03:41 PM, Oleg Fayans wrote: >> Wait a bit, the patch has problems with pylint: it does not build :) >> The updated version (without the setupmaster nonsense) is being tested >> now. >> >> On 11/05/2015 08:45 AM, Oleg Fayans wrote: >>> Hi Jan, >>> >>> Could you take a look at these, whenever you are free? >>> >>> On 10/30/2015 02:57 PM, Oleg Fayans wrote: >>>> Hi, >>>> >>>> The following patches contain updates to ca-less integration tests. >>>> It's still a proof of concept: 2 tests still fail seemingly due to the >>>> change in target system logic (marked as xfail with "ask jcholast >>>> comment") >>>> >>>> The test output looks like this: >>>> >>>> $ ipa-run-tests test_integration/test_caless.py --pdb >>>> ==================================================================================== >>>> >>>> >>>> >>>> test session starts >>>> ===================================================================================== >>>> >>>> >>>> >>>> >>>> platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 >>>> plugins: multihost, sourceorder >>>> collected 88 items >>>> >>>> test_integration/test_caless.py >>>> ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. >>>> >>>> >>>> >>>> >>>> >>>> ==================================================================== 53 >>>> passed, 29 skipped, 6 xfailed in 5620.17 seconds >>>> ===================================================================== >>>> >>>> Numerous skips correspond to the tests related to ipa-replica-prepare >>>> (unsupported under domain level 1) >>>> >>>> >>>> >>> >> > > > -- Jan Cholasta From jcholast at redhat.com Fri Nov 6 08:01:49 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 6 Nov 2015 09:01:49 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC In-Reply-To: <563C5B1A.1090803@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> Message-ID: <563C5E6D.4060307@redhat.com> Actually it might be better to keep them, but fix them to expect ipa-server-certinstall to success. On 6.11.2015 08:47, Jan Cholasta wrote: > Hi Oleg, > > I think you can just remove > TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are > imported correctly in this case and I didn't see anything break. > > Honza > > On 5.11.2015 20:20, Oleg Fayans wrote: >> Patch 0014 updated and passes lint >> >> On 11/05/2015 03:41 PM, Oleg Fayans wrote: >>> Wait a bit, the patch has problems with pylint: it does not build :) >>> The updated version (without the setupmaster nonsense) is being tested >>> now. >>> >>> On 11/05/2015 08:45 AM, Oleg Fayans wrote: >>>> Hi Jan, >>>> >>>> Could you take a look at these, whenever you are free? >>>> >>>> On 10/30/2015 02:57 PM, Oleg Fayans wrote: >>>>> Hi, >>>>> >>>>> The following patches contain updates to ca-less integration tests. >>>>> It's still a proof of concept: 2 tests still fail seemingly due to the >>>>> change in target system logic (marked as xfail with "ask jcholast >>>>> comment") >>>>> >>>>> The test output looks like this: >>>>> >>>>> $ ipa-run-tests test_integration/test_caless.py --pdb >>>>> ==================================================================================== >>>>> >>>>> >>>>> >>>>> >>>>> test session starts >>>>> ===================================================================================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 >>>>> plugins: multihost, sourceorder >>>>> collected 88 items >>>>> >>>>> test_integration/test_caless.py >>>>> ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ==================================================================== 53 >>>>> >>>>> passed, 29 skipped, 6 xfailed in 5620.17 seconds >>>>> ===================================================================== >>>>> >>>>> Numerous skips correspond to the tests related to ipa-replica-prepare >>>>> (unsupported under domain level 1) >>>>> >>>>> >>>>> >>>> >>> >> >> >> > > -- Jan Cholasta From mkosek at redhat.com Fri Nov 6 08:25:26 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 6 Nov 2015 09:25:26 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <563B99B5.8010205@redhat.com> References: <5628A1F1.8050602@redhat.com> <5636F031.4000901@redhat.com> <56374AED.7030002@redhat.com> <563B99B5.8010205@redhat.com> Message-ID: <563C63F6.4080509@redhat.com> On 11/05/2015 07:02 PM, Petr Vobornik wrote: > On 11/02/2015 12:37 PM, Martin Kosek wrote: >> On 11/02/2015 06:10 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5181 >>> >>> This should be handled by a separate object plugin: >>> >>> $ ipa servercomponent-find master.ipa.test >>> --------------------------- >>> 6 server components matched >>> --------------------------- >>> Component name: CA >>> Enabled: TRUE >>> Start order: 50 >>> >>> Component name: KDC >>> Enabled: TRUE >>> Start order: 10 >>> >>> Component name: KPASSWD >>> Enabled: TRUE >>> Start order: 20 >>> >>> Component name: MEMCACHE >>> Enabled: TRUE >>> Start order: 39 >>> >>> Component name: OTPD >>> Enabled: TRUE >>> Start order: 80 >>> >>> Component name: HTTP >>> Enabled: TRUE >>> Start order: 40 >>> ---------------------------- >>> Number of entries returned 6 >>> ---------------------------- >>> >>> This will allow us to consolidate all the ad-hoc component-related code >>> scattered throughout IPA (search for enable component, enable/disable >>> component, ...) into IPA command calls. >>> >>> I'm not opposed to showing a summary in server-show (although we don't do >>> anything like this for any other hierarchical objects), but it should be done >>> just for the users' sake, not for internal use (the ticket suggests to use this >>> for topology visualisation). >>> >>> BTW as far as the scalability of the current solution goes, you should have a >>> list of all the *non*-optional components and display everything else. >> >> The API proposal should be in line with our future extensions of the API. We >> for example want to move "ipa-csreplica-manage" set-renewal-master command to >> API call. Or DNSSEC generation master. Or we may want to change some other >> flag/role of a master via this interface. >> >> So we will need something like >> $ ipa server-add-role ipa.example.com --role "ca-renewal-master" >> or >> $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master > > Depends on usage. If we want to internally unify manipulation with configs for > component we can create low-level commands which won't be exposed to CLI. > > E.g. ipa servercomponent-find ipa.example.com > Component name: ADTRUST > Config: enabledService, startOrder 60 > > > > This is all what Web UI needs. > > > From user perspective, for CLI, something different is better. Martin used term > 'role', lets go with that. > > Idea 1: > $ ipa server-show ipa.example.com --roles > Server name: vm-073.idm.lab.eng.brq.redhat.com > Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca > Min domain level: 0 > Max domain level: 1 > Role: dns-server, cs-server, ca-renewal-master, trust-controller > > --all would imply --roles I am thinking "Roles" could be printed out even in default listing. It looks as an important piece of information you want to know about your master. I also originally used that with servercomponent, you moved it to server itself. It makes also sense. We will need a design for this servercomponent/roles anyway, to agree on the API with all stakeholders. > $ ipa server-add-role ipa.example.com --roles=ca-renewal-master > > This is not good because this add operation will also remove a role from > different master which could be unexpected. I.e. set-renewal-master might be a > separate command. Same would apply to DNSSec generation masters. I am not sure if having a separate command for every role scale well, but I am not that strong opposed. > Idea 2: > $ ipa serverrole-add ipa.example.com ca-renewal-master > $ ipa serverrole-find ipa.example.com > Role: dns-server > Role: cs-server > Role: ca-renewal-master > Role: trust-controller > > All variants alone are fine for Web UI. From mbabinsk at redhat.com Fri Nov 6 09:00:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 Nov 2015 10:00:33 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <56374F64.2040109@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <562E1F8A.8030202@redhat.com> <56334C29.5070305@redhat.com> <56374F64.2040109@redhat.com> Message-ID: <563C6C31.60704@redhat.com> On 11/02/2015 12:56 PM, Martin Babinsky wrote: > On 10/30/2015 11:53 AM, Martin Babinsky wrote: >> On 10/26/2015 01:41 PM, Martin Babinsky wrote: >>> On 10/22/2015 04:13 PM, Martin Basti wrote: >>>> >>>> >>>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5181 >>>>> >>>>> >>>>> >>>> >>>> Thank you for the patch. >>>> >>>> 1) >>>> +OPTIONAL_SERVICES = { >>>> + 'DNS', >>>> + 'CA', >>>> + 'KRA', >>>> + 'ADTRUST', >>>> + 'EXTID', >>>> + 'DNSKeyExporter', >>>> + 'DNSSEC', >>>> + 'DNSKeySync', >>>> +} >>>> >>>> This did not scale well, maybe we should improve it to use some general >>>> solution for whole IPA to distinct mandratory and optionl service, >>>> but I >>>> do not know how (or if it is possible) >>>> >>> Yes this does not scale well. After some playing around with relocating >>> the SERVICE_LIST object in 'ipaserver/install/service.py' I found out >>> that more refactoring would be needed to improve the layout and >>> availability of LDAP service names to both server and client code. I >>> have put the list of core services to ipalib/constants.py for now, and I >>> suggest to open a separate ticket for more general solution. >>> >>>> 2) >>>> + search_filter=('(&(objectclass=ipaConfigObject)' >>>> + '(ipaConfigString=enabledService))') >>>> >>>> Common user cannot read ipaConfigString, so this will work only for >>>> admins, I do not see any limitations of access in code for other users. >>>> >>> >>> I think that you agreed with Petr^2 that this filter is OK. I left it as >>> it is but I have rewritten it as a call to ldap.make_filter to improve >>> readability and/or potential extensibility a bit. >>> >>>> 3) >>>> + opt_components = [ >>>> + r['cn'][0] for r in result if r['cn'][0] in >>>> OPTIONAL_SERVICES >>>> + ] >>>> Probably instead of indexing, you may use result.single_value['cn'] >>>> >>>> Martin^2 >>> >>> Attaching updated patch. >>> >>> >>> >> Self-NACK, I found a bug in the patch during work on topology management >> stuff. >> > > Attaching updated patch. > > > Bump for review. -- Martin^3 Babinsky From pspacek at redhat.com Fri Nov 6 09:10:20 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 6 Nov 2015 10:10:20 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <563C6C31.60704@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <562E1F8A.8030202@redhat.com> <56334C29.5070305@redhat.com> <56374F64.2040109@redhat.com> <563C6C31.60704@redhat.com> Message-ID: <563C6E7C.1070802@redhat.com> On 6.11.2015 10:00, Martin Babinsky wrote: > On 11/02/2015 12:56 PM, Martin Babinsky wrote: >> On 10/30/2015 11:53 AM, Martin Babinsky wrote: >>> On 10/26/2015 01:41 PM, Martin Babinsky wrote: >>>> On 10/22/2015 04:13 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5181 >>>>>> >>>>>> >>>>>> >>>>> >>>>> Thank you for the patch. >>>>> >>>>> 1) >>>>> +OPTIONAL_SERVICES = { >>>>> + 'DNS', >>>>> + 'CA', >>>>> + 'KRA', >>>>> + 'ADTRUST', >>>>> + 'EXTID', >>>>> + 'DNSKeyExporter', >>>>> + 'DNSSEC', >>>>> + 'DNSKeySync', >>>>> +} >>>>> >>>>> This did not scale well, maybe we should improve it to use some general >>>>> solution for whole IPA to distinct mandratory and optionl service, >>>>> but I >>>>> do not know how (or if it is possible) >>>>> >>>> Yes this does not scale well. After some playing around with relocating >>>> the SERVICE_LIST object in 'ipaserver/install/service.py' I found out >>>> that more refactoring would be needed to improve the layout and >>>> availability of LDAP service names to both server and client code. I >>>> have put the list of core services to ipalib/constants.py for now, and I >>>> suggest to open a separate ticket for more general solution. >>>> >>>>> 2) >>>>> + search_filter=('(&(objectclass=ipaConfigObject)' >>>>> + '(ipaConfigString=enabledService))') >>>>> >>>>> Common user cannot read ipaConfigString, so this will work only for >>>>> admins, I do not see any limitations of access in code for other users. >>>>> >>>> >>>> I think that you agreed with Petr^2 that this filter is OK. I left it as >>>> it is but I have rewritten it as a call to ldap.make_filter to improve >>>> readability and/or potential extensibility a bit. >>>> >>>>> 3) >>>>> + opt_components = [ >>>>> + r['cn'][0] for r in result if r['cn'][0] in >>>>> OPTIONAL_SERVICES >>>>> + ] >>>>> Probably instead of indexing, you may use result.single_value['cn'] >>>>> >>>>> Martin^2 >>>> >>>> Attaching updated patch. >>>> >>>> >>>> >>> Self-NACK, I found a bug in the patch during work on topology management >>> stuff. >>> >> >> Attaching updated patch. >> >> >> > Bump for review. I apologize for the delay, ACK! -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 6 09:15:37 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 6 Nov 2015 10:15:37 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <563C63F6.4080509@redhat.com> References: <5628A1F1.8050602@redhat.com> <5636F031.4000901@redhat.com> <56374AED.7030002@redhat.com> <563B99B5.8010205@redhat.com> <563C63F6.4080509@redhat.com> Message-ID: <563C6FB9.9020908@redhat.com> On 6.11.2015 09:25, Martin Kosek wrote: > On 11/05/2015 07:02 PM, Petr Vobornik wrote: >> > On 11/02/2015 12:37 PM, Martin Kosek wrote: >>> >> On 11/02/2015 06:10 AM, Jan Cholasta wrote: >>>> >>> Hi, >>>> >>> >>>> >>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>> >>>> https://fedorahosted.org/freeipa/ticket/5181 >>>> >>> >>>> >>> This should be handled by a separate object plugin: >>>> >>> >>>> >>> $ ipa servercomponent-find master.ipa.test >>>> >>> --------------------------- >>>> >>> 6 server components matched >>>> >>> --------------------------- >>>> >>> Component name: CA >>>> >>> Enabled: TRUE >>>> >>> Start order: 50 >>>> >>> >>>> >>> Component name: KDC >>>> >>> Enabled: TRUE >>>> >>> Start order: 10 >>>> >>> >>>> >>> Component name: KPASSWD >>>> >>> Enabled: TRUE >>>> >>> Start order: 20 >>>> >>> >>>> >>> Component name: MEMCACHE >>>> >>> Enabled: TRUE >>>> >>> Start order: 39 >>>> >>> >>>> >>> Component name: OTPD >>>> >>> Enabled: TRUE >>>> >>> Start order: 80 >>>> >>> >>>> >>> Component name: HTTP >>>> >>> Enabled: TRUE >>>> >>> Start order: 40 >>>> >>> ---------------------------- >>>> >>> Number of entries returned 6 >>>> >>> ---------------------------- >>>> >>> >>>> >>> This will allow us to consolidate all the ad-hoc component-related code >>>> >>> scattered throughout IPA (search for enable component, enable/disable >>>> >>> component, ...) into IPA command calls. >>>> >>> >>>> >>> I'm not opposed to showing a summary in server-show (although we don't do >>>> >>> anything like this for any other hierarchical objects), but it should be done >>>> >>> just for the users' sake, not for internal use (the ticket suggests to use this >>>> >>> for topology visualisation). >>>> >>> >>>> >>> BTW as far as the scalability of the current solution goes, you should have a >>>> >>> list of all the *non*-optional components and display everything else. >>> >> >>> >> The API proposal should be in line with our future extensions of the API. We >>> >> for example want to move "ipa-csreplica-manage" set-renewal-master command to >>> >> API call. Or DNSSEC generation master. Or we may want to change some other >>> >> flag/role of a master via this interface. >>> >> >>> >> So we will need something like >>> >> $ ipa server-add-role ipa.example.com --role "ca-renewal-master" >>> >> or >>> >> $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master >> > >> > Depends on usage. If we want to internally unify manipulation with configs for >> > component we can create low-level commands which won't be exposed to CLI. >> > >> > E.g. ipa servercomponent-find ipa.example.com >> > Component name: ADTRUST >> > Config: enabledService, startOrder 60 >> > >> > >> > >> > This is all what Web UI needs. >> > >> > >> > From user perspective, for CLI, something different is better. Martin used term >> > 'role', lets go with that. >> > >> > Idea 1: >> > $ ipa server-show ipa.example.com --roles >> > Server name: vm-073.idm.lab.eng.brq.redhat.com >> > Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca >> > Min domain level: 0 >> > Max domain level: 1 >> > Role: dns-server, cs-server, ca-renewal-master, trust-controller >> > >> > --all would imply --roles > I am thinking "Roles" could be printed out even in default listing. It looks as > an important piece of information you want to know about your master. I also > originally used that with servercomponent, you moved it to server itself. It > makes also sense. > > We will need a design for this servercomponent/roles anyway, to agree on the > API with all stakeholders. > >> > $ ipa server-add-role ipa.example.com --roles=ca-renewal-master Just keep in mind that 'role' design requires yet another layer of indirection because there is no 1:1 mapping between services and roles. E.g. 'DNSSEC key master' role consists of several services, as 'DNS server' role etc. Also, we can get into trouble because role 'DNS server' in IPA 4.2 can contain different set of services than 'DNS server' in IPA 5.0 etc. For these reasons I question necessity of 'role' abstraction. Is it worth? -- Petr^2 Spacek From mbabinsk at redhat.com Fri Nov 6 09:30:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 Nov 2015 10:30:05 +0100 Subject: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options Message-ID: <563C731D.6010909@redhat.com> https://fedorahosted.org/freeipa/ticket/5433 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0094-fix-error-reporting-when-installer-option-is-supplie.patch Type: text/x-patch Size: 1131 bytes Desc: not available URL: From pvoborni at redhat.com Fri Nov 6 10:06:04 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 6 Nov 2015 11:06:04 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <563C6FB9.9020908@redhat.com> References: <5628A1F1.8050602@redhat.com> <5636F031.4000901@redhat.com> <56374AED.7030002@redhat.com> <563B99B5.8010205@redhat.com> <563C63F6.4080509@redhat.com> <563C6FB9.9020908@redhat.com> Message-ID: <563C7B8C.9030608@redhat.com> On 11/06/2015 10:15 AM, Petr Spacek wrote: > On 6.11.2015 09:25, Martin Kosek wrote: >> On 11/05/2015 07:02 PM, Petr Vobornik wrote: >>>> On 11/02/2015 12:37 PM, Martin Kosek wrote: >>>>>> On 11/02/2015 06:10 AM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5181 >>>>>>>> >>>>>>>> This should be handled by a separate object plugin: >>>>>>>> >>>>>>>> $ ipa servercomponent-find master.ipa.test >>>>>>>> --------------------------- >>>>>>>> 6 server components matched >>>>>>>> --------------------------- >>>>>>>> Component name: CA >>>>>>>> Enabled: TRUE >>>>>>>> Start order: 50 >>>>>>>> >>>>>>>> Component name: KDC >>>>>>>> Enabled: TRUE >>>>>>>> Start order: 10 >>>>>>>> >>>>>>>> Component name: KPASSWD >>>>>>>> Enabled: TRUE >>>>>>>> Start order: 20 >>>>>>>> >>>>>>>> Component name: MEMCACHE >>>>>>>> Enabled: TRUE >>>>>>>> Start order: 39 >>>>>>>> >>>>>>>> Component name: OTPD >>>>>>>> Enabled: TRUE >>>>>>>> Start order: 80 >>>>>>>> >>>>>>>> Component name: HTTP >>>>>>>> Enabled: TRUE >>>>>>>> Start order: 40 >>>>>>>> ---------------------------- >>>>>>>> Number of entries returned 6 >>>>>>>> ---------------------------- >>>>>>>> >>>>>>>> This will allow us to consolidate all the ad-hoc component-related code >>>>>>>> scattered throughout IPA (search for enable component, enable/disable >>>>>>>> component, ...) into IPA command calls. >>>>>>>> >>>>>>>> I'm not opposed to showing a summary in server-show (although we don't do >>>>>>>> anything like this for any other hierarchical objects), but it should be done >>>>>>>> just for the users' sake, not for internal use (the ticket suggests to use this >>>>>>>> for topology visualisation). >>>>>>>> >>>>>>>> BTW as far as the scalability of the current solution goes, you should have a >>>>>>>> list of all the *non*-optional components and display everything else. >>>>>> >>>>>> The API proposal should be in line with our future extensions of the API. We >>>>>> for example want to move "ipa-csreplica-manage" set-renewal-master command to >>>>>> API call. Or DNSSEC generation master. Or we may want to change some other >>>>>> flag/role of a master via this interface. >>>>>> >>>>>> So we will need something like >>>>>> $ ipa server-add-role ipa.example.com --role "ca-renewal-master" >>>>>> or >>>>>> $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master >>>> >>>> Depends on usage. If we want to internally unify manipulation with configs for >>>> component we can create low-level commands which won't be exposed to CLI. >>>> >>>> E.g. ipa servercomponent-find ipa.example.com >>>> Component name: ADTRUST >>>> Config: enabledService, startOrder 60 >>>> >>>> >>>> >>>> This is all what Web UI needs. >>>> >>>> >>>> From user perspective, for CLI, something different is better. Martin used term >>>> 'role', lets go with that. >>>> >>>> Idea 1: >>>> $ ipa server-show ipa.example.com --roles >>>> Server name: vm-073.idm.lab.eng.brq.redhat.com >>>> Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca >>>> Min domain level: 0 >>>> Max domain level: 1 >>>> Role: dns-server, cs-server, ca-renewal-master, trust-controller >>>> >>>> --all would imply --roles >> I am thinking "Roles" could be printed out even in default listing. It looks as >> an important piece of information you want to know about your master. I also >> originally used that with servercomponent, you moved it to server itself. It >> makes also sense. >> >> We will need a design for this servercomponent/roles anyway, to agree on the >> API with all stakeholders. >> >>>> $ ipa server-add-role ipa.example.com --roles=ca-renewal-master > > Just keep in mind that 'role' design requires yet another layer of indirection > because there is no 1:1 mapping between services and roles. E.g. 'DNSSEC key > master' role consists of several services, as 'DNS server' role etc. > > Also, we can get into trouble because role 'DNS server' in IPA 4.2 can contain > different set of services than 'DNS server' in IPA 5.0 etc. > > For these reasons I question necessity of 'role' abstraction. Is it worth? > IMO yes. Current patch is better than nothing but roles are more friendly, components are implementation detail. Showing only CNs on components doesn't show all info. E.g. ipa server-show `hostname` Server name: ipa.example.com Managed suffix: dc=example,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA This doesn't show that the server is actually also a ca-renewal-master. What is the command I can use to solve: "show me what server is the ca-renewal-master"? Then what's the difference between ADTRUST and EXTID? One is smb, second winbind but from user perspective it is the same thing - AD Trusts controller. Could there be DNS without DNSKeySync? -- Petr Vobornik From ofayans at redhat.com Fri Nov 6 10:58:25 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 Nov 2015 11:58:25 +0100 Subject: [Freeipa-devel] upstream under RHEL7 build failure Message-ID: <563C87D1.3020504@redhat.com> Hi all, I am trying to build upstream packages under RHEL-7.2. All the build-time dependencies were installed from RHEL repos except python-gssapi, which was taken from fedora-22. The build fails with a pile of lint errors: https://paste.fedoraproject.org/287566/ Could someone of you help me debug this? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Fri Nov 6 11:57:03 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 Nov 2015 12:57:03 +0100 Subject: [Freeipa-devel] upstream under RHEL7 build failure In-Reply-To: <563C87D1.3020504@redhat.com> References: <563C87D1.3020504@redhat.com> Message-ID: <563C958F.2000309@redhat.com> On 11/06/2015 11:58 AM, Oleg Fayans wrote: > Hi all, > > I am trying to build upstream packages under RHEL-7.2. All the > build-time dependencies were installed from RHEL repos except > python-gssapi, which was taken from fedora-22. The build fails with a > pile of lint errors: https://paste.fedoraproject.org/287566/ > Could someone of you help me debug this? > > I guess you don't have python-six package installed? -- Martin^3 Babinsky From pviktori at redhat.com Fri Nov 6 12:07:44 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 6 Nov 2015 13:07:44 +0100 Subject: [Freeipa-devel] [PATCH] 0749 Package ipapython, ipalib, ipaplatform, ipatests for Python 3 Message-ID: <563C9810.1050604@redhat.com> Hello, The Python 3 port is not 100% done, but I think the time has come to start packaging the py3 bits. This will make it easier to plug into CI. The existing Python 2 packages should not change, except I've added "freeipa-common" with files that aren't Python-specific. The new packages follow Fedora's Python guidelines a bit better. The main thing is the names: python3-ipalib, python3-ipatests, python3-ipap11helper. The pure-Python ones are built as noarch. The Makefiles are reorganized a bit, but they don't support building for both py versions at once -- you need to do `make` followed by `make PYTHON=/usr/bin/python3`. (The latter currently only works in the directories that are ported so far, though.) -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0749-Package-ipapython-ipalib-ipaplatform-ipatests-for-Py.patch Type: text/x-patch Size: 22157 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 6 12:09:45 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 Nov 2015 13:09:45 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <563C7B8C.9030608@redhat.com> References: <5628A1F1.8050602@redhat.com> <5636F031.4000901@redhat.com> <56374AED.7030002@redhat.com> <563B99B5.8010205@redhat.com> <563C63F6.4080509@redhat.com> <563C6FB9.9020908@redhat.com> <563C7B8C.9030608@redhat.com> Message-ID: <563C9889.7020904@redhat.com> On 11/06/2015 11:06 AM, Petr Vobornik wrote: > On 11/06/2015 10:15 AM, Petr Spacek wrote: >> On 6.11.2015 09:25, Martin Kosek wrote: >>> On 11/05/2015 07:02 PM, Petr Vobornik wrote: >>>>> On 11/02/2015 12:37 PM, Martin Kosek wrote: >>>>>>> On 11/02/2015 06:10 AM, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5181 >>>>>>>>> >>>>>>>>> This should be handled by a separate object plugin: >>>>>>>>> >>>>>>>>> $ ipa servercomponent-find master.ipa.test >>>>>>>>> --------------------------- >>>>>>>>> 6 server components matched >>>>>>>>> --------------------------- >>>>>>>>> Component name: CA >>>>>>>>> Enabled: TRUE >>>>>>>>> Start order: 50 >>>>>>>>> >>>>>>>>> Component name: KDC >>>>>>>>> Enabled: TRUE >>>>>>>>> Start order: 10 >>>>>>>>> >>>>>>>>> Component name: KPASSWD >>>>>>>>> Enabled: TRUE >>>>>>>>> Start order: 20 >>>>>>>>> >>>>>>>>> Component name: MEMCACHE >>>>>>>>> Enabled: TRUE >>>>>>>>> Start order: 39 >>>>>>>>> >>>>>>>>> Component name: OTPD >>>>>>>>> Enabled: TRUE >>>>>>>>> Start order: 80 >>>>>>>>> >>>>>>>>> Component name: HTTP >>>>>>>>> Enabled: TRUE >>>>>>>>> Start order: 40 >>>>>>>>> ---------------------------- >>>>>>>>> Number of entries returned 6 >>>>>>>>> ---------------------------- >>>>>>>>> >>>>>>>>> This will allow us to consolidate all the ad-hoc >>>>>>>>> component-related code >>>>>>>>> scattered throughout IPA (search for enable component, >>>>>>>>> enable/disable >>>>>>>>> component, ...) into IPA command calls. >>>>>>>>> >>>>>>>>> I'm not opposed to showing a summary in server-show (although >>>>>>>>> we don't do >>>>>>>>> anything like this for any other hierarchical objects), but it >>>>>>>>> should be done >>>>>>>>> just for the users' sake, not for internal use (the ticket >>>>>>>>> suggests to use this >>>>>>>>> for topology visualisation). >>>>>>>>> >>>>>>>>> BTW as far as the scalability of the current solution goes, you >>>>>>>>> should have a >>>>>>>>> list of all the *non*-optional components and display >>>>>>>>> everything else. >>>>>>> >>>>>>> The API proposal should be in line with our future extensions of >>>>>>> the API. We >>>>>>> for example want to move "ipa-csreplica-manage" >>>>>>> set-renewal-master command to >>>>>>> API call. Or DNSSEC generation master. Or we may want to change >>>>>>> some other >>>>>>> flag/role of a master via this interface. >>>>>>> >>>>>>> So we will need something like >>>>>>> $ ipa server-add-role ipa.example.com --role "ca-renewal-master" >>>>>>> or >>>>>>> $ ipa servercomponent-add-role ipa.example.com CA >>>>>>> --role=renewal-master >>>>> >>>>> Depends on usage. If we want to internally unify manipulation with >>>>> configs for >>>>> component we can create low-level commands which won't be exposed >>>>> to CLI. >>>>> >>>>> E.g. ipa servercomponent-find ipa.example.com >>>>> Component name: ADTRUST >>>>> Config: enabledService, startOrder 60 >>>>> >>>>> >>>>> >>>>> This is all what Web UI needs. >>>>> >>>>> >>>>> From user perspective, for CLI, something different is better. >>>>> Martin used term >>>>> 'role', lets go with that. >>>>> >>>>> Idea 1: >>>>> $ ipa server-show ipa.example.com --roles >>>>> Server name: vm-073.idm.lab.eng.brq.redhat.com >>>>> Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, >>>>> o=ipaca >>>>> Min domain level: 0 >>>>> Max domain level: 1 >>>>> Role: dns-server, cs-server, ca-renewal-master, trust-controller >>>>> >>>>> --all would imply --roles >>> I am thinking "Roles" could be printed out even in default listing. >>> It looks as >>> an important piece of information you want to know about your master. >>> I also >>> originally used that with servercomponent, you moved it to server >>> itself. It >>> makes also sense. >>> >>> We will need a design for this servercomponent/roles anyway, to agree >>> on the >>> API with all stakeholders. >>> >>>>> $ ipa server-add-role ipa.example.com --roles=ca-renewal-master >> >> Just keep in mind that 'role' design requires yet another layer of >> indirection >> because there is no 1:1 mapping between services and roles. E.g. >> 'DNSSEC key >> master' role consists of several services, as 'DNS server' role etc. >> >> Also, we can get into trouble because role 'DNS server' in IPA 4.2 can >> contain >> different set of services than 'DNS server' in IPA 5.0 etc. >> >> For these reasons I question necessity of 'role' abstraction. Is it >> worth? >> > > IMO yes. Current patch is better than nothing but roles are more > friendly, components are implementation detail. > > Showing only CNs on components doesn't show all info. E.g. > > ipa server-show `hostname` > Server name: ipa.example.com > Managed suffix: dc=example,dc=com, o=ipaca > Min domain level: 0 > Max domain level: 1 > Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA > > This doesn't show that the server is actually also a ca-renewal-master. > What is the command I can use to solve: "show me what server is the > ca-renewal-master"? > In that case we would IMHO need to redesign the whole service to LDAP mapping to incorporate server roles in some sane and scalable way. I'm not sure if that fits in the 4.3 timeframe. If yes, the we should first start with first putting the plumbing in and then adding API calls on top. It doesn't make much sense to push this patch first and then rework the whole thing. > Then what's the difference between ADTRUST and EXTID? One is smb, second > winbind but from user perspective it is the same thing - AD Trusts > controller. > > Could there be DNS without DNSKeySync? -- Martin^3 Babinsky From ofayans at redhat.com Fri Nov 6 13:04:53 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 Nov 2015 14:04:53 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC In-Reply-To: <563C5E6D.4060307@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> Message-ID: <563CA575.1030808@redhat.com> Hi Jan, On 11/06/2015 09:01 AM, Jan Cholasta wrote: > Actually it might be better to keep them, but fix them to expect > ipa-server-certinstall to success. Done. Updated patch attached. Also in the patch 0013 I removed a trailing whitespace which caused lint to complain Now with domain level 0 the test output looks like this: [11:40:51]ofayans at vm-076:~]$ ipa-run-tests test_integration/test_caless.py ==================================================================================== test session starts ===================================================================================== platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 plugins: multihost, sourceorder collected 88 items test_integration/test_caless.py ......xx......ss...............xx........ss....................xx......ss............... ===================================================================== 76 passed, 6 skipped, 6 xfailed in 7871.10 seconds ===================================================================== > > On 6.11.2015 08:47, Jan Cholasta wrote: >> Hi Oleg, >> >> I think you can just remove >> TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are >> imported correctly in this case and I didn't see anything break. >> >> Honza >> >> On 5.11.2015 20:20, Oleg Fayans wrote: >>> Patch 0014 updated and passes lint >>> >>> On 11/05/2015 03:41 PM, Oleg Fayans wrote: >>>> Wait a bit, the patch has problems with pylint: it does not build :) >>>> The updated version (without the setupmaster nonsense) is being tested >>>> now. >>>> >>>> On 11/05/2015 08:45 AM, Oleg Fayans wrote: >>>>> Hi Jan, >>>>> >>>>> Could you take a look at these, whenever you are free? >>>>> >>>>> On 10/30/2015 02:57 PM, Oleg Fayans wrote: >>>>>> Hi, >>>>>> >>>>>> The following patches contain updates to ca-less integration tests. >>>>>> It's still a proof of concept: 2 tests still fail seemingly due to >>>>>> the >>>>>> change in target system logic (marked as xfail with "ask jcholast >>>>>> comment") >>>>>> >>>>>> The test output looks like this: >>>>>> >>>>>> $ ipa-run-tests test_integration/test_caless.py --pdb >>>>>> ==================================================================================== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> test session starts >>>>>> ===================================================================================== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 >>>>>> plugins: multihost, sourceorder >>>>>> collected 88 items >>>>>> >>>>>> test_integration/test_caless.py >>>>>> ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ==================================================================== >>>>>> 53 >>>>>> >>>>>> passed, 29 skipped, 6 xfailed in 5620.17 seconds >>>>>> ===================================================================== >>>>>> >>>>>> Numerous skips correspond to the tests related to ipa-replica-prepare >>>>>> (unsupported under domain level 1) >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0013.1-Updated-the-script-creating-test-certificate-chains.patch Type: text/x-patch Size: 2642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0014.2-Updated-ca-less-tests.patch Type: text/x-patch Size: 29343 bytes Desc: not available URL: From ofayans at redhat.com Fri Nov 6 13:07:33 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 6 Nov 2015 14:07:33 +0100 Subject: [Freeipa-devel] upstream under RHEL7 build failure In-Reply-To: <563C958F.2000309@redhat.com> References: <563C87D1.3020504@redhat.com> <563C958F.2000309@redhat.com> Message-ID: <563CA615.7050401@redhat.com> On 11/06/2015 12:57 PM, Martin Babinsky wrote: > On 11/06/2015 11:58 AM, Oleg Fayans wrote: >> Hi all, >> >> I am trying to build upstream packages under RHEL-7.2. All the >> build-time dependencies were installed from RHEL repos except >> python-gssapi, which was taken from fedora-22. The build fails with a >> pile of lint errors: https://paste.fedoraproject.org/287566/ >> Could someone of you help me debug this? >> >> > I guess you don't have python-six package installed? > I do have it. All the packages marked as BuildRequires in freeipa.spec.in are installed -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From fskola at redhat.com Fri Nov 6 10:32:01 2015 From: fskola at redhat.com (Filip =?UTF-8?B?xaBrb2xh?=) Date: Fri, 6 Nov 2015 11:32:01 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Refactor test_user_plugin Message-ID: <20151106113201.5e6a7042@dhcp-24-123.brq.redhat.com> A non-text attachment was scrubbed... Name: freeipa-fskola-0001-Refactor-test_user_plugin.patch Type: text/x-patch Size: 105197 bytes Desc: not available URL: From pvoborni at redhat.com Fri Nov 6 15:22:55 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 6 Nov 2015 16:22:55 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <563C9889.7020904@redhat.com> References: <5628A1F1.8050602@redhat.com> <5636F031.4000901@redhat.com> <56374AED.7030002@redhat.com> <563B99B5.8010205@redhat.com> <563C63F6.4080509@redhat.com> <563C6FB9.9020908@redhat.com> <563C7B8C.9030608@redhat.com> <563C9889.7020904@redhat.com> Message-ID: <563CC5CF.5010908@redhat.com> On 11/06/2015 01:09 PM, Martin Babinsky wrote: > On 11/06/2015 11:06 AM, Petr Vobornik wrote: >> On 11/06/2015 10:15 AM, Petr Spacek wrote: >>> On 6.11.2015 09:25, Martin Kosek wrote: >>>> On 11/05/2015 07:02 PM, Petr Vobornik wrote: >>>>>> On 11/02/2015 12:37 PM, Martin Kosek wrote: >>>>>>>> On 11/02/2015 06:10 AM, Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5181 >>>>>>>>>> >>>>>>>>>> This should be handled by a separate object plugin: >>>>>>>>>> >>>>>>>>>> $ ipa servercomponent-find master.ipa.test >>>>>>>>>> --------------------------- >>>>>>>>>> 6 server components matched >>>>>>>>>> --------------------------- >>>>>>>>>> Component name: CA >>>>>>>>>> Enabled: TRUE >>>>>>>>>> Start order: 50 >>>>>>>>>> >>>>>>>>>> Component name: KDC >>>>>>>>>> Enabled: TRUE >>>>>>>>>> Start order: 10 >>>>>>>>>> >>>>>>>>>> Component name: KPASSWD >>>>>>>>>> Enabled: TRUE >>>>>>>>>> Start order: 20 >>>>>>>>>> >>>>>>>>>> Component name: MEMCACHE >>>>>>>>>> Enabled: TRUE >>>>>>>>>> Start order: 39 >>>>>>>>>> >>>>>>>>>> Component name: OTPD >>>>>>>>>> Enabled: TRUE >>>>>>>>>> Start order: 80 >>>>>>>>>> >>>>>>>>>> Component name: HTTP >>>>>>>>>> Enabled: TRUE >>>>>>>>>> Start order: 40 >>>>>>>>>> ---------------------------- >>>>>>>>>> Number of entries returned 6 >>>>>>>>>> ---------------------------- >>>>>>>>>> >>>>>>>>>> This will allow us to consolidate all the ad-hoc >>>>>>>>>> component-related code >>>>>>>>>> scattered throughout IPA (search for enable component, >>>>>>>>>> enable/disable >>>>>>>>>> component, ...) into IPA command calls. >>>>>>>>>> >>>>>>>>>> I'm not opposed to showing a summary in server-show (although >>>>>>>>>> we don't do >>>>>>>>>> anything like this for any other hierarchical objects), but it >>>>>>>>>> should be done >>>>>>>>>> just for the users' sake, not for internal use (the ticket >>>>>>>>>> suggests to use this >>>>>>>>>> for topology visualisation). >>>>>>>>>> >>>>>>>>>> BTW as far as the scalability of the current solution goes, you >>>>>>>>>> should have a >>>>>>>>>> list of all the *non*-optional components and display >>>>>>>>>> everything else. >>>>>>>> >>>>>>>> The API proposal should be in line with our future extensions of >>>>>>>> the API. We >>>>>>>> for example want to move "ipa-csreplica-manage" >>>>>>>> set-renewal-master command to >>>>>>>> API call. Or DNSSEC generation master. Or we may want to change >>>>>>>> some other >>>>>>>> flag/role of a master via this interface. >>>>>>>> >>>>>>>> So we will need something like >>>>>>>> $ ipa server-add-role ipa.example.com --role "ca-renewal-master" >>>>>>>> or >>>>>>>> $ ipa servercomponent-add-role ipa.example.com CA >>>>>>>> --role=renewal-master >>>>>> >>>>>> Depends on usage. If we want to internally unify manipulation with >>>>>> configs for >>>>>> component we can create low-level commands which won't be exposed >>>>>> to CLI. >>>>>> >>>>>> E.g. ipa servercomponent-find ipa.example.com >>>>>> Component name: ADTRUST >>>>>> Config: enabledService, startOrder 60 >>>>>> >>>>>> >>>>>> >>>>>> This is all what Web UI needs. >>>>>> >>>>>> >>>>>> From user perspective, for CLI, something different is better. >>>>>> Martin used term >>>>>> 'role', lets go with that. >>>>>> >>>>>> Idea 1: >>>>>> $ ipa server-show ipa.example.com --roles >>>>>> Server name: vm-073.idm.lab.eng.brq.redhat.com >>>>>> Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, >>>>>> o=ipaca >>>>>> Min domain level: 0 >>>>>> Max domain level: 1 >>>>>> Role: dns-server, cs-server, ca-renewal-master, trust-controller >>>>>> >>>>>> --all would imply --roles >>>> I am thinking "Roles" could be printed out even in default listing. >>>> It looks as >>>> an important piece of information you want to know about your master. >>>> I also >>>> originally used that with servercomponent, you moved it to server >>>> itself. It >>>> makes also sense. >>>> >>>> We will need a design for this servercomponent/roles anyway, to agree >>>> on the >>>> API with all stakeholders. >>>> >>>>>> $ ipa server-add-role ipa.example.com --roles=ca-renewal-master >>> >>> Just keep in mind that 'role' design requires yet another layer of >>> indirection >>> because there is no 1:1 mapping between services and roles. E.g. >>> 'DNSSEC key >>> master' role consists of several services, as 'DNS server' role etc. >>> >>> Also, we can get into trouble because role 'DNS server' in IPA 4.2 can >>> contain >>> different set of services than 'DNS server' in IPA 5.0 etc. >>> >>> For these reasons I question necessity of 'role' abstraction. Is it >>> worth? >>> >> >> IMO yes. Current patch is better than nothing but roles are more >> friendly, components are implementation detail. >> >> Showing only CNs on components doesn't show all info. E.g. >> >> ipa server-show `hostname` >> Server name: ipa.example.com >> Managed suffix: dc=example,dc=com, o=ipaca >> Min domain level: 0 >> Max domain level: 1 >> Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA >> >> This doesn't show that the server is actually also a ca-renewal-master. >> What is the command I can use to solve: "show me what server is the >> ca-renewal-master"? >> > In that case we would IMHO need to redesign the whole service to LDAP > mapping to incorporate server roles in some sane and scalable way. I'm > not sure if that fits in the 4.3 timeframe. If yes, the we should first > start with first putting the plumbing in and then adding API calls on top. > It is not a blocker for 4.3. Issue here is that we are discussing implementation and API purity without use-cases. The result doesn't have to be something big in the end. So far the only real use case was a consumption by Web UI for topology visualization. This definitely won't be part of 4.3. And Web UI will do exactly what I wrote here(hidden behind term "role". Just display which servers are: - vault backend (KRA) - CS - ca-renewal-master - trust controller - DNS server - DNS key master E.g. in form of icon (not-yet designed). Second use case is displaying the same but in CLI (Idea 1 above). This doesn't required any fancy refactoring. The only thing which needs to be agreed on is terminology. > It doesn't make much sense to push this patch first and then rework the > whole thing. I agree. I digged out some wip patch which could be actually enough (attached). It won't probably apply and the object name might not be the best. > >> Then what's the difference between ADTRUST and EXTID? One is smb, second >> winbind but from user perspective it is the same thing - AD Trusts >> controller. >> >> Could there be DNS without DNSKeySync? > > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0747-add-serverservice-internal-commands.patch Type: text/x-patch Size: 7927 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 6 15:37:57 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 Nov 2015 16:37:57 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <563C6E7C.1070802@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <562E1F8A.8030202@redhat.com> <56334C29.5070305@redhat.com> <56374F64.2040109@redhat.com> <563C6C31.60704@redhat.com> <563C6E7C.1070802@redhat.com> Message-ID: <563CC955.1050303@redhat.com> On 11/06/2015 10:10 AM, Petr Spacek wrote: > On 6.11.2015 10:00, Martin Babinsky wrote: >> On 11/02/2015 12:56 PM, Martin Babinsky wrote: >>> On 10/30/2015 11:53 AM, Martin Babinsky wrote: >>>> On 10/26/2015 01:41 PM, Martin Babinsky wrote: >>>>> On 10/22/2015 04:13 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5181 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Thank you for the patch. >>>>>> >>>>>> 1) >>>>>> +OPTIONAL_SERVICES = { >>>>>> + 'DNS', >>>>>> + 'CA', >>>>>> + 'KRA', >>>>>> + 'ADTRUST', >>>>>> + 'EXTID', >>>>>> + 'DNSKeyExporter', >>>>>> + 'DNSSEC', >>>>>> + 'DNSKeySync', >>>>>> +} >>>>>> >>>>>> This did not scale well, maybe we should improve it to use some general >>>>>> solution for whole IPA to distinct mandratory and optionl service, >>>>>> but I >>>>>> do not know how (or if it is possible) >>>>>> >>>>> Yes this does not scale well. After some playing around with relocating >>>>> the SERVICE_LIST object in 'ipaserver/install/service.py' I found out >>>>> that more refactoring would be needed to improve the layout and >>>>> availability of LDAP service names to both server and client code. I >>>>> have put the list of core services to ipalib/constants.py for now, and I >>>>> suggest to open a separate ticket for more general solution. >>>>> >>>>>> 2) >>>>>> + search_filter=('(&(objectclass=ipaConfigObject)' >>>>>> + '(ipaConfigString=enabledService))') >>>>>> >>>>>> Common user cannot read ipaConfigString, so this will work only for >>>>>> admins, I do not see any limitations of access in code for other users. >>>>>> >>>>> >>>>> I think that you agreed with Petr^2 that this filter is OK. I left it as >>>>> it is but I have rewritten it as a call to ldap.make_filter to improve >>>>> readability and/or potential extensibility a bit. >>>>> >>>>>> 3) >>>>>> + opt_components = [ >>>>>> + r['cn'][0] for r in result if r['cn'][0] in >>>>>> OPTIONAL_SERVICES >>>>>> + ] >>>>>> Probably instead of indexing, you may use result.single_value['cn'] >>>>>> >>>>>> Martin^2 >>>>> >>>>> Attaching updated patch. >>>>> >>>>> >>>>> >>>> Self-NACK, I found a bug in the patch during work on topology management >>>> stuff. >>>> >>> >>> Attaching updated patch. >>> >>> >>> >> Bump for review. > > I apologize for the delay, ACK! > NACKed by commitee until further notice. -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Nov 6 16:02:06 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 6 Nov 2015 17:02:06 +0100 Subject: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options In-Reply-To: <563C731D.6010909@redhat.com> References: <563C731D.6010909@redhat.com> Message-ID: <563CCEFE.5040906@redhat.com> On 11/06/2015 10:30 AM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5433 > > > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0094.1-fix-error-reporting-when-installer-option-is-supplie.patch Type: text/x-patch Size: 1137 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 9 06:15:00 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 Nov 2015 07:15:00 +0100 Subject: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options In-Reply-To: <563CCEFE.5040906@redhat.com> References: <563C731D.6010909@redhat.com> <563CCEFE.5040906@redhat.com> Message-ID: <564039E4.8000601@redhat.com> On 6.11.2015 17:02, Martin Babinsky wrote: > On 11/06/2015 10:30 AM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5433 >> >> >> > > Attaching updated patch. NACK, the first patch was better, there should be quotes around the values. -- Jan Cholasta From pspacek at redhat.com Mon Nov 9 07:42:18 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 Nov 2015 08:42:18 +0100 Subject: [Freeipa-devel] [PATCH 0062] DNS record-add warns when a suspicious DNS name is detected Message-ID: <56404E5A.6090709@redhat.com> Hello, DNS record-add warns when a suspicious DNS name is detected Relative name "record.zone" is being added into zone "zone.", which is probably a mistake. User probably wanted to either specify relative name "record" or use FQDN "record.zone.". -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0062-DNS-record-add-warns-when-a-suspicious-DNS-name-is-d.patch Type: text/x-patch Size: 3232 bytes Desc: not available URL: From pspacek at redhat.com Mon Nov 9 07:47:42 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 9 Nov 2015 08:47:42 +0100 Subject: [Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records In-Reply-To: <563A2158.80009@redhat.com> References: <563A2158.80009@redhat.com> Message-ID: <56404F9E.4090606@redhat.com> On 4.11.2015 16:16, Martin Basti wrote: > Patch attached. > > https://fedorahosted.org/freeipa/ticket/5421 I'm not entirely sure how this patch will interact with magic included in ipalib/plugins/dns.py:class dns_resolve(Command). I would like to delete the 'normalization' from at least one of these places. Also, as you know, DNS names are not strings and should be manipulated using python-dns so all crazy things in DNS names do not break in weird corner cases. -- Petr^2 Spacek From mbabinsk at redhat.com Mon Nov 9 08:55:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 9 Nov 2015 09:55:34 +0100 Subject: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options In-Reply-To: <564039E4.8000601@redhat.com> References: <563C731D.6010909@redhat.com> <563CCEFE.5040906@redhat.com> <564039E4.8000601@redhat.com> Message-ID: <56405F86.7070306@redhat.com> On 11/09/2015 07:15 AM, Jan Cholasta wrote: > On 6.11.2015 17:02, Martin Babinsky wrote: >> On 11/06/2015 10:30 AM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5433 >>> >>> >>> >> >> Attaching updated patch. > > NACK, the first patch was better, there should be quotes around the values. > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0094.2-fix-error-reporting-when-installer-option-is-supplie.patch Type: text/x-patch Size: 1139 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 9 10:52:49 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 Nov 2015 11:52:49 +0100 Subject: [Freeipa-devel] [PATCH 506] cert renewal: make renewal of ipaCert atomic Message-ID: <56407B01.4090804@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-506-cert-renewal-make-renewal-of-ipaCert-atomic.patch Type: text/x-patch Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-506.0.4_2-cert-renewal-make-renewal-of-ipaCert-atomic.patch Type: text/x-patch Size: 3383 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 9 10:52:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 9 Nov 2015 11:52:02 +0100 Subject: [Freeipa-devel] [patch 0023] Applied tier0 and tier1 marks on unit tests and xmlrpc tests In-Reply-To: <2132789766.3606122.1446740288271.JavaMail.zimbra@redhat.com> References: <563B2D77.8040701@redhat.com> <563B3B7D.3000103@redhat.com> <2132789766.3606122.1446740288271.JavaMail.zimbra@redhat.com> Message-ID: <56407AD2.8000406@redhat.com> On 05.11.2015 17:18, Ale? Mare?ek wrote: > Looks good, ACK. Pushed to ipa-4-2: 2f703e524552f1122645fdb83bb7808ef75e52fe Pushed to master: 0a64e9bd7061550b478be889b0e7fc90f560b06c > > ----- Original Message ----- >> From: "Milan Kub?k" >> To: freeipa-devel at redhat.com >> Sent: Thursday, November 5, 2015 12:20:29 PM >> Subject: Re: [Freeipa-devel] [patch 0023] Applied tier0 and tier1 marks on unit tests and xmlrpc tests >> >> On 11/05/2015 11:20 AM, Milan Kub?k wrote: >> >> >> Hi list, >> >> these patches introduce the tier categorization into the tests using >> pytest's mark mechanism. It is a step towards a change in our CI >> with which we hope to get more usefull/readable results as well as >> allow us to structure our CI in more logical way. >> >> Because of technical reasons, all tests that are subclasses of `Declarative` >> class are marked as tier1 tests. In these tests, if one suite is marked, all >> of >> the Declarative tests will be run as a big blob. >> >> The marks are not set in stone, please provide some feedback if you think >> some of the tests shoult go elsewhere. >> >> >> >> Self NACK after irc nitpick. Fixed pep8 complaints. >> >> -- >> Milan Kubik >> >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From tbabej at redhat.com Mon Nov 9 11:58:20 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 9 Nov 2015 12:58:20 +0100 Subject: [Freeipa-devel] [PATCH 0380] spec: Add Provides directives to alternative package names Message-ID: <56408A5C.4070702@redhat.com> Hi, this fixes: https://fedorahosted.org/freeipa/ticket/5408 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0380-spec-Add-Provides-directives-to-alternative-package-.patch Type: text/x-patch Size: 2955 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 9 12:10:36 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 Nov 2015 13:10:36 +0100 Subject: [Freeipa-devel] [PATCH 0380] spec: Add Provides directives to alternative package names In-Reply-To: <56408A5C.4070702@redhat.com> References: <56408A5C.4070702@redhat.com> Message-ID: <56408D3C.4030109@redhat.com> Hi, On 9.11.2015 12:58, Tomas Babej wrote: > Hi, > > this fixes: > > https://fedorahosted.org/freeipa/ticket/5408 a) Don't include %{release} in the Provides, release number is meaningless between distros. b) Please put the Provides near the related Conflicts and Obsoletes, like this: Provides: %{alt_name}-XXX = %{version} Conflicts: %{alt_name}-XXX Obsoletes: %{alt_name}-XXX < %{version} Honza -- Jan Cholasta From tbabej at redhat.com Mon Nov 9 12:34:27 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 9 Nov 2015 13:34:27 +0100 Subject: [Freeipa-devel] [PATCH 0380] spec: Add Provides directives to alternative package names In-Reply-To: <56408D3C.4030109@redhat.com> References: <56408A5C.4070702@redhat.com> <56408D3C.4030109@redhat.com> Message-ID: <564092D3.3050600@redhat.com> On 11/09/2015 01:10 PM, Jan Cholasta wrote: > Hi, > > On 9.11.2015 12:58, Tomas Babej wrote: >> Hi, >> >> this fixes: >> >> https://fedorahosted.org/freeipa/ticket/5408 > > a) Don't include %{release} in the Provides, release number is > meaningless between distros. > Good point. > b) Please put the Provides near the related Conflicts and Obsoletes, > like this: > > Provides: %{alt_name}-XXX = %{version} > Conflicts: %{alt_name}-XXX > Obsoletes: %{alt_name}-XXX < %{version} > > Honza > Updated version attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0380-2-spec-Add-Provides-directives-to-alternative-package-.patch Type: text/x-patch Size: 2226 bytes Desc: not available URL: From mkubik at redhat.com Mon Nov 9 12:35:02 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 9 Nov 2015 13:35:02 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Refactor test_user_plugin In-Reply-To: <20151106113201.5e6a7042@dhcp-24-123.brq.redhat.com> References: <20151106113201.5e6a7042@dhcp-24-123.brq.redhat.com> Message-ID: <564092F6.9000800@redhat.com> On 11/06/2015 11:32 AM, Filip ?kola wrote: > > Hi, the patch doesn't apply. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Mon Nov 9 13:37:00 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 9 Nov 2015 06:37:00 -0700 Subject: [Freeipa-devel] [PATCH 0063] ipa-replica-manage del continues when host does not exist in domain level 1 Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5424 thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0063-ipa-replica-manage-del-continues-when-host-does-not-.patch Type: text/x-patch Size: 1262 bytes Desc: not available URL: From redhatrises at gmail.com Mon Nov 9 13:39:44 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 9 Nov 2015 06:39:44 -0700 Subject: [Freeipa-devel] [PATCH 0343] Upgrade: enable custodia service during upgrade In-Reply-To: <5638FA60.9030603@redhat.com> References: <5638FA60.9030603@redhat.com> Message-ID: Ack. Thanks, Gabe On Tue, Nov 3, 2015 at 11:18 AM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5429 > > Patch attached. > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Mon Nov 9 14:09:15 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 9 Nov 2015 15:09:15 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan Message-ID: <5640A90B.6030906@redhat.com> Hi guys, Here are first two automated testcases from this (so far incomplete) testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan Testplan review is highly appreciated -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0016-First-part-of-replica-promotion-tests.patch Type: text/x-patch Size: 3881 bytes Desc: not available URL: From fskola at redhat.com Mon Nov 9 15:35:12 2015 From: fskola at redhat.com (Filip =?UTF-8?B?xaBrb2xh?=) Date: Mon, 9 Nov 2015 16:35:12 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Refactor test_user_plugin In-Reply-To: <564092F6.9000800@redhat.com> References: <20151106113201.5e6a7042@dhcp-24-123.brq.redhat.com> <564092F6.9000800@redhat.com> Message-ID: <20151109163512.3d3beb5f@redhat.com> Another patch was applied in the meantime. Attaching an updated version. F. On Mon, 9 Nov 2015 13:35:02 +0100 Milan Kub?k wrote: > On 11/06/2015 11:32 AM, Filip ?kola wrote: > > > > > Hi, > the patch doesn't apply. > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0001-Refactor-test_user_plugin.patch Type: text/x-patch Size: 105527 bytes Desc: not available URL: From rcritten at redhat.com Mon Nov 9 15:51:17 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Nov 2015 10:51:17 -0500 Subject: [Freeipa-devel] [PATCH 506] cert renewal: make renewal of ipaCert atomic In-Reply-To: <56407B01.4090804@redhat.com> References: <56407B01.4090804@redhat.com> Message-ID: <5640C0F5.7090404@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > There be a note in renew_ra_cert that the lock is obtained in advance by renew_ra_cert_pre. It looks like it will silently fail if the lock cannot be acquired. Is that desired? rob From mbasti at redhat.com Mon Nov 9 16:21:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 9 Nov 2015 17:21:59 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <5640A90B.6030906@redhat.com> References: <5640A90B.6030906@redhat.com> Message-ID: <5640C827.5090002@redhat.com> On 09.11.2015 15:09, Oleg Fayans wrote: > Hi guys, > > Here are first two automated testcases from this (so far incomplete) > testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan > > Testplan review is highly appreciated > > > > Hello, I did not test patch, I just read the testplan, I have a few comments: I'm not sure how test plan should look to cover QA needs, so maybe my following notes what is missing in test plan are not important. 1) CA has been affected by replica promotion patches 1a) test if ipa-ca-install works on replica with domain level 1 (test exists) 1b) test if ipa-ca-install works on replica with domain level 0 (test exists) 1c) test if ipa-ca-install works on master with domain level 1 (test exists) 1d) test if ipa-ca-install works on master with domain level 0 (test exists) 1e) test if ipa-ca-install with replica file fails with domain level 1 on replica 1f) test if ipa-ca-install fails without replica file with domain level 0 on replica 1g) test if ipa-ca-install works on CA-less master with domain level 0 (I'm not sure but probably tests exists) 1h) test if ipa-ca-install works on CA-less master with domain level 1 (I'm not sure but probably tests exists) 2) KRA has been affected by replica promotion patches 2a) test if ipa-kra-install works on replica with domain level 1 (test exists) 2b) test if ipa-kra-install works on replica with domain level 0 (test exists) 2c) test if ipa-krainstall works on master with domain level 1 (test exists) 2d) test if ipa-kra-install works on master with domain level 0 (test exists) 2e) test if ipa-kra-install with replica file fails with domain level 1 on replica 2f) test if ipa-kra-install fails without replica file with domain level 0 on replica 3) (not sure if this belongs to replica promotion or topology plugin testing) ipa-replica-manage behaves differently with domain level 1 3a) ipa-replica-manage connect should nto work with domain level 1 3b) ipa-replica-manage disconnect should not work with domain level 1 4) ipa-csreplica-manage behaves differently with domain level 1 4a) ipa-csreplica-manage connect should not work with domain level 1 4b) ipa-csreplica-manage disconnect should not work with domain level 1 4c) ipa-csreplica-manage del should not work with domain level 1 5) (this is not related to replica so much, but we miss this test) 5a) create new replica after master is restored from backup with domain level 1 5b) create new replica after master is restored from backup with domain level 0 Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Nov 10 08:28:45 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Nov 2015 09:28:45 +0100 Subject: [Freeipa-devel] [PATCH 507] install: drop support for Dogtag 9 Message-ID: <5641AABD.7010809@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-507-install-drop-support-for-Dogtag-9.patch Type: text/x-patch Size: 121015 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 10 08:52:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Nov 2015 09:52:23 +0100 Subject: [Freeipa-devel] [PATCH 507] install: drop support for Dogtag 9 In-Reply-To: <5641AABD.7010809@redhat.com> References: <5641AABD.7010809@redhat.com> Message-ID: <5641B047.3050909@redhat.com> On 10.11.2015 09:28, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Actually working patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-507.1-install-drop-support-for-Dogtag-9.patch Type: text/x-patch Size: 121015 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 10 09:38:52 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Nov 2015 10:38:52 +0100 Subject: [Freeipa-devel] [PATCH 506] cert renewal: make renewal of ipaCert atomic In-Reply-To: <5640C0F5.7090404@redhat.com> References: <56407B01.4090804@redhat.com> <5640C0F5.7090404@redhat.com> Message-ID: <5641BB2C.10103@redhat.com> On 9.11.2015 16:51, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > > There be a note in renew_ra_cert that the lock is obtained in advance by > renew_ra_cert_pre. Added comment. > > It looks like it will silently fail if the lock cannot be acquired. Is > that desired? All unhandled exceptions are logged to syslog in both renew_ra_cert_pre and renew_ra_cert: try: main() except Exception: syslog.syslog(syslog.LOG_ERR, traceback.format_exc()) Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-506.1-cert-renewal-make-renewal-of-ipaCert-atomic.patch Type: text/x-patch Size: 3432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-506.1.4_2-cert-renewal-make-renewal-of-ipaCert-atomic.patch Type: text/x-patch Size: 3430 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 10 09:42:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Nov 2015 10:42:49 +0100 Subject: [Freeipa-devel] [PATCH 0343] Upgrade: enable custodia service during upgrade In-Reply-To: References: <5638FA60.9030603@redhat.com> Message-ID: <5641BC19.70100@redhat.com> On 09.11.2015 14:39, Gabe Alford wrote: > Ack. > > Thanks, > > Gabe Thank you! Pushed to master: a8c3d6fbb7ac9c5e9f665473bfb7414bb073ae09 > > On Tue, Nov 3, 2015 at 11:18 AM, Martin Basti > wrote: > > https://fedorahosted.org/freeipa/ticket/5429 > > Patch attached. > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Tue Nov 10 09:52:45 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 10 Nov 2015 10:52:45 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Refactor test_user_plugin In-Reply-To: <20151109163512.3d3beb5f@redhat.com> References: <20151106113201.5e6a7042@dhcp-24-123.brq.redhat.com> <564092F6.9000800@redhat.com> <20151109163512.3d3beb5f@redhat.com> Message-ID: <5641BE6D.4060608@redhat.com> On 11/09/2015 04:35 PM, Filip ?kola wrote: > Another patch was applied in the meantime. > > Attaching an updated version. > > F. > > On Mon, 9 Nov 2015 13:35:02 +0100 > Milan Kub?k wrote: > >> On 11/06/2015 11:32 AM, Filip ?kola wrote: >>> >> Hi, >> the patch doesn't apply. >> Please fix this. ipatests/test_xmlrpc/test_user_plugin.py:1419: [E0602(undefined-variable), TestDeniedBindWithExpiredPrincipal.teardown_class] Undefined variable 'user1') Also, use the version numbers for your changed patches. -- Milan Kubik From mbasti at redhat.com Tue Nov 10 10:01:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Nov 2015 11:01:03 +0100 Subject: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options In-Reply-To: <56405F86.7070306@redhat.com> References: <563C731D.6010909@redhat.com> <563CCEFE.5040906@redhat.com> <564039E4.8000601@redhat.com> <56405F86.7070306@redhat.com> Message-ID: <5641C05F.2090901@redhat.com> On 09.11.2015 09:55, Martin Babinsky wrote: > On 11/09/2015 07:15 AM, Jan Cholasta wrote: >> On 6.11.2015 17:02, Martin Babinsky wrote: >>> On 11/06/2015 10:30 AM, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5433 >>>> >>>> >>>> >>> >>> Attaching updated patch. >> >> NACK, the first patch was better, there should be quotes around the >> values. >> > > Attaching updated patch. > ACK From mbasti at redhat.com Tue Nov 10 10:17:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Nov 2015 11:17:26 +0100 Subject: [Freeipa-devel] [PATCH 0062] DNS record-add warns when a suspicious DNS name is detected In-Reply-To: <56404E5A.6090709@redhat.com> References: <56404E5A.6090709@redhat.com> Message-ID: <5641C436.9050401@redhat.com> On 09.11.2015 08:42, Petr Spacek wrote: > Hello, > > DNS record-add warns when a suspicious DNS name is detected > > Relative name "record.zone" is being added into zone "zone.", > which is probably a mistake. User probably wanted to either specify > relative name "record" or use FQDN "record.zone.". > works as expected, I just have one nitpick: record name and zone are instances of DNSName class, thus would be better to use zone.relativize(DNSName.root) instead of zone.relativize(dns.name.root) Martin^2 From pspacek at redhat.com Tue Nov 10 10:19:30 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Nov 2015 11:19:30 +0100 Subject: [Freeipa-devel] [PATCH 0062] DNS record-add warns when a suspicious DNS name is detected In-Reply-To: <5641C436.9050401@redhat.com> References: <56404E5A.6090709@redhat.com> <5641C436.9050401@redhat.com> Message-ID: <5641C4B2.8010707@redhat.com> On 10.11.2015 11:17, Martin Basti wrote: > > > On 09.11.2015 08:42, Petr Spacek wrote: >> Hello, >> >> DNS record-add warns when a suspicious DNS name is detected >> >> Relative name "record.zone" is being added into zone "zone.", >> which is probably a mistake. User probably wanted to either specify >> relative name "record" or use FQDN "record.zone.". >> > > works as expected, I just have one nitpick: > > record name and zone are instances of DNSName class, thus would be better to use > zone.relativize(DNSName.root) > instead of > zone.relativize(dns.name.root) Thank you, I will keep it in mind for the next time. Please fix it before push ;-) -- Petr^2 Spacek From fskola at redhat.com Tue Nov 10 11:13:50 2015 From: fskola at redhat.com (Filip =?UTF-8?B?xaBrb2xh?=) Date: Tue, 10 Nov 2015 12:13:50 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Refactor test_user_plugin In-Reply-To: <5641BE6D.4060608@redhat.com> References: <20151106113201.5e6a7042@dhcp-24-123.brq.redhat.com> <564092F6.9000800@redhat.com> <20151109163512.3d3beb5f@redhat.com> <5641BE6D.4060608@redhat.com> Message-ID: <20151110121350.06295a68@dhcp-24-103.brq.redhat.com> Hi, fixed. F. On Tue, 10 Nov 2015 10:52:45 +0100 Milan Kub?k wrote: > On 11/09/2015 04:35 PM, Filip ?kola wrote: > > Another patch was applied in the meantime. > > > > Attaching an updated version. > > > > F. > > > > On Mon, 9 Nov 2015 13:35:02 +0100 > > Milan Kub?k wrote: > > > >> On 11/06/2015 11:32 AM, Filip ?kola wrote: > >>> > >> Hi, > >> the patch doesn't apply. > >> > Please fix this. > > ipatests/test_xmlrpc/test_user_plugin.py:1419: > [E0602(undefined-variable), > TestDeniedBindWithExpiredPrincipal.teardown_class] Undefined variable > 'user1') > > Also, use the version numbers for your changed patches. > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0001.2-Refactor-test_user_plugin.patch Type: text/x-patch Size: 105477 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 10 11:58:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Nov 2015 12:58:21 +0100 Subject: [Freeipa-devel] [PATCH 0063] Remove dead code in ipaserver/install/installutils: read_ip_address( Message-ID: <5641DBDD.8050805@redhat.com> Hello, Remove dead code in ipaserver/install/installutils: read_ip_address(). git grep claims that nothing is calling this function. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0063-Remove-dead-code-in-ipaserver-install-installutils-r.patch Type: text/x-patch Size: 1323 bytes Desc: not available URL: From dkupka at redhat.com Tue Nov 10 11:59:29 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 10 Nov 2015 12:59:29 +0100 Subject: [Freeipa-devel] [PATCH 0342] Use domain level constants in topology plugin In-Reply-To: <56388255.6010007@redhat.com> References: <56388255.6010007@redhat.com> Message-ID: <5641DC21.8080001@redhat.com> On 03/11/15 10:45, Martin Basti wrote: > Patch attached. > > Works for me, ACK. -- David Kupka From mbasti at redhat.com Tue Nov 10 12:49:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Nov 2015 13:49:13 +0100 Subject: [Freeipa-devel] [PATCH 0062] DNS record-add warns when a suspicious DNS name is detected In-Reply-To: <5641C4B2.8010707@redhat.com> References: <56404E5A.6090709@redhat.com> <5641C436.9050401@redhat.com> <5641C4B2.8010707@redhat.com> Message-ID: <5641E7C9.8040205@redhat.com> On 10.11.2015 11:19, Petr Spacek wrote: > On 10.11.2015 11:17, Martin Basti wrote: >> >> On 09.11.2015 08:42, Petr Spacek wrote: >>> Hello, >>> >>> DNS record-add warns when a suspicious DNS name is detected >>> >>> Relative name "record.zone" is being added into zone "zone.", >>> which is probably a mistake. User probably wanted to either specify >>> relative name "record" or use FQDN "record.zone.". >>> >> works as expected, I just have one nitpick: >> >> record name and zone are instances of DNSName class, thus would be better to use >> zone.relativize(DNSName.root) >> instead of >> zone.relativize(dns.name.root) > Thank you, I will keep it in mind for the next time. > > Please fix it before push ;-) > ACK the nitpick has been fixed, Pushed to master: 50b0471f01985d2d43998df1a9c4a73cf5cf47c1 From mbasti at redhat.com Tue Nov 10 12:50:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Nov 2015 13:50:49 +0100 Subject: [Freeipa-devel] [PATCH 0342] Use domain level constants in topology plugin In-Reply-To: <5641DC21.8080001@redhat.com> References: <56388255.6010007@redhat.com> <5641DC21.8080001@redhat.com> Message-ID: <5641E829.70108@redhat.com> On 10.11.2015 12:59, David Kupka wrote: > On 03/11/15 10:45, Martin Basti wrote: >> Patch attached. >> >> > Works for me, ACK. > Pushed to master: c339abbad1e82a264afc5cf9efa3aff80814aeaf From tbabej at redhat.com Tue Nov 10 13:10:22 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 10 Nov 2015 14:10:22 +0100 Subject: [Freeipa-devel] [PATCH 0063] Remove dead code in ipaserver/install/installutils: read_ip_address( In-Reply-To: <5641DBDD.8050805@redhat.com> References: <5641DBDD.8050805@redhat.com> Message-ID: <5641ECBE.1020904@redhat.com> On 11/10/2015 12:58 PM, Petr Spacek wrote: > Hello, > > Remove dead code in ipaserver/install/installutils: read_ip_address(). > > git grep claims that nothing is calling this function. > > > ACK. This should have been removed with the 26c1851e98f31f11cf52b36bcb7e399ccbb2af17. Tomas From mbabinsk at redhat.com Tue Nov 10 13:12:42 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 10 Nov 2015 14:12:42 +0100 Subject: [Freeipa-devel] [PATCHES] PoC: improve CLI and config option processing for installer Message-ID: <5641ED4A.3000903@redhat.com> these patches are a rough PoC of a new machinery that abstracts option handling/processing for installers ported on Jan's new installer framework and also implement https://fedorahosted.org/freeipa/ticket/4517 The code is admittedly ugly but functional and demonstrated the base architecture of the module. The user-facing entrypoints are the FrontendManager function call and the individual Frontend implementations which handle processing of options. Here is a short example of the usage: """ # we want the Server installer to accept options from both CLI and # config file ServerCLIConfig = FrontendManager(Server, ConfigFrontend, CLIFrontend) # add frontend-specific options to external option parser # in case of CLIFrontend, all installer knobs are fed to the parser as # options # in case of ConfigFrontend, a single option is added which holds # the location of config file option_parser = IPAOptionParser() ServerCLIConfig.add_options(option_parser) # let the parser parse the command line options, args = option_parser.parse_args(sys.argv[1:]) # get and validate all CLI/config options, instantiate the Server # configurator and run installation ServerCLIConfig.run(options, args) """ The second patch contains some basic tests for the new functionality The third patch in the series plugs this functionality into the existing CLI interface in a particularly nasty but (sorta-) functional way. I would very much appreciate any of your comments concerning the whole design and implementation. Suggestions to clean up the code are most welcome. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0003-POC-plug-the-new-option-handling-machinery-to-ipa-se.patch Type: text/x-patch Size: 14127 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0002-POC-test-suite-for-the-CLI-config-option-handlers.patch Type: text/x-patch Size: 13222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0001-POC-modular-processing-of-installer-options-from-mul.patch Type: text/x-patch Size: 15210 bytes Desc: not available URL: From tbabej at redhat.com Tue Nov 10 13:22:58 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 10 Nov 2015 14:22:58 +0100 Subject: [Freeipa-devel] [PATCH 0381] admintool: Remove the option to override the log file Message-ID: <5641EFB2.4080705@redhat.com> Hi, This has been rarely used, and can be replaced by proper shell output redirection. https://fedorahosted.org/freeipa/ticket/5408 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0381-admintool-Remove-the-option-to-override-the-log-file.patch Type: text/x-patch Size: 3892 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Nov 10 14:35:12 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 10 Nov 2015 15:35:12 +0100 Subject: [Freeipa-devel] [PATCHES 377-379] Hardening of ipa-adtrust-install In-Reply-To: <562F974A.2070909@redhat.com> References: <562F974A.2070909@redhat.com> Message-ID: <564200A0.8010209@redhat.com> On 10/27/2015 04:24 PM, Tomas Babej wrote: > Hi, > > this couple of patches harden the adtrust installer. > > Details in the commit messages. > > Fixes: https://fedorahosted.org/freeipa/ticket/5134 > > Tomas > > > NACK, in the first patch you forgot to instantiate the caught exception in the following snippet: + except Exception: + root_logger.debug("Exception occured during SID generation: {0}" + .format(str(e))) You should use 'except Exception as e:'. I'm also not quite sure that it is enough to log the error at debug level. If the sidgen task somehow fails, isn't it something which should interest the user and deserve at least warning-level message? -- Martin^3 Babinsky From tbabej at redhat.com Tue Nov 10 15:35:29 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 10 Nov 2015 16:35:29 +0100 Subject: [Freeipa-devel] [PATCHES 377-379] Hardening of ipa-adtrust-install In-Reply-To: <564200A0.8010209@redhat.com> References: <562F974A.2070909@redhat.com> <564200A0.8010209@redhat.com> Message-ID: <56420EC1.9040606@redhat.com> On 11/10/2015 03:35 PM, Martin Babinsky wrote: > On 10/27/2015 04:24 PM, Tomas Babej wrote: >> Hi, >> >> this couple of patches harden the adtrust installer. >> >> Details in the commit messages. >> >> Fixes: https://fedorahosted.org/freeipa/ticket/5134 >> >> Tomas >> >> >> > NACK, > > in the first patch you forgot to instantiate the caught exception in the > following snippet: > > + except Exception: > + root_logger.debug("Exception occured during SID generation: > {0}" > + .format(str(e))) > > You should use 'except Exception as e:'. > > I'm also not quite sure that it is enough to log the error at debug level. > > If the sidgen task somehow fails, isn't it something which should > interest the user and deserve at least warning-level message? > Thanks for catching this. Inappropriate message level indeed, I probably wasn't using my brain much when writing that snippet :) Updated patchset attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0377-2-adtrustinstance-Wait-for-sidgen-task-completion.patch Type: text/x-patch Size: 2205 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0378-2-adtrustinstance-Restart-samba-service-at-the-end-of-.patch Type: text/x-patch Size: 1542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0379-2-adtrustinstance-Do-not-use-bare-except-clauses.patch Type: text/x-patch Size: 3115 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Nov 10 15:43:50 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 10 Nov 2015 16:43:50 +0100 Subject: [Freeipa-devel] [PATCHES 377-379] Hardening of ipa-adtrust-install In-Reply-To: <56420EC1.9040606@redhat.com> References: <562F974A.2070909@redhat.com> <564200A0.8010209@redhat.com> <56420EC1.9040606@redhat.com> Message-ID: <564210B6.7070802@redhat.com> On 11/10/2015 04:35 PM, Tomas Babej wrote: > > > On 11/10/2015 03:35 PM, Martin Babinsky wrote: >> On 10/27/2015 04:24 PM, Tomas Babej wrote: >>> Hi, >>> >>> this couple of patches harden the adtrust installer. >>> >>> Details in the commit messages. >>> >>> Fixes: https://fedorahosted.org/freeipa/ticket/5134 >>> >>> Tomas >>> >>> >>> >> NACK, >> >> in the first patch you forgot to instantiate the caught exception in the >> following snippet: >> >> + except Exception: >> + root_logger.debug("Exception occured during SID generation: >> {0}" >> + .format(str(e))) >> >> You should use 'except Exception as e:'. >> >> I'm also not quite sure that it is enough to log the error at debug level. >> >> If the sidgen task somehow fails, isn't it something which should >> interest the user and deserve at least warning-level message? >> > > Thanks for catching this. Inappropriate message level indeed, I probably > wasn't using my brain much when writing that snippet :) > > Updated patchset attached. > > Tomas > Thanks, ACK. -- Martin^3 Babinsky From tbabej at redhat.com Tue Nov 10 15:53:56 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 10 Nov 2015 16:53:56 +0100 Subject: [Freeipa-devel] [PATCHES 377-379] Hardening of ipa-adtrust-install In-Reply-To: <564210B6.7070802@redhat.com> References: <562F974A.2070909@redhat.com> <564200A0.8010209@redhat.com> <56420EC1.9040606@redhat.com> <564210B6.7070802@redhat.com> Message-ID: <56421314.20201@redhat.com> On 11/10/2015 04:43 PM, Martin Babinsky wrote: > On 11/10/2015 04:35 PM, Tomas Babej wrote: >> >> >> On 11/10/2015 03:35 PM, Martin Babinsky wrote: >>> On 10/27/2015 04:24 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this couple of patches harden the adtrust installer. >>>> >>>> Details in the commit messages. >>>> >>>> Fixes: https://fedorahosted.org/freeipa/ticket/5134 >>>> >>>> Tomas >>>> >>>> >>>> >>> NACK, >>> >>> in the first patch you forgot to instantiate the caught exception in the >>> following snippet: >>> >>> + except Exception: >>> + root_logger.debug("Exception occured during SID generation: >>> {0}" >>> + .format(str(e))) >>> >>> You should use 'except Exception as e:'. >>> >>> I'm also not quite sure that it is enough to log the error at debug >>> level. >>> >>> If the sidgen task somehow fails, isn't it something which should >>> interest the user and deserve at least warning-level message? >>> >> >> Thanks for catching this. Inappropriate message level indeed, I probably >> wasn't using my brain much when writing that snippet :) >> >> Updated patchset attached. >> >> Tomas >> > Thanks, ACK. > Pushed to master: 767b8de01298e9de20f3b85bad5ac98472b14e99 From tbabej at redhat.com Tue Nov 10 15:54:55 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 10 Nov 2015 16:54:55 +0100 Subject: [Freeipa-devel] [PATCH 0063] Remove dead code in ipaserver/install/installutils: read_ip_address( In-Reply-To: <5641ECBE.1020904@redhat.com> References: <5641DBDD.8050805@redhat.com> <5641ECBE.1020904@redhat.com> Message-ID: <5642134F.8000200@redhat.com> On 11/10/2015 02:10 PM, Tomas Babej wrote: > > > On 11/10/2015 12:58 PM, Petr Spacek wrote: >> Hello, >> >> Remove dead code in ipaserver/install/installutils: read_ip_address(). >> >> git grep claims that nothing is calling this function. >> >> >> > > ACK. This should have been removed with the > 26c1851e98f31f11cf52b36bcb7e399ccbb2af17. > > Tomas > Pushed to master: bca9371d8e8aa138a0e638b52acc8929801d586f From pspacek at redhat.com Tue Nov 10 15:58:14 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Nov 2015 16:58:14 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder Message-ID: <56421416.8060104@redhat.com> Hello, Patch 64: ipa-dns-install offer IP addresses from resolv.conf as default forwarders In non-interactive more option --auto-forwarders can be used to do the same. --forward option can be used to supply additional IP addresses. https://fedorahosted.org/freeipa/ticket/5438 Patch 65: Remove global variable dns_forwarders from ipaserver.install.dns It seems to me that the global thingy is not necessary, so I've ripped it out. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0064-ipa-dns-install-offer-IP-addresses-from-resolv.conf-.patch Type: text/x-patch Size: 7327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0065-Remove-global-variable-dns_forwarders-from-ipaserver.patch Type: text/x-patch Size: 4783 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 10 16:04:55 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Nov 2015 17:04:55 +0100 Subject: [Freeipa-devel] [PATCH 0066] Remove unused constant NEW_MASTER_MARK from ipaserver.install.dn Message-ID: <564215A7.80900@redhat.com> Hello, Remove unused constant NEW_MASTER_MARK from ipaserver.install.dns. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0066-Remove-unused-constant-NEW_MASTER_MARK-from-ipaserve.patch Type: text/x-patch Size: 775 bytes Desc: not available URL: From redhatrises at gmail.com Tue Nov 10 16:07:16 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 10 Nov 2015 09:07:16 -0700 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: <56421416.8060104@redhat.com> References: <56421416.8060104@redhat.com> Message-ID: Does this also fix https://fedorahosted.org/freeipa/ticket/3926? On Tue, Nov 10, 2015 at 8:58 AM, Petr Spacek wrote: > Hello, > > Patch 64: > ipa-dns-install offer IP addresses from resolv.conf as default forwarders > > In non-interactive more option --auto-forwarders can be used to do the > same. --forward option can be used to supply additional IP addresses. > > https://fedorahosted.org/freeipa/ticket/5438 > > > Patch 65: > Remove global variable dns_forwarders from ipaserver.install.dns > It seems to me that the global thingy is not necessary, so I've ripped it > out. > > -- > Petr^2 Spacek > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Nov 10 16:10:58 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Nov 2015 17:10:58 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: References: <56421416.8060104@redhat.com> Message-ID: <56421712.7040405@redhat.com> On 10.11.2015 17:07, Gabe Alford wrote: > Does this also fix https://fedorahosted.org/freeipa/ticket/3926? Yes. Good catch, I did not know about this ticket :-) Petr Spacek @ Red Hat > On Tue, Nov 10, 2015 at 8:58 AM, Petr Spacek wrote: > >> Hello, >> >> Patch 64: >> ipa-dns-install offer IP addresses from resolv.conf as default forwarders >> >> In non-interactive more option --auto-forwarders can be used to do the >> same. --forward option can be used to supply additional IP addresses. >> >> https://fedorahosted.org/freeipa/ticket/5438 >> >> >> Patch 65: >> Remove global variable dns_forwarders from ipaserver.install.dns >> It seems to me that the global thingy is not necessary, so I've ripped it >> out. >> >> -- >> Petr^2 Spacek From pspacek at redhat.com Tue Nov 10 16:36:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Nov 2015 17:36:21 +0100 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <5639E448.5080302@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <5627B576.9060003@redhat.com> <56290176.5030303@redhat.com> <5639E448.5080302@redhat.com> Message-ID: <56421D05.5050908@redhat.com> On 4.11.2015 11:56, Martin Babinsky wrote: > On 10/22/2015 05:32 PM, Petr Spacek wrote: >> On 21.10.2015 17:55, Martin Babinsky wrote: >>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>> >>>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>>> associated credentials cache during its uninstall >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>> >>>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>>> during *install* so problems caused by failing uninstallation will be >>>> fixed on >>>> repeated install. This is yet another step towards idempotent installer. >>>> >>>> To me this makes more sense than doing so on uninstall. Does it make sense to >>>> you, too? >>>> >>> >>> Attaching updated patch that does cleanup also before each instance creation. >>> It is a bit ugly I admit, but I couldn't think of a better way to do it and >>> didn't want to poke into service/instance code more than neccesary. >> >> NACK, but we are almost there! >> >> * kdestroy -A is too aggressive and wipes root's keyring after each run of >> ipa-*-install utils. >> >> * There are some scattered leftovers of ipautil.run['kdestroy'...] in the >> tree. Please get rid of them. >> >> Thank you! >> > Attaching updated patch. It got lost somewhere in the list. ACK, thank you for patience. -- Petr^2 Spacek From mbabinsk at redhat.com Tue Nov 10 16:43:50 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 10 Nov 2015 17:43:50 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <563A456A.2070101@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> <5639FA77.3090907@redhat.com> <563A456A.2070101@redhat.com> Message-ID: <56421EC6.9050205@redhat.com> On 11/04/2015 06:50 PM, Petr Vobornik wrote: > On 11/04/2015 01:30 PM, Martin Babinsky wrote: >> On 10/30/2015 05:06 PM, Martin Babinsky wrote: >>> On 10/30/2015 03:38 PM, Petr Vobornik wrote: >>>> On 10/30/2015 03:26 PM, Martin Babinsky wrote: >>>>> patch for https://fedorahosted.org/freeipa/ticket/5309 >>>>> >>>>> The ticket itself is about connectivity checks in topology suffixes, >>>>> but >>>>> there is a code (install/tools/ipa-replica-manage starting at line 788 >>>>> after applying my patch) which monitors whether the segments pointing >>>>> to/from the deleted host are already deleted. >>>>> >>>>> These checks are currently hardcoded for 'realm' prefix, should we >>>>> generalize them as well or is it a part of other effort? >>>>> >>>> >>>> Could be separate patch but yes. >>> Ok I have included it in the attached patch so that both of these >>> operations are performed for all suffixes. >>> >>> >>> >> Hmm, I'm thinking whether the 'check_last_link_managed' and >> 'check_deleted_segments' should not be called per-suffix, but should >> themselves check all suffixes available. This could make the fix for >> https://fedorahosted.org/freeipa/ticket/5409 also easier. >> > > Depends if the output is reusable. If so then why not. > check_last_link_managed basically adds text to several > get_topology_connection_errors calls. Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0093.2-check-for-disconnected-topology-and-deleted-agreemen.patch Type: text/x-patch Size: 12845 bytes Desc: not available URL: From rcritten at redhat.com Tue Nov 10 18:19:51 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Nov 2015 13:19:51 -0500 Subject: [Freeipa-devel] [PATCH 506] cert renewal: make renewal of ipaCert atomic In-Reply-To: <5641BB2C.10103@redhat.com> References: <56407B01.4090804@redhat.com> <5640C0F5.7090404@redhat.com> <5641BB2C.10103@redhat.com> Message-ID: <56423547.5080207@redhat.com> Jan Cholasta wrote: > On 9.11.2015 16:51, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >>> >>> >> >> There be a note in renew_ra_cert that the lock is obtained in advance by >> renew_ra_cert_pre. > > Added comment. > >> >> It looks like it will silently fail if the lock cannot be acquired. Is >> that desired? > > All unhandled exceptions are logged to syslog in both renew_ra_cert_pre > and renew_ra_cert: > > try: > main() > except Exception: > syslog.syslog(syslog.LOG_ERR, traceback.format_exc()) > > Updated patch attached. > My confusion was with the auto-expiration. I guess this is ok. When debugging this sort of thing via logs the more the merrier, so I guess I'd have added a syslog to say "obtaining lock" or "locked" and then something when the renewal actually starts, so one can try to piece together what happened after the fact if something goes wrong. I guess certmonger already logs when a pre/post command is executed so that may already be available. rob From fcami at redhat.com Tue Nov 10 22:35:26 2015 From: fcami at redhat.com (Francois Cami) Date: Tue, 10 Nov 2015 17:35:26 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Fix download message In-Reply-To: <187238483.4254856.1447192534535.JavaMail.zimbra@redhat.com> Message-ID: <518086759.4263542.1447194926887.JavaMail.zimbra@redhat.com> Hi, The "Do you want download the CA cert from" message in ipa-client-install should be changed to "Do you want to download the CA cert from". As this is a single-line trivial fix I haven't opened a trac ticket. I will do so if anyone feels this is necessary even in this case. Thank you, Fran?ois -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fcami-0001-Fix-download-message.patch Type: text/x-patch Size: 1211 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Wed Nov 11 01:03:57 2015 From: mrniranjan at fedoraproject.org (Niranjan) Date: Wed, 11 Nov 2015 06:33:57 +0530 Subject: [Freeipa-devel] [PATCH] enable pem=True in export_pem_cert function In-Reply-To: <20151028002919.GA10557@mniranja.pnq.redhat.com> References: <20151026195959.GA20574@mniranja.pnq.redhat.com> <562F9BCF.2090502@redhat.com> <20151028002919.GA10557@mniranja.pnq.redhat.com> Message-ID: <20151111010357.GA8808@mniranja.pnq.redhat.com> Niranjan wrote: > Tomas Babej wrote: > > On 10/26/2015 08:59 PM, Niranjan wrote: > > > Greetings, > > > > > > export_pem_cert function from ipapython/certdb should export the certificate > > > in pem format but instead exports the cert in der format as it doesn't enable pem=True. > > > > > > This patch specifies pem=True for export_pem_cert function > > > > > > Regards > > > Niranjan > > > > Hi, > > > > the patch looks good, however, I'm curious as to how did you find this > > bug? Does it affect anything? > I am part of the CS(dogtag) QE team, and as part of CS Automation, i am relying > on some generic functions provided by ipapython. While using those functions > for our automation, I found it. > > > > It seems to me that this part of the code is a dead branch which should > > be removed. > I did not look further ipapython, so i am not aware where else export_pem_cert > is being used, but i would like the functions in certdb.py be available. > > > > $ git grep export_pem_cert > > ipapython/certdb.py: def export_pem_cert(self, nickname, location): > > ipaserver/install/certs.py: def export_pem_cert(self, nickname, > > ipaserver/install/certs.py: return self.nssdb.export_pem_ce.. Any update on this. > > > > Tomas > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From jcholast at redhat.com Wed Nov 11 07:12:59 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Nov 2015 08:12:59 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: <56421416.8060104@redhat.com> References: <56421416.8060104@redhat.com> Message-ID: <5642EA7B.1060505@redhat.com> On 10.11.2015 16:58, Petr Spacek wrote: > Hello, > > Patch 64: > ipa-dns-install offer IP addresses from resolv.conf as default forwarders > > In non-interactive more option --auto-forwarders can be used to do the > same. --forward option can be used to supply additional IP addresses. > > https://fedorahosted.org/freeipa/ticket/5438 IMO it's perverse to add option which effectively means "use default value" instead of actually using the value as default. This is inconsistent with every other option and I don't see what makes forwarders so special to require this. NACK unless you have a strong justification for this. > > > Patch 65: > Remove global variable dns_forwarders from ipaserver.install.dns > It seems to me that the global thingy is not necessary, so I've ripped it out. ACK. -- Jan Cholasta From slaznick at redhat.com Wed Nov 11 08:24:18 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 11 Nov 2015 09:24:18 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <563B8F41.8090902@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> Message-ID: <5642FB32.4070406@redhat.com> On 11/05/2015 06:17 PM, Petr Spacek wrote: > On 4.11.2015 15:20, Martin Basti wrote: > >> Hello, >> >> we (Standa and I) had offline discussion and I proposed following idea: >> >> 1) create new entry in LDAP for "time rule" instead of adding the time rule >> string directly into HBACRule. >> This will allow to reuse time rules among various HBAC Rules (and maybe in >> future with sudo rules, etc.) >> HBACrule gets only reference to time rule entry stored in LDAP db. > Good idea! I can see time rule entry 'working hours in Brno office' which is > linked to relevant HBAC rules. This seems like a good idea. However, it might be a bit messy to have even the least significant rules stored in separate objects. But I agree. It brings some questions, though. Where would be a good spot to store these time rules? Should they be able to form groups? Should such an object be able to hold more time policies strings and exceptions, as it does now, or would it be better to set that in the respective HBAC rule? > >> 2) Do not create a new time format, just reuse iCal (parts of iCal we need), >> to store time rule in LDAP in "time rule" entry >> (Or is possible to not store the values just as one string, we can use >> different attributes to store separate values, iCal can be used as export and >> import format) > I very much agree with re-using iCal! We have sufficient number of custom > parsers already ;-) > > Speaking about custom LDAP format, I do not think that it is a good idea. It > would prevent us from using iCal parsers and generators and we would risk that > our custom LDAP format will not be flexible enough. > > For these reasons I would go with 1 iCal string which can be fed into any > standard-compliant iCal library. I was thinking long and hard about actually using the iCalendar format for this purpose, ever since the 'repeat' keyword was supposed to be included in the language. However, as I mentioned some time ago, the iCalendar format recurrences are OK when it comes to recurring events but I am not sure about them being very suitable for describing time policies. Let me do a comparison of the options. I will take in question only the RRULE (and possibly PERIOD) part of the iCalendar format. Having the whole iCalendar format involved along with its parsing C library seemed to be a no-go for SSSD some 6 months ago and I can imagine such feelings persist. ---------------------------- Some iCalendar cons: 1) It is hard to represent continuous time of a day ranges There does not seem to be an easy equivalent to e.g. 'timeofday= 0730~1100, 1200~1615'. The easiest way to do this in iCalendar would be to have 2 rules of the form: DTSTART: 19700101T073000 DTEND: 19700101T110000 RRULE: FREQ=DAILY; INTERVAL=1 DTSTART: 19700101T120000 DTEND: 19700101T161500 RRULE: FREQ=DAILY; INTERVAL=1 If you were setting some more difficult policy, there would have to be a lot of duplicity in each of such rules. 2) All iCalendar events have to have a fixed starting point There must always be a check against the interval and the starting point. 3) There are no ranges e.g. 'dayofyear=2-50, 100-125' would translate to DTSTART:19700101T000000 RRULE: FREQ=SECONDLY; INTERVAL=1; BYYEARDAY=2,3,4,5,6,7,8,9,10,11,...50,100,101,102,... 4) There is no way to list specific years in which the HBAC rule should apply. 5) COUNT parameter makes you generate all previous events before you are able to tell if the current one actually applies. Imagine COUNT being a big number and an event that hardly ever happens. Imagine current time to fall into the last event. 6) The event descriptions are not so intuitive There would probably have to be better conversion system at least for CLI when user wants to set time ranges of access allowed times so that we can consider it good UX. I am not mentioning the lack of weekofmonth in iCal as I would rather drop it from the current solution, too. ---------------------------- On the other hand, there are also some big pros for iCalendar. 1) It is a standard. It behaves in a known and described manner. 2) By proper use of BYSETPOS of RRULE, it is able to describe some specific situations, e.g. last workday of a month. This is not possible in the current language. 3) Easier setting of absolute time ranges using the PERIOD property (although this could probably be easily solved by a minor addition to the current solution). 4) A GUI for setting RRULEs already exists. ad 4) The GUI, however, hides some of the features of the language (e.g. the mentioned BYSETPOS) and is not suitable for setting time policies as is. Try, for example, setting a policy "allow access from 7:00 to 16:00 (no break of the interval as iCalendar does not know it) every first Monday through Friday of a month for the first half of every year". In current language: timeofday=0700~1600 dayofmonth=1~7 dayofweek=1~5 monthofyear=1~6 In iCalendar RRULE: DTSTART: 19700101T070000 DTEND: 19700101T160000 RRULE: FREQ=YEARLY; BYMONTH=1,2,3,4,5,6;BYDAY=1MO,1TU,1WE,1TH,1FR ---------------------------- Hopefully, this was a thorough walk-through of the pros and cons of both approaches. I believe I stayed clear of any sentiment to the work I did of which a big part could come in vain if we moved to iCalendar format. Please correct me if I haven't. I wonder if we want to have someone from SSSD in this discussion, too. > >> 3) We may provide nice CLI and webUI to construct/show "time rule", this may >> be more user friendly than just passing the string containing time data to >> HBAC rule. > This is going to be the same as in any calendaring system. Just look to > Thunderbird "New Event" dialog. > Please, see my comments on the GUI in ad 4). On the other hand to the comments - there is at least something done in iCalendar GUI that we could use rather than coining out a whole new GUI for time policies. -- Standa -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Wed Nov 11 08:26:36 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 11 Nov 2015 09:26:36 +0100 Subject: [Freeipa-devel] ipa-kra-install at domain level 0 Message-ID: <5642FBBC.3090304@redhat.com> Hi all, when running ipa-kra-install on a replica with domain level 0 and with replica file proivided, I get the following error: $ ipa-kra-install -U -p /home/ofayans/ipatests/replica-info.gpg Your system may be partly configured. Run ipa-kra-install --uninstall to clean up. Too many parameters provided. No replica file is required. The ipa-kra-install command failed. See /var/log/ipaserver-kra-install.log for more information --------------------------------------------------------------------- However, when I issue the same command without the replica file, the installation starts, but fails in the middle, without any reasonable error message that I do need a replica file: $ ipa-kra-install -p -U =================================================================== This program will setup Dogtag KRA for the FreeIPA Server. Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds [1/8]: configuring KRA instance Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' 'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1 See the installation logs and the following files/directories for more information: /var/log/pki-ca-install.log /var/log/pki/pki-tomcat [error] RuntimeError: KRA configuration failed. Your system may be partly configured. Run ipa-kra-install --uninstall to clean up. KRA configuration failed. The ipa-kra-install command failed. See /var/log/ipaserver-kra-install.log for more information -------------------------------------------------------------------- Both logs are attached -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- 2015-11-11T08:20:24Z DEBUG Logging to /var/log/ipaserver-kra-install.log 2015-11-11T08:20:24Z DEBUG ipa-kra-install was invoked with arguments [] and options: {'verbose': False, 'no_host_dns': False, 'quiet': False, 'log_file': None, 'unattended': True, 'uninstall': False} 2015-11-11T08:20:24Z DEBUG IPA version 4.2.90.201511101521GITc339abb-0.fc22 2015-11-11T08:20:25Z DEBUG Created connection context.ldap2_139715914147472 2015-11-11T08:20:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-11-11T08:20:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-11-11T08:20:25Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2015-11-11T08:20:25Z DEBUG Trying to find certificate subject base in sysupgrade 2015-11-11T08:20:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2015-11-11T08:20:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2015-11-11T08:20:25Z DEBUG Found certificate subject base in sysupgrade: O=IDM.LAB.ENG.BRQ.REDHAT.COM 2015-11-11T08:20:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-11-11T08:20:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-11-11T08:20:25Z DEBUG Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds 2015-11-11T08:20:25Z DEBUG [1/8]: configuring KRA instance 2015-11-11T08:20:25Z DEBUG Contents of pkispawn configuration file (/tmp/tmpPQGCs0): [KRA] pki_security_domain_https_port = 443 pki_security_domain_password = XXXXXXXX pki_security_domain_user = admin pki_issuing_ca_uri = https://vm-070.idm.lab.eng.brq.redhat.com:443 pki_enable_proxy = True pki_restart_configured_instance = False pki_backup_keys = True pki_backup_password = XXXXXXXX pki_client_database_dir = /tmp/tmp-eb6gBl pki_client_database_password = XXXXXXXX pki_client_database_purge = False pki_client_pkcs12_password = XXXXXXXX pki_admin_name = admin pki_admin_uid = admin pki_admin_email = root at localhost pki_admin_password = XXXXXXXX pki_admin_nickname = ipa-ca-agent pki_admin_subject_dn = cn=ipa-ca-agent,O=IDM.LAB.ENG.BRQ.REDHAT.COM pki_import_admin_cert = True pki_admin_cert_file = /root/.dogtag/pki-tomcat/ca_admin.cert pki_client_admin_cert_p12 = /root/ca-agent.p12 pki_ds_ldap_port = 389 pki_ds_password = XXXXXXXX pki_ds_base_dn = o=kra,o=ipaca pki_ds_database = ipaca pki_ds_create_new_db = False pki_subsystem_subject_dn = cn=CA Subsystem,O=IDM.LAB.ENG.BRQ.REDHAT.COM pki_ssl_server_subject_dn = cn=vm-070.idm.lab.eng.brq.redhat.com,O=IDM.LAB.ENG.BRQ.REDHAT.COM pki_audit_signing_subject_dn = cn=KRA Audit,O=IDM.LAB.ENG.BRQ.REDHAT.COM pki_transport_subject_dn = cn=KRA Transport Certificate,O=IDM.LAB.ENG.BRQ.REDHAT.COM pki_storage_subject_dn = cn=KRA Storage Certificate,O=IDM.LAB.ENG.BRQ.REDHAT.COM pki_subsystem_nickname = subsystemCert cert-pki-ca pki_ssl_server_nickname = Server-Cert cert-pki-ca pki_audit_signing_nickname = auditSigningCert cert-pki-kra pki_transport_nickname = transportCert cert-pki-kra pki_storage_nickname = storageCert cert-pki-kra pki_share_db = True pki_share_dbuser_dn = uid=pkidbuser,ou=people,o=ipaca 2015-11-11T08:20:25Z DEBUG Starting external process 2015-11-11T08:20:25Z DEBUG args='/usr/sbin/pkispawn' '-s' 'KRA' '-f' '/tmp/tmpPQGCs0' 2015-11-11T08:20:53Z DEBUG Process finished, return code=1 2015-11-11T08:20:53Z DEBUG stdout=Log file: /var/log/pki/pki-kra-spawn.20151111092025.log Loading deployment configuration from /tmp/tmpPQGCs0. Installing KRA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/kra/deployment.cfg. Installation failed. 2015-11-11T08:20:53Z DEBUG stderr=/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html InsecureRequestWarning) /usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html InsecureRequestWarning) /usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html InsecureRequestWarning) /usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html InsecureRequestWarning) 2015-11-11T08:20:53Z CRITICAL Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' 'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1 2015-11-11T08:20:53Z CRITICAL See the installation logs and the following files/directories for more information: 2015-11-11T08:20:53Z CRITICAL /var/log/pki-ca-install.log 2015-11-11T08:20:53Z CRITICAL /var/log/pki/pki-tomcat 2015-11-11T08:20:53Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 445, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 435, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/krainstance.py", line 262, in __spawn_instance DogtagInstance.spawn_instance(self, cfg_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 207, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 470, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) RuntimeError: KRA configuration failed. 2015-11-11T08:20:53Z DEBUG [error] RuntimeError: KRA configuration failed. 2015-11-11T08:20:53Z ERROR Your system may be partly configured. Run ipa-kra-install --uninstall to clean up. 2015-11-11T08:20:53Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", line 226, in run self._run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", line 222, in _run kra.install(api, config, self.options) File "/usr/lib/python2.7/site-packages/ipaserver/install/kra.py", line 70, in install options.dm_password, subject_base=subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/krainstance.py", line 132, in configure_instance self.start_creation(runtime=126) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 445, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 435, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/krainstance.py", line 262, in __spawn_instance DogtagInstance.spawn_instance(self, cfg_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 207, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 470, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) 2015-11-11T08:20:53Z DEBUG The ipa-kra-install command failed, exception: RuntimeError: KRA configuration failed. 2015-11-11T08:20:53Z ERROR KRA configuration failed. 2015-11-11T08:20:53Z ERROR The ipa-kra-install command failed. See /var/log/ipaserver-kra-install.log for more information -------------- next part -------------- 2015-11-11T08:12:07Z DEBUG Logging to /var/log/ipaserver-kra-install.log 2015-11-11T08:12:07Z DEBUG ipa-kra-install was invoked with arguments ['/home/ofayans/ipatests/replica-info.gpg'] and options: {'verbose': False, 'no_host_dns': False, 'quiet': False, 'log_file': None, 'unattended': True, 'uninstall': False} 2015-11-11T08:12:07Z DEBUG IPA version 4.2.90.201511101521GITc339abb-0.fc22 2015-11-11T08:12:08Z ERROR Your system may be partly configured. Run ipa-kra-install --uninstall to clean up. 2015-11-11T08:12:08Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", line 226, in run self._run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", line 176, in _run raise RuntimeError("Too many parameters provided. " 2015-11-11T08:12:08Z DEBUG The ipa-kra-install command failed, exception: RuntimeError: Too many parameters provided. No replica file is required. 2015-11-11T08:12:08Z ERROR Too many parameters provided. No replica file is required. 2015-11-11T08:12:08Z ERROR The ipa-kra-install command failed. See /var/log/ipaserver-kra-install.log for more information From mbabinsk at redhat.com Wed Nov 11 08:27:16 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 11 Nov 2015 09:27:16 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: <5642EA7B.1060505@redhat.com> References: <56421416.8060104@redhat.com> <5642EA7B.1060505@redhat.com> Message-ID: <5642FBE4.8040501@redhat.com> On 11/11/2015 08:12 AM, Jan Cholasta wrote: > On 10.11.2015 16:58, Petr Spacek wrote: >> Hello, >> >> Patch 64: >> ipa-dns-install offer IP addresses from resolv.conf as default forwarders >> >> In non-interactive more option --auto-forwarders can be used to do the >> same. --forward option can be used to supply additional IP addresses. >> >> https://fedorahosted.org/freeipa/ticket/5438 > > IMO it's perverse to add option which effectively means "use default > value" instead of actually using the value as default. This is > inconsistent with every other option and I don't see what makes > forwarders so special to require this. > > NACK unless you have a strong justification for this. > Is it possible to use default_getter decorator to fetch defaults for the 'forwarders' knob from the resolver if it is avaliable like so (warning: untested and possibly wrong)? """ @@ -160,20 +162,27 @@ class BaseServerCA(common.Installable, core.Group, core.Composite): class BaseServerDNS(common.Installable, core.Group, core.Composite): description = "DNS" forwarders = Knob( (list, 'ip'), None, description=("Add a DNS forwarder. This option can be used multiple " "times"), cli_name='forwarder', ) + @forwarders.default_getter + def forwarders(self): + try: + return resolver.get_default_resolver().nameservers + except Exception: + return None + no_forwarders = Knob( bool, False, description="Do not add any DNS forwarders, use root servers instead", ) reverse_zones = Knob( (list, str), [], description=("The reverse DNS zone to use. This option can be used " """ >> >> >> Patch 65: >> Remove global variable dns_forwarders from ipaserver.install.dns >> It seems to me that the global thingy is not necessary, so I've ripped >> it out. > > ACK. > -- Martin^3 Babinsky From jcholast at redhat.com Wed Nov 11 08:32:39 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Nov 2015 09:32:39 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: <5642FBE4.8040501@redhat.com> References: <56421416.8060104@redhat.com> <5642EA7B.1060505@redhat.com> <5642FBE4.8040501@redhat.com> Message-ID: <5642FD27.1050103@redhat.com> On 11.11.2015 09:27, Martin Babinsky wrote: > On 11/11/2015 08:12 AM, Jan Cholasta wrote: >> On 10.11.2015 16:58, Petr Spacek wrote: >>> Hello, >>> >>> Patch 64: >>> ipa-dns-install offer IP addresses from resolv.conf as default >>> forwarders >>> >>> In non-interactive more option --auto-forwarders can be used to do the >>> same. --forward option can be used to supply additional IP addresses. >>> >>> https://fedorahosted.org/freeipa/ticket/5438 >> >> IMO it's perverse to add option which effectively means "use default >> value" instead of actually using the value as default. This is >> inconsistent with every other option and I don't see what makes >> forwarders so special to require this. >> >> NACK unless you have a strong justification for this. >> > Is it possible to use default_getter decorator to fetch defaults for the > 'forwarders' knob from the resolver if it is avaliable like so (warning: > untested and possibly wrong)? Yes, this is exactly how it should be used (although the exception handling could be better). > > """ > @@ -160,20 +162,27 @@ class BaseServerCA(common.Installable, core.Group, > core.Composite): > class BaseServerDNS(common.Installable, core.Group, core.Composite): > description = "DNS" > > forwarders = Knob( > (list, 'ip'), None, > description=("Add a DNS forwarder. This option can be used > multiple " > "times"), > cli_name='forwarder', > ) > > + @forwarders.default_getter > + def forwarders(self): > + try: > + return resolver.get_default_resolver().nameservers > + except Exception: > + return None > + > no_forwarders = Knob( > bool, False, > description="Do not add any DNS forwarders, use root servers > instead", > ) > > reverse_zones = Knob( > (list, str), [], > description=("The reverse DNS zone to use. This option can be > used " > > """ > >>> >>> >>> Patch 65: >>> Remove global variable dns_forwarders from ipaserver.install.dns >>> It seems to me that the global thingy is not necessary, so I've ripped >>> it out. >> >> ACK. >> > > -- Jan Cholasta From mbabinsk at redhat.com Wed Nov 11 08:36:02 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 11 Nov 2015 09:36:02 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: <5642FD27.1050103@redhat.com> References: <56421416.8060104@redhat.com> <5642EA7B.1060505@redhat.com> <5642FBE4.8040501@redhat.com> <5642FD27.1050103@redhat.com> Message-ID: <5642FDF2.3060609@redhat.com> On 11/11/2015 09:32 AM, Jan Cholasta wrote: > On 11.11.2015 09:27, Martin Babinsky wrote: >> On 11/11/2015 08:12 AM, Jan Cholasta wrote: >>> On 10.11.2015 16:58, Petr Spacek wrote: >>>> Hello, >>>> >>>> Patch 64: >>>> ipa-dns-install offer IP addresses from resolv.conf as default >>>> forwarders >>>> >>>> In non-interactive more option --auto-forwarders can be used to do the >>>> same. --forward option can be used to supply additional IP addresses. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5438 >>> >>> IMO it's perverse to add option which effectively means "use default >>> value" instead of actually using the value as default. This is >>> inconsistent with every other option and I don't see what makes >>> forwarders so special to require this. >>> >>> NACK unless you have a strong justification for this. >>> >> Is it possible to use default_getter decorator to fetch defaults for the >> 'forwarders' knob from the resolver if it is avaliable like so (warning: >> untested and possibly wrong)? > > Yes, this is exactly how it should be used (although the exception > handling could be better). > That was just a quick example off the top of my head without much thought going into it. Anyway, when running in interactive mode the installer can inform the user that he found these forwarders as defaults and prompt whether they shoud be used. >> >> """ >> @@ -160,20 +162,27 @@ class BaseServerCA(common.Installable, core.Group, >> core.Composite): >> class BaseServerDNS(common.Installable, core.Group, core.Composite): >> description = "DNS" >> >> forwarders = Knob( >> (list, 'ip'), None, >> description=("Add a DNS forwarder. This option can be used >> multiple " >> "times"), >> cli_name='forwarder', >> ) >> >> + @forwarders.default_getter >> + def forwarders(self): >> + try: >> + return resolver.get_default_resolver().nameservers >> + except Exception: >> + return None >> + >> no_forwarders = Knob( >> bool, False, >> description="Do not add any DNS forwarders, use root servers >> instead", >> ) >> >> reverse_zones = Knob( >> (list, str), [], >> description=("The reverse DNS zone to use. This option can be >> used " >> >> """ >> >>>> >>>> >>>> Patch 65: >>>> Remove global variable dns_forwarders from ipaserver.install.dns >>>> It seems to me that the global thingy is not necessary, so I've ripped >>>> it out. >>> >>> ACK. >>> >> >> > > -- Martin^3 Babinsky From pspacek at redhat.com Wed Nov 11 08:46:42 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 11 Nov 2015 09:46:42 +0100 Subject: [Freeipa-devel] [PATCH] Fix download message In-Reply-To: <518086759.4263542.1447194926887.JavaMail.zimbra@redhat.com> References: <518086759.4263542.1447194926887.JavaMail.zimbra@redhat.com> Message-ID: <56430072.6060804@redhat.com> On 10.11.2015 23:35, Francois Cami wrote: > > Hi, > > The "Do you want download the CA cert from" message in ipa-client-install should be changed to "Do you want to download the CA cert from". > As this is a single-line trivial fix I haven't opened a trac ticket. I will do so if anyone feels this is necessary even in this case. Obvious ACK. -- Petr^2 Spacek From mbasti at redhat.com Wed Nov 11 09:36:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 10:36:26 +0100 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <56421D05.5050908@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <5627B576.9060003@redhat.com> <56290176.5030303@redhat.com> <5639E448.5080302@redhat.com> <56421D05.5050908@redhat.com> Message-ID: <56430C1A.5000509@redhat.com> On 10.11.2015 17:36, Petr Spacek wrote: > On 4.11.2015 11:56, Martin Babinsky wrote: >> On 10/22/2015 05:32 PM, Petr Spacek wrote: >>> On 21.10.2015 17:55, Martin Babinsky wrote: >>>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>>>> associated credentials cache during its uninstall >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>>>> during *install* so problems caused by failing uninstallation will be >>>>> fixed on >>>>> repeated install. This is yet another step towards idempotent installer. >>>>> >>>>> To me this makes more sense than doing so on uninstall. Does it make sense to >>>>> you, too? >>>>> >>>> Attaching updated patch that does cleanup also before each instance creation. >>>> It is a bit ugly I admit, but I couldn't think of a better way to do it and >>>> didn't want to poke into service/instance code more than neccesary. >>> NACK, but we are almost there! >>> >>> * kdestroy -A is too aggressive and wipes root's keyring after each run of >>> ipa-*-install utils. >>> >>> * There are some scattered leftovers of ipautil.run['kdestroy'...] in the >>> tree. Please get rid of them. >>> >>> Thank you! >>> >> Attaching updated patch. It got lost somewhere in the list. > ACK, thank you for patience. > The patch needs rebase. From mbasti at redhat.com Wed Nov 11 09:41:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 10:41:56 +0100 Subject: [Freeipa-devel] [PATCH] Fix download message In-Reply-To: <56430072.6060804@redhat.com> References: <518086759.4263542.1447194926887.JavaMail.zimbra@redhat.com> <56430072.6060804@redhat.com> Message-ID: <56430D64.3040805@redhat.com> On 11.11.2015 09:46, Petr Spacek wrote: > On 10.11.2015 23:35, Francois Cami wrote: >> Hi, >> >> The "Do you want download the CA cert from" message in ipa-client-install should be changed to "Do you want to download the CA cert from". >> As this is a single-line trivial fix I haven't opened a trac ticket. I will do so if anyone feels this is necessary even in this case. > Obvious ACK. > Pushed to master: 9f3e8943a7c0be1ba6ae8738f8f88420a098c276 From mbasti at redhat.com Wed Nov 11 09:44:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 10:44:50 +0100 Subject: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options In-Reply-To: <5641C05F.2090901@redhat.com> References: <563C731D.6010909@redhat.com> <563CCEFE.5040906@redhat.com> <564039E4.8000601@redhat.com> <56405F86.7070306@redhat.com> <5641C05F.2090901@redhat.com> Message-ID: <56430E12.5000109@redhat.com> On 10.11.2015 11:01, Martin Basti wrote: > > > On 09.11.2015 09:55, Martin Babinsky wrote: >> On 11/09/2015 07:15 AM, Jan Cholasta wrote: >>> On 6.11.2015 17:02, Martin Babinsky wrote: >>>> On 11/06/2015 10:30 AM, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5433 >>>>> >>>>> >>>>> >>>> >>>> Attaching updated patch. >>> >>> NACK, the first patch was better, there should be quotes around the >>> values. >>> >> >> Attaching updated patch. >> > ACK > Pushed to: master: b6a2a1cfd2d811e4df77e5b90324d1453dab4b18 ipa-4-2: dc0f2d1fec8bdbe5cccebb1d3dfe403ad994e6f6 From mbabinsk at redhat.com Wed Nov 11 09:49:31 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 11 Nov 2015 10:49:31 +0100 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <56430C1A.5000509@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <5627B576.9060003@redhat.com> <56290176.5030303@redhat.com> <5639E448.5080302@redhat.com> <56421D05.5050908@redhat.com> <56430C1A.5000509@redhat.com> Message-ID: <56430F2B.8070109@redhat.com> On 11/11/2015 10:36 AM, Martin Basti wrote: > > > On 10.11.2015 17:36, Petr Spacek wrote: >> On 4.11.2015 11:56, Martin Babinsky wrote: >>> On 10/22/2015 05:32 PM, Petr Spacek wrote: >>>> On 21.10.2015 17:55, Martin Babinsky wrote: >>>>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>>>> each service possessing Kerberos keytab wiil now remove it and >>>>>>> destroy any >>>>>>> associated credentials cache during its uninstall >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>>>> BTW some time ago Simo proposed that we should remove caches and >>>>>> old keytabs >>>>>> during *install* so problems caused by failing uninstallation will be >>>>>> fixed on >>>>>> repeated install. This is yet another step towards idempotent >>>>>> installer. >>>>>> >>>>>> To me this makes more sense than doing so on uninstall. Does it >>>>>> make sense to >>>>>> you, too? >>>>>> >>>>> Attaching updated patch that does cleanup also before each instance >>>>> creation. >>>>> It is a bit ugly I admit, but I couldn't think of a better way to >>>>> do it and >>>>> didn't want to poke into service/instance code more than neccesary. >>>> NACK, but we are almost there! >>>> >>>> * kdestroy -A is too aggressive and wipes root's keyring after each >>>> run of >>>> ipa-*-install utils. >>>> >>>> * There are some scattered leftovers of ipautil.run['kdestroy'...] >>>> in the >>>> tree. Please get rid of them. >>>> >>>> Thank you! >>>> >>> Attaching updated patch. It got lost somewhere in the list. >> ACK, thank you for patience. >> > > The patch needs rebase. Rebased patch attached. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0082.3-remove-Kerberos-authenticators-when-installing-unins.patch Type: text/x-patch Size: 8262 bytes Desc: not available URL: From ofayans at redhat.com Wed Nov 11 10:27:53 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 11 Nov 2015 11:27:53 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC In-Reply-To: <563CA575.1030808@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> Message-ID: <56431829.30908@redhat.com> Hi guys, Is there a chance these patches might be reviewed again this week? On 11/06/2015 02:04 PM, Oleg Fayans wrote: > Hi Jan, > > On 11/06/2015 09:01 AM, Jan Cholasta wrote: >> Actually it might be better to keep them, but fix them to expect >> ipa-server-certinstall to success. > > Done. Updated patch attached. > Also in the patch 0013 I removed a trailing whitespace which caused lint > to complain > > Now with domain level 0 the test output looks like this: > > [11:40:51]ofayans at vm-076:~]$ ipa-run-tests test_integration/test_caless.py > ==================================================================================== > test session starts > ===================================================================================== > > platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 > plugins: multihost, sourceorder > collected 88 items > > test_integration/test_caless.py > ......xx......ss...............xx........ss....................xx......ss............... > > > ===================================================================== 76 > passed, 6 skipped, 6 xfailed in 7871.10 seconds > ===================================================================== > > >> >> On 6.11.2015 08:47, Jan Cholasta wrote: >>> Hi Oleg, >>> >>> I think you can just remove >>> TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are >>> imported correctly in this case and I didn't see anything break. >>> >>> Honza >>> >>> On 5.11.2015 20:20, Oleg Fayans wrote: >>>> Patch 0014 updated and passes lint >>>> >>>> On 11/05/2015 03:41 PM, Oleg Fayans wrote: >>>>> Wait a bit, the patch has problems with pylint: it does not build :) >>>>> The updated version (without the setupmaster nonsense) is being tested >>>>> now. >>>>> >>>>> On 11/05/2015 08:45 AM, Oleg Fayans wrote: >>>>>> Hi Jan, >>>>>> >>>>>> Could you take a look at these, whenever you are free? >>>>>> >>>>>> On 10/30/2015 02:57 PM, Oleg Fayans wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The following patches contain updates to ca-less integration tests. >>>>>>> It's still a proof of concept: 2 tests still fail seemingly due to >>>>>>> the >>>>>>> change in target system logic (marked as xfail with "ask jcholast >>>>>>> comment") >>>>>>> >>>>>>> The test output looks like this: >>>>>>> >>>>>>> $ ipa-run-tests test_integration/test_caless.py --pdb >>>>>>> ==================================================================================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> test session starts >>>>>>> ===================================================================================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 >>>>>>> plugins: multihost, sourceorder >>>>>>> collected 88 items >>>>>>> >>>>>>> test_integration/test_caless.py >>>>>>> ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ==================================================================== >>>>>>> 53 >>>>>>> >>>>>>> passed, 29 skipped, 6 xfailed in 5620.17 seconds >>>>>>> ===================================================================== >>>>>>> >>>>>>> >>>>>>> Numerous skips correspond to the tests related to >>>>>>> ipa-replica-prepare >>>>>>> (unsupported under domain level 1) >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pspacek at redhat.com Wed Nov 11 10:50:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 11 Nov 2015 11:50:09 +0100 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <56430F2B.8070109@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <5627B576.9060003@redhat.com> <56290176.5030303@redhat.com> <5639E448.5080302@redhat.com> <56421D05.5050908@redhat.com> <56430C1A.5000509@redhat.com> <56430F2B.8070109@redhat.com> Message-ID: <56431D61.8000705@redhat.com> On 11.11.2015 10:49, Martin Babinsky wrote: > On 11/11/2015 10:36 AM, Martin Basti wrote: >> >> >> On 10.11.2015 17:36, Petr Spacek wrote: >>> On 4.11.2015 11:56, Martin Babinsky wrote: >>>> On 10/22/2015 05:32 PM, Petr Spacek wrote: >>>>> On 21.10.2015 17:55, Martin Babinsky wrote: >>>>>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>>>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>>>>> each service possessing Kerberos keytab wiil now remove it and >>>>>>>> destroy any >>>>>>>> associated credentials cache during its uninstall >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>>>>> BTW some time ago Simo proposed that we should remove caches and >>>>>>> old keytabs >>>>>>> during *install* so problems caused by failing uninstallation will be >>>>>>> fixed on >>>>>>> repeated install. This is yet another step towards idempotent >>>>>>> installer. >>>>>>> >>>>>>> To me this makes more sense than doing so on uninstall. Does it >>>>>>> make sense to >>>>>>> you, too? >>>>>>> >>>>>> Attaching updated patch that does cleanup also before each instance >>>>>> creation. >>>>>> It is a bit ugly I admit, but I couldn't think of a better way to >>>>>> do it and >>>>>> didn't want to poke into service/instance code more than neccesary. >>>>> NACK, but we are almost there! >>>>> >>>>> * kdestroy -A is too aggressive and wipes root's keyring after each >>>>> run of >>>>> ipa-*-install utils. >>>>> >>>>> * There are some scattered leftovers of ipautil.run['kdestroy'...] >>>>> in the >>>>> tree. Please get rid of them. >>>>> >>>>> Thank you! >>>>> >>>> Attaching updated patch. It got lost somewhere in the list. >>> ACK, thank you for patience. >>> >> >> The patch needs rebase. > Rebased patch attached. I should have told you :-) Anyway, re-ACK. -- Petr^2 Spacek From mbasti at redhat.com Wed Nov 11 13:52:52 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 14:52:52 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5642FB32.4070406@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> Message-ID: <56434834.50109@redhat.com> Comments inline Martin^2 On 11.11.2015 09:24, Stanislav Laznicka wrote: > On 11/05/2015 06:17 PM, Petr Spacek wrote: >> On 4.11.2015 15:20, Martin Basti wrote: >> >>> Hello, >>> >>> we (Standa and I) had offline discussion and I proposed following idea: >>> >>> 1) create new entry in LDAP for "time rule" instead of adding the time rule >>> string directly into HBACRule. >>> This will allow to reuse time rules among various HBAC Rules (and maybe in >>> future with sudo rules, etc.) >>> HBACrule gets only reference to time rule entry stored in LDAP db. >> Good idea! I can see time rule entry 'working hours in Brno office' which is >> linked to relevant HBAC rules. > This seems like a good idea. However, it might be a bit messy to have > even the least significant rules stored in separate objects. But I > agree. It brings some questions, though. Imo to have separate entry for time rule is cleaner than add it directly to HBAC rule. > Where would be a good spot to store these time rules? As I originally thought that we can share time rules between HBAC, SUDO and everything else, I couldn't be wrong more. Example: HBAC admin have permission to edit HBAC rule, but doesn't have permission to edit SUDO rule. The HBAC admin should be able to edit time rules for HBAC rules, and cannot be able to edit time rules of SUDO rules. Thus time rules must be separated between HBAC, SUDO and others, and privilege that give the permission to modify HBAC rule, must give permission to modify only HBAC time rules. I suggest to add HBAC time rules to HBAC container. > Should they be able to form groups? I think to allow multiple time rules per HBAC rule is enough. > Should such an object be able to hold more time policies strings and > exceptions, as it does now, or would it be better to set that in the > respective HBAC rule? Can it be one time policy per entry? Do you expect that users may need a many complicated rules? Generally to have an object time policy that consist of time rule objects which are in fact the iCal string is good idea, but is it worth it? We should not overengineering it. >> >>> 2) Do not create a new time format, just reuse iCal (parts of iCal we need), >>> to store time rule in LDAP in "time rule" entry >>> (Or is possible to not store the values just as one string, we can use >>> different attributes to store separate values, iCal can be used as export and >>> import format) >> I very much agree with re-using iCal! We have sufficient number of custom >> parsers already ;-) >> >> Speaking about custom LDAP format, I do not think that it is a good idea. It >> would prevent us from using iCal parsers and generators and we would risk that >> our custom LDAP format will not be flexible enough. >> >> For these reasons I would go with 1 iCal string which can be fed into any >> standard-compliant iCal library. > I was thinking long and hard about actually using the iCalendar format > for this purpose, ever since the 'repeat' keyword was supposed to be > included in the language. However, as I mentioned some time ago, the > iCalendar format recurrences are OK when it comes to recurring events > but I am not sure about them being very suitable for describing time > policies. > > Let me do a comparison of the options. I will take in question only > the RRULE (and possibly PERIOD) part of the iCalendar format. Having > the whole iCalendar format involved along with its parsing C library > seemed to be a no-go for SSSD some 6 months ago and I can imagine such > feelings persist. > > ---------------------------- > Some iCalendar cons: > > 1) It is hard to represent continuous time of a day ranges > There does not seem to be an easy equivalent to e.g. 'timeofday= > 0730~1100, 1200~1615'. The easiest way to do this in iCalendar would > be to have 2 rules of the form: > > DTSTART: 19700101T073000 > DTEND: 19700101T110000 > RRULE: FREQ=DAILY; INTERVAL=1 > > DTSTART: 19700101T120000 > DTEND: 19700101T161500 > RRULE: FREQ=DAILY; INTERVAL=1 > > If you were setting some more difficult policy, there would have to be > a lot of duplicity in each of such rules. Is this common usage? I personally cannot imagine reason to using more than max 2 time periods per day. > > 2) All iCalendar events have to have a fixed starting point > There must always be a check against the interval and the starting point. MIN, or date of creation can be used as default > > 3) There are no ranges > e.g. 'dayofyear=2-50, 100-125' would translate to > > DTSTART:19700101T000000 > RRULE: FREQ=SECONDLY; INTERVAL=1; > BYYEARDAY=2,3,4,5,6,7,8,9,10,11,...50,100,101,102,... > > 4) There is no way to list specific years in which the HBAC rule > should apply. is this a real concern? > > 5) COUNT parameter makes you generate all previous events before you > are able to tell if the current one actually applies. > Imagine COUNT being a big number and an event that hardly ever > happens. Imagine current time to fall into the last event. If we want to have the iCal support, we must live with this, but we can force user to use end date in CLI/webUI (in other words disable COUNT as option in CLI/webUI) > > 6) The event descriptions are not so intuitive > There would probably have to be better conversion system at least for > CLI when user wants to set time ranges of access allowed times so that > we can consider it good UX. > UX is in our hands > I am not mentioning the lack of weekofmonth in iCal as I would rather > drop it from the current solution, too. > ---------------------------- > On the other hand, there are also some big pros for iCalendar. > > 1) It is a standard. It behaves in a known and described manner. > 2) By proper use of BYSETPOS of RRULE, it is able to describe some > specific situations, e.g. last workday of a month. This is not > possible in the current language. > 3) Easier setting of absolute time ranges using the PERIOD property > (although this could probably be easily solved by a minor addition to > the current solution). > 4) A GUI for setting RRULEs already exists. > > ad 4) The GUI, however, hides some of the features of the language > (e.g. the mentioned BYSETPOS) and is not suitable for setting time > policies as is. Try, for example, setting a policy "allow access from > 7:00 to 16:00 (no break of the interval as iCalendar does not know it) > every first Monday through Friday of a month for the first half of > every year". > > In current language: > > timeofday=0700~1600 dayofmonth=1~7 dayofweek=1~5 monthofyear=1~6 > > In iCalendar RRULE: > > DTSTART: 19700101T070000 > DTEND: 19700101T160000 > RRULE: FREQ=YEARLY; BYMONTH=1,2,3,4,5,6;BYDAY=1MO,1TU,1WE,1TH,1FR > ---------------------------- > > Hopefully, this was a thorough walk-through of the pros and cons of > both approaches. I believe I stayed clear of any sentiment to the work > I did of which a big part could come in vain if we moved to iCalendar > format. Please correct me if I haven't. IMO most of examples above are overkill and we only should solve in CLI/webUI how to easily add the time rules that are the most used. If somebody needs a something special, the one is allowed to import the own time rule in the iCal format. > > I wonder if we want to have someone from SSSD in this discussion, too. >> >>> 3) We may provide nice CLI and webUI to construct/show "time rule", this may >>> be more user friendly than just passing the string containing time data to >>> HBAC rule. >> This is going to be the same as in any calendaring system. Just look to >> Thunderbird "New Event" dialog. >> > Please, see my comments on the GUI in ad 4). On the other hand to the > comments - there is at least something done in iCalendar GUI that we > could use rather than coining out a whole new GUI for time policies. > > -- > Standa -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Wed Nov 11 13:59:22 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 11 Nov 2015 14:59:22 +0100 Subject: [Freeipa-devel] [PATCH 0066] Remove unused constant NEW_MASTER_MARK from ipaserver.install.dn In-Reply-To: <564215A7.80900@redhat.com> References: <564215A7.80900@redhat.com> Message-ID: <564349BA.5050208@redhat.com> On 11/10/2015 05:04 PM, Petr Spacek wrote: > Hello, > > Remove unused constant NEW_MASTER_MARK from ipaserver.install.dns. > > > ACK. Pushed to master: 0043065598f8e7767b45922806f14ed17a18508c From tbabej at redhat.com Wed Nov 11 14:05:01 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 11 Nov 2015 15:05:01 +0100 Subject: [Freeipa-devel] [PATCH] enable pem=True in export_pem_cert function In-Reply-To: <20151111010357.GA8808@mniranja.pnq.redhat.com> References: <20151026195959.GA20574@mniranja.pnq.redhat.com> <562F9BCF.2090502@redhat.com> <20151028002919.GA10557@mniranja.pnq.redhat.com> <20151111010357.GA8808@mniranja.pnq.redhat.com> Message-ID: <56434B0D.7090404@redhat.com> On 11/11/2015 02:03 AM, Niranjan wrote: > Niranjan wrote: >> Tomas Babej wrote: >>> On 10/26/2015 08:59 PM, Niranjan wrote: >>>> Greetings, >>>> >>>> export_pem_cert function from ipapython/certdb should export the certificate >>>> in pem format but instead exports the cert in der format as it doesn't enable pem=True. >>>> >>>> This patch specifies pem=True for export_pem_cert function >>>> >>>> Regards >>>> Niranjan >>> >>> Hi, >>> >>> the patch looks good, however, I'm curious as to how did you find this >>> bug? Does it affect anything? >> I am part of the CS(dogtag) QE team, and as part of CS Automation, i am relying >> on some generic functions provided by ipapython. While using those functions >> for our automation, I found it. >>> >>> It seems to me that this part of the code is a dead branch which should >>> be removed. >> I did not look further ipapython, so i am not aware where else export_pem_cert >> is being used, but i would like the functions in certdb.py be available. >>> >>> $ git grep export_pem_cert >>> ipapython/certdb.py: def export_pem_cert(self, nickname, location): >>> ipaserver/install/certs.py: def export_pem_cert(self, nickname, >>> ipaserver/install/certs.py: return self.nssdb.export_pem_ce.. > > Any update on this. > Sure, I will push the patch. However, I am not sure how stable the ipapython internal API is, so be watch out for changes if ipapython package is upgraded. ACK. Pushed to master: 0152d16820e527060be3363f590c49544b51b710 From tbabej at redhat.com Wed Nov 11 14:22:13 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 11 Nov 2015 15:22:13 +0100 Subject: [Freeipa-devel] [PATCH 0384] ipa-client-automount: Leverage IPAChangeConf to configure the idmapd Message-ID: <56434F15.6070600@redhat.com> Hi, Simple regexp substitution caused that the domain directive fell under an inapprorpiate section, if the domain directive was not present. Hence the idmapd.conf file was not properly parsed. Use IPAChangeConf to put the directive in its correct place even if it the domain directive is missing. https://fedorahosted.org/freeipa/ticket/5069 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0383-ipachangeconf-Add-ability-to-preserve-section-case.patch Type: text/x-patch Size: 1442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0384-ipa-client-automount-Leverage-IPAChangeConf-to-confi.patch Type: text/x-patch Size: 2003 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 11 14:27:38 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 11 Nov 2015 15:27:38 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: <5642FDF2.3060609@redhat.com> References: <56421416.8060104@redhat.com> <5642EA7B.1060505@redhat.com> <5642FBE4.8040501@redhat.com> <5642FD27.1050103@redhat.com> <5642FDF2.3060609@redhat.com> Message-ID: <5643505A.7000800@redhat.com> On 11.11.2015 09:36, Martin Babinsky wrote: > On 11/11/2015 09:32 AM, Jan Cholasta wrote: >> On 11.11.2015 09:27, Martin Babinsky wrote: >>> On 11/11/2015 08:12 AM, Jan Cholasta wrote: >>>> On 10.11.2015 16:58, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> Patch 64: >>>>> ipa-dns-install offer IP addresses from resolv.conf as default >>>>> forwarders >>>>> >>>>> In non-interactive more option --auto-forwarders can be used to do the >>>>> same. --forward option can be used to supply additional IP addresses. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5438 >>>> >>>> IMO it's perverse to add option which effectively means "use default >>>> value" instead of actually using the value as default. This is >>>> inconsistent with every other option and I don't see what makes >>>> forwarders so special to require this. >>>> >>>> NACK unless you have a strong justification for this. Motivation: /etc/resolv.conf holds nearest DNS servers. On the other hand, you want to have backup forwarder which may not be local but could work even if local ones fail. Option --default-forwarders reads list of "local" servers from resolv.conf and --forwarder option allows you to add additional IP addresses to it. So your Ansible script can contain call like: ipa-server-install --setup-dns --default-forwarder --forwarder= and you do not need to worry about mapping sites to nearest servers etc. >>> Is it possible to use default_getter decorator to fetch defaults for the >>> 'forwarders' knob from the resolver if it is avaliable like so (warning: >>> untested and possibly wrong)? >> >> Yes, this is exactly how it should be used (although the exception >> handling could be better). >> > That was just a quick example off the top of my head without much thought > going into it. > > Anyway, when running in interactive mode the installer can inform the user > that he found these forwarders as defaults and prompt whether they shoud be used. After discussion in person we decided to not use default_getter decorator because that would change current behavior in an unexpected way. Original option --auto-forwarders was renamed to --default-forwarders because it sounds nicer :-D >>>>> Patch 65: >>>>> Remove global variable dns_forwarders from ipaserver.install.dns >>>>> It seems to me that the global thingy is not necessary, so I've ripped >>>>> it out. >>>> >>>> ACK. Rebased version of patch 65 is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0064-2-ipa-dns-install-offer-IP-addresses-from-resolv.conf-.patch Type: text/x-patch Size: 7366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0065-2-Remove-global-variable-dns_forwarders-from-ipaserver.patch Type: text/x-patch Size: 4789 bytes Desc: not available URL: From mbasti at redhat.com Wed Nov 11 14:30:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 15:30:53 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <56434834.50109@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> Message-ID: <5643511D.8040108@redhat.com> On 11.11.2015 14:52, Martin Basti wrote: > Comments inline > Martin^2 > > On 11.11.2015 09:24, Stanislav Laznicka wrote: >> On 11/05/2015 06:17 PM, Petr Spacek wrote: >>> On 4.11.2015 15:20, Martin Basti wrote: >>> >>>> Hello, >>>> >>>> we (Standa and I) had offline discussion and I proposed following idea: >>>> >>>> 1) create new entry in LDAP for "time rule" instead of adding the time rule >>>> string directly into HBACRule. >>>> This will allow to reuse time rules among various HBAC Rules (and maybe in >>>> future with sudo rules, etc.) >>>> HBACrule gets only reference to time rule entry stored in LDAP db. >>> Good idea! I can see time rule entry 'working hours in Brno office' which is >>> linked to relevant HBAC rules. >> This seems like a good idea. However, it might be a bit messy to have >> even the least significant rules stored in separate objects. But I >> agree. It brings some questions, though. > Imo to have separate entry for time rule is cleaner than add it > directly to HBAC rule. > >> Where would be a good spot to store these time rules? > As I originally thought that we can share time rules between HBAC, > SUDO and everything else, I couldn't be wrong more. > > Example: HBAC admin have permission to edit HBAC rule, but doesn't > have permission to edit SUDO rule. The HBAC admin should be able to > edit time rules for HBAC rules, and cannot be able to edit time rules > of SUDO rules. Thus time rules must be separated between HBAC, SUDO > and others, and privilege that give the permission to modify HBAC > rule, must give permission to modify only HBAC time rules. > > I suggest to add HBAC time rules to HBAC container. After IRC discussion with pspacek and jcholast: We should just create separated privileges to time rules and allow them to be shared. So they should be stored in new container in LDAP Martin^2 > >> Should they be able to form groups? > I think to allow multiple time rules per HBAC rule is enough. >> Should such an object be able to hold more time policies strings and >> exceptions, as it does now, or would it be better to set that in the >> respective HBAC rule? > Can it be one time policy per entry? Do you expect that users may need > a many complicated rules? > Generally to have an object time policy that consist of time rule > objects which are in fact the iCal string is good idea, but is it > worth it? We should not overengineering it. >>> >>>> 2) Do not create a new time format, just reuse iCal (parts of iCal we need), >>>> to store time rule in LDAP in "time rule" entry >>>> (Or is possible to not store the values just as one string, we can use >>>> different attributes to store separate values, iCal can be used as export and >>>> import format) >>> I very much agree with re-using iCal! We have sufficient number of custom >>> parsers already ;-) >>> >>> Speaking about custom LDAP format, I do not think that it is a good idea. It >>> would prevent us from using iCal parsers and generators and we would risk that >>> our custom LDAP format will not be flexible enough. >>> >>> For these reasons I would go with 1 iCal string which can be fed into any >>> standard-compliant iCal library. >> I was thinking long and hard about actually using the iCalendar >> format for this purpose, ever since the 'repeat' keyword was supposed >> to be included in the language. However, as I mentioned some time >> ago, the iCalendar format recurrences are OK when it comes to >> recurring events but I am not sure about them being very suitable for >> describing time policies. >> >> Let me do a comparison of the options. I will take in question only >> the RRULE (and possibly PERIOD) part of the iCalendar format. Having >> the whole iCalendar format involved along with its parsing C library >> seemed to be a no-go for SSSD some 6 months ago and I can imagine >> such feelings persist. >> >> ---------------------------- >> Some iCalendar cons: >> >> 1) It is hard to represent continuous time of a day ranges >> There does not seem to be an easy equivalent to e.g. 'timeofday= >> 0730~1100, 1200~1615'. The easiest way to do this in iCalendar would >> be to have 2 rules of the form: >> >> DTSTART: 19700101T073000 >> DTEND: 19700101T110000 >> RRULE: FREQ=DAILY; INTERVAL=1 >> >> DTSTART: 19700101T120000 >> DTEND: 19700101T161500 >> RRULE: FREQ=DAILY; INTERVAL=1 >> >> If you were setting some more difficult policy, there would have to >> be a lot of duplicity in each of such rules. > Is this common usage? I personally cannot imagine reason to using more > than max 2 time periods per day. >> >> 2) All iCalendar events have to have a fixed starting point >> There must always be a check against the interval and the starting point. > MIN, or date of creation can be used as default >> >> 3) There are no ranges >> e.g. 'dayofyear=2-50, 100-125' would translate to >> >> DTSTART:19700101T000000 >> RRULE: FREQ=SECONDLY; INTERVAL=1; >> BYYEARDAY=2,3,4,5,6,7,8,9,10,11,...50,100,101,102,... > >> >> 4) There is no way to list specific years in which the HBAC rule >> should apply. > is this a real concern? >> >> 5) COUNT parameter makes you generate all previous events before you >> are able to tell if the current one actually applies. >> Imagine COUNT being a big number and an event that hardly ever >> happens. Imagine current time to fall into the last event. > If we want to have the iCal support, we must live with this, but we > can force user to use end date in CLI/webUI (in other words disable > COUNT as option in CLI/webUI) >> >> 6) The event descriptions are not so intuitive >> There would probably have to be better conversion system at least for >> CLI when user wants to set time ranges of access allowed times so >> that we can consider it good UX. >> > UX is in our hands >> I am not mentioning the lack of weekofmonth in iCal as I would rather >> drop it from the current solution, too. >> ---------------------------- >> On the other hand, there are also some big pros for iCalendar. >> >> 1) It is a standard. It behaves in a known and described manner. >> 2) By proper use of BYSETPOS of RRULE, it is able to describe some >> specific situations, e.g. last workday of a month. This is not >> possible in the current language. >> 3) Easier setting of absolute time ranges using the PERIOD property >> (although this could probably be easily solved by a minor addition to >> the current solution). >> 4) A GUI for setting RRULEs already exists. >> >> ad 4) The GUI, however, hides some of the features of the language >> (e.g. the mentioned BYSETPOS) and is not suitable for setting time >> policies as is. Try, for example, setting a policy "allow access from >> 7:00 to 16:00 (no break of the interval as iCalendar does not know >> it) every first Monday through Friday of a month for the first half >> of every year". >> >> In current language: >> >> timeofday=0700~1600 dayofmonth=1~7 dayofweek=1~5 monthofyear=1~6 >> >> In iCalendar RRULE: >> >> DTSTART: 19700101T070000 >> DTEND: 19700101T160000 >> RRULE: FREQ=YEARLY; BYMONTH=1,2,3,4,5,6;BYDAY=1MO,1TU,1WE,1TH,1FR >> ---------------------------- >> >> Hopefully, this was a thorough walk-through of the pros and cons of >> both approaches. I believe I stayed clear of any sentiment to the >> work I did of which a big part could come in vain if we moved to >> iCalendar format. Please correct me if I haven't. > IMO most of examples above are overkill and we only should solve in > CLI/webUI how to easily add the time rules that are the most used. > If somebody needs a something special, the one is allowed to import > the own time rule in the iCal format. >> >> I wonder if we want to have someone from SSSD in this discussion, too. >>> >>>> 3) We may provide nice CLI and webUI to construct/show "time rule", this may >>>> be more user friendly than just passing the string containing time data to >>>> HBAC rule. >>> This is going to be the same as in any calendaring system. Just look to >>> Thunderbird "New Event" dialog. >>> >> Please, see my comments on the GUI in ad 4). On the other hand to the >> comments - there is at least something done in iCalendar GUI that we >> could use rather than coining out a whole new GUI for time policies. >> >> -- >> Standa > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 11 14:32:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 15:32:40 +0100 Subject: [Freeipa-devel] ipa-kra-install at domain level 0 In-Reply-To: <5642FBBC.3090304@redhat.com> References: <5642FBBC.3090304@redhat.com> Message-ID: <56435188.2020006@redhat.com> On 11.11.2015 09:26, Oleg Fayans wrote: > Hi all, > > when running ipa-kra-install on a replica with domain level 0 and with > replica file proivided, I get the following error: > > $ ipa-kra-install -U -p > /home/ofayans/ipatests/replica-info.gpg > > Your system may be partly configured. > Run ipa-kra-install --uninstall to clean up. > > Too many parameters provided. No replica file is required. > The ipa-kra-install command failed. See > /var/log/ipaserver-kra-install.log for more information > > --------------------------------------------------------------------- > > However, when I issue the same command without the replica file, the > installation starts, but fails in the middle, without any reasonable > error message that I do need a replica file: > > $ ipa-kra-install -p -U > > =================================================================== > This program will setup Dogtag KRA for the FreeIPA Server. > > > Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds > [1/8]: configuring KRA instance > Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' > 'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1 > See the installation logs and the following files/directories for more > information: > /var/log/pki-ca-install.log > /var/log/pki/pki-tomcat > [error] RuntimeError: KRA configuration failed. > > Your system may be partly configured. > Run ipa-kra-install --uninstall to clean up. > > KRA configuration failed. > The ipa-kra-install command failed. See > /var/log/ipaserver-kra-install.log for more information > > -------------------------------------------------------------------- > > Both logs are attached > > Just to be sure, do you have KRA installed on master? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 11 14:40:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 15:40:25 +0100 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <56431D61.8000705@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <5627B576.9060003@redhat.com> <56290176.5030303@redhat.com> <5639E448.5080302@redhat.com> <56421D05.5050908@redhat.com> <56430C1A.5000509@redhat.com> <56430F2B.8070109@redhat.com> <56431D61.8000705@redhat.com> Message-ID: <56435359.6040501@redhat.com> On 11.11.2015 11:50, Petr Spacek wrote: > On 11.11.2015 10:49, Martin Babinsky wrote: >> On 11/11/2015 10:36 AM, Martin Basti wrote: >>> >>> On 10.11.2015 17:36, Petr Spacek wrote: >>>> On 4.11.2015 11:56, Martin Babinsky wrote: >>>>> On 10/22/2015 05:32 PM, Petr Spacek wrote: >>>>>> On 21.10.2015 17:55, Martin Babinsky wrote: >>>>>>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>>>>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>>>>>> each service possessing Kerberos keytab wiil now remove it and >>>>>>>>> destroy any >>>>>>>>> associated credentials cache during its uninstall >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>>>>>> BTW some time ago Simo proposed that we should remove caches and >>>>>>>> old keytabs >>>>>>>> during *install* so problems caused by failing uninstallation will be >>>>>>>> fixed on >>>>>>>> repeated install. This is yet another step towards idempotent >>>>>>>> installer. >>>>>>>> >>>>>>>> To me this makes more sense than doing so on uninstall. Does it >>>>>>>> make sense to >>>>>>>> you, too? >>>>>>>> >>>>>>> Attaching updated patch that does cleanup also before each instance >>>>>>> creation. >>>>>>> It is a bit ugly I admit, but I couldn't think of a better way to >>>>>>> do it and >>>>>>> didn't want to poke into service/instance code more than neccesary. >>>>>> NACK, but we are almost there! >>>>>> >>>>>> * kdestroy -A is too aggressive and wipes root's keyring after each >>>>>> run of >>>>>> ipa-*-install utils. >>>>>> >>>>>> * There are some scattered leftovers of ipautil.run['kdestroy'...] >>>>>> in the >>>>>> tree. Please get rid of them. >>>>>> >>>>>> Thank you! >>>>>> >>>>> Attaching updated patch. It got lost somewhere in the list. >>>> ACK, thank you for patience. >>>> >>> The patch needs rebase. >> Rebased patch attached. > I should have told you :-) Anyway, re-ACK. > Pushed to master: 117bf5af8c5ffa63dc380cb331843396ce8b8286 From ofayans at redhat.com Wed Nov 11 14:43:15 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 11 Nov 2015 15:43:15 +0100 Subject: [Freeipa-devel] ipa-kra-install at domain level 0 In-Reply-To: <56435188.2020006@redhat.com> References: <5642FBBC.3090304@redhat.com> <56435188.2020006@redhat.com> Message-ID: <56435403.5020307@redhat.com> Hi Martin, On 11/11/2015 03:32 PM, Martin Basti wrote: > > > On 11.11.2015 09:26, Oleg Fayans wrote: >> Hi all, >> >> when running ipa-kra-install on a replica with domain level 0 and with >> replica file proivided, I get the following error: >> >> $ ipa-kra-install -U -p >> /home/ofayans/ipatests/replica-info.gpg >> >> Your system may be partly configured. >> Run ipa-kra-install --uninstall to clean up. >> >> Too many parameters provided. No replica file is required. >> The ipa-kra-install command failed. See >> /var/log/ipaserver-kra-install.log for more information >> >> --------------------------------------------------------------------- >> >> However, when I issue the same command without the replica file, the >> installation starts, but fails in the middle, without any reasonable >> error message that I do need a replica file: >> >> $ ipa-kra-install -p -U >> >> =================================================================== >> This program will setup Dogtag KRA for the FreeIPA Server. >> >> >> Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds >> [1/8]: configuring KRA instance >> Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' >> 'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1 >> See the installation logs and the following files/directories for more >> information: >> /var/log/pki-ca-install.log >> /var/log/pki/pki-tomcat >> [error] RuntimeError: KRA configuration failed. >> >> Your system may be partly configured. >> Run ipa-kra-install --uninstall to clean up. >> >> KRA configuration failed. >> The ipa-kra-install command failed. See >> /var/log/ipaserver-kra-install.log for more information >> >> -------------------------------------------------------------------- >> >> Both logs are attached >> >> > Just to be sure, do you have KRA installed on master? > Great catch, actually I did not. So is this the reason? Should not we provide a more meaningful error message in this case? >> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Wed Nov 11 14:52:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Nov 2015 15:52:56 +0100 Subject: [Freeipa-devel] ipa-kra-install at domain level 0 In-Reply-To: <56435403.5020307@redhat.com> References: <5642FBBC.3090304@redhat.com> <56435188.2020006@redhat.com> <56435403.5020307@redhat.com> Message-ID: <56435648.6000901@redhat.com> On 11.11.2015 15:43, Oleg Fayans wrote: > Hi Martin, > > > On 11/11/2015 03:32 PM, Martin Basti wrote: >> >> >> On 11.11.2015 09:26, Oleg Fayans wrote: >>> Hi all, >>> >>> when running ipa-kra-install on a replica with domain level 0 and with >>> replica file proivided, I get the following error: >>> >>> $ ipa-kra-install -U -p >>> /home/ofayans/ipatests/replica-info.gpg >>> >>> Your system may be partly configured. >>> Run ipa-kra-install --uninstall to clean up. >>> >>> Too many parameters provided. No replica file is required. >>> The ipa-kra-install command failed. See >>> /var/log/ipaserver-kra-install.log for more information >>> >>> --------------------------------------------------------------------- >>> >>> However, when I issue the same command without the replica file, the >>> installation starts, but fails in the middle, without any reasonable >>> error message that I do need a replica file: >>> >>> $ ipa-kra-install -p -U >>> >>> =================================================================== >>> This program will setup Dogtag KRA for the FreeIPA Server. >>> >>> >>> Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 >>> seconds >>> [1/8]: configuring KRA instance >>> Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' >>> 'KRA' '-f' '/tmp/tmpPQGCs0'' returned non-zero exit status 1 >>> See the installation logs and the following files/directories for more >>> information: >>> /var/log/pki-ca-install.log >>> /var/log/pki/pki-tomcat >>> [error] RuntimeError: KRA configuration failed. >>> >>> Your system may be partly configured. >>> Run ipa-kra-install --uninstall to clean up. >>> >>> KRA configuration failed. >>> The ipa-kra-install command failed. See >>> /var/log/ipaserver-kra-install.log for more information >>> >>> -------------------------------------------------------------------- >>> >>> Both logs are attached >>> >>> >> Just to be sure, do you have KRA installed on master? >> > > Great catch, actually I did not. So is this the reason? Should not we > provide a more meaningful error message in this case? > There is right error: "No replica file is required" However IIRC in this case, ipa-kra-install without replica file should work, so this is the bug. >>> >>> >> > From mbabinsk at redhat.com Wed Nov 11 15:24:21 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 11 Nov 2015 16:24:21 +0100 Subject: [Freeipa-devel] [PATCH 0095] remove an unneccesary check from IPA server uninstaller Message-ID: <56435DA5.2080405@redhat.com> This check for a deprecated option added in https://fedorahosted.org/freeipa/ticket/4516 and somehow ended up in both install_check and uninstall_check during installer refactoring. The placement in the latter is rather pointless so this patch removes it. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0095-remove-an-unneccesary-check-from-IPA-server-uninstal.patch Type: text/x-patch Size: 1122 bytes Desc: not available URL: From jcholast at redhat.com Wed Nov 11 15:32:12 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Nov 2015 16:32:12 +0100 Subject: [Freeipa-devel] [PATCH 0095] remove an unneccesary check from IPA server uninstaller In-Reply-To: <56435DA5.2080405@redhat.com> References: <56435DA5.2080405@redhat.com> Message-ID: <56435F7C.3070305@redhat.com> On 11.11.2015 16:24, Martin Babinsky wrote: > This check for a deprecated option added in > https://fedorahosted.org/freeipa/ticket/4516 and somehow ended up in > both install_check and uninstall_check during installer refactoring. > > The placement in the latter is rather pointless so this patch removes it. ACK. -- Jan Cholasta From jcholast at redhat.com Thu Nov 12 08:49:11 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 Nov 2015 09:49:11 +0100 Subject: [Freeipa-devel] [PATCH 0095] remove an unneccesary check from IPA server uninstaller In-Reply-To: <56435F7C.3070305@redhat.com> References: <56435DA5.2080405@redhat.com> <56435F7C.3070305@redhat.com> Message-ID: <56445287.10301@redhat.com> On 11.11.2015 16:32, Jan Cholasta wrote: > On 11.11.2015 16:24, Martin Babinsky wrote: >> This check for a deprecated option added in >> https://fedorahosted.org/freeipa/ticket/4516 and somehow ended up in >> both install_check and uninstall_check during installer refactoring. >> >> The placement in the latter is rather pointless so this patch removes it. > > ACK. Pushed to master: d66492c15e847ffe68829e1b92cc43dbc60c4c7d -- Jan Cholasta From jcholast at redhat.com Thu Nov 12 08:55:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 Nov 2015 09:55:35 +0100 Subject: [Freeipa-devel] [PATCH 0380] spec: Add Provides directives to alternative package names In-Reply-To: <564092D3.3050600@redhat.com> References: <56408A5C.4070702@redhat.com> <56408D3C.4030109@redhat.com> <564092D3.3050600@redhat.com> Message-ID: <56445407.1020109@redhat.com> On 9.11.2015 13:34, Tomas Babej wrote: > > > On 11/09/2015 01:10 PM, Jan Cholasta wrote: >> Hi, >> >> On 9.11.2015 12:58, Tomas Babej wrote: >>> Hi, >>> >>> this fixes: >>> >>> https://fedorahosted.org/freeipa/ticket/5408 >> >> a) Don't include %{release} in the Provides, release number is >> meaningless between distros. >> > > Good point. > >> b) Please put the Provides near the related Conflicts and Obsoletes, >> like this: >> >> Provides: %{alt_name}-XXX = %{version} >> Conflicts: %{alt_name}-XXX >> Obsoletes: %{alt_name}-XXX < %{version} >> >> Honza >> > > Updated version attached. Thanks, ACK. Pushed to master: ab58ec0d50f172093e75b7834f6ed5e39992c2d9 -- Jan Cholasta From mbasti at redhat.com Thu Nov 12 09:35:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 10:35:36 +0100 Subject: [Freeipa-devel] ipa-4-2 branch is broken !!! Message-ID: <56445D68.7070808@redhat.com> Lint failed in current ipa-4-2 branch. =============================================================================== Errors were found during the static code check. If you are certain that any of the reported errors are false positives, please mark them in the source code according to the pylint documentation. =============================================================================== ************* Module ipatests.test_ipaserver.test_ldap ipatests/test_ipaserver/test_ldap.py:43: [E0602(undefined-variable), test_ldap] Undefined variable 'pytest') ipatests/test_ipaserver/test_ldap.py:154: [E0602(undefined-variable), test_LDAPEntry] Undefined variable 'pytest') Makefile:119: recipe for target 'lint' failed From mkubik at redhat.com Thu Nov 12 09:55:51 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 12 Nov 2015 10:55:51 +0100 Subject: [Freeipa-devel] [patch 0024] Fix missed module import in ipaserver tests Message-ID: <56446227.9010301@redhat.com> -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0024-ipatests-Fix-missed-module-import-in-ipaserver-tests.patch Type: text/x-patch Size: 748 bytes Desc: not available URL: From mkubik at redhat.com Thu Nov 12 10:00:45 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 12 Nov 2015 11:00:45 +0100 Subject: [Freeipa-devel] ipa-4-2 branch is broken !!! In-Reply-To: <56445D68.7070808@redhat.com> References: <56445D68.7070808@redhat.com> Message-ID: <5644634D.4030905@redhat.com> On 11/12/2015 10:35 AM, Martin Basti wrote: > Lint failed in current ipa-4-2 branch. > > =============================================================================== > > Errors were found during the static code check. > > If you are certain that any of the reported errors are false > positives, please > mark them in the source code according to the pylint documentation. > =============================================================================== > > > ************* Module ipatests.test_ipaserver.test_ldap > ipatests/test_ipaserver/test_ldap.py:43: [E0602(undefined-variable), > test_ldap] Undefined variable 'pytest') > ipatests/test_ipaserver/test_ldap.py:154: [E0602(undefined-variable), > test_LDAPEntry] Undefined variable 'pytest') > Makefile:119: recipe for target 'lint' failed Fixed by patch 0024. -- Milan Kubik From mbasti at redhat.com Thu Nov 12 11:02:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 12:02:21 +0100 Subject: [Freeipa-devel] [patch 0024] Fix missed module import in ipaserver tests In-Reply-To: <56446227.9010301@redhat.com> References: <56446227.9010301@redhat.com> Message-ID: <564471BD.9000700@redhat.com> On 12.11.2015 10:55, Milan Kub?k wrote: > > > ACK Pushed to ipa-4-2: af076525ccc26abd7f957d801b26bfb83718b5d7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 12 11:27:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 12:27:14 +0100 Subject: [Freeipa-devel] [PATCH 0338] Drop configure.jar file In-Reply-To: <563B9185.1050207@redhat.com> References: <56332AFF.8050904@redhat.com> <563B9185.1050207@redhat.com> Message-ID: <56447792.2090607@redhat.com> On 05.11.2015 18:27, Petr Vobornik wrote: > On 10/30/2015 09:31 AM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5144 >> >> Patch attached. >> >> > > configure.jar is basically a signed zip which contains > preferences.html therefore also all references to preferences.html > should be removed. > > > ssbrowser.html: > > Also whole section "Automatic Configuration of older versions" should > be removed. > > and list item: > """ >
  • Import CA certificate. Make sure you checked > all three checkboxes.
    • > """ > should be moved as a first item in the list in section

    Firefox

    Thank you, updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0338.2-Drop-configure.jar.patch Type: text/x-patch Size: 12910 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 12 11:36:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 12:36:36 +0100 Subject: [Freeipa-devel] [PATCH 0332] fix user post_callback In-Reply-To: <56275786.8090504@redhat.com> References: <56275786.8090504@redhat.com> Message-ID: <564479C4.7010305@redhat.com> On 21.10.2015 11:14, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5387 > > Patch attached. > > Fix for this ticket has been implemented in patch mbasti-0331-2 Attached patch contains only common postcallback code to from user and stageuser to parent class. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0332.2-Move-common-code-of-user-and-stageuser-to-baseuser-p.patch Type: text/x-patch Size: 2504 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 12 11:39:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 12:39:19 +0100 Subject: [Freeipa-devel] [PATCH 0331, 0337] User plugin: allow multiple managers per user - CLI part In-Reply-To: <562F832B.4060303@redhat.com> References: <56264855.50606@redhat.com> <56264AA6.5010003@redhat.com> <56266FCF.80909@redhat.com> <562F832B.4060303@redhat.com> Message-ID: <56447A67.8070607@redhat.com> On 27.10.2015 14:59, Martin Basti wrote: > > > On 20.10.2015 18:46, Martin Basti wrote: >> >> >> On 20.10.2015 16:07, Martin Basti wrote: >>> >>> >>> On 20.10.2015 15:57, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5344 >>>> >>>> Patch attached. >>>> >>>> Test are failing, a fix in UserTracker has to be done (partially in >>>> my patch 329) >>>> >>>> >>> SelfNACK, I forgot to add stageuser tests >>> >>> >> Updated patch attached. >> >> I extracted tests to the separate patch, tests do not work, I had >> issues with user and stageuser trackers. >> >> >> > Patch to fix issues with --addattr and managers added and attached. > > The new one patch 0331 attached, patch 0337 is not needed anymore. This patch also fixes https://fedorahosted.org/freeipa/ticket/5387 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0331.3-Allow-multiple-managers-per-user-CLI-part.patch Type: text/x-patch Size: 15889 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 12 11:47:15 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 12:47:15 +0100 Subject: [Freeipa-devel] ipa-4-2 branch is broken !!! In-Reply-To: <5644634D.4030905@redhat.com> References: <56445D68.7070808@redhat.com> <5644634D.4030905@redhat.com> Message-ID: <56447C43.2090000@redhat.com> On 12.11.2015 11:00, Milan Kub?k wrote: > On 11/12/2015 10:35 AM, Martin Basti wrote: >> Lint failed in current ipa-4-2 branch. >> >> =============================================================================== >> >> Errors were found during the static code check. >> >> If you are certain that any of the reported errors are false >> positives, please >> mark them in the source code according to the pylint documentation. >> =============================================================================== >> >> >> ************* Module ipatests.test_ipaserver.test_ldap >> ipatests/test_ipaserver/test_ldap.py:43: [E0602(undefined-variable), >> test_ldap] Undefined variable 'pytest') >> ipatests/test_ipaserver/test_ldap.py:154: [E0602(undefined-variable), >> test_LDAPEntry] Undefined variable 'pytest') >> Makefile:119: recipe for target 'lint' failed > Fixed by patch 0024. > The issue has been fixed, thanks. From mbasti at redhat.com Thu Nov 12 12:58:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 13:58:46 +0100 Subject: [Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records In-Reply-To: <56404F9E.4090606@redhat.com> References: <563A2158.80009@redhat.com> <56404F9E.4090606@redhat.com> Message-ID: <56448D06.3020700@redhat.com> On 09.11.2015 08:47, Petr Spacek wrote: > On 4.11.2015 16:16, Martin Basti wrote: >> Patch attached. >> >> https://fedorahosted.org/freeipa/ticket/5421 > I'm not entirely sure how this patch will interact with magic included in > ipalib/plugins/dns.py:class dns_resolve(Command). > > I would like to delete the 'normalization' from at least one of these places. > > Also, as you know, DNS names are not strings and should be manipulated using > python-dns so all crazy things in DNS names do not break in weird corner cases. > Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0344.2-Use-absolute-domain-in-detection-of-A-AAAA-records.patch Type: text/x-patch Size: 1552 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 12 13:02:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 14:02:27 +0100 Subject: [Freeipa-devel] [PATCH 0063] ipa-replica-manage del continues when host does not exist in domain level 1 In-Reply-To: References: Message-ID: <56448DE3.9060209@redhat.com> On 09.11.2015 14:37, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5424 > > thanks, > > Gabe > > Thank you for you patch, almost ACK, but I propose following changes (patch attached) in error message. Let me know if you agree with the change. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0063-2-ipa-replica-manage-del-continues-when-host-does-not-.patch Type: text/x-patch Size: 1303 bytes Desc: not available URL: From mkubik at redhat.com Thu Nov 12 13:03:19 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 12 Nov 2015 14:03:19 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Refactor test_user_plugin In-Reply-To: <20151110121350.06295a68@dhcp-24-103.brq.redhat.com> References: <20151106113201.5e6a7042@dhcp-24-123.brq.redhat.com> <564092F6.9000800@redhat.com> <20151109163512.3d3beb5f@redhat.com> <5641BE6D.4060608@redhat.com> <20151110121350.06295a68@dhcp-24-103.brq.redhat.com> Message-ID: <56448E17.2010409@redhat.com> On 11/10/2015 12:13 PM, Filip ?kola wrote: > Hi, > > fixed. > > F. > > On Tue, 10 Nov 2015 10:52:45 +0100 > Milan Kub?k wrote: > >> On 11/09/2015 04:35 PM, Filip ?kola wrote: >>> Another patch was applied in the meantime. >>> >>> Attaching an updated version. >>> >>> F. >>> >>> On Mon, 9 Nov 2015 13:35:02 +0100 >>> Milan Kub?k wrote: >>> >>>> On 11/06/2015 11:32 AM, Filip ?kola wrote: >>>> Hi, >>>> the patch doesn't apply. >>>> >> Please fix this. >> >> ipatests/test_xmlrpc/test_user_plugin.py:1419: >> [E0602(undefined-variable), >> TestDeniedBindWithExpiredPrincipal.teardown_class] Undefined variable >> 'user1') >> >> Also, use the version numbers for your changed patches. >> > > Thanks for the patch. Several issues: 1. Use dict.items instead of dict.iteritems, for python3 compatibility 2. What is the purpose of TestPrepare class? The 'purge' methods do not call any ipa commands. Tracker.make_fixture should be used to make the Tracked resources clean themselves up when they're out of scope. 3. Why reference the resources by hardcoded name if they have a fixture representation? 4. Rewrite {create,delete}_test_group to a fixture. You may want to use different scope (or not). 5. In `def atest_rename_to_invalid_login(self, user):` - use pytest.skipif decorator and provide a reason if you must, do not obfuscate method name in order not to run it. -- Milan Kubik From pvoborni at redhat.com Thu Nov 12 13:04:56 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Nov 2015 14:04:56 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <56421EC6.9050205@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> <5639FA77.3090907@redhat.com> <563A456A.2070101@redhat.com> <56421EC6.9050205@redhat.com> Message-ID: <56448E78.8080304@redhat.com> On 11/10/2015 05:43 PM, Martin Babinsky wrote: > On 11/04/2015 06:50 PM, Petr Vobornik wrote: >> On 11/04/2015 01:30 PM, Martin Babinsky wrote: >>> On 10/30/2015 05:06 PM, Martin Babinsky wrote: >>>> On 10/30/2015 03:38 PM, Petr Vobornik wrote: >>>>> On 10/30/2015 03:26 PM, Martin Babinsky wrote: >>>>>> patch for https://fedorahosted.org/freeipa/ticket/5309 >>>>>> >>>>>> The ticket itself is about connectivity checks in topology suffixes, >>>>>> but >>>>>> there is a code (install/tools/ipa-replica-manage starting at line >>>>>> 788 >>>>>> after applying my patch) which monitors whether the segments pointing >>>>>> to/from the deleted host are already deleted. >>>>>> >>>>>> These checks are currently hardcoded for 'realm' prefix, should we >>>>>> generalize them as well or is it a part of other effort? >>>>>> >>>>> >>>>> Could be separate patch but yes. >>>> Ok I have included it in the attached patch so that both of these >>>> operations are performed for all suffixes. >>>> >>>> >>>> >>> Hmm, I'm thinking whether the 'check_last_link_managed' and >>> 'check_deleted_segments' should not be called per-suffix, but should >>> themselves check all suffixes available. This could make the fix for >>> https://fedorahosted.org/freeipa/ticket/5409 also easier. >>> >> >> Depends if the output is reusable. If so then why not. >> check_last_link_managed basically adds text to several >> get_topology_connection_errors calls. > > Attaching updated patch. > I'm not sure about (pseudo code): topo_errors = ([], []) for each suffix: topo_errors[0].extend(orig_errors) topo_errors[1].extend(new_errors) return topo_errors In check_deleted_segments wait_for_segment_removal is per-suffix check but uses topo_errors which contains errors from both suffices. Topo erros are used to relax the check if topology is disconnected but this might relax it too much. I would change the errors to per-suffix as well, e.g.: topo_errors = {} for each suffix: topo_errors[suffix_name] = (orig_errors, new_errors) return topo_errors Otherwise it looks OK (not tested yet). -- Petr Vobornik From redhatrises at gmail.com Thu Nov 12 13:32:44 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 12 Nov 2015 06:32:44 -0700 Subject: [Freeipa-devel] [PATCH 0063] ipa-replica-manage del continues when host does not exist in domain level 1 In-Reply-To: <56448DE3.9060209@redhat.com> References: <56448DE3.9060209@redhat.com> Message-ID: Yeah. That's better. Thanks, Martin. Ack. On Thu, Nov 12, 2015 at 6:02 AM, Martin Basti wrote: > > > On 09.11.2015 14:37, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5424 > > thanks, > > Gabe > > > Thank you for you patch, almost ACK, but I propose following changes > (patch attached) in error message. > > Let me know if you agree with the change. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Nov 12 13:53:54 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Nov 2015 14:53:54 +0100 Subject: [Freeipa-devel] [PATCH 0338] Drop configure.jar file In-Reply-To: <56447792.2090607@redhat.com> References: <56332AFF.8050904@redhat.com> <563B9185.1050207@redhat.com> <56447792.2090607@redhat.com> Message-ID: <564499F2.2020008@redhat.com> On 11/12/2015 12:27 PM, Martin Basti wrote: > > > On 05.11.2015 18:27, Petr Vobornik wrote: >> On 10/30/2015 09:31 AM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5144 >>> >>> Patch attached. >>> >>> >> >> configure.jar is basically a signed zip which contains >> preferences.html therefore also all references to preferences.html >> should be removed. >> >> >> ssbrowser.html: >> >> Also whole section "Automatic Configuration of older versions" should >> be removed. >> >> and list item: >> """ >>
  • Import CA certificate. Make sure you checked >> all three checkboxes.
    • >> """ >> should be moved as a first item in the list in section

    Firefox

    > Thank you, updated patch attached. 1. following first line should be removed as well: preferences_filename = paths.PREFERENCES_HTML - if ipautil.file_exists(preferences_filename): Which also means that PREFERENCES_HTML won't be used and can be removed. -- Petr Vobornik From mbasti at redhat.com Thu Nov 12 13:55:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 14:55:21 +0100 Subject: [Freeipa-devel] [PATCH 0063] ipa-replica-manage del continues when host does not exist in domain level 1 In-Reply-To: References: <56448DE3.9060209@redhat.com> Message-ID: <56449A49.8040703@redhat.com> On 12.11.2015 14:32, Gabe Alford wrote: > Yeah. That's better. Thanks, Martin. Ack. > > Pushed to master: efe8f26ddf81db471bbce693dacd35f80e7615e2 > > On Thu, Nov 12, 2015 at 6:02 AM, Martin Basti > wrote: > > > > On 09.11.2015 14:37, Gabe Alford wrote: >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5424 >> >> thanks, >> >> Gabe >> >> > Thank you for you patch, almost ACK, but I propose following > changes (patch attached) in error message. > > Let me know if you agree with the change. > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 12 14:31:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Nov 2015 15:31:50 +0100 Subject: [Freeipa-devel] [PATCH 0338] Drop configure.jar file In-Reply-To: <564499F2.2020008@redhat.com> References: <56332AFF.8050904@redhat.com> <563B9185.1050207@redhat.com> <56447792.2090607@redhat.com> <564499F2.2020008@redhat.com> Message-ID: <5644A2D6.80709@redhat.com> On 12.11.2015 14:53, Petr Vobornik wrote: > On 11/12/2015 12:27 PM, Martin Basti wrote: >> >> >> On 05.11.2015 18:27, Petr Vobornik wrote: >>> On 10/30/2015 09:31 AM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5144 >>>> >>>> Patch attached. >>>> >>>> >>> >>> configure.jar is basically a signed zip which contains >>> preferences.html therefore also all references to preferences.html >>> should be removed. >>> >>> >>> ssbrowser.html: >>> >>> Also whole section "Automatic Configuration of older versions" should >>> be removed. >>> >>> and list item: >>> """ >>>
  • Import CA certificate. Make sure you checked >>> all three checkboxes.
    • >>> """ >>> should be moved as a first item in the list in section

    Firefox

    >> Thank you, updated patch attached. > > > 1. following first line should be removed as well: > preferences_filename = paths.PREFERENCES_HTML > - if ipautil.file_exists(preferences_filename): > > Which also means that PREFERENCES_HTML won't be used and can be removed. > Aaa sorry my bad, I wanted to remove it from paths, I just somehow forgot to do that. Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0338.3-Drop-configure.jar.patch Type: text/x-patch Size: 13290 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Nov 12 15:24:46 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 12 Nov 2015 16:24:46 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <56448E78.8080304@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> <5639FA77.3090907@redhat.com> <563A456A.2070101@redhat.com> <56421EC6.9050205@redhat.com> <56448E78.8080304@redhat.com> Message-ID: <5644AF3E.8040007@redhat.com> On 11/12/2015 02:04 PM, Petr Vobornik wrote: > On 11/10/2015 05:43 PM, Martin Babinsky wrote: >> On 11/04/2015 06:50 PM, Petr Vobornik wrote: >>> On 11/04/2015 01:30 PM, Martin Babinsky wrote: >>>> On 10/30/2015 05:06 PM, Martin Babinsky wrote: >>>>> On 10/30/2015 03:38 PM, Petr Vobornik wrote: >>>>>> On 10/30/2015 03:26 PM, Martin Babinsky wrote: >>>>>>> patch for https://fedorahosted.org/freeipa/ticket/5309 >>>>>>> >>>>>>> The ticket itself is about connectivity checks in topology suffixes, >>>>>>> but >>>>>>> there is a code (install/tools/ipa-replica-manage starting at line >>>>>>> 788 >>>>>>> after applying my patch) which monitors whether the segments >>>>>>> pointing >>>>>>> to/from the deleted host are already deleted. >>>>>>> >>>>>>> These checks are currently hardcoded for 'realm' prefix, should we >>>>>>> generalize them as well or is it a part of other effort? >>>>>>> >>>>>> >>>>>> Could be separate patch but yes. >>>>> Ok I have included it in the attached patch so that both of these >>>>> operations are performed for all suffixes. >>>>> >>>>> >>>>> >>>> Hmm, I'm thinking whether the 'check_last_link_managed' and >>>> 'check_deleted_segments' should not be called per-suffix, but should >>>> themselves check all suffixes available. This could make the fix for >>>> https://fedorahosted.org/freeipa/ticket/5409 also easier. >>>> >>> >>> Depends if the output is reusable. If so then why not. >>> check_last_link_managed basically adds text to several >>> get_topology_connection_errors calls. >> >> Attaching updated patch. >> > > I'm not sure about (pseudo code): > > topo_errors = ([], []) > for each suffix: > topo_errors[0].extend(orig_errors) > topo_errors[1].extend(new_errors) > return topo_errors > > In check_deleted_segments wait_for_segment_removal is per-suffix check > but uses topo_errors which contains errors from both suffices. Topo > erros are used to relax the check if topology is disconnected but this > might relax it too much. > > I would change the errors to per-suffix as well, e.g.: > topo_errors = {} > for each suffix: > topo_errors[suffix_name] = (orig_errors, new_errors) > return topo_errors > > Otherwise it looks OK (not tested yet). I didn't realize that. I have modified the patch accordingly. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0093.3-check-for-disconnected-topology-and-deleted-agreemen.patch Type: text/x-patch Size: 12857 bytes Desc: not available URL: From lslebodn at redhat.com Fri Nov 13 08:29:32 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 13 Nov 2015 09:29:32 +0100 Subject: [Freeipa-devel] [PATCH] ipa_kdb_tests: Fix test with default krb5.conf Message-ID: <20151113082931.GC14420@mail.corp.redhat.com> ehlo, ipa_kdb_tests test failed for me on minimal f23. LS -------------- next part -------------- >From ba5ecf13cac1b4822651987ba5db9ed16214cb8f Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Thu, 12 Nov 2015 19:22:56 +0000 Subject: [PATCH 1/8] ipa_kdb_tests: Fix test with default krb5.conf Default krb5.conf needn't have defined default_realm. Unit tests should not rely on existing default value. --- daemons/ipa-kdb/tests/ipa_kdb_tests.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index edd4ae0975628d6b3abe9bab2852c990c9a8c590..9f577529c7f8a22da2bb1a01898e804b6bc6d259 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -82,6 +82,10 @@ void setup(void **state) kerr = krb5_init_context(&krb5_ctx); assert_int_equal(kerr, 0); + + kerr = krb5_set_default_realm(krb5_ctx, "EXAMPLE.COM"); + assert_int_equal(kerr, 0); + kerr = krb5_db_setup_lib_handle(krb5_ctx); assert_int_equal(kerr, 0); -- 2.5.0 From lslebodn at redhat.com Fri Nov 13 08:32:59 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 13 Nov 2015 09:32:59 +0100 Subject: [Freeipa-devel] [PATCHES] Fix few gcc warnings Message-ID: <20151113083259.GA10464@mail.corp.redhat.com> ehlo, Few simple patches are attached. LS -------------- next part -------------- >From e7320a93df1f20e6f29e0a067187e70b41c10ef8 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Thu, 12 Nov 2015 19:25:15 +0000 Subject: [PATCH 2/8] ipa_kdb_tests: Remove unused variables --- daemons/ipa-kdb/tests/ipa_kdb_tests.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index 9f577529c7f8a22da2bb1a01898e804b6bc6d259..59e69d0c645026e5ce0884431b85486e599a3af0 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -126,9 +126,6 @@ void setup(void **state) &ipa_ctx->mspac->trusts[0].sid_blacklist_incoming[0]); assert_int_equal(ret, 0); - struct dom_sid *sid_blacklist_incoming; - int len_sid_blacklist_incoming; - ipa_ctx->kcontext = krb5_ctx; kerr = krb5_db_set_context(krb5_ctx, ipa_ctx); assert_int_equal(kerr, 0); @@ -317,7 +314,6 @@ void test_get_authz_data_types(void **state) char *ad_none_and_pad[] = {"NONE", "PAD", NULL}; char *ad_global_pac_nfs_none[] = {"MS-PAC", "nfs:NONE", NULL}; char *ad_global_pac_nfs_pad[] = {"MS-PAC", "nfs:PAD", NULL}; - krb5_context krb5_ctx; krb5_error_code kerr; struct ipadb_context *ipa_ctx; krb5_principal nfs_princ; -- 2.5.0 -------------- next part -------------- >From 935e22dc78f20e732cca0895899acae8ee233e10 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Thu, 12 Nov 2015 19:32:06 +0000 Subject: [PATCH 3/8] ipa_kdb_tests: Fix warning Wmissing-braces MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit tests/ipa_kdb_tests.c:254:9: warning: missing braces around initializer [-Wmissing-braces] {3, {BLACKLIST_SID"-1000", BLACKLIST_SID"-1001", BLACKLIST_SID"-1002"}, ^ tests/ipa_kdb_tests.c:254:9: note: (near initialization for ?test_data[6]?) tests/ipa_kdb_tests.c:256:9: warning: missing braces around initializer [-Wmissing-braces] {0, NULL, 0 , NULL} ^ tests/ipa_kdb_tests.c:256:9: note: (near initialization for ?test_data[7]?) tests/ipa_kdb_tests.c:234:21: warning: missing braces around initializer [-Wmissing-braces] } test_data[] = { ^ --- daemons/ipa-kdb/tests/ipa_kdb_tests.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index 59e69d0c645026e5ce0884431b85486e599a3af0..7483a1799d4c8462f212ff6e8e4140c1c053d6a7 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -252,8 +252,8 @@ void test_filter_logon_info(void **state) 1, {DOM_SID_TRUST"-1002"}}, /* all SIDs filtered*/ {3, {BLACKLIST_SID"-1000", BLACKLIST_SID"-1001", BLACKLIST_SID"-1002"}, - 0, NULL}, - {0, NULL, 0 , NULL} + 0, {}}, + {0, {}, 0 , {}} }; for (c = 0; test_data[c].sidcount != 0; c++) { -- 2.5.0 -------------- next part -------------- >From 215fd247ff9a6136c17228bf5e7369cb3f478512 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Thu, 12 Nov 2015 19:49:16 +0000 Subject: [PATCH 4/8] topology: Fix warning Wshadow MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit topology_pre.c: In function ?ipa_topo_pre_add?: topology_pre.c:509:15: warning: declaration of ?errtxt? shadows a previous local [-Wshadow] char *errtxt; ^ topology_pre.c:494:11: note: shadowed declaration is here char *errtxt = NULL; ^ --- daemons/ipa-slapi-plugins/topology/topology_pre.c | 1 - 1 file changed, 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/topology/topology_pre.c b/daemons/ipa-slapi-plugins/topology/topology_pre.c index c6c22be24e9ef4d48e9a62e59ef20d7fb049568f..1788c6d3e9d95543d905054d9d1f31c40dddc045 100644 --- a/daemons/ipa-slapi-plugins/topology/topology_pre.c +++ b/daemons/ipa-slapi-plugins/topology/topology_pre.c @@ -506,7 +506,6 @@ int ipa_topo_pre_add(Slapi_PBlock *pb) if (ipa_topo_is_entry_managed(pb)) { int rc = LDAP_UNWILLING_TO_PERFORM; - char *errtxt; errtxt = slapi_ch_smprintf("Entry is managed by topology plugin." " Adding of entry not allowed.\n"); slapi_pblock_set(pb, SLAPI_PB_RESULT_TEXT, errtxt); -- 2.5.0 -------------- next part -------------- >From 6d494c1c02914fd9c169b980b1e01d14061bb729 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 13 Nov 2015 06:51:59 +0000 Subject: [PATCH 5/8] ipa-extdom-extop: Fix warning Wformat MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In file included from ipa_extdom_extop.c:41:0: ipa_extdom_extop.c: In function ?ipa_extdom_init_ctx?: ipa_extdom_extop.c:203:9: warning: format ?%d? expects argument of type ?int?, but argument 4 has type ?size_t {aka long unsigned int}? [-Wformat=] LOG("Maximal nss buffer size set to [%d]!\n", ctx->max_nss_buf_size); ^ ../common/util.h:53:21: note: in definition of macro ?LOG_PLUGIN_NAME? fmt, ##__VA_ARGS__) ^ ipa_extdom_extop.c:203:5: note: in expansion of macro ?LOG? --- daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c index 708d0e4a2fc9da4f87a24a49c945587049f7280f..bc25e7643cdebe0eadc0cee4dcba3a392fdc33be 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -200,7 +200,7 @@ static int ipa_extdom_init_ctx(Slapi_PBlock *pb, struct ipa_extdom_ctx **_ctx) if (ctx->max_nss_buf_size == 0) { ctx->max_nss_buf_size = DEFAULT_MAX_NSS_BUFFER; } - LOG("Maximal nss buffer size set to [%d]!\n", ctx->max_nss_buf_size); + LOG("Maximal nss buffer size set to [%zu]!\n", ctx->max_nss_buf_size); ret = 0; -- 2.5.0 From lslebodn at redhat.com Fri Nov 13 08:33:50 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 13 Nov 2015 09:33:50 +0100 Subject: [Freeipa-devel] [PATCH] cmocka_tests: Do not use deprecated cmocka interface Message-ID: <20151113083350.GB10464@mail.corp.redhat.com> ehlo, The cmocka-1.0 introduced new interface for tests which is not compatible with the old one. And the old interface is deprecated which caused compiled warnings. LS -------------- next part -------------- >From 15c7610984f8561bceca2a729fc4cc7e81a1d2b1 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Thu, 12 Nov 2015 19:43:56 +0000 Subject: [PATCH 6/8] cmocka_tests: Do not use deprecated cmocka interface The cmocka-1.0 introduced new interface for tests which is not compatible with the old one. And the old interface is deprecated which caused compiled warnings. --- daemons/ipa-kdb/tests/ipa_kdb_tests.c | 23 ++++++++++------ .../ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c | 6 ++-- .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c | 32 ++++++++++++---------- 3 files changed, 36 insertions(+), 25 deletions(-) diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c b/daemons/ipa-kdb/tests/ipa_kdb_tests.c index 7483a1799d4c8462f212ff6e8e4140c1c053d6a7..5bc89e23410de4f779db44a9f2cf50bf521ef403 100644 --- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c +++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c @@ -72,7 +72,7 @@ struct test_ctx { #define DOM_SID_TRUST "S-1-5-21-4-5-6" #define BLACKLIST_SID "S-1-5-1" -void setup(void **state) +static int setup(void **state) { int ret; krb5_context krb5_ctx; @@ -136,9 +136,11 @@ void setup(void **state) test_ctx->krb5_ctx = krb5_ctx; *state = test_ctx; + + return 0; } -void teardown(void **state) +static int teardown(void **state) { struct test_ctx *test_ctx; struct ipadb_context *ipa_ctx; @@ -153,6 +155,8 @@ void teardown(void **state) krb5_free_context(test_ctx->krb5_ctx); talloc_free(test_ctx); + + return 0; } extern krb5_error_code filter_logon_info(krb5_context context, @@ -468,12 +472,15 @@ void test_dom_sid_string(void **state) int main(int argc, const char *argv[]) { - const UnitTest tests[] = { - unit_test_setup_teardown(test_get_authz_data_types, setup, teardown), - unit_test_setup_teardown(test_filter_logon_info, setup, teardown), - unit_test(test_string_to_sid), - unit_test_setup_teardown(test_dom_sid_string, setup, teardown), + const struct CMUnitTest tests[] = { + cmocka_unit_test_setup_teardown(test_get_authz_data_types, + setup, teardown), + cmocka_unit_test_setup_teardown(test_filter_logon_info, + setup, teardown), + cmocka_unit_test(test_string_to_sid), + cmocka_unit_test_setup_teardown(test_dom_sid_string, + setup, teardown), }; - return run_tests(tests); + return cmocka_run_group_tests(tests, NULL, NULL); } diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c index 8f579cb0c051551471a55273c4bce97717200ffd..48b9636fa4c7cc8d545f6adeb4283bfdf6472c2a 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_tests.c @@ -59,10 +59,10 @@ void test_make_netbios_name(void **state) int main(int argc, const char *argv[]) { - const UnitTest tests[] = { - unit_test(test_make_netbios_name), + const struct CMUnitTest tests[] = { + cmocka_unit_test(test_make_netbios_name), }; - return run_tests(tests); + return cmocka_run_group_tests(tests, NULL, NULL); } diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c index ec553fe62c27738f258defc267fe761c72157df0..526f903d2416e62ee5781909c234bd5ee2d89183 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c @@ -258,7 +258,7 @@ struct test_data { struct ipa_extdom_ctx *ctx; }; -void extdom_req_setup(void **state) +static int extdom_req_setup(void **state) { struct test_data *test_data; @@ -272,9 +272,11 @@ void extdom_req_setup(void **state) assert_non_null(test_data->req); *state = test_data; + + return 0; } -void extdom_req_teardown(void **state) +static int extdom_req_teardown(void **state) { struct test_data *test_data; @@ -283,6 +285,8 @@ void extdom_req_teardown(void **state) free_req_data(test_data->req); free(test_data->ctx); free(test_data); + + return 0; } void test_set_err_msg(void **state) @@ -433,18 +437,18 @@ void test_decode(void **state) int main(int argc, const char *argv[]) { - const UnitTest tests[] = { - unit_test(test_getpwnam_r_wrapper), - unit_test(test_getpwuid_r_wrapper), - unit_test(test_getgrnam_r_wrapper), - unit_test(test_getgrgid_r_wrapper), - unit_test(test_get_user_grouplist), - unit_test_setup_teardown(test_set_err_msg, - extdom_req_setup, extdom_req_teardown), - unit_test_setup_teardown(test_encode, - extdom_req_setup, extdom_req_teardown), - unit_test(test_decode), + const struct CMUnitTest tests[] = { + cmocka_unit_test(test_getpwnam_r_wrapper), + cmocka_unit_test(test_getpwuid_r_wrapper), + cmocka_unit_test(test_getgrnam_r_wrapper), + cmocka_unit_test(test_getgrgid_r_wrapper), + cmocka_unit_test(test_get_user_grouplist), + cmocka_unit_test_setup_teardown(test_set_err_msg, + extdom_req_setup, extdom_req_teardown), + cmocka_unit_test_setup_teardown(test_encode, + extdom_req_setup, extdom_req_teardown), + cmocka_unit_test(test_decode), }; - return run_tests(tests); + return cmocka_run_group_tests(tests, NULL, NULL); } -- 2.5.0 From lslebodn at redhat.com Fri Nov 13 08:36:02 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 13 Nov 2015 09:36:02 +0100 Subject: [Freeipa-devel] [PATCH] BUILD: provide check target in custom Makefiles Message-ID: <20151113083601.GC10464@mail.corp.redhat.com> ehlo, The automake generated makefiles have already a target check. We need to provide this target also to non-generated Makefiles so we can recursively call make check from top level Makefile. LS -------------- next part -------------- >From ba0e01bb8dd754b24580615decf54b718ba07b2e Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 13 Nov 2015 06:54:12 +0000 Subject: [PATCH 7/8] BUILD: provide check target in custom Makefiles The automake generated makefiles have already a target check. We need to provide this target also to non-generated Makefiles so we can recursively call make check from top level Makefile --- Makefile | 5 +++++ install/po/Makefile.in | 2 ++ ipapython/Makefile | 2 ++ 3 files changed, 9 insertions(+) diff --git a/Makefile b/Makefile index 3c81466d3728022c1d9cf5bb216990f14a59b7e5..d2c37f1597a011af2bd9ef1a4f7ce87ac59620a3 100644 --- a/Makefile +++ b/Makefile @@ -74,6 +74,11 @@ client: client-autogen done cd ipaplatform && $(PYTHON) setup.py build +check: bootstrap-autogen server tests + @for subdir in $(SUBDIRS); do \ + (cd $$subdir && $(MAKE) check) || exit 1; \ + done + bootstrap-autogen: version-update client-autogen @echo "Building IPA $(IPA_VERSION)" cd asn1; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi diff --git a/install/po/Makefile.in b/install/po/Makefile.in index e0bf2e0a1f3db14d485c7d787ae95e433703856f..713fcb5aa9143d718049bf691e7c3bc9e102803f 100644 --- a/install/po/Makefile.in +++ b/install/po/Makefile.in @@ -78,6 +78,8 @@ C_POTFILES = $(C_FILES) $(H_FILES) all: +check: + SUFFIXES = .po .mo .po.mo: diff --git a/ipapython/Makefile b/ipapython/Makefile index 8527643232fd1b14fc246bd36678631baac088db..a865ca7580f5270eca4383508ced23e8537da669 100644 --- a/ipapython/Makefile +++ b/ipapython/Makefile @@ -10,6 +10,8 @@ all: (cd $$subdir && $(MAKE) $@) || exit 1; \ done +check: + .PHONY: install install: if [ "$(DESTDIR)" = "" ]; then \ -- 2.5.0 From lslebodn at redhat.com Fri Nov 13 08:37:02 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 13 Nov 2015 09:37:02 +0100 Subject: [Freeipa-devel] [PATCH] SPEC: Run cmocka based uni test in %check phase Message-ID: <20151113083701.GD10464@mail.corp.redhat.com> ehlo, this patch depends on freeipa-lslebodn-0007-BUILD-provide-check-target-in-custom-Makefile.patch LS -------------- next part -------------- >From 507b57b4a166b0490d4217a9603a67577bb36036 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 13 Nov 2015 07:11:38 +0000 Subject: [PATCH 8/8] SPEC: Run cmocka based uni test in %check phase --- freeipa.spec.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index c3ca3413ffc3850b849a69adbbae8476355f3c76..fec2a83fcc83c02423601d88500e789c83f7a7d0 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -405,6 +405,9 @@ make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} all make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} client %endif # ONLY_CLIENT +%check +make %{?_smp_mflags} check VERBOSE=yes + %install rm -rf %{buildroot} export SUPPORTED_PLATFORM=%{platform_module} -- 2.5.0 From mbasti at redhat.com Fri Nov 13 09:05:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 10:05:58 +0100 Subject: [Freeipa-devel] [PATCH 0345 - 0346] Fix DNS test on fedora 23 Message-ID: <5645A7F6.5080609@redhat.com> Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0345-Tests-DNS-replace-192.0.2.0-24-with-198.18.0.0-15-ra.patch Type: text/x-patch Size: 2470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0346-Tests-DNS-various-exceptions-can-be-raised-in-test.patch Type: text/x-patch Size: 1683 bytes Desc: not available URL: From pvoborni at redhat.com Fri Nov 13 09:17:21 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Nov 2015 10:17:21 +0100 Subject: [Freeipa-devel] [PATCH 0338] Drop configure.jar file In-Reply-To: <5644A2D6.80709@redhat.com> References: <56332AFF.8050904@redhat.com> <563B9185.1050207@redhat.com> <56447792.2090607@redhat.com> <564499F2.2020008@redhat.com> <5644A2D6.80709@redhat.com> Message-ID: <5645AAA1.2000004@redhat.com> On 11/12/2015 03:31 PM, Martin Basti wrote: >> >> >> 1. following first line should be removed as well: >> preferences_filename = paths.PREFERENCES_HTML >> - if ipautil.file_exists(preferences_filename): >> >> Which also means that PREFERENCES_HTML won't be used and can be removed. >> > Aaa sorry my bad, I wanted to remove it from paths, I just somehow > forgot to do that. > Updated patch attached. ACK -- Petr Vobornik From mbabinsk at redhat.com Fri Nov 13 09:46:25 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 13 Nov 2015 10:46:25 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <5644AF3E.8040007@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> <5639FA77.3090907@redhat.com> <563A456A.2070101@redhat.com> <56421EC6.9050205@redhat.com> <56448E78.8080304@redhat.com> <5644AF3E.8040007@redhat.com> Message-ID: <5645B171.8020502@redhat.com> On 11/12/2015 04:24 PM, Martin Babinsky wrote: > On 11/12/2015 02:04 PM, Petr Vobornik wrote: >> On 11/10/2015 05:43 PM, Martin Babinsky wrote: >>> On 11/04/2015 06:50 PM, Petr Vobornik wrote: >>>> On 11/04/2015 01:30 PM, Martin Babinsky wrote: >>>>> On 10/30/2015 05:06 PM, Martin Babinsky wrote: >>>>>> On 10/30/2015 03:38 PM, Petr Vobornik wrote: >>>>>>> On 10/30/2015 03:26 PM, Martin Babinsky wrote: >>>>>>>> patch for https://fedorahosted.org/freeipa/ticket/5309 >>>>>>>> >>>>>>>> The ticket itself is about connectivity checks in topology >>>>>>>> suffixes, >>>>>>>> but >>>>>>>> there is a code (install/tools/ipa-replica-manage starting at line >>>>>>>> 788 >>>>>>>> after applying my patch) which monitors whether the segments >>>>>>>> pointing >>>>>>>> to/from the deleted host are already deleted. >>>>>>>> >>>>>>>> These checks are currently hardcoded for 'realm' prefix, should we >>>>>>>> generalize them as well or is it a part of other effort? >>>>>>>> >>>>>>> >>>>>>> Could be separate patch but yes. >>>>>> Ok I have included it in the attached patch so that both of these >>>>>> operations are performed for all suffixes. >>>>>> >>>>>> >>>>>> >>>>> Hmm, I'm thinking whether the 'check_last_link_managed' and >>>>> 'check_deleted_segments' should not be called per-suffix, but should >>>>> themselves check all suffixes available. This could make the fix for >>>>> https://fedorahosted.org/freeipa/ticket/5409 also easier. >>>>> >>>> >>>> Depends if the output is reusable. If so then why not. >>>> check_last_link_managed basically adds text to several >>>> get_topology_connection_errors calls. >>> >>> Attaching updated patch. >>> >> >> I'm not sure about (pseudo code): >> >> topo_errors = ([], []) >> for each suffix: >> topo_errors[0].extend(orig_errors) >> topo_errors[1].extend(new_errors) >> return topo_errors >> >> In check_deleted_segments wait_for_segment_removal is per-suffix check >> but uses topo_errors which contains errors from both suffices. Topo >> erros are used to relax the check if topology is disconnected but this >> might relax it too much. >> >> I would change the errors to per-suffix as well, e.g.: >> topo_errors = {} >> for each suffix: >> topo_errors[suffix_name] = (orig_errors, new_errors) >> return topo_errors >> >> Otherwise it looks OK (not tested yet). > > I didn't realize that. I have modified the patch accordingly. > > > Attaching updated patch with changed docstring of 'check_last_link_managed()' -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0093.4-check-for-disconnected-topology-and-deleted-agreemen.patch Type: text/x-patch Size: 13050 bytes Desc: not available URL: From lslebodn at redhat.com Fri Nov 13 11:04:44 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 13 Nov 2015 12:04:44 +0100 Subject: [Freeipa-devel] [PATCH] SPEC: Run cmocka based uni test in %check phase In-Reply-To: <20151113083701.GD10464@mail.corp.redhat.com> References: <20151113083701.GD10464@mail.corp.redhat.com> Message-ID: <20151113110443.GI10464@mail.corp.redhat.com> On (13/11/15 09:37), Lukas Slebodnik wrote: >ehlo, > >this patch depends on >freeipa-lslebodn-0007-BUILD-provide-check-target-in-custom-Makefile.patch > >LS >>From 507b57b4a166b0490d4217a9603a67577bb36036 Mon Sep 17 00:00:00 2001 >From: Lukas Slebodnik >Date: Fri, 13 Nov 2015 07:11:38 +0000 >Subject: [PATCH 8/8] SPEC: Run cmocka based uni test in %check phase > >--- > freeipa.spec.in | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index c3ca3413ffc3850b849a69adbbae8476355f3c76..fec2a83fcc83c02423601d88500e789c83f7a7d0 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -405,6 +405,9 @@ make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} all > make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} client > %endif # ONLY_CLIENT > >+%check >+make %{?_smp_mflags} check VERBOSE=yes >+ Tests were not executed in mock because there were missing build dependencies. Updated patch is attached. LS -------------- next part -------------- >From d33f9c7994be5ab8964db297609b5267ed012295 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Fri, 13 Nov 2015 07:11:38 +0000 Subject: [PATCH 8/8] SPEC: Run cmocka based unit test in %check phase This patch also consolidate build dependencies for c based unit tests --- freeipa.spec.in | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index c3ca341..075b2ca 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -78,7 +78,6 @@ BuildRequires: python-lxml BuildRequires: python-pyasn1 >= 0.0.9a BuildRequires: python-qrcode-core >= 5.0.0 BuildRequires: python-dns >= 1.11.1 -BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: libsss_nss_idmap-devel >= 1.12.2 BuildRequires: java-headless @@ -99,6 +98,10 @@ BuildRequires: python-six BuildRequires: python-jwcrypto BuildRequires: custodia +# Build dependencies for unit tests +BuildRequires: libcmocka-devel +BuildRequires: nss_wrapper + %description IPA is an integrated solution to provide centrally managed Identity (users, hosts, services), Authentication (SSO, 2FA), and Authorization @@ -405,6 +408,9 @@ make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} all make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} client %endif # ONLY_CLIENT +%check +make %{?_smp_mflags} check VERBOSE=yes + %install rm -rf %{buildroot} export SUPPORTED_PLATFORM=%{platform_module} -- 2.5.0 From pspacek at redhat.com Fri Nov 13 12:21:16 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Nov 2015 13:21:16 +0100 Subject: [Freeipa-devel] [PATCH 0345 - 0346] Fix DNS test on fedora 23 In-Reply-To: <5645A7F6.5080609@redhat.com> References: <5645A7F6.5080609@redhat.com> Message-ID: <5645D5BC.5030702@redhat.com> On 13.11.2015 10:05, Martin Basti wrote: > Patches attached. ACK, test_xmlrpc/test_dns_plugin.py passed when I managed to get though test process and all failures in other modules. -- Petr^2 Spacek From mbasti at redhat.com Fri Nov 13 13:03:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 14:03:01 +0100 Subject: [Freeipa-devel] [PATCH 0345 - 0346] Fix DNS test on fedora 23 In-Reply-To: <5645D5BC.5030702@redhat.com> References: <5645A7F6.5080609@redhat.com> <5645D5BC.5030702@redhat.com> Message-ID: <5645DF85.4030409@redhat.com> On 13.11.2015 13:21, Petr Spacek wrote: > On 13.11.2015 10:05, Martin Basti wrote: >> Patches attached. > ACK, test_xmlrpc/test_dns_plugin.py passed when I managed to get though test > process and all failures in other modules. > Pushed to master: b0faf30eac6b75267923fac59ef0728d763d29fe From mbasti at redhat.com Fri Nov 13 13:03:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 14:03:19 +0100 Subject: [Freeipa-devel] [PATCH 0338] Drop configure.jar file In-Reply-To: <5645AAA1.2000004@redhat.com> References: <56332AFF.8050904@redhat.com> <563B9185.1050207@redhat.com> <56447792.2090607@redhat.com> <564499F2.2020008@redhat.com> <5644A2D6.80709@redhat.com> <5645AAA1.2000004@redhat.com> Message-ID: <5645DF97.7000708@redhat.com> On 13.11.2015 10:17, Petr Vobornik wrote: > On 11/12/2015 03:31 PM, Martin Basti wrote: >>> >>> >>> 1. following first line should be removed as well: >>> preferences_filename = paths.PREFERENCES_HTML >>> - if ipautil.file_exists(preferences_filename): >>> >>> Which also means that PREFERENCES_HTML won't be used and can be >>> removed. >>> >> Aaa sorry my bad, I wanted to remove it from paths, I just somehow >> forgot to do that. >> Updated patch attached. > > ACK Pushed to master: 19044e87ac54200b7710b8ec5405175c3d749e76 From pvoborni at redhat.com Fri Nov 13 13:33:51 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Nov 2015 14:33:51 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <5645B171.8020502@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> <5639FA77.3090907@redhat.com> <563A456A.2070101@redhat.com> <56421EC6.9050205@redhat.com> <56448E78.8080304@redhat.com> <5644AF3E.8040007@redhat.com> <5645B171.8020502@redhat.com> Message-ID: <5645E6BF.4050707@redhat.com> On 11/13/2015 10:46 AM, Martin Babinsky wrote: >>> >>> Otherwise it looks OK (not tested yet). >> >> I didn't realize that. I have modified the patch accordingly. >> >> >> > Attaching updated patch with changed docstring of > 'check_last_link_managed()' > ACK -- Petr Vobornik From simo at redhat.com Fri Nov 13 13:41:45 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Nov 2015 08:41:45 -0500 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5643511D.8040108@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> Message-ID: <5645E899.10408@redhat.com> On 11/11/15 09:30, Martin Basti wrote: > > > On 11.11.2015 14:52, Martin Basti wrote: >> Comments inline >> Martin^2 >> >> On 11.11.2015 09:24, Stanislav Laznicka wrote: >>> On 11/05/2015 06:17 PM, Petr Spacek wrote: >>>> On 4.11.2015 15:20, Martin Basti wrote: >>>> >>>>> Hello, >>>>> >>>>> we (Standa and I) had offline discussion and I proposed following idea: >>>>> >>>>> 1) create new entry in LDAP for "time rule" instead of adding the time rule >>>>> string directly into HBACRule. >>>>> This will allow to reuse time rules among various HBAC Rules (and maybe in >>>>> future with sudo rules, etc.) >>>>> HBACrule gets only reference to time rule entry stored in LDAP db. >>>> Good idea! I can see time rule entry 'working hours in Brno office' which is >>>> linked to relevant HBAC rules. >>> This seems like a good idea. However, it might be a bit messy to have >>> even the least significant rules stored in separate objects. But I >>> agree. It brings some questions, though. >> Imo to have separate entry for time rule is cleaner than add it >> directly to HBAC rule. I really disagree, see below. >>> Where would be a good spot to store these time rules? >> As I originally thought that we can share time rules between HBAC, >> SUDO and everything else, I couldn't be wrong more. >> >> Example: HBAC admin have permission to edit HBAC rule, but doesn't >> have permission to edit SUDO rule. The HBAC admin should be able to >> edit time rules for HBAC rules, and cannot be able to edit time rules >> of SUDO rules. Thus time rules must be separated between HBAC, SUDO >> and others, and privilege that give the permission to modify HBAC >> rule, must give permission to modify only HBAC time rules. >> >> I suggest to add HBAC time rules to HBAC container. > After IRC discussion with pspacek and jcholast: > > We should just create separated privileges to time rules and allow them > to be shared. > So they should be stored in new container in LDAP I do not understand what this means. And in general I am opposed to have a separate object on performance grounds (for clients) and also on the fact that is becomes tricky to keep objects in sync. We then have to deal with cases where you delete a time object but an HBAC still references it and also assuring you have permissions to fully change an HBAC rule, you may end up in situations where you can change the HBAC rule for everything but the times (or vice versa). So please, explain carefully what would require a separate time object. On privileges alone I see no value in a separate privilege for time than for the HBAC object it applies to (preference for using the same object). I also see no technical reason to store the time rules for completely different stuff in the same tree. Yes, there may be the odd case in which you want to have the same time rule for a sudo rule and an HBAC rule, we can make that easy in the interface by providing a "copy time rules from X" kind of interface. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Nov 13 15:17:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 16:17:13 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5645E899.10408@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> Message-ID: <5645FEF9.2050403@redhat.com> On 13.11.2015 14:41, Simo Sorce wrote: > On 11/11/15 09:30, Martin Basti wrote: >> >> >> On 11.11.2015 14:52, Martin Basti wrote: >>> Comments inline >>> Martin^2 >>> >>> On 11.11.2015 09:24, Stanislav Laznicka wrote: >>>> On 11/05/2015 06:17 PM, Petr Spacek wrote: >>>>> On 4.11.2015 15:20, Martin Basti wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> we (Standa and I) had offline discussion and I proposed following >>>>>> idea: >>>>>> >>>>>> 1) create new entry in LDAP for "time rule" instead of adding the >>>>>> time rule >>>>>> string directly into HBACRule. >>>>>> This will allow to reuse time rules among various HBAC Rules (and >>>>>> maybe in >>>>>> future with sudo rules, etc.) >>>>>> HBACrule gets only reference to time rule entry stored in LDAP db. >>>>> Good idea! I can see time rule entry 'working hours in Brno >>>>> office' which is >>>>> linked to relevant HBAC rules. >>>> This seems like a good idea. However, it might be a bit messy to have >>>> even the least significant rules stored in separate objects. But I >>>> agree. It brings some questions, though. >>> Imo to have separate entry for time rule is cleaner than add it >>> directly to HBAC rule. > > I really disagree, see below. > >>>> Where would be a good spot to store these time rules? >>> As I originally thought that we can share time rules between HBAC, >>> SUDO and everything else, I couldn't be wrong more. >>> >>> Example: HBAC admin have permission to edit HBAC rule, but doesn't >>> have permission to edit SUDO rule. The HBAC admin should be able to >>> edit time rules for HBAC rules, and cannot be able to edit time rules >>> of SUDO rules. Thus time rules must be separated between HBAC, SUDO >>> and others, and privilege that give the permission to modify HBAC >>> rule, must give permission to modify only HBAC time rules. >>> >>> I suggest to add HBAC time rules to HBAC container. >> After IRC discussion with pspacek and jcholast: >> >> We should just create separated privileges to time rules and allow them >> to be shared. >> So they should be stored in new container in LDAP > > I do not understand what this means. > > And in general I am opposed to have a separate object on performance > grounds (for clients) and also on the fact that is becomes tricky to > keep objects in sync. What exactly is the performance issue there? To download extra entry from LDAP? The SSSD do the same sync with users and groups, doesn't it? > > We then have to deal with cases where you delete a time object but an > HBAC still references it and also assuring you have permissions to > fully change an HBAC rule, you may end up in situations where you can > change the HBAC rule for everything but the times (or vice versa). IMO this should solve referint plugin if the time policy is removed, then it will be removed from HBAC rules as well. > > So please, explain carefully what would require a separate time object. > > On privileges alone I see no value in a separate privilege for time > than for the HBAC object it applies to (preference for using the same > object). I also see no technical reason to store the time rules for > completely different stuff in the same tree. > Yes, there may be the odd case in which you want to have the same time > rule for a sudo rule and an HBAC rule, we can make that easy in the > interface by providing a "copy time rules from X" kind of interface. My original suggestion was to have it separated, HBAC time policy under HBAC container and sudo time policy under sudo container. So HBAC admin will have access to the same subtree and the one can modify time policy for HBAC. However pspacek and jcholast disagree I will let them to explain the reasons. Martin^2 > > Simo. > > > From simo at redhat.com Fri Nov 13 15:40:27 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Nov 2015 10:40:27 -0500 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5645FEF9.2050403@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> Message-ID: <5646046B.3020900@redhat.com> On 13/11/15 10:17, Martin Basti wrote: > > > On 13.11.2015 14:41, Simo Sorce wrote: >> On 11/11/15 09:30, Martin Basti wrote: >>> >>> >>> On 11.11.2015 14:52, Martin Basti wrote: >>>> Comments inline >>>> Martin^2 >>>> >>>> On 11.11.2015 09:24, Stanislav Laznicka wrote: >>>>> On 11/05/2015 06:17 PM, Petr Spacek wrote: >>>>>> On 4.11.2015 15:20, Martin Basti wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> we (Standa and I) had offline discussion and I proposed following >>>>>>> idea: >>>>>>> >>>>>>> 1) create new entry in LDAP for "time rule" instead of adding the >>>>>>> time rule >>>>>>> string directly into HBACRule. >>>>>>> This will allow to reuse time rules among various HBAC Rules (and >>>>>>> maybe in >>>>>>> future with sudo rules, etc.) >>>>>>> HBACrule gets only reference to time rule entry stored in LDAP db. >>>>>> Good idea! I can see time rule entry 'working hours in Brno >>>>>> office' which is >>>>>> linked to relevant HBAC rules. >>>>> This seems like a good idea. However, it might be a bit messy to have >>>>> even the least significant rules stored in separate objects. But I >>>>> agree. It brings some questions, though. >>>> Imo to have separate entry for time rule is cleaner than add it >>>> directly to HBAC rule. >> >> I really disagree, see below. >> >>>>> Where would be a good spot to store these time rules? >>>> As I originally thought that we can share time rules between HBAC, >>>> SUDO and everything else, I couldn't be wrong more. >>>> >>>> Example: HBAC admin have permission to edit HBAC rule, but doesn't >>>> have permission to edit SUDO rule. The HBAC admin should be able to >>>> edit time rules for HBAC rules, and cannot be able to edit time rules >>>> of SUDO rules. Thus time rules must be separated between HBAC, SUDO >>>> and others, and privilege that give the permission to modify HBAC >>>> rule, must give permission to modify only HBAC time rules. >>>> >>>> I suggest to add HBAC time rules to HBAC container. >>> After IRC discussion with pspacek and jcholast: >>> >>> We should just create separated privileges to time rules and allow them >>> to be shared. >>> So they should be stored in new container in LDAP >> >> I do not understand what this means. >> >> And in general I am opposed to have a separate object on performance >> grounds (for clients) and also on the fact that is becomes tricky to >> keep objects in sync. > What exactly is the performance issue there? To download extra entry > from LDAP? Yes because now you have to download rules, parse them, find out what needs tro be downloaded and pull it, or wore just download all time rules > The SSSD do the same sync with users and groups, doesn't it? No, by default we do not enumerate users and groups, and for HBAC rules we download only those that apply to the machine. All this exactly to reduce the amount of time taken, and load on the server. >> >> We then have to deal with cases where you delete a time object but an >> HBAC still references it and also assuring you have permissions to >> fully change an HBAC rule, you may end up in situations where you can >> change the HBAC rule for everything but the times (or vice versa). > IMO this should solve referint plugin if the time policy is removed, > then it will be removed from HBAC rules as well. This is *not* ok though, you do not want an HBAC rule that limits users to a specific time to suddenly become "any time" because someone removed a time rule and didn't know it was referenced by multiple rules. These are exactly the type of issues you end up having when you split the rule in multiple objects. >> >> So please, explain carefully what would require a separate time object. >> >> On privileges alone I see no value in a separate privilege for time >> than for the HBAC object it applies to (preference for using the same >> object). I also see no technical reason to store the time rules for >> completely different stuff in the same tree. >> Yes, there may be the odd case in which you want to have the same time >> rule for a sudo rule and an HBAC rule, we can make that easy in the >> interface by providing a "copy time rules from X" kind of interface. > My original suggestion was to have it separated, HBAC time policy under > HBAC container and sudo time policy under sudo container. So HBAC admin > will have access to the same subtree and the one can modify time policy > for HBAC. However pspacek and jcholast disagree I will let them to > explain the reasons. Seriopusly, the HBAC time policy should be (on the HBAC rule object) and I mean it as an additional object class with the policy embedded in the specific HBAC rule. This is more efficient and avoid issues like the one above. Can you explain *why* you propose to have separate objects ? What's the rationale ? What are the failure modes ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Nov 13 16:39:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 17:39:56 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <5645E6BF.4050707@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> <56339585.7020505@redhat.com> <5639FA77.3090907@redhat.com> <563A456A.2070101@redhat.com> <56421EC6.9050205@redhat.com> <56448E78.8080304@redhat.com> <5644AF3E.8040007@redhat.com> <5645B171.8020502@redhat.com> <5645E6BF.4050707@redhat.com> Message-ID: <5646125C.2030604@redhat.com> On 13.11.2015 14:33, Petr Vobornik wrote: > On 11/13/2015 10:46 AM, Martin Babinsky wrote: >>>> >>>> Otherwise it looks OK (not tested yet). >>> >>> I didn't realize that. I have modified the patch accordingly. >>> >>> >>> >> Attaching updated patch with changed docstring of >> 'check_last_link_managed()' >> > > ACK > Pushed to master: a6cdafd37451c99c1a7492ce5901195405881bb2 From mbasti at redhat.com Fri Nov 13 16:51:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 17:51:55 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5646046B.3020900@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> Message-ID: <5646152B.4010007@redhat.com> On 13.11.2015 16:40, Simo Sorce wrote: > On 13/11/15 10:17, Martin Basti wrote: >> >> >> On 13.11.2015 14:41, Simo Sorce wrote: >>> On 11/11/15 09:30, Martin Basti wrote: >>>> >>>> >>>> On 11.11.2015 14:52, Martin Basti wrote: >>>>> Comments inline >>>>> Martin^2 >>>>> >>>>> On 11.11.2015 09:24, Stanislav Laznicka wrote: >>>>>> On 11/05/2015 06:17 PM, Petr Spacek wrote: >>>>>>> On 4.11.2015 15:20, Martin Basti wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> we (Standa and I) had offline discussion and I proposed following >>>>>>>> idea: >>>>>>>> >>>>>>>> 1) create new entry in LDAP for "time rule" instead of adding the >>>>>>>> time rule >>>>>>>> string directly into HBACRule. >>>>>>>> This will allow to reuse time rules among various HBAC Rules (and >>>>>>>> maybe in >>>>>>>> future with sudo rules, etc.) >>>>>>>> HBACrule gets only reference to time rule entry stored in LDAP db. >>>>>>> Good idea! I can see time rule entry 'working hours in Brno >>>>>>> office' which is >>>>>>> linked to relevant HBAC rules. >>>>>> This seems like a good idea. However, it might be a bit messy to >>>>>> have >>>>>> even the least significant rules stored in separate objects. But I >>>>>> agree. It brings some questions, though. >>>>> Imo to have separate entry for time rule is cleaner than add it >>>>> directly to HBAC rule. >>> >>> I really disagree, see below. >>> >>>>>> Where would be a good spot to store these time rules? >>>>> As I originally thought that we can share time rules between HBAC, >>>>> SUDO and everything else, I couldn't be wrong more. >>>>> >>>>> Example: HBAC admin have permission to edit HBAC rule, but doesn't >>>>> have permission to edit SUDO rule. The HBAC admin should be able to >>>>> edit time rules for HBAC rules, and cannot be able to edit time rules >>>>> of SUDO rules. Thus time rules must be separated between HBAC, SUDO >>>>> and others, and privilege that give the permission to modify HBAC >>>>> rule, must give permission to modify only HBAC time rules. >>>>> >>>>> I suggest to add HBAC time rules to HBAC container. >>>> After IRC discussion with pspacek and jcholast: >>>> >>>> We should just create separated privileges to time rules and allow >>>> them >>>> to be shared. >>>> So they should be stored in new container in LDAP >>> >>> I do not understand what this means. >>> >>> And in general I am opposed to have a separate object on performance >>> grounds (for clients) and also on the fact that is becomes tricky to >>> keep objects in sync. >> What exactly is the performance issue there? To download extra entry >> from LDAP? > > Yes because now you have to download rules, parse them, find out what > needs tro be downloaded and pull it, or wore just download all time rules > >> The SSSD do the same sync with users and groups, doesn't it? > > No, by default we do not enumerate users and groups, and for HBAC > rules we download only those that apply to the machine. > > All this exactly to reduce the amount of time taken, and load on the > server. > >>> >>> We then have to deal with cases where you delete a time object but an >>> HBAC still references it and also assuring you have permissions to >>> fully change an HBAC rule, you may end up in situations where you can >>> change the HBAC rule for everything but the times (or vice versa). >> IMO this should solve referint plugin if the time policy is removed, >> then it will be removed from HBAC rules as well. > > This is *not* ok though, you do not want an HBAC rule that limits > users to a specific time to suddenly become "any time" because someone > removed a time rule and didn't know it was referenced by multiple rules. > These are exactly the type of issues you end up having when you split > the rule in multiple objects. > >>> >>> So please, explain carefully what would require a separate time object. >>> >>> On privileges alone I see no value in a separate privilege for time >>> than for the HBAC object it applies to (preference for using the same >>> object). I also see no technical reason to store the time rules for >>> completely different stuff in the same tree. >>> Yes, there may be the odd case in which you want to have the same time >>> rule for a sudo rule and an HBAC rule, we can make that easy in the >>> interface by providing a "copy time rules from X" kind of interface. >> My original suggestion was to have it separated, HBAC time policy under >> HBAC container and sudo time policy under sudo container. So HBAC admin >> will have access to the same subtree and the one can modify time policy >> for HBAC. However pspacek and jcholast disagree I will let them to >> explain the reasons. > > Seriopusly, the HBAC time policy should be (on the HBAC rule object) > and I mean it as an additional object class with the policy embedded > in the specific HBAC rule. This is more efficient and avoid issues > like the one above. > > Can you explain *why* you propose to have separate objects ? What's > the rationale ? What are the failure modes ? > The main purpose is to have time policies like "Work hours in Brno", "Work hours in Brisbane" ... which can be associated with many HBAC rules, instead of adding a separate time policy for each HBAC rule. Martin > Simo. > From simo at redhat.com Fri Nov 13 16:57:04 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Nov 2015 11:57:04 -0500 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5646152B.4010007@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> <5646152B.4010007@redhat.com> Message-ID: <56461660.5080501@redhat.com> On 13/11/15 11:51, Martin Basti wrote: > > > On 13.11.2015 16:40, Simo Sorce wrote: >> On 13/11/15 10:17, Martin Basti wrote: >>> >>> >>> On 13.11.2015 14:41, Simo Sorce wrote: >>>> On 11/11/15 09:30, Martin Basti wrote: >>>>> >>>>> >>>>> On 11.11.2015 14:52, Martin Basti wrote: >>>>>> Comments inline >>>>>> Martin^2 >>>>>> >>>>>> On 11.11.2015 09:24, Stanislav Laznicka wrote: >>>>>>> On 11/05/2015 06:17 PM, Petr Spacek wrote: >>>>>>>> On 4.11.2015 15:20, Martin Basti wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> we (Standa and I) had offline discussion and I proposed following >>>>>>>>> idea: >>>>>>>>> >>>>>>>>> 1) create new entry in LDAP for "time rule" instead of adding the >>>>>>>>> time rule >>>>>>>>> string directly into HBACRule. >>>>>>>>> This will allow to reuse time rules among various HBAC Rules (and >>>>>>>>> maybe in >>>>>>>>> future with sudo rules, etc.) >>>>>>>>> HBACrule gets only reference to time rule entry stored in LDAP db. >>>>>>>> Good idea! I can see time rule entry 'working hours in Brno >>>>>>>> office' which is >>>>>>>> linked to relevant HBAC rules. >>>>>>> This seems like a good idea. However, it might be a bit messy to >>>>>>> have >>>>>>> even the least significant rules stored in separate objects. But I >>>>>>> agree. It brings some questions, though. >>>>>> Imo to have separate entry for time rule is cleaner than add it >>>>>> directly to HBAC rule. >>>> >>>> I really disagree, see below. >>>> >>>>>>> Where would be a good spot to store these time rules? >>>>>> As I originally thought that we can share time rules between HBAC, >>>>>> SUDO and everything else, I couldn't be wrong more. >>>>>> >>>>>> Example: HBAC admin have permission to edit HBAC rule, but doesn't >>>>>> have permission to edit SUDO rule. The HBAC admin should be able to >>>>>> edit time rules for HBAC rules, and cannot be able to edit time rules >>>>>> of SUDO rules. Thus time rules must be separated between HBAC, SUDO >>>>>> and others, and privilege that give the permission to modify HBAC >>>>>> rule, must give permission to modify only HBAC time rules. >>>>>> >>>>>> I suggest to add HBAC time rules to HBAC container. >>>>> After IRC discussion with pspacek and jcholast: >>>>> >>>>> We should just create separated privileges to time rules and allow >>>>> them >>>>> to be shared. >>>>> So they should be stored in new container in LDAP >>>> >>>> I do not understand what this means. >>>> >>>> And in general I am opposed to have a separate object on performance >>>> grounds (for clients) and also on the fact that is becomes tricky to >>>> keep objects in sync. >>> What exactly is the performance issue there? To download extra entry >>> from LDAP? >> >> Yes because now you have to download rules, parse them, find out what >> needs tro be downloaded and pull it, or wore just download all time rules >> >>> The SSSD do the same sync with users and groups, doesn't it? >> >> No, by default we do not enumerate users and groups, and for HBAC >> rules we download only those that apply to the machine. >> >> All this exactly to reduce the amount of time taken, and load on the >> server. >> >>>> >>>> We then have to deal with cases where you delete a time object but an >>>> HBAC still references it and also assuring you have permissions to >>>> fully change an HBAC rule, you may end up in situations where you can >>>> change the HBAC rule for everything but the times (or vice versa). >>> IMO this should solve referint plugin if the time policy is removed, >>> then it will be removed from HBAC rules as well. >> >> This is *not* ok though, you do not want an HBAC rule that limits >> users to a specific time to suddenly become "any time" because someone >> removed a time rule and didn't know it was referenced by multiple rules. >> These are exactly the type of issues you end up having when you split >> the rule in multiple objects. >> >>>> >>>> So please, explain carefully what would require a separate time object. >>>> >>>> On privileges alone I see no value in a separate privilege for time >>>> than for the HBAC object it applies to (preference for using the same >>>> object). I also see no technical reason to store the time rules for >>>> completely different stuff in the same tree. >>>> Yes, there may be the odd case in which you want to have the same time >>>> rule for a sudo rule and an HBAC rule, we can make that easy in the >>>> interface by providing a "copy time rules from X" kind of interface. >>> My original suggestion was to have it separated, HBAC time policy under >>> HBAC container and sudo time policy under sudo container. So HBAC admin >>> will have access to the same subtree and the one can modify time policy >>> for HBAC. However pspacek and jcholast disagree I will let them to >>> explain the reasons. >> >> Seriopusly, the HBAC time policy should be (on the HBAC rule object) >> and I mean it as an additional object class with the policy embedded >> in the specific HBAC rule. This is more efficient and avoid issues >> like the one above. >> >> Can you explain *why* you propose to have separate objects ? What's >> the rationale ? What are the failure modes ? >> > The main purpose is to have time policies like "Work hours in Brno", > "Work hours in Brisbane" ... which can be associated with many HBAC > rules, instead of adding a separate time policy for each HBAC rule. This seem a convenience issue, it can be addressed by UI allowing to use templates which can be stored in some other tree for reference. Are there any other advantages to keeping references instead of adding the data directly to the entry (also remember we may use CoS in some cases). The disadvantages of having a separate object are clear tome, not so the advantages, and I am not saying there aren't, just that it is not clear to me they are sufficient to offset the disadvantages. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Nov 13 17:37:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 18:37:56 +0100 Subject: [Freeipa-devel] [PATCHES] Fix few gcc warnings In-Reply-To: <20151113083259.GA10464@mail.corp.redhat.com> References: <20151113083259.GA10464@mail.corp.redhat.com> Message-ID: <56461FF4.90606@redhat.com> On 13.11.2015 09:32, Lukas Slebodnik wrote: > ehlo, > > Few simple patches are attached. > > LS > > ACK Pushed to master: be6ecac220a8182ace0c8b8444cc2ec23bcff214 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Nov 13 17:49:36 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 13 Nov 2015 18:49:36 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5646046B.3020900@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> Message-ID: <20151113174936.GZ9901@hendrix.arn.redhat.com> On Fri, Nov 13, 2015 at 10:40:27AM -0500, Simo Sorce wrote: > On 13/11/15 10:17, Martin Basti wrote: > > > > > >On 13.11.2015 14:41, Simo Sorce wrote: > >>On 11/11/15 09:30, Martin Basti wrote: > >>> > >>> > >>>On 11.11.2015 14:52, Martin Basti wrote: > >>>>Comments inline > >>>>Martin^2 > >>>> > >>>>On 11.11.2015 09:24, Stanislav Laznicka wrote: > >>>>>On 11/05/2015 06:17 PM, Petr Spacek wrote: > >>>>>>On 4.11.2015 15:20, Martin Basti wrote: > >>>>>> > >>>>>>>Hello, > >>>>>>> > >>>>>>>we (Standa and I) had offline discussion and I proposed following > >>>>>>>idea: > >>>>>>> > >>>>>>>1) create new entry in LDAP for "time rule" instead of adding the > >>>>>>>time rule > >>>>>>>string directly into HBACRule. > >>>>>>>This will allow to reuse time rules among various HBAC Rules (and > >>>>>>>maybe in > >>>>>>>future with sudo rules, etc.) > >>>>>>>HBACrule gets only reference to time rule entry stored in LDAP db. > >>>>>>Good idea! I can see time rule entry 'working hours in Brno > >>>>>>office' which is > >>>>>>linked to relevant HBAC rules. > >>>>>This seems like a good idea. However, it might be a bit messy to have > >>>>>even the least significant rules stored in separate objects. But I > >>>>>agree. It brings some questions, though. > >>>>Imo to have separate entry for time rule is cleaner than add it > >>>>directly to HBAC rule. > >> > >>I really disagree, see below. > >> > >>>>>Where would be a good spot to store these time rules? > >>>>As I originally thought that we can share time rules between HBAC, > >>>>SUDO and everything else, I couldn't be wrong more. > >>>> > >>>>Example: HBAC admin have permission to edit HBAC rule, but doesn't > >>>>have permission to edit SUDO rule. The HBAC admin should be able to > >>>>edit time rules for HBAC rules, and cannot be able to edit time rules > >>>>of SUDO rules. Thus time rules must be separated between HBAC, SUDO > >>>>and others, and privilege that give the permission to modify HBAC > >>>>rule, must give permission to modify only HBAC time rules. > >>>> > >>>>I suggest to add HBAC time rules to HBAC container. > >>>After IRC discussion with pspacek and jcholast: > >>> > >>>We should just create separated privileges to time rules and allow them > >>>to be shared. > >>>So they should be stored in new container in LDAP > >> > >>I do not understand what this means. > >> > >>And in general I am opposed to have a separate object on performance > >>grounds (for clients) and also on the fact that is becomes tricky to > >>keep objects in sync. ~~~~~~~~~~~~~~~~~~~ I think this is even more important than performance. > >What exactly is the performance issue there? To download extra entry > >from LDAP? > > Yes because now you have to download rules, parse them, find out what needs > tro be downloaded and pull it, or wore just download all time rules Yes, if each rule referenced a timerule, then we would have to do something like: for rule in all_rules_for_this_host: dereference_attribute(rule_time_attr) We'd probably just end up fetching all timerules and establishing the relationship locally (which takes up computing time on the client). > > >The SSSD do the same sync with users and groups, doesn't it? > > No, by default we do not enumerate users and groups, and for HBAC rules we > download only those that apply to the machine. > > All this exactly to reduce the amount of time taken, and load on the server. Right, we try to reduce the number of round-trips, but also the number of separate objects we save to the cache and we try to avoid complex logic to link objects to one another. tl;dr - I agree with Simo. From mbasti at redhat.com Fri Nov 13 18:39:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Nov 2015 19:39:00 +0100 Subject: [Freeipa-devel] [PATCH 0347] Fix CI tests domain_level ENV config Message-ID: <56462E44.6080004@redhat.com> Patch attached. Following test should pass: ipa-run-tests test_integration/test_testconfig.py --verbose -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0347-Fix-CI-tests-domain_level-env-config.patch Type: text/x-patch Size: 1590 bytes Desc: not available URL: From mkosek at redhat.com Mon Nov 16 09:32:43 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Nov 2015 10:32:43 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5646046B.3020900@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> Message-ID: <5649A2BB.5000408@redhat.com> On 11/13/2015 04:40 PM, Simo Sorce wrote: > On 13/11/15 10:17, Martin Basti wrote: ... >>> And in general I am opposed to have a separate object on performance >>> grounds (for clients) and also on the fact that is becomes tricky to >>> keep objects in sync. >> What exactly is the performance issue there? To download extra entry >> from LDAP? > > Yes because now you have to download rules, parse them, find out what needs tro > be downloaded and pull it, or wore just download all time rules Just for the record, you should be able to pull that in one LDAP search, when you cast dereference on the HBAC time linking attribute and pull the settings from time object also. This is what SSSD does with user search AFAIK, though I am not sure you can do it in non-base search returning multiple results. From lkrispen at redhat.com Mon Nov 16 11:02:57 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 16 Nov 2015 12:02:57 +0100 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5649A2BB.5000408@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> <5649A2BB.5000408@redhat.com> Message-ID: <5649B7E1.5010007@redhat.com> On 11/16/2015 10:32 AM, Martin Kosek wrote: > On 11/13/2015 04:40 PM, Simo Sorce wrote: >> On 13/11/15 10:17, Martin Basti wrote: > ... >>>> And in general I am opposed to have a separate object on performance >>>> grounds (for clients) and also on the fact that is becomes tricky to >>>> keep objects in sync. >>> What exactly is the performance issue there? To download extra entry >>> from LDAP? >> >> Yes because now you have to download rules, parse them, find out what >> needs tro >> be downloaded and pull it, or wore just download all time rules > > Just for the record, you should be able to pull that in one LDAP > search, when you cast dereference on the HBAC time linking attribute > and pull the settings from time object also. but then you will have the corresponding internal searches, and the use of the deref control is not always efficient. If you want to define general rules like "brno" or "rest of the world" to reuse rules, why not use CoS and define virtual attributes in the entry, which would be populated by CoS. The client would have to read only one entry, the CoS allows flexibility to assign rules to entries > > This is what SSSD does with user search AFAIK, though I am not sure > you can do it in non-base search returning multiple results. > From abokovoy at redhat.com Mon Nov 16 11:37:02 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Nov 2015 13:37:02 +0200 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5649B7E1.5010007@redhat.com> References: <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> <5649A2BB.5000408@redhat.com> <5649B7E1.5010007@redhat.com> Message-ID: <20151116113702.GD9605@redhat.com> On Mon, 16 Nov 2015, Ludwig Krispenz wrote: > >On 11/16/2015 10:32 AM, Martin Kosek wrote: >>On 11/13/2015 04:40 PM, Simo Sorce wrote: >>>On 13/11/15 10:17, Martin Basti wrote: >>... >>>>>And in general I am opposed to have a separate object on performance >>>>>grounds (for clients) and also on the fact that is becomes tricky to >>>>>keep objects in sync. >>>>What exactly is the performance issue there? To download extra entry >>>>from LDAP? >>> >>>Yes because now you have to download rules, parse them, find out >>>what needs tro >>>be downloaded and pull it, or wore just download all time rules >> >>Just for the record, you should be able to pull that in one LDAP >>search, when you cast dereference on the HBAC time linking attribute >>and pull the settings from time object also. >but then you will have the corresponding internal searches, and the >use of the deref control is not always efficient. > >If you want to define general rules like "brno" or "rest of the world" >to reuse rules, why not use CoS and define virtual attributes in the >entry, which would be populated by CoS. The client would have to read >only one entry, the CoS allows flexibility to assign rules to entries I agree. To me CoS seems to be a better solution even though it means we would need to develop dynamically managed CoS rules beyond what we have right now in the password policies. -- / Alexander Bokovoy From mbasti at redhat.com Mon Nov 16 15:06:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 Nov 2015 16:06:51 +0100 Subject: [Freeipa-devel] [PATCH 0348] CI: fix KRA installation with domain level>0 Message-ID: <5649F10B.7060501@redhat.com> Patch attached. Part of https://fedorahosted.org/freeipa/ticket/5379 Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0348-CI-test-Fix-installation-of-KRA-on-a-replica.patch Type: text/x-patch Size: 1164 bytes Desc: not available URL: From amarecek at redhat.com Mon Nov 16 16:32:58 2015 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Mon, 16 Nov 2015 11:32:58 -0500 (EST) Subject: [Freeipa-devel] [PATCH 0347] Fix CI tests domain_level ENV config In-Reply-To: <56462E44.6080004@redhat.com> References: <56462E44.6080004@redhat.com> Message-ID: <661764287.9799097.1447691578769.JavaMail.zimbra@redhat.com> ACK. ----- Original Message ----- > From: "Martin Basti" > To: "freeipa-devel" > Sent: Friday, November 13, 2015 7:39:00 PM > Subject: [Freeipa-devel] [PATCH 0347] Fix CI tests domain_level ENV config > > Patch attached. > > Following test should pass: > ipa-run-tests test_integration/test_testconfig.py --verbose > > > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From amarecek at redhat.com Mon Nov 16 16:33:07 2015 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Mon, 16 Nov 2015 11:33:07 -0500 (EST) Subject: [Freeipa-devel] [PATCH 0348] CI: fix KRA installation with domain level>0 In-Reply-To: <5649F10B.7060501@redhat.com> References: <5649F10B.7060501@redhat.com> Message-ID: <1716073920.9799636.1447691587299.JavaMail.zimbra@redhat.com> ACK. ----- Original Message ----- > From: "Martin Basti" > To: "freeipa-devel" > Sent: Monday, November 16, 2015 4:06:51 PM > Subject: [Freeipa-devel] [PATCH 0348] CI: fix KRA installation with domain level>0 > > Patch attached. > Part of https://fedorahosted.org/freeipa/ticket/5379 > > Martin^2 > > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From mbasti at redhat.com Mon Nov 16 17:57:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 Nov 2015 18:57:17 +0100 Subject: [Freeipa-devel] How does this code work? (performance) Message-ID: <564A18FD.4020703@redhat.com> How does this code work (IMO it doesn't), ldap2.py def find_entries(self, filter=None, attrs_list=None, base_dn=None, scope=_ldap.SCOPE_SUBTREE, time_limit=None, size_limit=None, search_refs=False, paged_search=False): def _get_limits(): """Get configured global limits, caching them for more calls""" if not _lims: config = self.get_ipa_config() _lims['time'] = int(config.get('ipasearchtimelimit', [None])[0]) _lims['size'] = int(config.get('ipasearchrecordslimit', [None])[0]) return _lims _lims = {} if time_limit is None: time_limit = _get_limits()['time'] if size_limit is None: size_limit = _get_limits()['size'] Code above is supposed to do caching, but it doesn't do it. This might work if _lims were self._lims. I tried similar code to test this behavior: class test: def __init__(self): pass def cached_call(self): """configured global limits""" _lims = {} def _get_limits(): if not _lims: _lims['t']='oujeee' print 'getting limits' return _lims print "Limits:", _get_limits()['t'] t = test() t.cached_call() t.cached_call() t.cached_call() t.cached_call() Output: $ python testcaching.py Limits: getting limits oujeee Limits: getting limits oujeee Limits: getting limits oujeee Limits: getting limits oujeee So it does not do caching, or am I wrong? Martin^2 From simo at redhat.com Mon Nov 16 18:07:54 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Nov 2015 13:07:54 -0500 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <5649B7E1.5010007@redhat.com> References: <5639FE27.1040605@redhat.com> <563A1422.6020906@redhat.com> <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> <5649A2BB.5000408@redhat.com> <5649B7E1.5010007@redhat.com> Message-ID: <564A1B7A.9010207@redhat.com> On 16/11/15 06:02, Ludwig Krispenz wrote: > > On 11/16/2015 10:32 AM, Martin Kosek wrote: >> On 11/13/2015 04:40 PM, Simo Sorce wrote: >>> On 13/11/15 10:17, Martin Basti wrote: >> ... >>>>> And in general I am opposed to have a separate object on performance >>>>> grounds (for clients) and also on the fact that is becomes tricky to >>>>> keep objects in sync. >>>> What exactly is the performance issue there? To download extra entry >>>> from LDAP? >>> >>> Yes because now you have to download rules, parse them, find out what >>> needs tro >>> be downloaded and pull it, or wore just download all time rules >> >> Just for the record, you should be able to pull that in one LDAP >> search, when you cast dereference on the HBAC time linking attribute >> and pull the settings from time object also. > but then you will have the corresponding internal searches, and the use > of the deref control is not always efficient. > > If you want to define general rules like "brno" or "rest of the world" > to reuse rules, why not use CoS and define virtual attributes in the > entry, which would be populated by CoS. The client would have to read > only one entry, the CoS allows flexibility to assign rules to entries The nice thing about keeping it in the HBAC entry is indeed that we *ca* use CoS ... or not. We can decided that w/o breaking the schema. I think we will mostly *not* want to use CoS, but it remains an option. CoS is partially undesirable because it makes any change to the time policy an immediate change to all HBAC rules that reference them. While if times rules are templates, then a change to a time rule can be tested before applying it to all rules that reference it and you also have the option to have some HBAC rules break off and go on their own. It makes for a potentially more flexible and error forgiving system in this case. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Nov 16 18:20:54 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Nov 2015 20:20:54 +0200 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <564A1B7A.9010207@redhat.com> References: <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> <5649A2BB.5000408@redhat.com> <5649B7E1.5010007@redhat.com> <564A1B7A.9010207@redhat.com> Message-ID: <20151116182054.GI9605@redhat.com> On Mon, 16 Nov 2015, Simo Sorce wrote: >On 16/11/15 06:02, Ludwig Krispenz wrote: >> >>On 11/16/2015 10:32 AM, Martin Kosek wrote: >>>On 11/13/2015 04:40 PM, Simo Sorce wrote: >>>>On 13/11/15 10:17, Martin Basti wrote: >>>... >>>>>>And in general I am opposed to have a separate object on performance >>>>>>grounds (for clients) and also on the fact that is becomes tricky to >>>>>>keep objects in sync. >>>>>What exactly is the performance issue there? To download extra entry >>>>>from LDAP? >>>> >>>>Yes because now you have to download rules, parse them, find out what >>>>needs tro >>>>be downloaded and pull it, or wore just download all time rules >>> >>>Just for the record, you should be able to pull that in one LDAP >>>search, when you cast dereference on the HBAC time linking attribute >>>and pull the settings from time object also. >>but then you will have the corresponding internal searches, and the use >>of the deref control is not always efficient. >> >>If you want to define general rules like "brno" or "rest of the world" >>to reuse rules, why not use CoS and define virtual attributes in the >>entry, which would be populated by CoS. The client would have to read >>only one entry, the CoS allows flexibility to assign rules to entries > >The nice thing about keeping it in the HBAC entry is indeed that we >*ca* use CoS ... or not. We can decided that w/o breaking the schema. > >I think we will mostly *not* want to use CoS, but it remains an option. > >CoS is partially undesirable because it makes any change to the time >policy an immediate change to all HBAC rules that reference them. >While if times rules are templates, then a change to a time rule can >be tested before applying it to all rules that reference it and you >also have the option to have some HBAC rules break off and go on their >own. > >It makes for a potentially more flexible and error forgiving system in >this case. I don't see any contradiction here. You can create CoS configuration based on the instantiated template entry. That's why I wrote in the other answer we need to extend our current cosentry_* support a bit. -- / Alexander Bokovoy From simo at redhat.com Mon Nov 16 18:30:10 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Nov 2015 13:30:10 -0500 Subject: [Freeipa-devel] [Update]Time-Based Account Policies In-Reply-To: <20151116182054.GI9605@redhat.com> References: <563B8F41.8090902@redhat.com> <5642FB32.4070406@redhat.com> <56434834.50109@redhat.com> <5643511D.8040108@redhat.com> <5645E899.10408@redhat.com> <5645FEF9.2050403@redhat.com> <5646046B.3020900@redhat.com> <5649A2BB.5000408@redhat.com> <5649B7E1.5010007@redhat.com> <564A1B7A.9010207@redhat.com> <20151116182054.GI9605@redhat.com> Message-ID: <564A20B2.2060604@redhat.com> On 16/11/15 13:20, Alexander Bokovoy wrote: > On Mon, 16 Nov 2015, Simo Sorce wrote: >> On 16/11/15 06:02, Ludwig Krispenz wrote: >>> >>> On 11/16/2015 10:32 AM, Martin Kosek wrote: >>>> On 11/13/2015 04:40 PM, Simo Sorce wrote: >>>>> On 13/11/15 10:17, Martin Basti wrote: >>>> ... >>>>>>> And in general I am opposed to have a separate object on performance >>>>>>> grounds (for clients) and also on the fact that is becomes tricky to >>>>>>> keep objects in sync. >>>>>> What exactly is the performance issue there? To download extra entry >>>>>> from LDAP? >>>>> >>>>> Yes because now you have to download rules, parse them, find out what >>>>> needs tro >>>>> be downloaded and pull it, or wore just download all time rules >>>> >>>> Just for the record, you should be able to pull that in one LDAP >>>> search, when you cast dereference on the HBAC time linking attribute >>>> and pull the settings from time object also. >>> but then you will have the corresponding internal searches, and the use >>> of the deref control is not always efficient. >>> >>> If you want to define general rules like "brno" or "rest of the world" >>> to reuse rules, why not use CoS and define virtual attributes in the >>> entry, which would be populated by CoS. The client would have to read >>> only one entry, the CoS allows flexibility to assign rules to entries >> >> The nice thing about keeping it in the HBAC entry is indeed that we >> *ca* use CoS ... or not. We can decided that w/o breaking the schema. >> >> I think we will mostly *not* want to use CoS, but it remains an option. >> >> CoS is partially undesirable because it makes any change to the time >> policy an immediate change to all HBAC rules that reference them. >> While if times rules are templates, then a change to a time rule can >> be tested before applying it to all rules that reference it and you >> also have the option to have some HBAC rules break off and go on their >> own. >> >> It makes for a potentially more flexible and error forgiving system in >> this case. > I don't see any contradiction here. You can create CoS configuration > based on the instantiated template entry. That's why I wrote in the > other answer we need to extend our current cosentry_* support a bit. I wasn't implying any contradiction, I hadn't even read your message yet when I replied to Ludwig, sorry :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Nov 16 19:01:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 16 Nov 2015 20:01:33 +0100 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564A18FD.4020703@redhat.com> References: <564A18FD.4020703@redhat.com> Message-ID: <564A280D.80805@redhat.com> On 16.11.2015 18:57, Martin Basti wrote: > How does this code work (IMO it doesn't), ldap2.py > > def find_entries(self, filter=None, attrs_list=None, base_dn=None, > scope=_ldap.SCOPE_SUBTREE, time_limit=None, > size_limit=None, search_refs=False, > paged_search=False): > > def _get_limits(): > """Get configured global limits, caching them for more > calls""" > if not _lims: > config = self.get_ipa_config() > _lims['time'] = int(config.get('ipasearchtimelimit', > [None])[0]) > _lims['size'] = > int(config.get('ipasearchrecordslimit', [None])[0]) > return _lims > _lims = {} > > if time_limit is None: > time_limit = _get_limits()['time'] > if size_limit is None: > size_limit = _get_limits()['size'] > > Code above is supposed to do caching, but it doesn't do it. This might > work if _lims were self._lims. > I tried similar code to test this behavior: > > class test: > def __init__(self): > pass > > def cached_call(self): > """configured global limits""" > _lims = {} > def _get_limits(): > if not _lims: > _lims['t']='oujeee' > print 'getting limits' > return _lims > > print "Limits:", _get_limits()['t'] > > t = test() > t.cached_call() > t.cached_call() > t.cached_call() > t.cached_call() > > Output: > $ python testcaching.py > Limits: getting limits > oujeee > Limits: getting limits > oujeee > Limits: getting limits > oujeee > Limits: getting limits > oujeee > > So it does not do caching, or am I wrong? > Martin^2 > That code works, the whole caching is just for the second call of _get_limits() Can we instead just caching limits for second use, do caching for whole connection? This may be effective for methods/commands that calls search and show several times. Is there something that prevents us to do that? From rcritten at redhat.com Mon Nov 16 19:18:23 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Nov 2015 14:18:23 -0500 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564A280D.80805@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> Message-ID: <564A2BFF.4090100@redhat.com> Martin Basti wrote: > > > On 16.11.2015 18:57, Martin Basti wrote: >> How does this code work (IMO it doesn't), ldap2.py >> >> def find_entries(self, filter=None, attrs_list=None, base_dn=None, >> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >> size_limit=None, search_refs=False, >> paged_search=False): >> >> def _get_limits(): >> """Get configured global limits, caching them for more >> calls""" >> if not _lims: >> config = self.get_ipa_config() >> _lims['time'] = int(config.get('ipasearchtimelimit', >> [None])[0]) >> _lims['size'] = >> int(config.get('ipasearchrecordslimit', [None])[0]) >> return _lims >> _lims = {} >> >> if time_limit is None: >> time_limit = _get_limits()['time'] >> if size_limit is None: >> size_limit = _get_limits()['size'] >> >> Code above is supposed to do caching, but it doesn't do it. This might >> work if _lims were self._lims. >> I tried similar code to test this behavior: >> >> class test: >> def __init__(self): >> pass >> >> def cached_call(self): >> """configured global limits""" >> _lims = {} >> def _get_limits(): >> if not _lims: >> _lims['t']='oujeee' >> print 'getting limits' >> return _lims >> >> print "Limits:", _get_limits()['t'] >> >> t = test() >> t.cached_call() >> t.cached_call() >> t.cached_call() >> t.cached_call() >> >> Output: >> $ python testcaching.py >> Limits: getting limits >> oujeee >> Limits: getting limits >> oujeee >> Limits: getting limits >> oujeee >> Limits: getting limits >> oujeee >> >> So it does not do caching, or am I wrong? >> Martin^2 >> > That code works, the whole caching is just for the second call of > _get_limits() > > Can we instead just caching limits for second use, do caching for whole > connection? > This may be effective for methods/commands that calls search and show > several times. > > Is there something that prevents us to do that? > It already is cached. See get_ipa_config(). rob From mbasti at redhat.com Tue Nov 17 09:37:52 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 17 Nov 2015 10:37:52 +0100 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564A2BFF.4090100@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> <564A2BFF.4090100@redhat.com> Message-ID: <564AF570.5050901@redhat.com> On 16.11.2015 20:18, Rob Crittenden wrote: > Martin Basti wrote: >> >> >> On 16.11.2015 18:57, Martin Basti wrote: >>> How does this code work (IMO it doesn't), ldap2.py >>> >>> def find_entries(self, filter=None, attrs_list=None, base_dn=None, >>> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >>> size_limit=None, search_refs=False, >>> paged_search=False): >>> >>> def _get_limits(): >>> """Get configured global limits, caching them for more >>> calls""" >>> if not _lims: >>> config = self.get_ipa_config() >>> _lims['time'] = int(config.get('ipasearchtimelimit', >>> [None])[0]) >>> _lims['size'] = >>> int(config.get('ipasearchrecordslimit', [None])[0]) >>> return _lims >>> _lims = {} >>> >>> if time_limit is None: >>> time_limit = _get_limits()['time'] >>> if size_limit is None: >>> size_limit = _get_limits()['size'] >>> >>> Code above is supposed to do caching, but it doesn't do it. This might >>> work if _lims were self._lims. >>> I tried similar code to test this behavior: >>> >>> class test: >>> def __init__(self): >>> pass >>> >>> def cached_call(self): >>> """configured global limits""" >>> _lims = {} >>> def _get_limits(): >>> if not _lims: >>> _lims['t']='oujeee' >>> print 'getting limits' >>> return _lims >>> >>> print "Limits:", _get_limits()['t'] >>> >>> t = test() >>> t.cached_call() >>> t.cached_call() >>> t.cached_call() >>> t.cached_call() >>> >>> Output: >>> $ python testcaching.py >>> Limits: getting limits >>> oujeee >>> Limits: getting limits >>> oujeee >>> Limits: getting limits >>> oujeee >>> Limits: getting limits >>> oujeee >>> >>> So it does not do caching, or am I wrong? >>> Martin^2 >>> >> That code works, the whole caching is just for the second call of >> _get_limits() >> >> Can we instead just caching limits for second use, do caching for whole >> connection? >> This may be effective for methods/commands that calls search and show >> several times. >> >> Is there something that prevents us to do that? >> > > It already is cached. See get_ipa_config(). > > rob I missed that part there, thank you. Martin From mbasti at redhat.com Tue Nov 17 10:47:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 17 Nov 2015 11:47:58 +0100 Subject: [Freeipa-devel] [PATCH 0349] baseuser.py compare objectclasses as case insensitive Message-ID: <564B05DE.8020908@redhat.com> https://fedorahosted.org/freeipa/ticket/5456 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0349-Compare-objectclasses-as-cas-insensitive-in-baseuser.patch Type: text/x-patch Size: 2149 bytes Desc: not available URL: From sbose at redhat.com Wed Nov 18 11:45:46 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 18 Nov 2015 12:45:46 +0100 Subject: [Freeipa-devel] [PATCHES 151-153] ipasam: fix wrong usage of talloc_new() Message-ID: <20151118114546.GH21891@p.redhat.com> Hi, please find attached 3 small patches for ipasam. The first fixes https://fedorahosted.org/freeipa/ticket/5457 . The second is related because if the compat tree is enabled the lookup will still fails because the group is found twice. The third patch fixes an issue valgrind found while I was checking the other issue. bye, Sumit -------------- next part -------------- From 8b4025136271f158ae50172cdbc6dca4fbe2ee65 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 18 Nov 2015 12:29:43 +0100 Subject: [PATCH 151/153] ipasam: fix wrong usage of talloc_new() Fixes https://fedorahosted.org/freeipa/ticket/5457 --- daemons/ipa-sam/ipa_sam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 96452302f31e7a102b0ae2c17f343c75014b987b..37b5cf9140b9507e189363bff4c56cb33a82a89b 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -3029,7 +3029,7 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, enum idmap_error_code err; struct unixid id; - tmp_ctx = talloc_new("ipasam_get_sid_by_gid"); + tmp_ctx = talloc_init("ipasam_get_sid_by_gid"); if (tmp_ctx == NULL) { return ENOMEM; } -- 2.4.3 -------------- next part -------------- From deea949d98bff62493dd9048f0de3b5986103534 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 18 Nov 2015 12:31:26 +0100 Subject: [PATCH 152/153] ipasam: use more restrictive search filter for group lookup Since we are interested in looking up the SID of a group it makes sense to include the objectclass which contains the SID attribute in the search filter. This makes sure the group is not accidentally found a second time in the compat tree. Related to https://fedorahosted.org/freeipa/ticket/5457 --- daemons/ipa-sam/ipa_sam.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 37b5cf9140b9507e189363bff4c56cb33a82a89b..60e73374df6c3e1cda8287069bc062101439fc64 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -3034,9 +3034,11 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, return ENOMEM; } - filter = talloc_asprintf(tmp_ctx, "(&(%s=%s)(%s=%lu))", + filter = talloc_asprintf(tmp_ctx, "(&(%s=%s)(%s=%s)(%s=%lu))", LDAP_ATTRIBUTE_OBJECTCLASS, LDAP_OBJ_POSIXGROUP, + LDAP_ATTRIBUTE_OBJECTCLASS, + LDAP_OBJ_GROUPMAP, LDAP_ATTRIBUTE_GIDNUMBER, (unsigned long) gid); if (filter == NULL) { -- 2.4.3 -------------- next part -------------- From 08195df7a456cacd6438b8e75be8dc215c6c780c Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 18 Nov 2015 12:34:49 +0100 Subject: [PATCH 153/153] ipasam: fix a use-after-free issue Since endptr points to a location inside of dummy, dummy should be freed only after dereferencing endptr. --- daemons/ipa-sam/ipa_sam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 60e73374df6c3e1cda8287069bc062101439fc64..c51316757a80994a3992ab29f52e21b5a2c5673c 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2105,11 +2105,12 @@ static bool get_uint32_t_from_ldap_msg(struct ldapsam_privates *ldap_state, } l = strtoul(dummy, &endptr, 10); - TALLOC_FREE(dummy); if (l < 0 || l > UINT32_MAX || *endptr != '\0') { + TALLOC_FREE(dummy); return false; } + TALLOC_FREE(dummy); *val = l; -- 2.4.3 From mbasti at redhat.com Wed Nov 18 11:52:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 12:52:57 +0100 Subject: [Freeipa-devel] [PATCH] SPEC: Run cmocka based uni test in %check phase In-Reply-To: <20151113110443.GI10464@mail.corp.redhat.com> References: <20151113083701.GD10464@mail.corp.redhat.com> <20151113110443.GI10464@mail.corp.redhat.com> Message-ID: <564C6699.3030904@redhat.com> On 13.11.2015 12:04, Lukas Slebodnik wrote: > On (13/11/15 09:37), Lukas Slebodnik wrote: >> ehlo, >> >> this patch depends on >> freeipa-lslebodn-0007-BUILD-provide-check-target-in-custom-Makefile.patch >> >> LS >> >From 507b57b4a166b0490d4217a9603a67577bb36036 Mon Sep 17 00:00:00 2001 >> From: Lukas Slebodnik >> Date: Fri, 13 Nov 2015 07:11:38 +0000 >> Subject: [PATCH 8/8] SPEC: Run cmocka based uni test in %check phase >> >> --- >> freeipa.spec.in | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index c3ca3413ffc3850b849a69adbbae8476355f3c76..fec2a83fcc83c02423601d88500e789c83f7a7d0 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -405,6 +405,9 @@ make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} all >> make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} client >> %endif # ONLY_CLIENT >> >> +%check >> +make %{?_smp_mflags} check VERBOSE=yes >> + > Tests were not executed in mock because there were missing build > dependencies. Updated patch is attached. > > LS > > ACK Pushed to master: 559420562839b7cfe8e9af45bf22a3e9755963a7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 18 11:54:06 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 12:54:06 +0100 Subject: [Freeipa-devel] [PATCH] BUILD: provide check target in custom Makefiles In-Reply-To: <20151113083601.GC10464@mail.corp.redhat.com> References: <20151113083601.GC10464@mail.corp.redhat.com> Message-ID: <564C66DE.5010803@redhat.com> On 13.11.2015 09:36, Lukas Slebodnik wrote: > ehlo, > > The automake generated makefiles have already a target check. > We need to provide this target also to non-generated > Makefiles so we can recursively call make check from > top level Makefile. > > LS > > ACK Pushed to master: 2d39acf626358c01b5f18567f991b195ca842641 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 18 11:55:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 12:55:11 +0100 Subject: [Freeipa-devel] [PATCH] cmocka_tests: Do not use deprecated cmocka interface In-Reply-To: <20151113083350.GB10464@mail.corp.redhat.com> References: <20151113083350.GB10464@mail.corp.redhat.com> Message-ID: <564C671F.5000908@redhat.com> On 13.11.2015 09:33, Lukas Slebodnik wrote: > ehlo, > > The cmocka-1.0 introduced new interface for tests > which is not compatible with the old one. > And the old interface is deprecated which caused compiled warnings. > > LS > > ACK Pushed to master: 75c26f9ec8d69af88bbf1d07b2c7b38d08e8d67d -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 18 11:56:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 12:56:14 +0100 Subject: [Freeipa-devel] [PATCH] ipa_kdb_tests: Fix test with default krb5.conf In-Reply-To: <20151113082931.GC14420@mail.corp.redhat.com> References: <20151113082931.GC14420@mail.corp.redhat.com> Message-ID: <564C675E.4000708@redhat.com> On 13.11.2015 09:29, Lukas Slebodnik wrote: > ehlo, > > ipa_kdb_tests test failed for me on minimal f23. > > LS > > ACK Pushed to master: 73058af717b1ab470858be9273d38ff27d35002a -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 18 11:57:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 12:57:46 +0100 Subject: [Freeipa-devel] [PATCH 0347] Fix CI tests domain_level ENV config In-Reply-To: <661764287.9799097.1447691578769.JavaMail.zimbra@redhat.com> References: <56462E44.6080004@redhat.com> <661764287.9799097.1447691578769.JavaMail.zimbra@redhat.com> Message-ID: <564C67BA.1040806@redhat.com> On 16.11.2015 17:32, Ale? Mare?ek wrote: > ACK. Pushed to master: 79f7c71e61698457ae63b4f67bf296859e3f12d1 > > ----- Original Message ----- >> From: "Martin Basti" >> To: "freeipa-devel" >> Sent: Friday, November 13, 2015 7:39:00 PM >> Subject: [Freeipa-devel] [PATCH 0347] Fix CI tests domain_level ENV config >> >> Patch attached. >> >> Following test should pass: >> ipa-run-tests test_integration/test_testconfig.py --verbose >> >> >> >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From mbasti at redhat.com Wed Nov 18 11:58:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 12:58:44 +0100 Subject: [Freeipa-devel] [PATCH 0348] CI: fix KRA installation with domain level>0 In-Reply-To: <1716073920.9799636.1447691587299.JavaMail.zimbra@redhat.com> References: <5649F10B.7060501@redhat.com> <1716073920.9799636.1447691587299.JavaMail.zimbra@redhat.com> Message-ID: <564C67F4.3030200@redhat.com> On 16.11.2015 17:33, Ale? Mare?ek wrote: > ACK. Pushed to master: e56a1535b041c1ca1f398b54eda6bf04f1c1e33b > ----- Original Message ----- >> From: "Martin Basti" >> To: "freeipa-devel" >> Sent: Monday, November 16, 2015 4:06:51 PM >> Subject: [Freeipa-devel] [PATCH 0348] CI: fix KRA installation with domain level>0 >> >> Patch attached. >> Part of https://fedorahosted.org/freeipa/ticket/5379 >> >> Martin^2 >> >> >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From abokovoy at redhat.com Wed Nov 18 11:59:03 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Nov 2015 13:59:03 +0200 Subject: [Freeipa-devel] [PATCHES 151-153] ipasam: fix wrong usage of talloc_new() In-Reply-To: <20151118114546.GH21891@p.redhat.com> References: <20151118114546.GH21891@p.redhat.com> Message-ID: <20151118115903.GY9605@redhat.com> On Wed, 18 Nov 2015, Sumit Bose wrote: >Hi, > >please find attached 3 small patches for ipasam. The first fixes >https://fedorahosted.org/freeipa/ticket/5457 . The second is related >because if the compat tree is enabled the lookup will still fails >because the group is found twice. > >The third patch fixes an issue valgrind found while I was checking the >other issue. ACK for all three, they are obvious fixes (now ;). We should also commit them to 4.1 and 4.2. -- / Alexander Bokovoy From mbabinsk at redhat.com Wed Nov 18 12:25:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 18 Nov 2015 13:25:34 +0100 Subject: [Freeipa-devel] [PATCH 0096] check whether replica exists before executing the domain level 1 deletion code Message-ID: <564C6E3E.5040606@redhat.com> Additional fix for https://fedorahosted.org/freeipa/ticket/5424 In current implementation the topology suffices are checked first and after that the error about non-existent host is raised. This does not make much sense to me, we should check for host existence before any work is done. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0096-check-whether-replica-exists-before-executing-the-do.patch Type: text/x-patch Size: 2103 bytes Desc: not available URL: From mbasti at redhat.com Wed Nov 18 12:30:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 13:30:54 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade Message-ID: <564C6F7E.1060803@redhat.com> https://fedorahosted.org/freeipa/ticket/5267 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0350-Upgrade-increase-time-limit-for-upgrades.patch Type: text/x-patch Size: 9844 bytes Desc: not available URL: From mkosek at redhat.com Wed Nov 18 12:55:05 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Nov 2015 13:55:05 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564C6F7E.1060803@redhat.com> References: <564C6F7E.1060803@redhat.com> Message-ID: <564C7529.8090909@redhat.com> On 11/18/2015 01:30 PM, Martin Basti wrote: > + DEFAULT_TIME_LIMIT = -1.0 > + DEFAULT_SIZE_LIMIT = 0 ... > if time_limit is None or time_limit == 0: > - time_limit = -1.0 > + if self.time_limit is not None and self.time_limit != 0: > + time_limit = self.time_limit > + else: > + time_limit = self.DEFAULT_TIME_LIMIT > + I wonder why is the -1 default time limit a float number, I would expect that some trouble may emerge out of it. Maybe Rob knows? From jcholast at redhat.com Wed Nov 18 13:10:58 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 Nov 2015 14:10:58 +0100 Subject: [Freeipa-devel] [PATCH 506] cert renewal: make renewal of ipaCert atomic In-Reply-To: <56423547.5080207@redhat.com> References: <56407B01.4090804@redhat.com> <5640C0F5.7090404@redhat.com> <5641BB2C.10103@redhat.com> <56423547.5080207@redhat.com> Message-ID: <564C78E2.9040406@redhat.com> On 10.11.2015 19:19, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 9.11.2015 16:51, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes . >>>> >>>> Honza >>>> >>>> >>>> >>> >>> There be a note in renew_ra_cert that the lock is obtained in advance by >>> renew_ra_cert_pre. >> >> Added comment. >> >>> >>> It looks like it will silently fail if the lock cannot be acquired. Is >>> that desired? >> >> All unhandled exceptions are logged to syslog in both renew_ra_cert_pre >> and renew_ra_cert: >> >> try: >> main() >> except Exception: >> syslog.syslog(syslog.LOG_ERR, traceback.format_exc()) >> >> Updated patch attached. >> > > My confusion was with the auto-expiration. I guess this is ok. When > debugging this sort of thing via logs the more the merrier, so I guess > I'd have added a syslog to say "obtaining lock" or "locked" and then > something when the renewal actually starts, so one can try to piece > together what happened after the fact if something goes wrong. > > I guess certmonger already logs when a pre/post command is executed so > that may already be available. Yes. The ticket is not related to logging anyway. Is the last patch OK, then? -- Jan Cholasta From ldoudova at redhat.com Wed Nov 18 13:16:19 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 18 Nov 2015 14:16:19 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0006] Add comments to stageuser plugin tests Message-ID: <564C7A23.5010500@redhat.com> Hi, here's a patch that adds a few comments to stageuser tests in order to allow easier determining of a problem when tests fail. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0006-Adding-comments-in-stageuser-plugin-tests.patch Type: text/x-patch Size: 3979 bytes Desc: not available URL: From mbasti at redhat.com Wed Nov 18 13:18:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 14:18:19 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564C7529.8090909@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> Message-ID: <564C7A9B.6060107@redhat.com> On 18.11.2015 13:55, Martin Kosek wrote: > On 11/18/2015 01:30 PM, Martin Basti wrote: >> + DEFAULT_TIME_LIMIT = -1.0 >> + DEFAULT_SIZE_LIMIT = 0 > ... >> if time_limit is None or time_limit == 0: >> - time_limit = -1.0 >> + if self.time_limit is not None and self.time_limit != 0: >> + time_limit = self.time_limit >> + else: >> + time_limit = self.DEFAULT_TIME_LIMIT >> + > I wonder why is the -1 default time limit a float number, I would expect that > some trouble may emerge out of it. Maybe Rob knows? > Python LDAP allows to have smaller granularity than seconds and it internally convert time limit values to float. From mkosek at redhat.com Wed Nov 18 13:24:54 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Nov 2015 14:24:54 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564C7A9B.6060107@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> Message-ID: <564C7C26.5000107@redhat.com> On 11/18/2015 02:18 PM, Martin Basti wrote: > > > On 18.11.2015 13:55, Martin Kosek wrote: >> On 11/18/2015 01:30 PM, Martin Basti wrote: >>> + DEFAULT_TIME_LIMIT = -1.0 >>> + DEFAULT_SIZE_LIMIT = 0 >> ... >>> if time_limit is None or time_limit == 0: >>> - time_limit = -1.0 >>> + if self.time_limit is not None and self.time_limit != 0: >>> + time_limit = self.time_limit >>> + else: >>> + time_limit = self.DEFAULT_TIME_LIMIT >>> + >> I wonder why is the -1 default time limit a float number, I would expect that >> some trouble may emerge out of it. Maybe Rob knows? >> > Python LDAP allows to have smaller granularity than seconds and it internally > convert time limit values to float. Hm, ok. I was just curious since the value we expose in API is Int and the default does not use the smaller granularity, so I was thinking "Why bother?". If it is fixed in your patch, good. If not, good also, no need to bikeshed here I suppose. From pvoborni at redhat.com Wed Nov 18 13:25:31 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 18 Nov 2015 14:25:31 +0100 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564AF570.5050901@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> <564A2BFF.4090100@redhat.com> <564AF570.5050901@redhat.com> Message-ID: <564C7C4B.9040800@redhat.com> On 11/17/2015 10:37 AM, Martin Basti wrote: > > > On 16.11.2015 20:18, Rob Crittenden wrote: >> Martin Basti wrote: >>> >>> >>> On 16.11.2015 18:57, Martin Basti wrote: >>>> How does this code work (IMO it doesn't), ldap2.py >>>> >>>> def find_entries(self, filter=None, attrs_list=None, base_dn=None, >>>> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >>>> size_limit=None, search_refs=False, >>>> paged_search=False): >>>> >>>> def _get_limits(): >>>> """Get configured global limits, caching them for more >>>> calls""" >>>> if not _lims: >>>> config = self.get_ipa_config() >>>> _lims['time'] = int(config.get('ipasearchtimelimit', >>>> [None])[0]) >>>> _lims['size'] = >>>> int(config.get('ipasearchrecordslimit', [None])[0]) >>>> return _lims >>>> _lims = {} >>>> >>>> if time_limit is None: >>>> time_limit = _get_limits()['time'] >>>> if size_limit is None: >>>> size_limit = _get_limits()['size'] >>>> >>>> Code above is supposed to do caching, but it doesn't do it. This might >>>> work if _lims were self._lims. >>>> I tried similar code to test this behavior: >>>> >>>> class test: >>>> def __init__(self): >>>> pass >>>> >>>> def cached_call(self): >>>> """configured global limits""" >>>> _lims = {} >>>> def _get_limits(): >>>> if not _lims: >>>> _lims['t']='oujeee' >>>> print 'getting limits' >>>> return _lims >>>> >>>> print "Limits:", _get_limits()['t'] >>>> >>>> t = test() >>>> t.cached_call() >>>> t.cached_call() >>>> t.cached_call() >>>> t.cached_call() >>>> >>>> Output: >>>> $ python testcaching.py >>>> Limits: getting limits >>>> oujeee >>>> Limits: getting limits >>>> oujeee >>>> Limits: getting limits >>>> oujeee >>>> Limits: getting limits >>>> oujeee >>>> >>>> So it does not do caching, or am I wrong? >>>> Martin^2 >>>> >>> That code works, the whole caching is just for the second call of >>> _get_limits() >>> >>> Can we instead just caching limits for second use, do caching for whole >>> connection? >>> This may be effective for methods/commands that calls search and show >>> several times. >>> >>> Is there something that prevents us to do that? >>> >> >> It already is cached. See get_ipa_config(). >> >> rob > I missed that part there, thank you. > Martin > I tried user_add and according to access log( http://fpaste.org/291835/44785307/ ) it alone does 13 searches for ipa config: SRCH base="cn=ipaconfig,cn=etc,dc=example.com" scope=0 filter="(objectClass=*)" attrs=ALL So I think it is not working correctly. -- Petr Vobornik From mbasti at redhat.com Wed Nov 18 13:26:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 14:26:12 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564C7C26.5000107@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> Message-ID: <564C7C74.3030607@redhat.com> On 18.11.2015 14:24, Martin Kosek wrote: > On 11/18/2015 02:18 PM, Martin Basti wrote: >> >> On 18.11.2015 13:55, Martin Kosek wrote: >>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>> + DEFAULT_TIME_LIMIT = -1.0 >>>> + DEFAULT_SIZE_LIMIT = 0 >>> ... >>>> if time_limit is None or time_limit == 0: >>>> - time_limit = -1.0 >>>> + if self.time_limit is not None and self.time_limit != 0: >>>> + time_limit = self.time_limit >>>> + else: >>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>> + >>> I wonder why is the -1 default time limit a float number, I would expect that >>> some trouble may emerge out of it. Maybe Rob knows? >>> >> Python LDAP allows to have smaller granularity than seconds and it internally >> convert time limit values to float. > Hm, ok. I was just curious since the value we expose in API is Int and the > default does not use the smaller granularity, so I was thinking "Why bother?". > If it is fixed in your patch, good. If not, good also, no need to bikeshed here > I suppose. I just keep the original values there, I do not want to touch it with this patch From mbasti at redhat.com Wed Nov 18 15:10:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 16:10:45 +0100 Subject: [Freeipa-devel] [PATCH 0331, 0337] User plugin: allow multiple managers per user - CLI part In-Reply-To: <56447A67.8070607@redhat.com> References: <56264855.50606@redhat.com> <56264AA6.5010003@redhat.com> <56266FCF.80909@redhat.com> <562F832B.4060303@redhat.com> <56447A67.8070607@redhat.com> Message-ID: <564C94F5.1030209@redhat.com> On 12.11.2015 12:39, Martin Basti wrote: > > > On 27.10.2015 14:59, Martin Basti wrote: >> >> >> On 20.10.2015 18:46, Martin Basti wrote: >>> >>> >>> On 20.10.2015 16:07, Martin Basti wrote: >>>> >>>> >>>> On 20.10.2015 15:57, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5344 >>>>> >>>>> Patch attached. >>>>> >>>>> Test are failing, a fix in UserTracker has to be done (partially >>>>> in my patch 329) >>>>> >>>>> >>>> SelfNACK, I forgot to add stageuser tests >>>> >>>> >>> Updated patch attached. >>> >>> I extracted tests to the separate patch, tests do not work, I had >>> issues with user and stageuser trackers. >>> >>> >>> >> Patch to fix issues with --addattr and managers added and attached. >> >> > > The new one patch 0331 attached, patch 0337 is not needed anymore. > > This patch also fixes https://fedorahosted.org/freeipa/ticket/5387 > > updated patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0331.4-Allow-multiple-managers-per-user-CLI-part.patch Type: text/x-patch Size: 15949 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Nov 18 15:51:19 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 18 Nov 2015 16:51:19 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0006] Add comments to stageuser plugin tests In-Reply-To: <564C7A23.5010500@redhat.com> References: <564C7A23.5010500@redhat.com> Message-ID: <564C9E77.4050406@redhat.com> On 11/18/2015 02:16 PM, Lenka Doudova wrote: > Hi, > > here's a patch that adds a few comments to stageuser tests in order to > allow easier determining of a problem when tests fail. > > Lenka > > Hi Lenka, Firstly a technical detail: Python indexes lists from 0, so the comments in 'options_ok' do not correctly map to the test names anyway. I am also not sure if this patch is worth reviewing and pushing as it IMHO doesn't help in the identification of failed tests at all. This should be solved at more fundamental level. -- Martin^3 Babinsky From mbasti at redhat.com Wed Nov 18 16:20:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 17:20:00 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <5640A90B.6030906@redhat.com> References: <5640A90B.6030906@redhat.com> Message-ID: <564CA530.3060006@redhat.com> On 09.11.2015 15:09, Oleg Fayans wrote: > Hi guys, > > Here are first two automated testcases from this (so far incomplete) > testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan > > Testplan review is highly appreciated > > > > PATCH 16: NACK 1) What is the reason to add an unused parameter to 'domain_level' to install_topo()? Also it is good practise to add new option as the last parameter. 2) cab you in both tests specify a domain level with constant instead of number literal? 3) both test call install_topo with custom domain level, but it cannot work because 1) (did you run the test?) 4) How the test "TestLevel1" is supposed to work? Respectively why there is call of install_topo() that installs replica. As this test just tests that ipa-replica-prepare is not working anymore, is it worth to spend 20 minutes with installing replica and then just no tot use it? IMO to install master in install step is enough. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 18 16:34:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 17:34:29 +0100 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564C7C4B.9040800@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> <564A2BFF.4090100@redhat.com> <564AF570.5050901@redhat.com> <564C7C4B.9040800@redhat.com> Message-ID: <564CA895.1040408@redhat.com> On 18.11.2015 14:25, Petr Vobornik wrote: > On 11/17/2015 10:37 AM, Martin Basti wrote: >> >> >> On 16.11.2015 20:18, Rob Crittenden wrote: >>> Martin Basti wrote: >>>> >>>> >>>> On 16.11.2015 18:57, Martin Basti wrote: >>>>> How does this code work (IMO it doesn't), ldap2.py >>>>> >>>>> def find_entries(self, filter=None, attrs_list=None, >>>>> base_dn=None, >>>>> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >>>>> size_limit=None, search_refs=False, >>>>> paged_search=False): >>>>> >>>>> def _get_limits(): >>>>> """Get configured global limits, caching them for more >>>>> calls""" >>>>> if not _lims: >>>>> config = self.get_ipa_config() >>>>> _lims['time'] = int(config.get('ipasearchtimelimit', >>>>> [None])[0]) >>>>> _lims['size'] = >>>>> int(config.get('ipasearchrecordslimit', [None])[0]) >>>>> return _lims >>>>> _lims = {} >>>>> >>>>> if time_limit is None: >>>>> time_limit = _get_limits()['time'] >>>>> if size_limit is None: >>>>> size_limit = _get_limits()['size'] >>>>> >>>>> Code above is supposed to do caching, but it doesn't do it. This >>>>> might >>>>> work if _lims were self._lims. >>>>> I tried similar code to test this behavior: >>>>> >>>>> class test: >>>>> def __init__(self): >>>>> pass >>>>> >>>>> def cached_call(self): >>>>> """configured global limits""" >>>>> _lims = {} >>>>> def _get_limits(): >>>>> if not _lims: >>>>> _lims['t']='oujeee' >>>>> print 'getting limits' >>>>> return _lims >>>>> >>>>> print "Limits:", _get_limits()['t'] >>>>> >>>>> t = test() >>>>> t.cached_call() >>>>> t.cached_call() >>>>> t.cached_call() >>>>> t.cached_call() >>>>> >>>>> Output: >>>>> $ python testcaching.py >>>>> Limits: getting limits >>>>> oujeee >>>>> Limits: getting limits >>>>> oujeee >>>>> Limits: getting limits >>>>> oujeee >>>>> Limits: getting limits >>>>> oujeee >>>>> >>>>> So it does not do caching, or am I wrong? >>>>> Martin^2 >>>>> >>>> That code works, the whole caching is just for the second call of >>>> _get_limits() >>>> >>>> Can we instead just caching limits for second use, do caching for >>>> whole >>>> connection? >>>> This may be effective for methods/commands that calls search and show >>>> several times. >>>> >>>> Is there something that prevents us to do that? >>>> >>> >>> It already is cached. See get_ipa_config(). >>> >>> rob >> I missed that part there, thank you. >> Martin >> > > I tried user_add and according to access log( > http://fpaste.org/291835/44785307/ ) it alone does 13 searches for ipa > config: > > SRCH base="cn=ipaconfig,cn=etc,dc=example.com" scope=0 > filter="(objectClass=*)" attrs=ALL > > So I think it is not working correctly. I did testing, I put following debug prints into get_ipa_config method: + print("call: get_ipa_config") try: config_entry = getattr(context, 'config_entry') if config_entry.conn is self.conn: return config_entry + print("get_ipa_config: different connection!") except AttributeError: # Not in our context yet pass then I restarted apache, executed "ipa user-add test2" and result is here: http://fpaste.org/291926/64204144/ what means that the check in get_ipa_config is wrong, or ipa framework always creates a new connection. Except the first call that does not have cached value in context, every other call asked directly LDAP for the value. From mbasti at redhat.com Wed Nov 18 16:43:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 17:43:20 +0100 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564CA895.1040408@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> <564A2BFF.4090100@redhat.com> <564AF570.5050901@redhat.com> <564C7C4B.9040800@redhat.com> <564CA895.1040408@redhat.com> Message-ID: <564CAAA8.6020307@redhat.com> On 18.11.2015 17:34, Martin Basti wrote: > > > On 18.11.2015 14:25, Petr Vobornik wrote: >> On 11/17/2015 10:37 AM, Martin Basti wrote: >>> >>> >>> On 16.11.2015 20:18, Rob Crittenden wrote: >>>> Martin Basti wrote: >>>>> >>>>> >>>>> On 16.11.2015 18:57, Martin Basti wrote: >>>>>> How does this code work (IMO it doesn't), ldap2.py >>>>>> >>>>>> def find_entries(self, filter=None, attrs_list=None, >>>>>> base_dn=None, >>>>>> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >>>>>> size_limit=None, search_refs=False, >>>>>> paged_search=False): >>>>>> >>>>>> def _get_limits(): >>>>>> """Get configured global limits, caching them for more >>>>>> calls""" >>>>>> if not _lims: >>>>>> config = self.get_ipa_config() >>>>>> _lims['time'] = int(config.get('ipasearchtimelimit', >>>>>> [None])[0]) >>>>>> _lims['size'] = >>>>>> int(config.get('ipasearchrecordslimit', [None])[0]) >>>>>> return _lims >>>>>> _lims = {} >>>>>> >>>>>> if time_limit is None: >>>>>> time_limit = _get_limits()['time'] >>>>>> if size_limit is None: >>>>>> size_limit = _get_limits()['size'] >>>>>> >>>>>> Code above is supposed to do caching, but it doesn't do it. This >>>>>> might >>>>>> work if _lims were self._lims. >>>>>> I tried similar code to test this behavior: >>>>>> >>>>>> class test: >>>>>> def __init__(self): >>>>>> pass >>>>>> >>>>>> def cached_call(self): >>>>>> """configured global limits""" >>>>>> _lims = {} >>>>>> def _get_limits(): >>>>>> if not _lims: >>>>>> _lims['t']='oujeee' >>>>>> print 'getting limits' >>>>>> return _lims >>>>>> >>>>>> print "Limits:", _get_limits()['t'] >>>>>> >>>>>> t = test() >>>>>> t.cached_call() >>>>>> t.cached_call() >>>>>> t.cached_call() >>>>>> t.cached_call() >>>>>> >>>>>> Output: >>>>>> $ python testcaching.py >>>>>> Limits: getting limits >>>>>> oujeee >>>>>> Limits: getting limits >>>>>> oujeee >>>>>> Limits: getting limits >>>>>> oujeee >>>>>> Limits: getting limits >>>>>> oujeee >>>>>> >>>>>> So it does not do caching, or am I wrong? >>>>>> Martin^2 >>>>>> >>>>> That code works, the whole caching is just for the second call of >>>>> _get_limits() >>>>> >>>>> Can we instead just caching limits for second use, do caching for >>>>> whole >>>>> connection? >>>>> This may be effective for methods/commands that calls search and show >>>>> several times. >>>>> >>>>> Is there something that prevents us to do that? >>>>> >>>> >>>> It already is cached. See get_ipa_config(). >>>> >>>> rob >>> I missed that part there, thank you. >>> Martin >>> >> >> I tried user_add and according to access log( >> http://fpaste.org/291835/44785307/ ) it alone does 13 searches for >> ipa config: >> >> SRCH base="cn=ipaconfig,cn=etc,dc=example.com" scope=0 >> filter="(objectClass=*)" attrs=ALL >> >> So I think it is not working correctly. > > I did testing, I put following debug prints into get_ipa_config method: > > + print("call: get_ipa_config") > try: > config_entry = getattr(context, 'config_entry') > if config_entry.conn is self.conn: > return config_entry > + print("get_ipa_config: different connection!") > except AttributeError: > # Not in our context yet > pass > > then I restarted apache, executed "ipa user-add test2" and result is > here: http://fpaste.org/291926/64204144/ > > what means that the check in get_ipa_config is wrong, or ipa framework > always creates a new connection. > Except the first call that does not have cached value in context, > every other call asked directly LDAP for the value. > The comparation of connections in get_ipa_config does not work. http://fpaste.org/291937/64863144/ I added repr(connection) of cached and current connection, and self.conn is still the same but *is* operator returned failed. From rcritten at redhat.com Wed Nov 18 16:58:22 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Nov 2015 11:58:22 -0500 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564CAAA8.6020307@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> <564A2BFF.4090100@redhat.com> <564AF570.5050901@redhat.com> <564C7C4B.9040800@redhat.com> <564CA895.1040408@redhat.com> <564CAAA8.6020307@redhat.com> Message-ID: <564CAE2E.5000506@redhat.com> Martin Basti wrote: > > > On 18.11.2015 17:34, Martin Basti wrote: >> >> >> On 18.11.2015 14:25, Petr Vobornik wrote: >>> On 11/17/2015 10:37 AM, Martin Basti wrote: >>>> >>>> >>>> On 16.11.2015 20:18, Rob Crittenden wrote: >>>>> Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 16.11.2015 18:57, Martin Basti wrote: >>>>>>> How does this code work (IMO it doesn't), ldap2.py >>>>>>> >>>>>>> def find_entries(self, filter=None, attrs_list=None, >>>>>>> base_dn=None, >>>>>>> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >>>>>>> size_limit=None, search_refs=False, >>>>>>> paged_search=False): >>>>>>> >>>>>>> def _get_limits(): >>>>>>> """Get configured global limits, caching them for more >>>>>>> calls""" >>>>>>> if not _lims: >>>>>>> config = self.get_ipa_config() >>>>>>> _lims['time'] = int(config.get('ipasearchtimelimit', >>>>>>> [None])[0]) >>>>>>> _lims['size'] = >>>>>>> int(config.get('ipasearchrecordslimit', [None])[0]) >>>>>>> return _lims >>>>>>> _lims = {} >>>>>>> >>>>>>> if time_limit is None: >>>>>>> time_limit = _get_limits()['time'] >>>>>>> if size_limit is None: >>>>>>> size_limit = _get_limits()['size'] >>>>>>> >>>>>>> Code above is supposed to do caching, but it doesn't do it. This >>>>>>> might >>>>>>> work if _lims were self._lims. >>>>>>> I tried similar code to test this behavior: >>>>>>> >>>>>>> class test: >>>>>>> def __init__(self): >>>>>>> pass >>>>>>> >>>>>>> def cached_call(self): >>>>>>> """configured global limits""" >>>>>>> _lims = {} >>>>>>> def _get_limits(): >>>>>>> if not _lims: >>>>>>> _lims['t']='oujeee' >>>>>>> print 'getting limits' >>>>>>> return _lims >>>>>>> >>>>>>> print "Limits:", _get_limits()['t'] >>>>>>> >>>>>>> t = test() >>>>>>> t.cached_call() >>>>>>> t.cached_call() >>>>>>> t.cached_call() >>>>>>> t.cached_call() >>>>>>> >>>>>>> Output: >>>>>>> $ python testcaching.py >>>>>>> Limits: getting limits >>>>>>> oujeee >>>>>>> Limits: getting limits >>>>>>> oujeee >>>>>>> Limits: getting limits >>>>>>> oujeee >>>>>>> Limits: getting limits >>>>>>> oujeee >>>>>>> >>>>>>> So it does not do caching, or am I wrong? >>>>>>> Martin^2 >>>>>>> >>>>>> That code works, the whole caching is just for the second call of >>>>>> _get_limits() >>>>>> >>>>>> Can we instead just caching limits for second use, do caching for >>>>>> whole >>>>>> connection? >>>>>> This may be effective for methods/commands that calls search and show >>>>>> several times. >>>>>> >>>>>> Is there something that prevents us to do that? >>>>>> >>>>> >>>>> It already is cached. See get_ipa_config(). >>>>> >>>>> rob >>>> I missed that part there, thank you. >>>> Martin >>>> >>> >>> I tried user_add and according to access log( >>> http://fpaste.org/291835/44785307/ ) it alone does 13 searches for >>> ipa config: >>> >>> SRCH base="cn=ipaconfig,cn=etc,dc=example.com" scope=0 >>> filter="(objectClass=*)" attrs=ALL >>> >>> So I think it is not working correctly. >> >> I did testing, I put following debug prints into get_ipa_config method: >> >> + print("call: get_ipa_config") >> try: >> config_entry = getattr(context, 'config_entry') >> if config_entry.conn is self.conn: >> return config_entry >> + print("get_ipa_config: different connection!") >> except AttributeError: >> # Not in our context yet >> pass >> >> then I restarted apache, executed "ipa user-add test2" and result is >> here: http://fpaste.org/291926/64204144/ >> >> what means that the check in get_ipa_config is wrong, or ipa framework >> always creates a new connection. >> Except the first call that does not have cached value in context, >> every other call asked directly LDAP for the value. >> > The comparation of connections in get_ipa_config does not work. > http://fpaste.org/291937/64863144/ > > I added repr(connection) of cached and current connection, and self.conn > is still the same but *is* operator returned failed. > Nice catch. I guess the next step is to see when this was broken. I had a 4.1.4 system lying around and that works so this is a fairly recent issue. I'd suggest expanding your debugging to show the two connections, maybe that will provide some clues. IIRC there are tests to ensure that context.conn is being set but perhaps something changed. rob From mbasti at redhat.com Wed Nov 18 17:01:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 18:01:29 +0100 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564CAE2E.5000506@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> <564A2BFF.4090100@redhat.com> <564AF570.5050901@redhat.com> <564C7C4B.9040800@redhat.com> <564CA895.1040408@redhat.com> <564CAAA8.6020307@redhat.com> <564CAE2E.5000506@redhat.com> Message-ID: <564CAEE9.3050008@redhat.com> On 18.11.2015 17:58, Rob Crittenden wrote: > Martin Basti wrote: >> >> On 18.11.2015 17:34, Martin Basti wrote: >>> >>> On 18.11.2015 14:25, Petr Vobornik wrote: >>>> On 11/17/2015 10:37 AM, Martin Basti wrote: >>>>> >>>>> On 16.11.2015 20:18, Rob Crittenden wrote: >>>>>> Martin Basti wrote: >>>>>>> >>>>>>> On 16.11.2015 18:57, Martin Basti wrote: >>>>>>>> How does this code work (IMO it doesn't), ldap2.py >>>>>>>> >>>>>>>> def find_entries(self, filter=None, attrs_list=None, >>>>>>>> base_dn=None, >>>>>>>> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >>>>>>>> size_limit=None, search_refs=False, >>>>>>>> paged_search=False): >>>>>>>> >>>>>>>> def _get_limits(): >>>>>>>> """Get configured global limits, caching them for more >>>>>>>> calls""" >>>>>>>> if not _lims: >>>>>>>> config = self.get_ipa_config() >>>>>>>> _lims['time'] = int(config.get('ipasearchtimelimit', >>>>>>>> [None])[0]) >>>>>>>> _lims['size'] = >>>>>>>> int(config.get('ipasearchrecordslimit', [None])[0]) >>>>>>>> return _lims >>>>>>>> _lims = {} >>>>>>>> >>>>>>>> if time_limit is None: >>>>>>>> time_limit = _get_limits()['time'] >>>>>>>> if size_limit is None: >>>>>>>> size_limit = _get_limits()['size'] >>>>>>>> >>>>>>>> Code above is supposed to do caching, but it doesn't do it. This >>>>>>>> might >>>>>>>> work if _lims were self._lims. >>>>>>>> I tried similar code to test this behavior: >>>>>>>> >>>>>>>> class test: >>>>>>>> def __init__(self): >>>>>>>> pass >>>>>>>> >>>>>>>> def cached_call(self): >>>>>>>> """configured global limits""" >>>>>>>> _lims = {} >>>>>>>> def _get_limits(): >>>>>>>> if not _lims: >>>>>>>> _lims['t']='oujeee' >>>>>>>> print 'getting limits' >>>>>>>> return _lims >>>>>>>> >>>>>>>> print "Limits:", _get_limits()['t'] >>>>>>>> >>>>>>>> t = test() >>>>>>>> t.cached_call() >>>>>>>> t.cached_call() >>>>>>>> t.cached_call() >>>>>>>> t.cached_call() >>>>>>>> >>>>>>>> Output: >>>>>>>> $ python testcaching.py >>>>>>>> Limits: getting limits >>>>>>>> oujeee >>>>>>>> Limits: getting limits >>>>>>>> oujeee >>>>>>>> Limits: getting limits >>>>>>>> oujeee >>>>>>>> Limits: getting limits >>>>>>>> oujeee >>>>>>>> >>>>>>>> So it does not do caching, or am I wrong? >>>>>>>> Martin^2 >>>>>>>> >>>>>>> That code works, the whole caching is just for the second call of >>>>>>> _get_limits() >>>>>>> >>>>>>> Can we instead just caching limits for second use, do caching for >>>>>>> whole >>>>>>> connection? >>>>>>> This may be effective for methods/commands that calls search and show >>>>>>> several times. >>>>>>> >>>>>>> Is there something that prevents us to do that? >>>>>>> >>>>>> It already is cached. See get_ipa_config(). >>>>>> >>>>>> rob >>>>> I missed that part there, thank you. >>>>> Martin >>>>> >>>> I tried user_add and according to access log( >>>> http://fpaste.org/291835/44785307/ ) it alone does 13 searches for >>>> ipa config: >>>> >>>> SRCH base="cn=ipaconfig,cn=etc,dc=example.com" scope=0 >>>> filter="(objectClass=*)" attrs=ALL >>>> >>>> So I think it is not working correctly. >>> I did testing, I put following debug prints into get_ipa_config method: >>> >>> + print("call: get_ipa_config") >>> try: >>> config_entry = getattr(context, 'config_entry') >>> if config_entry.conn is self.conn: >>> return config_entry >>> + print("get_ipa_config: different connection!") >>> except AttributeError: >>> # Not in our context yet >>> pass >>> >>> then I restarted apache, executed "ipa user-add test2" and result is >>> here: http://fpaste.org/291926/64204144/ >>> >>> what means that the check in get_ipa_config is wrong, or ipa framework >>> always creates a new connection. >>> Except the first call that does not have cached value in context, >>> every other call asked directly LDAP for the value. >>> >> The comparation of connections in get_ipa_config does not work. >> http://fpaste.org/291937/64863144/ >> >> I added repr(connection) of cached and current connection, and self.conn >> is still the same but *is* operator returned failed. >> > Nice catch. I guess the next step is to see when this was broken. I had > a 4.1.4 system lying around and that works so this is a fairly recent issue. > > I'd suggest expanding your debugging to show the two connections, maybe > that will provide some clues. > > IIRC there are tests to ensure that context.conn is being set but > perhaps something changed. > > rob > Yes, thank you Petr to catch this. https://fedorahosted.org/freeipa/ticket/5463 From pspacek at redhat.com Wed Nov 18 17:33:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 Nov 2015 18:33:21 +0100 Subject: [Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records In-Reply-To: <56448D06.3020700@redhat.com> References: <563A2158.80009@redhat.com> <56404F9E.4090606@redhat.com> <56448D06.3020700@redhat.com> Message-ID: <564CB661.9040106@redhat.com> On 12.11.2015 13:58, Martin Basti wrote: > > > On 09.11.2015 08:47, Petr Spacek wrote: >> On 4.11.2015 16:16, Martin Basti wrote: >>> Patch attached. >>> >>> https://fedorahosted.org/freeipa/ticket/5421 >> I'm not entirely sure how this patch will interact with magic included in >> ipalib/plugins/dns.py:class dns_resolve(Command). >> >> I would like to delete the 'normalization' from at least one of these places. >> >> Also, as you know, DNS names are not strings and should be manipulated using >> python-dns so all crazy things in DNS names do not break in weird corner cases. >> > Updated patch attached. Hmm, you bravely ignored my comment about class dns_resolve(Command) above, sooo: NACK. As far as I can tell ipalib/plugins/dns.py:class dns_resolve(Command) behaves in the same brain-dead way as original is_host_resolvable() function. Please fix both, not just one. -- Petr^2 Spacek From mbasti at redhat.com Wed Nov 18 17:47:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Nov 2015 18:47:44 +0100 Subject: [Freeipa-devel] Caching ldap limits for whole connection (performance) In-Reply-To: <564CAEE9.3050008@redhat.com> References: <564A18FD.4020703@redhat.com> <564A280D.80805@redhat.com> <564A2BFF.4090100@redhat.com> <564AF570.5050901@redhat.com> <564C7C4B.9040800@redhat.com> <564CA895.1040408@redhat.com> <564CAAA8.6020307@redhat.com> <564CAE2E.5000506@redhat.com> <564CAEE9.3050008@redhat.com> Message-ID: <564CB9C0.7000108@redhat.com> On 18.11.2015 18:01, Martin Basti wrote: > > > On 18.11.2015 17:58, Rob Crittenden wrote: >> Martin Basti wrote: >>> >>> On 18.11.2015 17:34, Martin Basti wrote: >>>> >>>> On 18.11.2015 14:25, Petr Vobornik wrote: >>>>> On 11/17/2015 10:37 AM, Martin Basti wrote: >>>>>> >>>>>> On 16.11.2015 20:18, Rob Crittenden wrote: >>>>>>> Martin Basti wrote: >>>>>>>> >>>>>>>> On 16.11.2015 18:57, Martin Basti wrote: >>>>>>>>> How does this code work (IMO it doesn't), ldap2.py >>>>>>>>> >>>>>>>>> def find_entries(self, filter=None, attrs_list=None, >>>>>>>>> base_dn=None, >>>>>>>>> scope=_ldap.SCOPE_SUBTREE, time_limit=None, >>>>>>>>> size_limit=None, search_refs=False, >>>>>>>>> paged_search=False): >>>>>>>>> >>>>>>>>> def _get_limits(): >>>>>>>>> """Get configured global limits, caching them for >>>>>>>>> more >>>>>>>>> calls""" >>>>>>>>> if not _lims: >>>>>>>>> config = self.get_ipa_config() >>>>>>>>> _lims['time'] = >>>>>>>>> int(config.get('ipasearchtimelimit', >>>>>>>>> [None])[0]) >>>>>>>>> _lims['size'] = >>>>>>>>> int(config.get('ipasearchrecordslimit', [None])[0]) >>>>>>>>> return _lims >>>>>>>>> _lims = {} >>>>>>>>> >>>>>>>>> if time_limit is None: >>>>>>>>> time_limit = _get_limits()['time'] >>>>>>>>> if size_limit is None: >>>>>>>>> size_limit = _get_limits()['size'] >>>>>>>>> >>>>>>>>> Code above is supposed to do caching, but it doesn't do it. This >>>>>>>>> might >>>>>>>>> work if _lims were self._lims. >>>>>>>>> I tried similar code to test this behavior: >>>>>>>>> >>>>>>>>> class test: >>>>>>>>> def __init__(self): >>>>>>>>> pass >>>>>>>>> >>>>>>>>> def cached_call(self): >>>>>>>>> """configured global limits""" >>>>>>>>> _lims = {} >>>>>>>>> def _get_limits(): >>>>>>>>> if not _lims: >>>>>>>>> _lims['t']='oujeee' >>>>>>>>> print 'getting limits' >>>>>>>>> return _lims >>>>>>>>> >>>>>>>>> print "Limits:", _get_limits()['t'] >>>>>>>>> >>>>>>>>> t = test() >>>>>>>>> t.cached_call() >>>>>>>>> t.cached_call() >>>>>>>>> t.cached_call() >>>>>>>>> t.cached_call() >>>>>>>>> >>>>>>>>> Output: >>>>>>>>> $ python testcaching.py >>>>>>>>> Limits: getting limits >>>>>>>>> oujeee >>>>>>>>> Limits: getting limits >>>>>>>>> oujeee >>>>>>>>> Limits: getting limits >>>>>>>>> oujeee >>>>>>>>> Limits: getting limits >>>>>>>>> oujeee >>>>>>>>> >>>>>>>>> So it does not do caching, or am I wrong? >>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>> That code works, the whole caching is just for the second call of >>>>>>>> _get_limits() >>>>>>>> >>>>>>>> Can we instead just caching limits for second use, do caching for >>>>>>>> whole >>>>>>>> connection? >>>>>>>> This may be effective for methods/commands that calls search >>>>>>>> and show >>>>>>>> several times. >>>>>>>> >>>>>>>> Is there something that prevents us to do that? >>>>>>>> >>>>>>> It already is cached. See get_ipa_config(). >>>>>>> >>>>>>> rob >>>>>> I missed that part there, thank you. >>>>>> Martin >>>>>> >>>>> I tried user_add and according to access log( >>>>> http://fpaste.org/291835/44785307/ ) it alone does 13 searches for >>>>> ipa config: >>>>> >>>>> SRCH base="cn=ipaconfig,cn=etc,dc=example.com" scope=0 >>>>> filter="(objectClass=*)" attrs=ALL >>>>> >>>>> So I think it is not working correctly. >>>> I did testing, I put following debug prints into get_ipa_config >>>> method: >>>> >>>> + print("call: get_ipa_config") >>>> try: >>>> config_entry = getattr(context, 'config_entry') >>>> if config_entry.conn is self.conn: >>>> return config_entry >>>> + print("get_ipa_config: different connection!") >>>> except AttributeError: >>>> # Not in our context yet >>>> pass >>>> >>>> then I restarted apache, executed "ipa user-add test2" and result is >>>> here: http://fpaste.org/291926/64204144/ >>>> >>>> what means that the check in get_ipa_config is wrong, or ipa framework >>>> always creates a new connection. >>>> Except the first call that does not have cached value in context, >>>> every other call asked directly LDAP for the value. >>>> >>> The comparation of connections in get_ipa_config does not work. >>> http://fpaste.org/291937/64863144/ >>> >>> I added repr(connection) of cached and current connection, and >>> self.conn >>> is still the same but *is* operator returned failed. >>> >> Nice catch. I guess the next step is to see when this was broken. I had >> a 4.1.4 system lying around and that works so this is a fairly recent >> issue. >> >> I'd suggest expanding your debugging to show the two connections, maybe >> that will provide some clues. >> >> IIRC there are tests to ensure that context.conn is being set but >> perhaps something changed. >> >> rob >> > Yes, thank you Petr to catch this. > https://fedorahosted.org/freeipa/ticket/5463 > > Connection objects has different reference since beginning id(self.conn) != id(config_entry.conn), so the object in config_entry.conn is not the same as object self.conn. Otherwise object added and received to/from context is the same object. From pviktori at redhat.com Wed Nov 18 23:55:05 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Nov 2015 00:55:05 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run In-Reply-To: <5638B8F9.6010703@redhat.com> References: <5638B8F9.6010703@redhat.com> Message-ID: <564D0FD9.4070505@redhat.com> On 11/03/2015 02:39 PM, Petr Viktorin wrote: > Hello, > Python 3's strings are Unicode, so data coming to or leaving a Python > program needs to be decoded/encoded if it's to be handled as a string. > One of the boundaries where encoding is necessary is external programs, > specifically, ipautil.run. > Unfortunately there's no one set of options that would work for all > run() invocations, so I went through them all and specified the > stdin/stdout/stderr encoding where necessary. I've also updated the call > sites to make it clearer if the return values are used or not. > If an encoding is not set, run() will accept/return bytes. (This is a > fail-safe setting, since it can't raise errors, and using bytes where > strings are expected generally fails loudly in py3.) > > Note that the changes are not effective under Python 2. ping, Could someone look at this patch? -- Petr Viktorin From jcholast at redhat.com Thu Nov 19 08:07:04 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 09:07:04 +0100 Subject: [Freeipa-devel] [PATCH 508] install: export KRA agent PEM file in ipa-kra-install Message-ID: <564D8328.2020703@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-508-install-export-KRA-agent-PEM-file-in-ipa-kra-install.patch Type: text/x-patch Size: 802 bytes Desc: not available URL: From ldoudova at redhat.com Thu Nov 19 08:30:39 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 19 Nov 2015 09:30:39 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0006] Add comments to stageuser plugin tests In-Reply-To: <564C9E77.4050406@redhat.com> References: <564C7A23.5010500@redhat.com> <564C9E77.4050406@redhat.com> Message-ID: <564D88AF.8010500@redhat.com> On 11/18/2015 04:51 PM, Martin Babinsky wrote: > On 11/18/2015 02:16 PM, Lenka Doudova wrote: >> Hi, >> >> here's a patch that adds a few comments to stageuser tests in order to >> allow easier determining of a problem when tests fail. >> >> Lenka >> >> > > Hi Lenka, > > Firstly a technical detail: Python indexes lists from 0, so the > comments in 'options_ok' do not correctly map to the test names anyway. > > I am also not sure if this patch is worth reviewing and pushing as it > IMHO doesn't help in the identification of failed tests at all. > > This should be solved at more fundamental level. > Ouch, good point, I didn't realize. Sorry. Anyway, the issue is that even if tests are run in verbose mode, you get output like this: ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser27] PASSED ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser28] PASSED ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser29] PASSED ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser210] PASSED ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser211] PASSED ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser212] PASSED If some test fails, you can't really tell which command was the one responsible for the fail. This should be solved by https://fedorahosted.org/freeipa/ticket/5449. Until that's done, though, the only way to find out which command failed is looking at the code and finding which parameters were put into the command, which was not much possible without better commenting the test case (as I realized last week when David Kupka asked me to help him find the reason for failed tests). Obviously I can rewrite the tests so there's 27 separate test cases, one for each parameter, instead of one method that 'unwraps' into 27 test cases, which would entirely eliminate the confusion. So far I don't know of a way to put 27 similar test cases in one method which would allow easy recognition of the test cases. I'll wait with fixing the patch until further discussion. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Nov 19 09:34:36 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Nov 2015 10:34:36 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0006] Add comments to stageuser plugin tests In-Reply-To: <564D88AF.8010500@redhat.com> References: <564C7A23.5010500@redhat.com> <564C9E77.4050406@redhat.com> <564D88AF.8010500@redhat.com> Message-ID: <564D97AC.6050901@redhat.com> On 11/19/2015 09:30 AM, Lenka Doudova wrote: > On 11/18/2015 04:51 PM, Martin Babinsky wrote: >> On 11/18/2015 02:16 PM, Lenka Doudova wrote: >>> Hi, >>> >>> here's a patch that adds a few comments to stageuser tests in order to >>> allow easier determining of a problem when tests fail. >>> >>> Lenka >>> >>> >> >> Hi Lenka, >> >> Firstly a technical detail: Python indexes lists from 0, so the >> comments in 'options_ok' do not correctly map to the test names anyway. >> >> I am also not sure if this patch is worth reviewing and pushing as it >> IMHO doesn't help in the identification of failed tests at all. >> >> This should be solved at more fundamental level. >> > Ouch, good point, I didn't realize. Sorry. > > Anyway, the issue is that even if tests are run in verbose mode, you get > output like this: > > ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser27] > PASSED > > ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser28] > PASSED > > ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser29] > PASSED > > ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser210] > PASSED > > ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser211] > PASSED > > ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser212] > PASSED > > > If some test fails, you can't really tell which command was the one > responsible for the fail. This should be solved by > https://fedorahosted.org/freeipa/ticket/5449. Until that's done, though, > the only way to find out which command failed is looking at the code and > finding which parameters were put into the command, which was not much > possible without better commenting the test case (as I realized last > week when David Kupka asked me to help him find the reason for failed > tests). > Obviously I can rewrite the tests so there's 27 separate test cases, one > for each parameter, instead of one method that 'unwraps' into 27 test > cases, which would entirely eliminate the confusion. So far I don't know > of a way to put 27 similar test cases in one method which would allow > easy recognition of the test cases. > I'll wait with fixing the patch until further discussion. Hello, Pytest wants you to be a bit more explicit about how to name the parameters. (It "hides" dicts by default, because large dicts would make the output even more confusing than the numbers.) Please try the attached patch. Docs are at https://pytest.org/latest/fixture.html#parametrizing-a-fixture -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0750-stageuser-tests-Use-str-to-display-fixture-parameter.patch Type: text/x-patch Size: 1015 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Nov 19 09:50:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 Nov 2015 10:50:29 +0100 Subject: [Freeipa-devel] [PATCH 0097] fix critical error messages when adding KRA container that already exists Message-ID: <564D9B65.1020004@redhat.com> https://fedorahosted.org/freeipa/ticket/5346 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0097-suppress-errors-arising-from-adding-existing-LDAP-en.patch Type: text/x-patch Size: 2746 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0097-suppress-errors-arising-from-adding-existing-LDAP-en.patch Type: text/x-patch Size: 2828 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Nov 19 10:01:08 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 Nov 2015 11:01:08 +0100 Subject: [Freeipa-devel] [PATCH 508] install: export KRA agent PEM file in ipa-kra-install In-Reply-To: <564D8328.2020703@redhat.com> References: <564D8328.2020703@redhat.com> Message-ID: <564D9DE4.8030808@redhat.com> On 11/19/2015 09:07 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Thu Nov 19 10:05:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 Nov 2015 11:05:18 +0100 Subject: [Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records In-Reply-To: <564CB661.9040106@redhat.com> References: <563A2158.80009@redhat.com> <56404F9E.4090606@redhat.com> <56448D06.3020700@redhat.com> <564CB661.9040106@redhat.com> Message-ID: <564D9EDE.9040001@redhat.com> On 18.11.2015 18:33, Petr Spacek wrote: > On 12.11.2015 13:58, Martin Basti wrote: >> >> On 09.11.2015 08:47, Petr Spacek wrote: >>> On 4.11.2015 16:16, Martin Basti wrote: >>>> Patch attached. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5421 >>> I'm not entirely sure how this patch will interact with magic included in >>> ipalib/plugins/dns.py:class dns_resolve(Command). >>> >>> I would like to delete the 'normalization' from at least one of these places. >>> >>> Also, as you know, DNS names are not strings and should be manipulated using >>> python-dns so all crazy things in DNS names do not break in weird corner cases. >>> >> Updated patch attached. > Hmm, you bravely ignored my comment about class dns_resolve(Command) above, > sooo: NACK. > > As far as I can tell ipalib/plugins/dns.py:class dns_resolve(Command) behaves > in the same brain-dead way as original is_host_resolvable() function. Please > fix both, not just one. > If you are sure that the behavior of the dns-resolve is bad, then updated patch that removes the code which appending the api.env.domain to query. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0344.3-Use-absolute-domain-in-detection-of-A-AAAA-records.patch Type: text/x-patch Size: 2332 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 19 10:11:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 Nov 2015 11:11:04 +0100 Subject: [Freeipa-devel] [PATCH 0351] call directly is_host_resolvable function to verify addresses in NS records Message-ID: <564DA038.7020404@redhat.com> Testing if address is resolvable can be done by directly call of is_host_resovable, instead of call the dns-resolve command which is doing the same (works as proxy). Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0351-Call-directly-function-is_host_resolvable-instead-do.patch Type: text/x-patch Size: 1052 bytes Desc: not available URL: From jcholast at redhat.com Thu Nov 19 10:18:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 11:18:14 +0100 Subject: [Freeipa-devel] [PATCH 508] install: export KRA agent PEM file in ipa-kra-install In-Reply-To: <564D9DE4.8030808@redhat.com> References: <564D8328.2020703@redhat.com> <564D9DE4.8030808@redhat.com> Message-ID: <564DA1E6.8020101@redhat.com> On 19.11.2015 11:01, Martin Babinsky wrote: > On 11/19/2015 09:07 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK Thanks. Pushed to: master: 164fb7b1d19ef316d2ec55a8f85876ccf310544f ipa-4-2: 9d4f383a94b28d415396e1529c747c5e5bbdbc0f -- Jan Cholasta From mbabinsk at redhat.com Thu Nov 19 10:23:14 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 Nov 2015 11:23:14 +0100 Subject: [Freeipa-devel] [PATCH 0097] fix critical error messages when adding KRA container that already exists In-Reply-To: <564D9B65.1020004@redhat.com> References: <564D9B65.1020004@redhat.com> Message-ID: <564DA312.3010407@redhat.com> On 11/19/2015 10:50 AM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5346 > > > Attaching updated patches. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0097.1-suppress-errors-arising-from-adding-existing-LDAP-en.patch Type: text/x-patch Size: 2513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0097.1-suppress-errors-arising-from-adding-existing-LDAP-en.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 19 11:54:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 Nov 2015 12:54:29 +0100 Subject: [Freeipa-devel] [PATCH 0331, 0337] User plugin: allow multiple managers per user - CLI part In-Reply-To: <564C94F5.1030209@redhat.com> References: <56264855.50606@redhat.com> <56264AA6.5010003@redhat.com> <56266FCF.80909@redhat.com> <562F832B.4060303@redhat.com> <56447A67.8070607@redhat.com> <564C94F5.1030209@redhat.com> Message-ID: <564DB875.4040007@redhat.com> On 18.11.2015 16:10, Martin Basti wrote: > > > On 12.11.2015 12:39, Martin Basti wrote: >> >> >> On 27.10.2015 14:59, Martin Basti wrote: >>> >>> >>> On 20.10.2015 18:46, Martin Basti wrote: >>>> >>>> >>>> On 20.10.2015 16:07, Martin Basti wrote: >>>>> >>>>> >>>>> On 20.10.2015 15:57, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5344 >>>>>> >>>>>> Patch attached. >>>>>> >>>>>> Test are failing, a fix in UserTracker has to be done (partially >>>>>> in my patch 329) >>>>>> >>>>>> >>>>> SelfNACK, I forgot to add stageuser tests >>>>> >>>>> >>>> Updated patch attached. >>>> >>>> I extracted tests to the separate patch, tests do not work, I had >>>> issues with user and stageuser trackers. >>>> >>>> >>>> >>> Patch to fix issues with --addattr and managers added and attached. >>> >>> >> >> The new one patch 0331 attached, patch 0337 is not needed anymore. >> >> This patch also fixes https://fedorahosted.org/freeipa/ticket/5387 >> >> > updated patch attached. > > updated patch attached -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0331.5-Allow-multiple-managers-per-user-CLI-part.patch Type: text/x-patch Size: 15574 bytes Desc: not available URL: From dkupka at redhat.com Thu Nov 19 12:01:35 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 19 Nov 2015 13:01:35 +0100 Subject: [Freeipa-devel] [PATCH 506] cert renewal: make renewal of ipaCert atomic In-Reply-To: <564C78E2.9040406@redhat.com> References: <56407B01.4090804@redhat.com> <5640C0F5.7090404@redhat.com> <5641BB2C.10103@redhat.com> <56423547.5080207@redhat.com> <564C78E2.9040406@redhat.com> Message-ID: <564DBA1F.3070606@redhat.com> On 18/11/15 14:10, Jan Cholasta wrote: > On 10.11.2015 19:19, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 9.11.2015 16:51, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>>> >>>>> >>>>> >>>> >>>> There be a note in renew_ra_cert that the lock is obtained in >>>> advance by >>>> renew_ra_cert_pre. >>> >>> Added comment. >>> >>>> >>>> It looks like it will silently fail if the lock cannot be acquired. Is >>>> that desired? >>> >>> All unhandled exceptions are logged to syslog in both renew_ra_cert_pre >>> and renew_ra_cert: >>> >>> try: >>> main() >>> except Exception: >>> syslog.syslog(syslog.LOG_ERR, traceback.format_exc()) >>> >>> Updated patch attached. >>> >> >> My confusion was with the auto-expiration. I guess this is ok. When >> debugging this sort of thing via logs the more the merrier, so I guess >> I'd have added a syslog to say "obtaining lock" or "locked" and then >> something when the renewal actually starts, so one can try to piece >> together what happened after the fact if something goes wrong. >> >> I guess certmonger already logs when a pre/post command is executed so >> that may already be available. > > Yes. The ticket is not related to logging anyway. > > Is the last patch OK, then? > Thanks for the patch. Works for me, ACK. -- David Kupka From jcholast at redhat.com Thu Nov 19 12:07:16 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 13:07:16 +0100 Subject: [Freeipa-devel] [PATCH 506] cert renewal: make renewal of ipaCert atomic In-Reply-To: <564DBA1F.3070606@redhat.com> References: <56407B01.4090804@redhat.com> <5640C0F5.7090404@redhat.com> <5641BB2C.10103@redhat.com> <56423547.5080207@redhat.com> <564C78E2.9040406@redhat.com> <564DBA1F.3070606@redhat.com> Message-ID: <564DBB74.4020109@redhat.com> On 19.11.2015 13:01, David Kupka wrote: > On 18/11/15 14:10, Jan Cholasta wrote: >> On 10.11.2015 19:19, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 9.11.2015 16:51, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes >>>>>> . >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> >>>>> >>>>> There be a note in renew_ra_cert that the lock is obtained in >>>>> advance by >>>>> renew_ra_cert_pre. >>>> >>>> Added comment. >>>> >>>>> >>>>> It looks like it will silently fail if the lock cannot be acquired. Is >>>>> that desired? >>>> >>>> All unhandled exceptions are logged to syslog in both renew_ra_cert_pre >>>> and renew_ra_cert: >>>> >>>> try: >>>> main() >>>> except Exception: >>>> syslog.syslog(syslog.LOG_ERR, traceback.format_exc()) >>>> >>>> Updated patch attached. >>>> >>> >>> My confusion was with the auto-expiration. I guess this is ok. When >>> debugging this sort of thing via logs the more the merrier, so I guess >>> I'd have added a syslog to say "obtaining lock" or "locked" and then >>> something when the renewal actually starts, so one can try to piece >>> together what happened after the fact if something goes wrong. >>> >>> I guess certmonger already logs when a pre/post command is executed so >>> that may already be available. >> >> Yes. The ticket is not related to logging anyway. >> >> Is the last patch OK, then? >> > > Thanks for the patch. Works for me, ACK. Pushed to: master: f3076c6ab37e081ba9b0ec9f0502379f60dfbd10 ipa-4-2: f831cb6a3da0c5f2a3e71004ae327273b25723fa -- Jan Cholasta From mbasti at redhat.com Thu Nov 19 12:08:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 Nov 2015 13:08:53 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564C7C74.3030607@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> <564C7C74.3030607@redhat.com> Message-ID: <564DBBD5.6040805@redhat.com> On 18.11.2015 14:26, Martin Basti wrote: > > > On 18.11.2015 14:24, Martin Kosek wrote: >> On 11/18/2015 02:18 PM, Martin Basti wrote: >>> >>> On 18.11.2015 13:55, Martin Kosek wrote: >>>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>>> + DEFAULT_TIME_LIMIT = -1.0 >>>>> + DEFAULT_SIZE_LIMIT = 0 >>>> ... >>>>> if time_limit is None or time_limit == 0: >>>>> - time_limit = -1.0 >>>>> + if self.time_limit is not None and self.time_limit != 0: >>>>> + time_limit = self.time_limit >>>>> + else: >>>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>>> + >>>> I wonder why is the -1 default time limit a float number, I would >>>> expect that >>>> some trouble may emerge out of it. Maybe Rob knows? >>>> >>> Python LDAP allows to have smaller granularity than seconds and it >>> internally >>> convert time limit values to float. >> Hm, ok. I was just curious since the value we expose in API is Int >> and the >> default does not use the smaller granularity, so I was thinking "Why >> bother?". >> If it is fixed in your patch, good. If not, good also, no need to >> bikeshed here >> I suppose. > I just keep the original values there, I do not want to touch it with > this patch > Updated patch attached, the original one has wrong default limit for ldap2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0350.2-Upgrade-increase-time-limit-for-upgrades.patch Type: text/x-patch Size: 9813 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 19 12:29:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 Nov 2015 13:29:38 +0100 Subject: [Freeipa-devel] [PATCH 0352] fix caching in get_ipa_config Message-ID: <564DC0B2.3030908@redhat.com> https://fedorahosted.org/freeipa/ticket/5463 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0352-fix-caching-in-get_ipa_config.patch Type: text/x-patch Size: 1023 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Nov 19 13:09:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 Nov 2015 14:09:34 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564DBBD5.6040805@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> <564C7C74.3030607@redhat.com> <564DBBD5.6040805@redhat.com> Message-ID: <564DCA0E.40304@redhat.com> On 11/19/2015 01:08 PM, Martin Basti wrote: > > > On 18.11.2015 14:26, Martin Basti wrote: >> >> >> On 18.11.2015 14:24, Martin Kosek wrote: >>> On 11/18/2015 02:18 PM, Martin Basti wrote: >>>> >>>> On 18.11.2015 13:55, Martin Kosek wrote: >>>>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>>>> + DEFAULT_TIME_LIMIT = -1.0 >>>>>> + DEFAULT_SIZE_LIMIT = 0 >>>>> ... >>>>>> if time_limit is None or time_limit == 0: >>>>>> - time_limit = -1.0 >>>>>> + if self.time_limit is not None and self.time_limit != 0: >>>>>> + time_limit = self.time_limit >>>>>> + else: >>>>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>>>> + >>>>> I wonder why is the -1 default time limit a float number, I would >>>>> expect that >>>>> some trouble may emerge out of it. Maybe Rob knows? >>>>> >>>> Python LDAP allows to have smaller granularity than seconds and it >>>> internally >>>> convert time limit values to float. >>> Hm, ok. I was just curious since the value we expose in API is Int >>> and the >>> default does not use the smaller granularity, so I was thinking "Why >>> bother?". >>> If it is fixed in your patch, good. If not, good also, no need to >>> bikeshed here >>> I suppose. >> I just keep the original values there, I do not want to touch it with >> this patch >> > Updated patch attached, the original one has wrong default limit for ldap2 > > ACK -- Martin^3 Babinsky From jcholast at redhat.com Thu Nov 19 13:13:31 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 14:13:31 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564DCA0E.40304@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> <564C7C74.3030607@redhat.com> <564DBBD5.6040805@redhat.com> <564DCA0E.40304@redhat.com> Message-ID: <564DCAFB.3050602@redhat.com> On 19.11.2015 14:09, Martin Babinsky wrote: > On 11/19/2015 01:08 PM, Martin Basti wrote: >> >> >> On 18.11.2015 14:26, Martin Basti wrote: >>> >>> >>> On 18.11.2015 14:24, Martin Kosek wrote: >>>> On 11/18/2015 02:18 PM, Martin Basti wrote: >>>>> >>>>> On 18.11.2015 13:55, Martin Kosek wrote: >>>>>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>>>>> + DEFAULT_TIME_LIMIT = -1.0 >>>>>>> + DEFAULT_SIZE_LIMIT = 0 >>>>>> ... >>>>>>> if time_limit is None or time_limit == 0: >>>>>>> - time_limit = -1.0 >>>>>>> + if self.time_limit is not None and self.time_limit >>>>>>> != 0: >>>>>>> + time_limit = self.time_limit >>>>>>> + else: >>>>>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>>>>> + >>>>>> I wonder why is the -1 default time limit a float number, I would >>>>>> expect that >>>>>> some trouble may emerge out of it. Maybe Rob knows? >>>>>> >>>>> Python LDAP allows to have smaller granularity than seconds and it >>>>> internally >>>>> convert time limit values to float. >>>> Hm, ok. I was just curious since the value we expose in API is Int >>>> and the >>>> default does not use the smaller granularity, so I was thinking "Why >>>> bother?". >>>> If it is fixed in your patch, good. If not, good also, no need to >>>> bikeshed here >>>> I suppose. >>> I just keep the original values there, I do not want to touch it with >>> this patch >>> >> Updated patch attached, the original one has wrong default limit for >> ldap2 >> >> > ACK Hold your horses. -- Jan Cholasta From jcholast at redhat.com Thu Nov 19 13:31:13 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 14:31:13 +0100 Subject: [Freeipa-devel] [PATCH 0097] fix critical error messages when adding KRA container that already exists In-Reply-To: <564DA312.3010407@redhat.com> References: <564D9B65.1020004@redhat.com> <564DA312.3010407@redhat.com> Message-ID: <564DCF21.50706@redhat.com> On 19.11.2015 11:23, Martin Babinsky wrote: > On 11/19/2015 10:50 AM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5346 >> >> >> > Attaching updated patches. 1) It seems the self._ldap_disconnect() was actually necessary: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket': The ipa-kra-install command failed. See /var/log/ipaserver-kra-install.log for more information After re-adding it, ipa-kra-install works again. 2) I don't want to see any messages when there's nothing wrong: [7/8]: add vault container Vault container already exists Please lower the log level of this message from info to debug. -- Jan Cholasta From mbabinsk at redhat.com Thu Nov 19 13:47:46 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 Nov 2015 14:47:46 +0100 Subject: [Freeipa-devel] [PATCH 0097] fix critical error messages when adding KRA container that already exists In-Reply-To: <564DCF21.50706@redhat.com> References: <564D9B65.1020004@redhat.com> <564DA312.3010407@redhat.com> <564DCF21.50706@redhat.com> Message-ID: <564DD302.7040409@redhat.com> On 11/19/2015 02:31 PM, Jan Cholasta wrote: > On 19.11.2015 11:23, Martin Babinsky wrote: >> On 11/19/2015 10:50 AM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5346 >>> >>> >>> >> Attaching updated patches. > > 1) It seems the self._ldap_disconnect() was actually necessary: > > cannot connect to > 'ldapi://%2fvar%2frun%2fslapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket': > The ipa-kra-install command failed. See > /var/log/ipaserver-kra-install.log for more information > > After re-adding it, ipa-kra-install works again. > > > 2) I don't want to see any messages when there's nothing wrong: > > [7/8]: add vault container > Vault container already exists > > Please lower the log level of this message from info to debug. > OK, attaching updated patches. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0097.2-suppress-errors-arising-from-adding-existing-LDAP-en.patch Type: text/x-patch Size: 2702 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0097.2-suppress-errors-arising-from-adding-existing-LDAP-en.patch Type: text/x-patch Size: 2718 bytes Desc: not available URL: From dkupka at redhat.com Thu Nov 19 13:56:41 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 19 Nov 2015 14:56:41 +0100 Subject: [Freeipa-devel] [PATCH 0332] fix user post_callback In-Reply-To: <564479C4.7010305@redhat.com> References: <56275786.8090504@redhat.com> <564479C4.7010305@redhat.com> Message-ID: <564DD519.3090903@redhat.com> On 12/11/15 12:36, Martin Basti wrote: > > > On 21.10.2015 11:14, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5387 >> >> Patch attached. >> >> > > Fix for this ticket has been implemented in patch mbasti-0331-2 > > Attached patch contains only common postcallback code to from user and > stageuser to parent class. > > > Works for me, ACK. -- David Kupka From dkupka at redhat.com Thu Nov 19 13:57:04 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 19 Nov 2015 14:57:04 +0100 Subject: [Freeipa-devel] [PATCH 0331, 0337] User plugin: allow multiple managers per user - CLI part In-Reply-To: <564DB875.4040007@redhat.com> References: <56264855.50606@redhat.com> <56264AA6.5010003@redhat.com> <56266FCF.80909@redhat.com> <562F832B.4060303@redhat.com> <56447A67.8070607@redhat.com> <564C94F5.1030209@redhat.com> <564DB875.4040007@redhat.com> Message-ID: <564DD530.7070603@redhat.com> On 19/11/15 12:54, Martin Basti wrote: > > > On 18.11.2015 16:10, Martin Basti wrote: >> >> >> On 12.11.2015 12:39, Martin Basti wrote: >>> >>> >>> On 27.10.2015 14:59, Martin Basti wrote: >>>> >>>> >>>> On 20.10.2015 18:46, Martin Basti wrote: >>>>> >>>>> >>>>> On 20.10.2015 16:07, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 20.10.2015 15:57, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5344 >>>>>>> >>>>>>> Patch attached. >>>>>>> >>>>>>> Test are failing, a fix in UserTracker has to be done (partially >>>>>>> in my patch 329) >>>>>>> >>>>>>> >>>>>> SelfNACK, I forgot to add stageuser tests >>>>>> >>>>>> >>>>> Updated patch attached. >>>>> >>>>> I extracted tests to the separate patch, tests do not work, I had >>>>> issues with user and stageuser trackers. >>>>> >>>>> >>>>> >>>> Patch to fix issues with --addattr and managers added and attached. >>>> >>>> >>> >>> The new one patch 0331 attached, patch 0337 is not needed anymore. >>> >>> This patch also fixes https://fedorahosted.org/freeipa/ticket/5387 >>> >>> >> updated patch attached. >> >> > updated patch attached > Works for me, ACK. -- David Kupka From jcholast at redhat.com Thu Nov 19 14:05:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 15:05:14 +0100 Subject: [Freeipa-devel] [PATCH 0097] fix critical error messages when adding KRA container that already exists In-Reply-To: <564DD302.7040409@redhat.com> References: <564D9B65.1020004@redhat.com> <564DA312.3010407@redhat.com> <564DCF21.50706@redhat.com> <564DD302.7040409@redhat.com> Message-ID: <564DD71A.3060702@redhat.com> On 19.11.2015 14:47, Martin Babinsky wrote: > On 11/19/2015 02:31 PM, Jan Cholasta wrote: >> On 19.11.2015 11:23, Martin Babinsky wrote: >>> On 11/19/2015 10:50 AM, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5346 >>>> >>>> >>>> >>> Attaching updated patches. >> >> 1) It seems the self._ldap_disconnect() was actually necessary: >> >> cannot connect to >> 'ldapi://%2fvar%2frun%2fslapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket': >> The ipa-kra-install command failed. See >> /var/log/ipaserver-kra-install.log for more information >> >> After re-adding it, ipa-kra-install works again. >> >> >> 2) I don't want to see any messages when there's nothing wrong: >> >> [7/8]: add vault container >> Vault container already exists >> >> Please lower the log level of this message from info to debug. >> > OK, attaching updated patches. > Thanks, ACK. Pushed to: master: 4d59a711af2b5b5e3441116f6d18d54ec9eccfb8 ipa-4-2: f2a7a3ee011263ae95982c875f3e9d9c5091438c -- Jan Cholasta From jcholast at redhat.com Thu Nov 19 14:43:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 15:43:35 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication Message-ID: <564DE017.4020408@redhat.com> Hi, the attached patches fix and . I worked around the issue of checking if the user is privileged to perform replica promotion by using host credentials instead. The host must be a member of the IPA servers host group "ipaservers" in order to be able to promote itself. Using host credentials will also allow replica install using one-time password. User credentials are still used for connection check and to automatically add the host to ipaservers if the user is privileged to do that. Simo, is this approach OK? Could you check the new ACIs in patches 510 and 513? I have a couple of questions: 1) Why are custodia keys for the replica added to LDAP using connection to the remote master instead of local ldapi connection? Is it to eliminate race conditions caused by replication timeout from the replica to the remote master? If the code was changed to use ldapi and wait until the key appears in custodia on the remote master, we could lose the "IPA server hosts can create own Custodia secrets" and "IPA server hosts can manage own Custodia secrets" ACIs from patch 510. Not sure if it's worth the change though. 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? If 'member' was used instead, we would gain referential integrity and the ability to add ACIs based on the attribute (think userattr="member#USERDN"). 3) Why is 'memberPrincipal' used in cn=custodia at all? The hostname of the replica is already in 'cn', so instead of searching cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we could get cn={enc,sig}/$HOSTNAME,cn=custodia directly. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-509-aci-add-IPA-servers-host-group-ipaservers.patch Type: text/x-patch Size: 20954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-510-aci-allow-members-of-ipaservers-to-set-up-replicatio.patch Type: text/x-patch Size: 3270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-511-ipautil-use-file-in-a-temporary-dir-as-ccache-in-pri.patch Type: text/x-patch Size: 1314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-512-replica-promotion-use-host-credentials-when-setting-.patch Type: text/x-patch Size: 4976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-513-aci-allow-hosts-to-do-replica-promotion-checks.patch Type: text/x-patch Size: 2747 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-514-replica-promotion-automatically-add-the-local-host-t.patch Type: text/x-patch Size: 3141 bytes Desc: not available URL: From jcholast at redhat.com Thu Nov 19 15:44:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Nov 2015 16:44:10 +0100 Subject: [Freeipa-devel] [PATCH 0352] fix caching in get_ipa_config In-Reply-To: <564DC0B2.3030908@redhat.com> References: <564DC0B2.3030908@redhat.com> Message-ID: <564DEE4A.5050104@redhat.com> On 19.11.2015 13:29, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5463 > > Patch attached. Thanks, ACK. Pushed to: master: 7f0d018c66da1fe2adedd45aa9f5a63c913e4527 ipa-4-2: 0ca4c1db3ee6d9366f447d0d704fa56d98e366b4 -- Jan Cholasta From dkupka at redhat.com Thu Nov 19 16:28:53 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 19 Nov 2015 17:28:53 +0100 Subject: [Freeipa-devel] [PATCH 0067] ipa-cacert-renew: Fix connection to ldap. Message-ID: <564DF8C5.9090706@redhat.com> https://fedorahosted.org/freeipa/ticket/5468 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0067-ipa-cacert-renew-Fix-connection-to-ldap.patch Type: text/x-patch Size: 883 bytes Desc: not available URL: From simo at redhat.com Thu Nov 19 16:43:54 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Nov 2015 11:43:54 -0500 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <564DE017.4020408@redhat.com> References: <564DE017.4020408@redhat.com> Message-ID: <1447951434.5132.27.camel@redhat.com> On Thu, 2015-11-19 at 15:43 +0100, Jan Cholasta wrote: > Hi, > > the attached patches fix > and . > > I worked around the issue of checking if the user is privileged to > perform replica promotion by using host credentials instead. The host > must be a member of the IPA servers host group "ipaservers" in order to > be able to promote itself. Using host credentials will also allow > replica install using one-time password. > > User credentials are still used for connection check and to > automatically add the host to ipaservers if the user is privileged to do > that. > > Simo, is this approach OK? Could you check the new ACIs in patches 510 > and 513? > > I have a couple of questions: > > 1) Why are custodia keys for the replica added to LDAP using connection > to the remote master instead of local ldapi connection? Is it to > eliminate race conditions caused by replication timeout from the replica > to the remote master? Yes it is critical for that reason. > If the code was changed to use ldapi and wait until the key appears in > custodia on the remote master, we could lose the "IPA server hosts can > create own Custodia secrets" and "IPA server hosts can manage own > Custodia secrets" ACIs from patch 510. Not sure if it's worth the change > though. Not worth the change, as it has the same security properties. > 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? > > If 'member' was used instead, we would gain referential integrity and > the ability to add ACIs based on the attribute (think > userattr="member#USERDN"). To avoid referential integrity and mixup with other group objects, it was intentional. > 3) Why is 'memberPrincipal' used in cn=custodia at all? > > The hostname of the replica is already in 'cn', so instead of searching > cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we > could get cn={enc,sig}/$HOSTNAME,cn=custodia directly. They idea was to be flexible, in a future we might have some shared keys, then the only way to properly resolve keys would be to use a multivalued attribute. Or we may want to have multiple keys sets for the same principal (it doesn't have to be a host technically, it could be a service or even a user in the future), and a naming based convention would make it harder to deal with that. On the patches -- 509: - commit says only: "aci: add IPA servers host group 'ipaservers'" but it does other things like changing how CA renewal certificate acis are added, I think that must be separated in another patch. - Why "Manage Host Keytab" aci has been changed to exclude ipaservers ? - Why adding the host to the ipaservers group is done in the krbinstance ? I would expect LDAP ops to be mostly done in the DSinstance. - I do not see where the host is added to the ipaservers group on upgrade. 510: - We should probably tightenup the ACI to allos host X to only add memberPrincipal = X and no other value, also the host should not be allowed to change the memberPrincipal attribute only the keys. If we can't express this in ACIs we can live with the ones you propose though. 511: ack, but I think you should catch potential exceptions from the os.rmdir, as it will throw if there is some other file in the dir (for whatever reason). The exception can be safely ignored, we just do not want to blow up with a traceback here. 512: - I do not think this is correct, it seem to me you are overriding the local ccache (if any) with the host keytab. If I read this right, this means that if you run kinit admin && ipa-replica-install then you will kind your admin credentials gone and a host TGT instead. Am I reading this change correctly ? 513: Nack - Should be folded into 510 - Should not allow all hosts in the domain but only ipaservers for aal three changes 514: - Should be folded in 512, they are completely interdependent changes. - I do not understand how this works. promote_check() runs before promote() and will fail if the host is not already in the ipaservers group, so you will never be able to actually add the host to the group ? sounds like chicken-egg ... or what am I missing ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Thu Nov 19 17:19:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 19 Nov 2015 18:19:58 +0100 Subject: [Freeipa-devel] [PATCH 0098-0099] domain level 1 topology checks during IPA server uninstall Message-ID: <564E04BE.1020304@redhat.com> These two patches fix the following tickets: https://fedorahosted.org/freeipa/ticket/5377 https://fedorahosted.org/freeipa/ticket/5409 I have added a new option '--ignore-disconnected-topology' which forces IPA master uninstall despite reported errors in topology. I'm not quite sure if we want to flood ipa-server-install with uninstall-specific options, maybe it is better to skip the check in unattended mode and just print a warning about disconnected topology and what to do about it. I would like to hear your opinions about this. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0099-implement-domain-level-1-specific-topology-checks-in.patch Type: text/x-patch Size: 11171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0098-extract-domain-level-1-topology-checking-code-from-i.patch Type: text/x-patch Size: 10443 bytes Desc: not available URL: From jcholast at redhat.com Fri Nov 20 07:29:47 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Nov 2015 08:29:47 +0100 Subject: [Freeipa-devel] [PATCH 0067] ipa-cacert-renew: Fix connection to ldap. In-Reply-To: <564DF8C5.9090706@redhat.com> References: <564DF8C5.9090706@redhat.com> Message-ID: <564ECBEB.2090505@redhat.com> On 19.11.2015 17:28, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/5468 ipa-cacert-manage is not the only code which uses ldap2 this way. It would be better to find the root cause of this rather than working around it. -- Jan Cholasta From jcholast at redhat.com Fri Nov 20 08:00:04 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Nov 2015 09:00:04 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564DCAFB.3050602@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> <564C7C74.3030607@redhat.com> <564DBBD5.6040805@redhat.com> <564DCA0E.40304@redhat.com> <564DCAFB.3050602@redhat.com> Message-ID: <564ED304.4020000@redhat.com> On 19.11.2015 14:13, Jan Cholasta wrote: > On 19.11.2015 14:09, Martin Babinsky wrote: >> On 11/19/2015 01:08 PM, Martin Basti wrote: >>> >>> >>> On 18.11.2015 14:26, Martin Basti wrote: >>>> >>>> >>>> On 18.11.2015 14:24, Martin Kosek wrote: >>>>> On 11/18/2015 02:18 PM, Martin Basti wrote: >>>>>> >>>>>> On 18.11.2015 13:55, Martin Kosek wrote: >>>>>>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>>>>>> + DEFAULT_TIME_LIMIT = -1.0 >>>>>>>> + DEFAULT_SIZE_LIMIT = 0 >>>>>>> ... >>>>>>>> if time_limit is None or time_limit == 0: >>>>>>>> - time_limit = -1.0 >>>>>>>> + if self.time_limit is not None and self.time_limit >>>>>>>> != 0: >>>>>>>> + time_limit = self.time_limit >>>>>>>> + else: >>>>>>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>>>>>> + >>>>>>> I wonder why is the -1 default time limit a float number, I would >>>>>>> expect that >>>>>>> some trouble may emerge out of it. Maybe Rob knows? >>>>>>> >>>>>> Python LDAP allows to have smaller granularity than seconds and it >>>>>> internally >>>>>> convert time limit values to float. >>>>> Hm, ok. I was just curious since the value we expose in API is Int >>>>> and the >>>>> default does not use the smaller granularity, so I was thinking "Why >>>>> bother?". >>>>> If it is fixed in your patch, good. If not, good also, no need to >>>>> bikeshed here >>>>> I suppose. >>>> I just keep the original values there, I do not want to touch it with >>>> this patch >>>> >>> Updated patch attached, the original one has wrong default limit for >>> ldap2 >>> >>> >> ACK > > Hold your horses. 1) The upgrade_ldapsearch_limit option is not very useful, either add generic search_time_limit and search_records_limit options, or don't add any options at all (which, incidentally, is exactly what the ticket asks for). 2) The limits are not passed to the connection using __init__() anywhere, so there is no need to have arguments for them. 3) Rather than adding layers of if statements everywhere, implement the time_limit and size_limit attributes as properties. 4) Use config_entry.single_value when setting defaults in ldap2.get_ipa_config(). BTW, add comments only when it's not obvious what the code does - a comment saying "set defaults" above two .setdefault() calls is pretty redundant. -- Jan Cholasta From jcholast at redhat.com Fri Nov 20 08:56:36 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Nov 2015 09:56:36 +0100 Subject: [Freeipa-devel] [PATCH 515] client install: do not corrupt OpenSSH config with Match sections Message-ID: <564EE044.2060705@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-515-client-install-do-not-corrupt-OpenSSH-config-with-Ma.patch Type: text/x-patch Size: 1950 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 20 09:19:10 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 10:19:10 +0100 Subject: [Freeipa-devel] [PATCH 0100] replica promotion: modify default.conf even if DS configuration fails Message-ID: <564EE58E.6080605@redhat.com> Fixes https://fedorahosted.org/freeipa/ticket/5417 -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Nov 20 09:46:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 10:46:58 +0100 Subject: [Freeipa-devel] [PATCH 0100] replica promotion: modify default.conf even if DS configuration fails In-Reply-To: <564EE58E.6080605@redhat.com> References: <564EE58E.6080605@redhat.com> Message-ID: <564EEC12.5090107@redhat.com> On 11/20/2015 10:19 AM, Martin Babinsky wrote: > Fixes https://fedorahosted.org/freeipa/ticket/5417 > Sorry forgot to add the patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0100-replica-promotion-modify-default.conf-even-if-DS-con.patch Type: text/x-patch Size: 3994 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 20 11:13:14 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 12:13:14 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0006] Add comments to stageuser plugin tests In-Reply-To: <564D97AC.6050901@redhat.com> References: <564C7A23.5010500@redhat.com> <564C9E77.4050406@redhat.com> <564D88AF.8010500@redhat.com> <564D97AC.6050901@redhat.com> Message-ID: <564F004A.2060806@redhat.com> On 11/19/2015 10:34 AM, Petr Viktorin wrote: > On 11/19/2015 09:30 AM, Lenka Doudova wrote: >> On 11/18/2015 04:51 PM, Martin Babinsky wrote: >>> On 11/18/2015 02:16 PM, Lenka Doudova wrote: >>>> Hi, >>>> >>>> here's a patch that adds a few comments to stageuser tests in order to >>>> allow easier determining of a problem when tests fail. >>>> >>>> Lenka >>>> >>>> >>> >>> Hi Lenka, >>> >>> Firstly a technical detail: Python indexes lists from 0, so the >>> comments in 'options_ok' do not correctly map to the test names anyway. >>> >>> I am also not sure if this patch is worth reviewing and pushing as it >>> IMHO doesn't help in the identification of failed tests at all. >>> >>> This should be solved at more fundamental level. >>> >> Ouch, good point, I didn't realize. Sorry. >> >> Anyway, the issue is that even if tests are run in verbose mode, you get >> output like this: >> >> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser27] >> PASSED >> >> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser28] >> PASSED >> >> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser29] >> PASSED >> >> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser210] >> PASSED >> >> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser211] >> PASSED >> >> ipatests/test_xmlrpc/test_stageuser_plugin.py::TestStagedUser::test_create_attr[stageduser212] >> PASSED >> >> >> If some test fails, you can't really tell which command was the one >> responsible for the fail. This should be solved by >> https://fedorahosted.org/freeipa/ticket/5449. Until that's done, though, >> the only way to find out which command failed is looking at the code and >> finding which parameters were put into the command, which was not much >> possible without better commenting the test case (as I realized last >> week when David Kupka asked me to help him find the reason for failed >> tests). >> Obviously I can rewrite the tests so there's 27 separate test cases, one >> for each parameter, instead of one method that 'unwraps' into 27 test >> cases, which would entirely eliminate the confusion. So far I don't know >> of a way to put 27 similar test cases in one method which would allow >> easy recognition of the test cases. >> I'll wait with fixing the patch until further discussion. > > Hello, > Pytest wants you to be a bit more explicit about how to name the > parameters. (It "hides" dicts by default, because large dicts would make > the output even more confusing than the numbers.) > > Please try the attached patch. > Docs are at https://pytest.org/latest/fixture.html#parametrizing-a-fixture > > > This looks like a better approach IMHO, you can then see which attribute/value was being checked. I would very much favor more descriptive test/fixture names in the beginning. -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Nov 20 11:15:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 12:15:58 +0100 Subject: [Freeipa-devel] [PATCH 515] client install: do not corrupt OpenSSH config with Match sections In-Reply-To: <564EE044.2060705@redhat.com> References: <564EE044.2060705@redhat.com> Message-ID: <564F00EE.7060007@redhat.com> On 11/20/2015 09:56 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From jcholast at redhat.com Fri Nov 20 11:29:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Nov 2015 12:29:23 +0100 Subject: [Freeipa-devel] [PATCH 515] client install: do not corrupt OpenSSH config with Match sections In-Reply-To: <564F00EE.7060007@redhat.com> References: <564EE044.2060705@redhat.com> <564F00EE.7060007@redhat.com> Message-ID: <564F0413.4090906@redhat.com> On 20.11.2015 12:15, Martin Babinsky wrote: > On 11/20/2015 09:56 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK Thanks. Pushed to: master: 2d041daf17a4c461489cdd0879056d0cb5eacde5 ipa-4-2: f3b04d5fd8f001631d4434737cca32d9b235a01d -- Jan Cholasta From fskola at redhat.com Fri Nov 20 12:56:36 2015 From: fskola at redhat.com (Filip =?UTF-8?B?xaBrb2xh?=) Date: Fri, 20 Nov 2015 13:56:36 +0100 Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin Message-ID: <20151120135636.71171d5c@vor2.netbox.priv> Another one. F. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0002-Refactor-test_group_plugin.patch Type: text/x-patch Size: 73005 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 20 13:34:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Nov 2015 14:34:37 +0100 Subject: [Freeipa-devel] [PATCH 0353] upgrade: fix migration of old dns forward zones Message-ID: <564F216D.2080703@redhat.com> https://fedorahosted.org/freeipa/ticket/5472 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0353-upgrade-fix-migration-of-old-dns-forward-zones.patch Type: text/x-patch Size: 9518 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 20 13:37:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Nov 2015 14:37:14 +0100 Subject: [Freeipa-devel] [PATCH 0354] Remove forgotten print in DNS plugin Message-ID: <564F220A.8060304@redhat.com> patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0354-remove-forgotten-print-in-DNS-plugin.patch Type: text/x-patch Size: 924 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 20 13:43:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Nov 2015 14:43:37 +0100 Subject: [Freeipa-devel] [PATCH 0353] upgrade: fix migration of old dns forward zones In-Reply-To: <564F216D.2080703@redhat.com> References: <564F216D.2080703@redhat.com> Message-ID: <564F2389.5080601@redhat.com> On 20.11.2015 14:34, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5472 > > Patch attached. > > I forgot to attached rebased patch for ipa-4-2 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0353-upgrade-fix-migration-of-old-dns-forward-zones.patch Type: text/x-patch Size: 9518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ipa42-mbasti-0353-upgrade-fix-migration-of-old-dns-forward-zones.patch Type: text/x-patch Size: 9443 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 20 13:51:25 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 14:51:25 +0100 Subject: [Freeipa-devel] [PATCH 0101] raise more descriptive Backend connection-related exceptions Message-ID: <564F255D.8020008@redhat.com> Fixes https://fedorahosted.org/freeipa/ticket/5473 Patch is for master only, I will rebase it for 4-2 if we decide that it can land there as well. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0101-raise-more-descriptive-Backend-connection-related-ex.patch Type: text/x-patch Size: 4650 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 20 14:33:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Nov 2015 15:33:14 +0100 Subject: [Freeipa-devel] [PATCH 0332] fix user post_callback In-Reply-To: <564DD519.3090903@redhat.com> References: <56275786.8090504@redhat.com> <564479C4.7010305@redhat.com> <564DD519.3090903@redhat.com> Message-ID: <564F2F2A.8060704@redhat.com> On 19.11.2015 14:56, David Kupka wrote: > On 12/11/15 12:36, Martin Basti wrote: >> >> >> On 21.10.2015 11:14, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5387 >>> >>> Patch attached. >>> >>> >> >> Fix for this ticket has been implemented in patch mbasti-0331-2 >> >> Attached patch contains only common postcallback code to from user and >> stageuser to parent class. >> >> >> > Works for me, ACK. > Pushed to master: c56d45bc382a6e72c0439452994e998798b22b57 From mbasti at redhat.com Fri Nov 20 14:36:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Nov 2015 15:36:00 +0100 Subject: [Freeipa-devel] [PATCH 0331, 0337] User plugin: allow multiple managers per user - CLI part In-Reply-To: <564DD530.7070603@redhat.com> References: <56264855.50606@redhat.com> <56264AA6.5010003@redhat.com> <56266FCF.80909@redhat.com> <562F832B.4060303@redhat.com> <56447A67.8070607@redhat.com> <564C94F5.1030209@redhat.com> <564DB875.4040007@redhat.com> <564DD530.7070603@redhat.com> Message-ID: <564F2FD0.90207@redhat.com> On 19.11.2015 14:57, David Kupka wrote: > On 19/11/15 12:54, Martin Basti wrote: >> >> >> On 18.11.2015 16:10, Martin Basti wrote: >>> >>> >>> On 12.11.2015 12:39, Martin Basti wrote: >>>> >>>> >>>> On 27.10.2015 14:59, Martin Basti wrote: >>>>> >>>>> >>>>> On 20.10.2015 18:46, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 20.10.2015 16:07, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 20.10.2015 15:57, Martin Basti wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/5344 >>>>>>>> >>>>>>>> Patch attached. >>>>>>>> >>>>>>>> Test are failing, a fix in UserTracker has to be done (partially >>>>>>>> in my patch 329) >>>>>>>> >>>>>>>> >>>>>>> SelfNACK, I forgot to add stageuser tests >>>>>>> >>>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> I extracted tests to the separate patch, tests do not work, I had >>>>>> issues with user and stageuser trackers. >>>>>> >>>>>> >>>>>> >>>>> Patch to fix issues with --addattr and managers added and attached. >>>>> >>>>> >>>> >>>> The new one patch 0331 attached, patch 0337 is not needed anymore. >>>> >>>> This patch also fixes https://fedorahosted.org/freeipa/ticket/5387 >>>> >>>> >>> updated patch attached. >>> >>> >> updated patch attached >> > > Works for me, ACK. > Pushed to master: 457c9746709042e6f4f8f37a85ca8ad562962405 From mkubik at redhat.com Fri Nov 20 14:44:30 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 20 Nov 2015 15:44:30 +0100 Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package Message-ID: <564F31CE.5010402@redhat.com> Fixes https://fedorahosted.org/freeipa/ticket/5467 Patches attached. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0025-Separated-Tracker-implementations-into-standalone-pa.patch Type: text/x-patch Size: 111791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0025-Separated-Tracker-implementations-into-standalone-pa.patch Type: text/x-patch Size: 111810 bytes Desc: not available URL: From pvoborni at redhat.com Fri Nov 20 14:56:37 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Nov 2015 15:56:37 +0100 Subject: [Freeipa-devel] [PATCH] 927 topology: treat server suffix as multivalued attribute in API Message-ID: <564F34A5.60208@redhat.com> -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0927-topology-treat-server-suffix-as-multivalued-attribut.patch Type: text/x-patch Size: 3408 bytes Desc: not available URL: From pvoborni at redhat.com Fri Nov 20 15:00:07 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Nov 2015 16:00:07 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization Message-ID: <564F3577.9090207@redhat.com> Patches 928-931 are prerequisites. Patches 932-934 implements the visualization Patches 935-936 adds 'add' and 'remove' segment functionality to the visualization page. https://fedorahosted.org/freeipa/ticket/4286 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0936-webui-remove-segments-on-topology-graph-page.patch Type: text/x-patch Size: 4620 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0935-webui-add-segments-on-topology-graph-page.patch Type: text/x-patch Size: 6597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0934-webui-topology-graph-facet.patch Type: text/x-patch Size: 16574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0933-webui-topology-graph-component.patch Type: text/x-patch Size: 15453 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0932-webui-add-d3-library-version-3.5.6.patch Type: text/x-patch Size: 155164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0931-webui-allow-to-update-action_state-directly.patch Type: text/x-patch Size: 1122 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0930-webui-extract-header-and-action-logic-from-facet-to-.patch Type: text/x-patch Size: 12124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0929-webui-split-facet-header-into-two-classes.patch Type: text/x-patch Size: 10466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0928-webui-add-Deferred-Promise-API-to-rpc.command.patch Type: text/x-patch Size: 2434 bytes Desc: not available URL: From redhatrises at gmail.com Fri Nov 20 15:02:24 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 20 Nov 2015 08:02:24 -0700 Subject: [Freeipa-devel] [PATCH 0064] Check if IPA is configured before attempting a winsync migration Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5470 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0064-Check-if-IPA-is-configured-before-attempting-a-winsy.patch Type: text/x-patch Size: 1455 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 20 15:06:11 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 16:06:11 +0100 Subject: [Freeipa-devel] [PATCH 0102] update idrange tests to reflect disabled modification of local ID ranges Message-ID: <564F36E3.90807@redhat.com> When I fixed https://fedorahosted.org/freeipa/ticket/4826 I forgot to fix the corresponding xmlrpc tests. This oversight bit me today when I ran in-tree tests on my VM. Here is the patch that makes idrange tests green and shiny again. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0102-update-idrange-tests-to-reflect-disabled-modificatio.patch Type: text/x-patch Size: 4074 bytes Desc: not available URL: From pspacek at redhat.com Fri Nov 20 15:43:40 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 Nov 2015 16:43:40 +0100 Subject: [Freeipa-devel] [PATCH 0353] upgrade: fix migration of old dns forward zones In-Reply-To: <564F2389.5080601@redhat.com> References: <564F216D.2080703@redhat.com> <564F2389.5080601@redhat.com> Message-ID: <564F3FAC.1060308@redhat.com> On 20.11.2015 14:43, Martin Basti wrote: > > > On 20.11.2015 14:34, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5472 >> >> Patch attached. >> >> > I forgot to attached rebased patch for ipa-4-2 ACK, thank you! -- Petr^2 Spacek From mbasti at redhat.com Fri Nov 20 15:45:32 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Nov 2015 16:45:32 +0100 Subject: [Freeipa-devel] [PATCH 0353] upgrade: fix migration of old dns forward zones In-Reply-To: <564F3FAC.1060308@redhat.com> References: <564F216D.2080703@redhat.com> <564F2389.5080601@redhat.com> <564F3FAC.1060308@redhat.com> Message-ID: <564F401C.3080500@redhat.com> On 20.11.2015 16:43, Petr Spacek wrote: > On 20.11.2015 14:43, Martin Basti wrote: >> >> On 20.11.2015 14:34, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5472 >>> >>> Patch attached. >>> >>> >> I forgot to attached rebased patch for ipa-4-2 > ACK, thank you! > Pushed to master: 72b03a5d7931635b8563e374f217fa48c729450b Pushed to ipa-4-2: 68eef6c21f3fa0f1351f420d20f5cea93dac64ec From jcholast at redhat.com Fri Nov 20 15:49:25 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Nov 2015 16:49:25 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <1447951434.5132.27.camel@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> Message-ID: <564F4105.1040204@redhat.com> On 19.11.2015 17:43, Simo Sorce wrote: > On Thu, 2015-11-19 at 15:43 +0100, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix >> and . >> >> I worked around the issue of checking if the user is privileged to >> perform replica promotion by using host credentials instead. The host >> must be a member of the IPA servers host group "ipaservers" in order to >> be able to promote itself. Using host credentials will also allow >> replica install using one-time password. >> >> User credentials are still used for connection check and to >> automatically add the host to ipaservers if the user is privileged to do >> that. >> >> Simo, is this approach OK? Could you check the new ACIs in patches 510 >> and 513? >> >> I have a couple of questions: >> >> 1) Why are custodia keys for the replica added to LDAP using connection >> to the remote master instead of local ldapi connection? Is it to >> eliminate race conditions caused by replication timeout from the replica >> to the remote master? > > Yes it is critical for that reason. > >> If the code was changed to use ldapi and wait until the key appears in >> custodia on the remote master, we could lose the "IPA server hosts can >> create own Custodia secrets" and "IPA server hosts can manage own >> Custodia secrets" ACIs from patch 510. Not sure if it's worth the change >> though. > > Not worth the change, as it has the same security properties. > >> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? >> >> If 'member' was used instead, we would gain referential integrity and >> the ability to add ACIs based on the attribute (think >> userattr="member#USERDN"). > > To avoid referential integrity and mixup with other group objects, it > was intentional. > >> 3) Why is 'memberPrincipal' used in cn=custodia at all? >> >> The hostname of the replica is already in 'cn', so instead of searching >> cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we >> could get cn={enc,sig}/$HOSTNAME,cn=custodia directly. > > They idea was to be flexible, in a future we might have some shared > keys, then the only way to properly resolve keys would be to use a > multivalued attribute. > Or we may want to have multiple keys sets for the same principal (it > doesn't have to be a host technically, it could be a service or even a > user in the future), and a naming based convention would make it harder > to deal with that. > > > On the patches > -- > 509: > - commit says only: "aci: add IPA servers host group 'ipaservers'" > but it does other things like changing how CA renewal certificate acis > are added, I think that must be separated in another patch. > > - Why "Manage Host Keytab" aci has been changed to exclude ipaservers ? To allow only members of the admins group to manage keytabs of IPA servers. This is analogous to how only members of the admins group can change passwords of other admins. > > - Why adding the host to the ipaservers group is done in the > krbinstance ? I would expect LDAP ops to be mostly done in the > DSinstance. It is the same place where the host entry is created. > > - I do not see where the host is added to the ipaservers group on > upgrade. It's in install/updates/20-ipaservers_hostgroup.update: add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX > > 510: > - We should probably tightenup the ACI to allos host X to only add > memberPrincipal = X and no other value, also the host should not be > allowed to change the memberPrincipal attribute only the keys. > If we can't express this in ACIs we can live with the ones you propose > though. I think this can be done. memberPrincipal is included in the ACI because KEMLdap.set_key() touches it. Perhaps it is not intentional? > > 511: > ack, but I think you should catch potential exceptions from the > os.rmdir, as it will throw if there is some other file in the dir (for > whatever reason). The exception can be safely ignored, we just do not > want to blow up with a traceback here. OK. > > 512: > - I do not think this is correct, it seem to me you are overriding the > local ccache (if any) with the host keytab. If I read this right, this > means that if you run kinit admin && ipa-replica-install then you will > kind your admin credentials gone and a host TGT instead. Am I reading > this change correctly ? No. :-) Temporary ccache is now used for the install and the host is kinited into it. The initial ccache is used only for connection check (and adding the host to ipaservers in patch 514). Your kinit admin will not be lost. > > 513: > Nack > - Should be folded into 510 These ACIs are required only for patch 514. > - Should not allow all hosts in the domain but only ipaservers for aal > three changes If the host isn't member of ipaservers before ipa-replica-install is run, the "Check that we don't already have a replication agreement", "Detect if the other master can handle replication managers" and "Find if any server has a CA" steps will fail without these ACIs, which breaks patch 514. > > 514: > - Should be folded in 512, they are completely interdependent changes. Patch 512 works fine without this patch, but the host has to be member of ipaservers before ipa-replica-install is run. > - I do not understand how this works. promote_check() runs before > promote() and will fail if the host is not already in the ipaservers > group, so you will never be able to actually add the host to the group ? > sounds like chicken-egg ... or what am I missing ? The chicken-egg is solved by the ACIs from patch 513. They allow any host to perform the checks necessary for promote_check() to succeed, so the host can be added to ipaservers in promote(). > > Simo. > -- Jan Cholasta From simo at redhat.com Fri Nov 20 16:58:43 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Nov 2015 11:58:43 -0500 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <564F4105.1040204@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> Message-ID: <1448038723.5132.59.camel@redhat.com> On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote: > On 19.11.2015 17:43, Simo Sorce wrote: [..] > > On the patches > > -- > > 509: > > - commit says only: "aci: add IPA servers host group 'ipaservers'" > > but it does other things like changing how CA renewal certificate acis > > are added, I think that must be separated in another patch. > > > > - Why "Manage Host Keytab" aci has been changed to exclude ipaservers ? > > To allow only members of the admins group to manage keytabs of IPA > servers. This is analogous to how only members of the admins group can > change passwords of other admins. I guess there is an interaction between ACIs I am not getting here, can you give a small overview of how we end up here ? If IPAservers are not supposed to access those attributes, why are they added to the permissions at all ? Wouldn't it make sense to have 2 set of permissions ? One for admin type users (with access to all attributes) and one for less privileged users ? > > - Why adding the host to the ipaservers group is done in the > > krbinstance ? I would expect LDAP ops to be mostly done in the > > DSinstance. > > It is the same place where the host entry is created. I will translate this with "historical" :-) > > - I do not see where the host is added to the ipaservers group on > > upgrade. > > It's in install/updates/20-ipaservers_hostgroup.update: > > add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX Ahh, I missed that, thanks! > > 510: > > - We should probably tightenup the ACI to allos host X to only add > > memberPrincipal = X and no other value, also the host should not be > > allowed to change the memberPrincipal attribute only the keys. > > If we can't express this in ACIs we can live with the ones you propose > > though. > > I think this can be done. > > memberPrincipal is included in the ACI because KEMLdap.set_key() touches > it. Perhaps it is not intentional? Yeah, it is a bug in set_key(), of course we need to add memberPrincipal when creating a whole new entry, but we should not modify it on existing entries. > > 511: > > ack, but I think you should catch potential exceptions from the > > os.rmdir, as it will throw if there is some other file in the dir (for > > whatever reason). The exception can be safely ignored, we just do not > > want to blow up with a traceback here. > > OK. > > > > > 512: > > - I do not think this is correct, it seem to me you are overriding the > > local ccache (if any) with the host keytab. If I read this right, this > > means that if you run kinit admin && ipa-replica-install then you will > > kind your admin credentials gone and a host TGT instead. Am I reading > > this change correctly ? > > No. :-) Temporary ccache is now used for the install and the host is > kinited into it. The initial ccache is used only for connection check > (and adding the host to ipaservers in patch 514). Your kinit admin will > not be lost. Ok, got it. > > > > 513: > > Nack > > - Should be folded into 510 > > These ACIs are required only for patch 514. Yes, but they are close and will give a full picture of the change required for the feature if they are together. They won't hurt anything even if unused until a few patches later (IIUC). > > - Should not allow all hosts in the domain but only ipaservers for aal > > three changes > > If the host isn't member of ipaservers before ipa-replica-install is > run, the "Check that we don't already have a replication agreement", > "Detect if the other master can handle replication managers" and "Find > if any server has a CA" steps will fail without these ACIs, which breaks > patch 514. Yes I understood that, but it is intentional, these are administrative checks, they need to be done as admin or with a host account that has been pre-added to the ipaservers group. We do not want to expose information to all other hosts in the domain as replication agreements can include passwords in some cases, or other access information the admin may not want to make available to random hosts. > > 514: > > - Should be folded in 512, they are completely interdependent changes. > > Patch 512 works fine without this patch, but the host has to be member > of ipaservers before ipa-replica-install is run. Yeah, this is a problem, we do not want admins to have to do that, right ? > > - I do not understand how this works. promote_check() runs before > > promote() and will fail if the host is not already in the ipaservers > > group, so you will never be able to actually add the host to the group ? > > sounds like chicken-egg ... or what am I missing ? > > The chicken-egg is solved by the ACIs from patch 513. They allow any > host to perform the checks necessary for promote_check() to succeed, so > the host can be added to ipaservers in promote(). I do not see how ACIs solve the problem where the code check if the server is already in ipaservers, and the server isn't. My reading is this please tell me where I am wrong: Admin, out of the blue, run ipa-replica-install on a random client. promote_check(): checks if host is in ipaservers host is not in ipaservers and we bail --> end of the story here ? promote(): add itself to ipaserver <-- how do we get here ? HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Fri Nov 20 17:36:02 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Nov 2015 18:36:02 +0100 Subject: [Freeipa-devel] [PATCH 0064] Check if IPA is configured before attempting a winsync migration In-Reply-To: References: Message-ID: <564F5A02.2060302@redhat.com> On 11/20/2015 04:02 PM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5470 > > Thanks, > > Gabe > > Hi Gabe, patch looks good. IMHO it would be better if you moved the check before API initialization like so: """ @@ -340,6 +340,12 @@ class WinsyncMigrate(admintool.AdminTool): the plumbing. """ + # Check if the IPA server is configured before attempting to migrate + try: + installutils.check_server_configuration() + except RuntimeError as e: + sys.exit(e) + # Finalize API api.bootstrap(in_server=True, context='server') api.finalize() """ There's no point in initializing API if there is no server installed. -- Martin^3 Babinsky From mkubik at redhat.com Fri Nov 20 17:41:13 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 20 Nov 2015 18:41:13 +0100 Subject: [Freeipa-devel] [PATCH 0102] update idrange tests to reflect disabled modification of local ID ranges In-Reply-To: <564F36E3.90807@redhat.com> References: <564F36E3.90807@redhat.com> Message-ID: <564F5B39.7060804@redhat.com> On 11/20/2015 04:06 PM, Martin Babinsky wrote: > When I fixed https://fedorahosted.org/freeipa/ticket/4826 I forgot to > fix the corresponding xmlrpc tests. > > This oversight bit me today when I ran in-tree tests on my VM. > > Here is the patch that makes idrange tests green and shiny again. > Tests are now passing, ACK -- Milan Kubik From redhatrises at gmail.com Fri Nov 20 18:10:10 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 20 Nov 2015 11:10:10 -0700 Subject: [Freeipa-devel] [PATCH 0064] Check if IPA is configured before attempting a winsync migration In-Reply-To: <564F5A02.2060302@redhat.com> References: <564F5A02.2060302@redhat.com> Message-ID: Thanks. Updated patch attached. Gabe On Fri, Nov 20, 2015 at 10:36 AM, Martin Babinsky wrote: > On 11/20/2015 04:02 PM, Gabe Alford wrote: > >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5470 >> >> Thanks, >> >> Gabe >> >> >> Hi Gabe, > > patch looks good. IMHO it would be better if you moved the check before > API initialization like so: > > """ > @@ -340,6 +340,12 @@ class WinsyncMigrate(admintool.AdminTool): > the plumbing. > """ > > + # Check if the IPA server is configured before attempting to > migrate > + try: > + installutils.check_server_configuration() > + except RuntimeError as e: > + sys.exit(e) > + > # Finalize API > api.bootstrap(in_server=True, context='server') > api.finalize() > """ > > There's no point in initializing API if there is no server installed. > > -- > Martin^3 Babinsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0064-2-Check-if-IPA-is-configured-before-attempting-a-winsy.patch Type: text/x-patch Size: 1424 bytes Desc: not available URL: From amarecek at redhat.com Fri Nov 20 19:54:30 2015 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Fri, 20 Nov 2015 14:54:30 -0500 (EST) Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package In-Reply-To: <564F31CE.5010402@redhat.com> References: <564F31CE.5010402@redhat.com> Message-ID: <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> Looks good. ACK. ----- Original Message ----- > From: "Milan Kub?k" > To: "freeipa-devel" > Cc: "Filip Skola" , "Ales Marecek" > Sent: Friday, November 20, 2015 3:44:30 PM > Subject: [patch 0025] Separated Tracker implementations into standalone package > > Fixes https://fedorahosted.org/freeipa/ticket/5467 > Patches attached. > > -- > Milan Kubik > > From ftweedal at redhat.com Mon Nov 23 05:46:44 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 23 Nov 2015 15:46:44 +1000 Subject: [Freeipa-devel] [PATCH] 0042-0043 Avoid race condition in profile creation Message-ID: <20151123054644.GL5336@dhcp-40-8.bne.redhat.com> The attached patch 0043 fixes #5269[1]: nondeterministic failure of certificate profile creation during ipa-server-install. [1] https://fedorahosted.org/freeipa/ticket/5269 The other patch 0042 is drive-by improvements of IPA install/upgrade logging that I did while diagnosing the issue. Thanks, Fraser -------------- next part -------------- From c6991e5095f7a8f7c13d1dd943a26b0b06365f6a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 20 Nov 2015 15:39:00 +1100 Subject: [PATCH 42/43] TLS and Dogtag HTTPS request logging improvements Pretty printing the TLS peer certificate to logs on every request introduces a lot of noise; do not log it (subject name, key usage and validity are still logged). Fix and tidy up some HTTP logging messages for Dogtag requests. Part of: https://fedorahosted.org/freeipa/ticket/5269 --- ipapython/dogtag.py | 9 ++++----- ipapython/nsslib.py | 3 --- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 3f0d08154d21a3072e344c311c3e70e414d9dee4..26b2de6ca77202fa9ccc61ee16ed7623e10ecb5f 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -314,7 +314,7 @@ def _httplib_request( if isinstance(host, unicode): host = host.encode('utf-8') uri = '%s://%s%s' % (protocol, ipautil.format_netloc(host, port), path) - root_logger.debug('request %r', uri) + root_logger.debug('request %s %s', method, uri) root_logger.debug('request body %r', request_body) headers = headers or {} @@ -337,9 +337,8 @@ def _httplib_request( except Exception, e: raise NetworkError(uri=uri, error=str(e)) - root_logger.debug('request status %d', http_status) - root_logger.debug('request reason_phrase %r', http_reason_phrase) - root_logger.debug('request headers %s', http_headers) - root_logger.debug('request body %r', http_body) + root_logger.debug('response status %d %s', http_status, http_reason_phrase) + root_logger.debug('response headers %s', http_headers) + root_logger.debug('response body %r', http_body) return http_status, http_reason_phrase, http_headers, http_body diff --git a/ipapython/nsslib.py b/ipapython/nsslib.py index def6b104e18fa67268a8c5a8629b533783fb5a95..79b8dc5be6a26cd6136ac62a4fa49572d765a9a0 100644 --- a/ipapython/nsslib.py +++ b/ipapython/nsslib.py @@ -39,9 +39,6 @@ def auth_certificate_callback(sock, check_sig, is_server, certdb): cert = sock.get_peer_certificate() - root_logger.debug("auth_certificate_callback: check_sig=%s is_server=%s\n%s", - check_sig, is_server, str(cert)) - pin_args = sock.get_pkcs11_pin_arg() if pin_args is None: pin_args = () -- 2.4.3 -------------- next part -------------- From e1809a951893a466d27bf30d55577184dd32ec1b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 20 Nov 2015 15:59:11 +1100 Subject: [PATCH 43/43] Avoid race condition caused by profile delete and recreate When importing IPA-managed certificate profiles into Dogtag, profiles with the same name (usually caIPAserviceCert) are removed, then immediately recreated with the new profile data. This causes a race condition - Dogtag's LDAPProfileSystem profileChangeMonitor thread could observe and process the deletion after the profile was recreated, disappearing it again. Update the profile instead of deleting and recreating it to avoid this race condition. Fixes: https://fedorahosted.org/freeipa/ticket/5269 --- ipaserver/install/cainstance.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index d230c9bdcab68f02cce32a2aeb89ca3e2143eefe..3e3dce93de2b8ca48a3fe3ea5994ee92a1b0ce49 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1812,8 +1812,7 @@ def _create_dogtag_profile(profile_id, profile_data): root_logger.debug( "Failed to disable profile '%s' " "(it is probably already disabled)") - profile_api.delete_profile(profile_id) - profile_api.create_profile(profile_data) + profile_api.update_profile(profile_id, profile_data) # enable the profile try: -- 2.4.3 From ftweedal at redhat.com Mon Nov 23 05:54:23 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 23 Nov 2015 15:54:23 +1000 Subject: [Freeipa-devel] [PATCH] 0044-0045 Add profiles and default CA ACL on migration Message-ID: <20151123055423.GM5336@dhcp-40-8.bne.redhat.com> Hi all, The attached patches fix #5459[1]: Default CA ACL rule is not created during ipa-replica-install. These patches apply on branch ipa-4-2. There is a (trivial) conflict in imports when applying to master. I strongly recommend review / testing of these patches with patches 0042-0043[2] due to the prevalence of the other issue. [1] https://fedorahosted.org/freeipa/ticket/5459 [2] https://www.redhat.com/archives/freeipa-devel/2015-November/msg00298.html Thanks, Fraser -------------- next part -------------- From 8c3f2ce4a985e873277b7e84a8b95acca80c0348 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 23 Nov 2015 12:09:32 +1100 Subject: [PATCH 44/45] Do not erroneously reinit NSS in Dogtag interface The Dogtag interface always attempts to (re)init NSS, which can fail with SEC_ERROR_BUSY. Do not reinitialise NSS when it has already been initialised with the given dbdir. Part of: https://fedorahosted.org/freeipa/ticket/5459 --- ipapython/dogtag.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 3f0d08154d21a3072e344c311c3e70e414d9dee4..75c34db697ec5f7b1aac771de8517937fa09fbdd 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -255,7 +255,8 @@ def https_request(host, port, url, secdir, password, nickname, """ def connection_factory(host, port): - conn = nsslib.NSSConnection(host, port, dbdir=secdir, + no_init = secdir == nsslib.current_dbdir + conn = nsslib.NSSConnection(host, port, dbdir=secdir, no_init=no_init, tls_version_min=api.env.tls_version_min, tls_version_max=api.env.tls_version_max) conn.set_debuglevel(0) -- 2.4.3 -------------- next part -------------- From 2a05260345627e5b636596a715333a20b5631cd1 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 23 Nov 2015 14:50:45 +1100 Subject: [PATCH 45/45] Add profiles and default CA ACL on migration Profiles and the default CA ACL were not being added during replica install from pre-4.2 servers. Update ipa-replica-install to add these if they are missing. Also update the caacl plugin to prevent deletion of the default CA ACL and instruct the administrator to disable it instead. Fixes: https://fedorahosted.org/freeipa/ticket/5459 --- install/updates/50-dogtag10-migration.update | 1 + ipalib/plugins/caacl.py | 7 +++++++ ipaserver/install/server/replicainstall.py | 8 ++++++++ ipaserver/install/server/upgrade.py | 28 ++++++++++++++++------------ 4 files changed, 32 insertions(+), 12 deletions(-) diff --git a/install/updates/50-dogtag10-migration.update b/install/updates/50-dogtag10-migration.update index 2ab9d15bd220540dbc6b3fcd7928fc15c42caf80..0070c308aefc39aa4c27a046d185ce6d268e6270 100644 --- a/install/updates/50-dogtag10-migration.update +++ b/install/updates/50-dogtag10-migration.update @@ -16,3 +16,4 @@ addifexist:resourceACLS:certServer.ca.groups:execute:allow (execute) group="Admi addifexist:resourceACLS:certServer.ca.users:execute:allow (execute) group="Administrators":Admins may execute user operations replace:resourceACLS:certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group":Anybody is allowed to read domain.xml but only Subsystem group is allowed to modify the domain.xml::certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" || group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise RA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml replace:resourceACLS:certServer.ca.connectorInfo:read,modify:allow (modify,read) group="Enterprise KRA Administrators":Only Enterprise Administrators are allowed to update the connector information::certServer.ca.connectorInfo:read,modify:allow (read) group="Enterprise KRA Administrators";allow (modify) group="Enterprise KRA Administrators" || group="Subsystem Group":Only Enterprise Administrators and Subsystem Group are allowed to update the connector information +addifexist:resourceACLS:certServer.profile.configuration:read,modify:allow (read,modify) group="Certificate Manager Agents":Certificate Manager agents may modify (create/update/delete) and read profiles diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py index 247d6df143aef1fba9f0ee74a9f7d8386bef5180..77bad38cd7e9f3cf10b7476acc7ac16fc6494bdf 100644 --- a/ipalib/plugins/caacl.py +++ b/ipalib/plugins/caacl.py @@ -307,6 +307,13 @@ class caacl_del(LDAPDelete): msg_summary = _('Deleted CA ACL "%(value)s"') + def pre_callback(self, ldap, dn, *keys, **options): + if keys[0] == 'hosts_services_caIPAserviceCert': + raise errors.ValidationError(name='name', + error=_("Cannot delete the default CA ACL; disable it instead")) + + return dn + @register() class caacl_mod(LDAPUpdate): diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py index c1edd3e48d36c8ad62c6a72e988604b59c574c0c..a4eded759cc566ba6747b23e04428c0c16d11007 100644 --- a/ipaserver/install/server/replicainstall.py +++ b/ipaserver/install/server/replicainstall.py @@ -27,6 +27,7 @@ from ipaserver.install import ( bindinstance, ca, cainstance, certs, dns, dsinstance, httpinstance, installutils, kra, krbinstance, memcacheinstance, ntpinstance, otpdinstance, service) +from ipaserver.install.server.upgrade import _add_default_caacl from ipaserver.install.installutils import create_replica_config from ipaserver.install.replication import ( ReplicationManager, replica_conn_check) @@ -615,6 +616,13 @@ def install(installer): dogtag_service = services.knownservices[dogtag_constants.SERVICE_NAME] dogtag_service.restart(dogtag_constants.PKI_INSTANCE_NAME) + # must add profiles after Dogtag restart to ensure that + # resourceACLS are current + service.print_msg("Synchronizing certificate profiles") + cainstance.migrate_profiles_to_ldap() + cainstance.import_included_profiles() + _add_default_caacl() + if options.setup_dns: api.Backend.ldap2.connect(autobind=True) dns.install(False, True, options) diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index c8f744c392c7b859459bda63c1f397226553d4ba..bd56fd070e41f9450c48f7f3b9a095de1a665c60 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1321,22 +1321,26 @@ def add_default_caacl(ca): return if ca.is_configured(): - if not api.Backend.ldap2.isconnected(): - try: - api.Backend.ldap2.connect(autobind=True) - except ipalib.errors.PublicError as e: - root_logger.error("Cannot connect to LDAP to add CA ACLs: %s", e) - return - - if not api.Command.caacl_find()['result']: - api.Command.caacl_add(u'hosts_services_caIPAserviceCert', - hostcategory=u'all', servicecategory=u'all') - api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', - certprofile=(u'caIPAserviceCert',)) + _add_default_caacl() sysupgrade.set_upgrade_state('caacl', 'add_default_caacl', True) +def _add_default_caacl(): + if not api.Backend.ldap2.isconnected(): + try: + api.Backend.ldap2.connect(autobind=True) + except ipalib.errors.PublicError as e: + root_logger.error("Cannot connect to LDAP to add CA ACLs: %s", e) + return + + if not api.Command.caacl_find()['result']: + api.Command.caacl_add(u'hosts_services_caIPAserviceCert', + hostcategory=u'all', servicecategory=u'all') + api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', + certprofile=(u'caIPAserviceCert',)) + + def upgrade_configuration(): """ Execute configuration upgrade of the IPA services -- 2.4.3 From jcholast at redhat.com Mon Nov 23 06:43:56 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 07:43:56 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run In-Reply-To: <564D0FD9.4070505@redhat.com> References: <5638B8F9.6010703@redhat.com> <564D0FD9.4070505@redhat.com> Message-ID: <5652B5AC.2040508@redhat.com> On 19.11.2015 00:55, Petr Viktorin wrote: > On 11/03/2015 02:39 PM, Petr Viktorin wrote: >> Hello, >> Python 3's strings are Unicode, so data coming to or leaving a Python >> program needs to be decoded/encoded if it's to be handled as a string. >> One of the boundaries where encoding is necessary is external programs, >> specifically, ipautil.run. >> Unfortunately there's no one set of options that would work for all >> run() invocations, so I went through them all and specified the >> stdin/stdout/stderr encoding where necessary. I've also updated the call >> sites to make it clearer if the return values are used or not. >> If an encoding is not set, run() will accept/return bytes. (This is a >> fail-safe setting, since it can't raise errors, and using bytes where >> strings are expected generally fails loudly in py3.) >> >> Note that the changes are not effective under Python 2. > > ping, > Could someone look at this patch? Looking. -- Jan Cholasta From jcholast at redhat.com Mon Nov 23 07:54:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 08:54:38 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <1448038723.5132.59.camel@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> <1448038723.5132.59.camel@redhat.com> Message-ID: <5652C63E.5090206@redhat.com> On 20.11.2015 17:58, Simo Sorce wrote: > On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote: >> On 19.11.2015 17:43, Simo Sorce wrote: > [..] >>> On the patches >>> -- >>> 509: >>> - commit says only: "aci: add IPA servers host group 'ipaservers'" >>> but it does other things like changing how CA renewal certificate acis >>> are added, I think that must be separated in another patch. >>> >>> - Why "Manage Host Keytab" aci has been changed to exclude ipaservers ? >> >> To allow only members of the admins group to manage keytabs of IPA >> servers. This is analogous to how only members of the admins group can >> change passwords of other admins. > > I guess there is an interaction between ACIs I am not getting here, can > you give a small overview of how we end up here ? This ACI allows admins to modify keytab of any host: aci: (targetattr = "krbPrincipalKey || krbLastPwdChange")(target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl "Admins can manage host keytab";allow (write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) The original "Manage Host Keytab" ACI allows any user with the corresponding permission to modify keytab of any host. The modified "Manage Host Keytab" ACI allows any user with the correcponding permission to modify keytab of any host except for members of ipaservers. The result is that the user has to be member of admins to be able to modify keytab of IPA servers. > If IPAservers are not supposed to access those attributes, why are they > added to the permissions at all ? The effect of the change is not to limit access of IPA servers, but to limit access of non-admin users *to* IPA servers. > Wouldn't it make sense to have 2 set of permissions ? > One for admin type users (with access to all attributes) and one for > less privileged users ? There already is a separate ACI which allows admins full access to the attributes, see above. > >>> - Why adding the host to the ipaservers group is done in the >>> krbinstance ? I would expect LDAP ops to be mostly done in the >>> DSinstance. >> >> It is the same place where the host entry is created. > > I will translate this with "historical" :-) > >>> - I do not see where the host is added to the ipaservers group on >>> upgrade. >> >> It's in install/updates/20-ipaservers_hostgroup.update: >> >> add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX > > Ahh, I missed that, thanks! > >>> 510: >>> - We should probably tightenup the ACI to allos host X to only add >>> memberPrincipal = X and no other value, also the host should not be >>> allowed to change the memberPrincipal attribute only the keys. >>> If we can't express this in ACIs we can live with the ones you propose >>> though. >> >> I think this can be done. >> >> memberPrincipal is included in the ACI because KEMLdap.set_key() touches >> it. Perhaps it is not intentional? > > Yeah, it is a bug in set_key(), of course we need to add memberPrincipal > when creating a whole new entry, but we should not modify it on existing > entries. I though so, I will fix that. > >>> 511: >>> ack, but I think you should catch potential exceptions from the >>> os.rmdir, as it will throw if there is some other file in the dir (for >>> whatever reason). The exception can be safely ignored, we just do not >>> want to blow up with a traceback here. >> >> OK. >> >>> >>> 512: >>> - I do not think this is correct, it seem to me you are overriding the >>> local ccache (if any) with the host keytab. If I read this right, this >>> means that if you run kinit admin && ipa-replica-install then you will >>> kind your admin credentials gone and a host TGT instead. Am I reading >>> this change correctly ? >> >> No. :-) Temporary ccache is now used for the install and the host is >> kinited into it. The initial ccache is used only for connection check >> (and adding the host to ipaservers in patch 514). Your kinit admin will >> not be lost. > > Ok, got it. > >>> >>> 513: >>> Nack >>> - Should be folded into 510 >> >> These ACIs are required only for patch 514. > > Yes, but they are close and will give a full picture of the change > required for the feature if they are together. They won't hurt anything > even if unused until a few patches later (IIUC). OK, makes sense. > >>> - Should not allow all hosts in the domain but only ipaservers for aal >>> three changes >> >> If the host isn't member of ipaservers before ipa-replica-install is >> run, the "Check that we don't already have a replication agreement", >> "Detect if the other master can handle replication managers" and "Find >> if any server has a CA" steps will fail without these ACIs, which breaks >> patch 514. > > Yes I understood that, but it is intentional, these are administrative > checks, they need to be done as admin or with a host account that has > been pre-added to the ipaservers group. We do not want to expose > information to all other hosts in the domain as replication agreements > can include passwords in some cases, or other access information the > admin may not want to make available to random hosts. The access is limited to objectclass and cn only, so the hosts will be able to see only if the entry exists. Additionaly, for replication agreements, only the host with the hostname corresponding to the replication agreement can access the entry. > >>> 514: >>> - Should be folded in 512, they are completely interdependent changes. >> >> Patch 512 works fine without this patch, but the host has to be member >> of ipaservers before ipa-replica-install is run. > > Yeah, this is a problem, we do not want admins to have to do that, > right ? > >>> - I do not understand how this works. promote_check() runs before >>> promote() and will fail if the host is not already in the ipaservers >>> group, so you will never be able to actually add the host to the group ? >>> sounds like chicken-egg ... or what am I missing ? >> >> The chicken-egg is solved by the ACIs from patch 513. They allow any >> host to perform the checks necessary for promote_check() to succeed, so >> the host can be added to ipaservers in promote(). > > I do not see how ACIs solve the problem where the code check if the > server is already in ipaservers, and the server isn't. My reading is > this please tell me where I am wrong: > > Admin, out of the blue, run ipa-replica-install on a random client. > promote_check(): > checks if host is in ipaservers > host is not in ipaservers and we bail --> end of the story here ? > promote(): > add itself to ipaserver <-- how do we get here ? It's: promote_check(): check if host is in ipaservers if host is not in ipaservers: if the user can't modify ipaserver we bail --> end of story here do a bunch of other checks (these require the ACIs if the host is not in ipaservers) promote(): add the host to ipaservers (if it's not already in and the user can modify ipaservers) > > HTH, > Simo. > -- Jan Cholasta From dkupka at redhat.com Mon Nov 23 07:53:27 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 23 Nov 2015 08:53:27 +0100 Subject: [Freeipa-devel] [PATCH 0067, 0068] ipa-{cacert-renew, otptoken-import}: Fix connection to ldap. In-Reply-To: <564ECBEB.2090505@redhat.com> References: <564DF8C5.9090706@redhat.com> <564ECBEB.2090505@redhat.com> Message-ID: <5652C5F7.2060006@redhat.com> On 20/11/15 08:29, Jan Cholasta wrote: > On 19.11.2015 17:28, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/5468 > > ipa-cacert-manage is not the only code which uses ldap2 this way. > > It would be better to find the root cause of this rather than working > around it. > The root cause is that some scripts are creating custom connection to LDAP and using api which is not connected to LDAP. As we discussed personally ipa-cacert-manage and ipa-otptoken-import have this issue. Updated patch and new one for ipa-otptoken-import attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0068-ipa-otptoken-import-Fix-connection-to-ldap.patch Type: text/x-patch Size: 1771 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0067.1-ipa-cacert-renew-Fix-connection-to-ldap.patch Type: text/x-patch Size: 4232 bytes Desc: not available URL: From pspacek at redhat.com Mon Nov 23 08:10:36 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Nov 2015 09:10:36 +0100 Subject: [Freeipa-devel] [PATCH 0354] Remove forgotten print in DNS plugin In-Reply-To: <564F220A.8060304@redhat.com> References: <564F220A.8060304@redhat.com> Message-ID: <5652C9FC.1030701@redhat.com> On 20.11.2015 14:37, Martin Basti wrote: > patch attached. Obvous ACK. -- Petr^2 Spacek From jcholast at redhat.com Mon Nov 23 09:04:51 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 10:04:51 +0100 Subject: [Freeipa-devel] [PATCH] 0042-0043 Avoid race condition in profile creation In-Reply-To: <20151123054644.GL5336@dhcp-40-8.bne.redhat.com> References: <20151123054644.GL5336@dhcp-40-8.bne.redhat.com> Message-ID: <5652D6B3.9040600@redhat.com> On 23.11.2015 06:46, Fraser Tweedale wrote: > The attached patch 0043 fixes #5269[1]: nondeterministic failure of > certificate profile creation during ipa-server-install. > > [1] https://fedorahosted.org/freeipa/ticket/5269 > > The other patch 0042 is drive-by improvements of IPA install/upgrade > logging that I did while diagnosing the issue. > > Thanks, > Fraser > Patch 0042: Does not apply on master. Patch 0043: ACK Honza -- Jan Cholasta From jcholast at redhat.com Mon Nov 23 09:05:32 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 10:05:32 +0100 Subject: [Freeipa-devel] [PATCH] 0044-0045 Add profiles and default CA ACL on migration In-Reply-To: <20151123055423.GM5336@dhcp-40-8.bne.redhat.com> References: <20151123055423.GM5336@dhcp-40-8.bne.redhat.com> Message-ID: <5652D6DC.9050205@redhat.com> On 23.11.2015 06:54, Fraser Tweedale wrote: > Hi all, > > The attached patches fix #5459[1]: Default CA ACL rule is not > created during ipa-replica-install. > > These patches apply on branch ipa-4-2. There is a (trivial) > conflict in imports when applying to master. When a patch does not apply cleanly on all the target branches, you should attach a rebased patch as well. > > I strongly recommend review / testing of these patches with patches > 0042-0043[2] due to the prevalence of the other issue. > > [1] https://fedorahosted.org/freeipa/ticket/5459 > [2] https://www.redhat.com/archives/freeipa-devel/2015-November/msg00298.html Patch 0044: ACK Patch 0045: 1) The check in caacl_del could be better, please take a look at how the admins group is handled in ipalib/plugins/group.py for an example. You should at least raise ProtectedEntryError rather than ValidationError. 2) _add_default_caacl() should be located in ipaserver/install/cainstance.py. 3) Rather than calling the cainstance functions in replicainstall.install(), they should be called from CAInstance.configure_instance() to make them effective in ipa-ca-install and replica promotion as well. Honza -- Jan Cholasta From jcholast at redhat.com Mon Nov 23 09:09:12 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 10:09:12 +0100 Subject: [Freeipa-devel] [PATCH 0067, 0068] ipa-{cacert-renew, otptoken-import}: Fix connection to ldap. In-Reply-To: <5652C5F7.2060006@redhat.com> References: <564DF8C5.9090706@redhat.com> <564ECBEB.2090505@redhat.com> <5652C5F7.2060006@redhat.com> Message-ID: <5652D7B8.8040200@redhat.com> On 23.11.2015 08:53, David Kupka wrote: > On 20/11/15 08:29, Jan Cholasta wrote: >> On 19.11.2015 17:28, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/5468 >> >> ipa-cacert-manage is not the only code which uses ldap2 this way. >> >> It would be better to find the root cause of this rather than working >> around it. >> > > The root cause is that some scripts are creating custom connection to > LDAP and using api which is not connected to LDAP. > As we discussed personally ipa-cacert-manage and ipa-otptoken-import > have this issue. > Updated patch and new one for ipa-otptoken-import attached. The patches do not apply on ipa-4-2. -- Jan Cholasta From ldoudova at redhat.com Mon Nov 23 09:43:10 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 23 Nov 2015 10:43:10 +0100 Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package In-Reply-To: <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> References: <564F31CE.5010402@redhat.com> <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> Message-ID: <5652DFAE.90906@redhat.com> NACK - there's a "typo" in ..../tracker/user_plugin.py, line 17-18: def get_user_dn(cn): return DN(('cn', cn), api.env.container_user, api.env.basedn) should be def get_user_dn(uid): return DN(('uid', uid), api.env.container_user, api.env.basedn) Some tests may fail because of that. Lenka On 11/20/2015 08:54 PM, Ale? Mare?ek wrote: > Looks good. ACK. > > ----- Original Message ----- >> From: "Milan Kub?k" >> To: "freeipa-devel" >> Cc: "Filip Skola" , "Ales Marecek" >> Sent: Friday, November 20, 2015 3:44:30 PM >> Subject: [patch 0025] Separated Tracker implementations into standalone package >> >> Fixes https://fedorahosted.org/freeipa/ticket/5467 >> Patches attached. >> >> -- >> Milan Kubik >> >> From jcholast at redhat.com Mon Nov 23 09:50:44 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 10:50:44 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run In-Reply-To: <5652B5AC.2040508@redhat.com> References: <5638B8F9.6010703@redhat.com> <564D0FD9.4070505@redhat.com> <5652B5AC.2040508@redhat.com> Message-ID: <5652E174.50301@redhat.com> On 23.11.2015 07:43, Jan Cholasta wrote: > On 19.11.2015 00:55, Petr Viktorin wrote: >> On 11/03/2015 02:39 PM, Petr Viktorin wrote: >>> Hello, >>> Python 3's strings are Unicode, so data coming to or leaving a Python >>> program needs to be decoded/encoded if it's to be handled as a string. >>> One of the boundaries where encoding is necessary is external programs, >>> specifically, ipautil.run. >>> Unfortunately there's no one set of options that would work for all >>> run() invocations, so I went through them all and specified the >>> stdin/stdout/stderr encoding where necessary. I've also updated the call >>> sites to make it clearer if the return values are used or not. >>> If an encoding is not set, run() will accept/return bytes. (This is a >>> fail-safe setting, since it can't raise errors, and using bytes where >>> strings are expected generally fails loudly in py3.) >>> >>> Note that the changes are not effective under Python 2. >> >> ping, >> Could someone look at this patch? > > Looking. 1) I think a better approach would be to use str for stdin/stdout/stderr by default in both Python 2 and 3, i.e. do nothing in Python 2 and encode/decode using locale.getpreferredencoding() in Python 3. This is consistent with sys.std{in,out,err} in both Python 2 and 3. Using bytes or different encoding should be opt-in. Note that different encoding should be used only if the LC_ALL or LANG variables are overriden in the command's environment. 2) The str() here is wrong: + arg_string = nolog_replace(' '.join(str(shell_quote(a)) for a in args), nolog) It converts b'data' to "b'data'" in Python 3. Popen accepts both bytes and text in both Python 2 and 3, so there is nothing to be done for bytes arguments. 3) I think the "surrogateescape" error handler would be better for non-strict decoding, as the text can be encoded back to bytes without loss of information. 4) There are direct calls to subprocess.Popen() in a few places, have you checked them as well? -- Jan Cholasta From jcholast at redhat.com Mon Nov 23 10:07:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 11:07:23 +0100 Subject: [Freeipa-devel] [PATCH] 0042-0043 Avoid race condition in profile creation In-Reply-To: <5652D6B3.9040600@redhat.com> References: <20151123054644.GL5336@dhcp-40-8.bne.redhat.com> <5652D6B3.9040600@redhat.com> Message-ID: <5652E55B.9020903@redhat.com> On 23.11.2015 10:04, Jan Cholasta wrote: > On 23.11.2015 06:46, Fraser Tweedale wrote: >> The attached patch 0043 fixes #5269[1]: nondeterministic failure of >> certificate profile creation during ipa-server-install. >> >> [1] https://fedorahosted.org/freeipa/ticket/5269 >> >> The other patch 0042 is drive-by improvements of IPA install/upgrade >> logging that I did while diagnosing the issue. >> >> Thanks, >> Fraser >> > > Patch 0042: Does not apply on master. > > Patch 0043: ACK I have rebased the patches on top of master, see attachment. ACK and pushed to: master: 5136cd6e4bd305d6f4b6bf22d22fb4abc365cfad ipa-4-2: a8a666416201a7a7d6739f60854c5e5223b9ceb5 -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-TLS-and-Dogtag-HTTPS-request-logging-improvements.patch Type: text/x-patch Size: 2313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Avoid-race-condition-caused-by-profile-delete-and-re.patch Type: text/x-patch Size: 1498 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Nov 23 11:11:31 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 23 Nov 2015 12:11:31 +0100 Subject: [Freeipa-devel] [PATCH 0064] Check if IPA is configured before attempting a winsync migration In-Reply-To: References: <564F5A02.2060302@redhat.com> Message-ID: <5652F463.8070909@redhat.com> On 11/20/2015 07:10 PM, Gabe Alford wrote: > Thanks. Updated patch attached. > > > Gabe > > On Fri, Nov 20, 2015 at 10:36 AM, Martin Babinsky > wrote: > > On 11/20/2015 04:02 PM, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5470 > > Thanks, > > Gabe > > > Hi Gabe, > > patch looks good. IMHO it would be better if you moved the check > before API initialization like so: > > """ > @@ -340,6 +340,12 @@ class WinsyncMigrate(admintool.AdminTool): > the plumbing. > """ > > + # Check if the IPA server is configured before attempting > to migrate > + try: > + installutils.check_server_configuration() > + except RuntimeError as e: > + sys.exit(e) > + > # Finalize API > api.bootstrap(in_server=True, context='server') > api.finalize() > """ > > There's no point in initializing API if there is no server installed. > > -- > Martin^3 Babinsky > > Thanks, ACK. -- Martin^3 Babinsky From mbasti at redhat.com Mon Nov 23 11:39:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 Nov 2015 12:39:09 +0100 Subject: [Freeipa-devel] [PATCH 0354] Remove forgotten print in DNS plugin In-Reply-To: <5652C9FC.1030701@redhat.com> References: <564F220A.8060304@redhat.com> <5652C9FC.1030701@redhat.com> Message-ID: <5652FADD.4020000@redhat.com> On 23.11.2015 09:10, Petr Spacek wrote: > On 20.11.2015 14:37, Martin Basti wrote: >> patch attached. > Obvous ACK. > Pushed to master: bf654aee1ca339b7807e80bd6a8dd42b008553c9 From mbasti at redhat.com Mon Nov 23 11:45:30 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 Nov 2015 12:45:30 +0100 Subject: [Freeipa-devel] [PATCH 0102] update idrange tests to reflect disabled modification of local ID ranges In-Reply-To: <564F5B39.7060804@redhat.com> References: <564F36E3.90807@redhat.com> <564F5B39.7060804@redhat.com> Message-ID: <5652FC5A.70901@redhat.com> On 20.11.2015 18:41, Milan Kub?k wrote: > On 11/20/2015 04:06 PM, Martin Babinsky wrote: >> When I fixed https://fedorahosted.org/freeipa/ticket/4826 I forgot to >> fix the corresponding xmlrpc tests. >> >> This oversight bit me today when I ran in-tree tests on my VM. >> >> Here is the patch that makes idrange tests green and shiny again. >> > Tests are now passing, ACK > Pushed to: master: 8909506a880719478dc1c346ee325566620a9d18 ipa-4-2: 92e00d11acbabcfbafca311b1dd286054ee8d7c3 From tbabej at redhat.com Mon Nov 23 11:50:29 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 12:50:29 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one Message-ID: <5652FD85.3050105@redhat.com> Hi, this patch implements the single command replica promotion&enrollment for #5310. Tomas https://fedorahosted.org/freeipa/ticket/5310 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0385-replicainstall-Add-possiblity-to-install-client-in-o.patch Type: text/x-patch Size: 4115 bytes Desc: not available URL: From tbabej at redhat.com Mon Nov 23 11:53:08 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 12:53:08 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable Message-ID: <5652FE24.2040004@redhat.com> Hi, If the code within the private_ccache contextmanager does not set/removes the KRB5CCNAME, the pop method will raise KeyError, which will cause unnecessary termination of the code flow. Make sure the KRB5CCNAME is popped out of os.environ only if present. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0386-private_ccache-Harden-the-removal-of-KRB5CCNAME-env-.patch Type: text/x-patch Size: 1219 bytes Desc: not available URL: From tbabej at redhat.com Mon Nov 23 11:58:45 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 12:58:45 +0100 Subject: [Freeipa-devel] [PATCH 0102] update idrange tests to reflect disabled modification of local ID ranges In-Reply-To: <564F5B39.7060804@redhat.com> References: <564F36E3.90807@redhat.com> <564F5B39.7060804@redhat.com> Message-ID: <5652FF75.4000008@redhat.com> On 11/20/2015 06:41 PM, Milan Kub?k wrote: > On 11/20/2015 04:06 PM, Martin Babinsky wrote: >> When I fixed https://fedorahosted.org/freeipa/ticket/4826 I forgot to >> fix the corresponding xmlrpc tests. >> >> This oversight bit me today when I ran in-tree tests on my VM. >> >> Here is the patch that makes idrange tests green and shiny again. >> > Tests are now passing, ACK > Tests are now passing, however, the code paths that have been checked by these tests are no longer executed (as an modifications to the local ranges are prohibited now). This essentially means that we are testing the same thing multiple times (i.e. local range cannot be dealt with), and the test names are misleading currently. I think we should either reduce the set of (effectively) duplicate tests, or, better, introduce their replacements that are using allowed range types, if possible. Tomas From jcholast at redhat.com Mon Nov 23 12:11:07 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 13:11:07 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5652FE24.2040004@redhat.com> References: <5652FE24.2040004@redhat.com> Message-ID: <5653025B.1030100@redhat.com> On 23.11.2015 12:53, Tomas Babej wrote: > Hi, > > If the code within the private_ccache contextmanager does not > set/removes the KRB5CCNAME, the pop method will raise KeyError, which > will cause unnecessary termination of the code flow. > > Make sure the KRB5CCNAME is popped out of os.environ only if present. > > Tomas NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. Also I don't think the comment is necessary, it's quite obvious what the code does. -- Jan Cholasta From tbabej at redhat.com Mon Nov 23 12:28:42 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 13:28:42 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5653025B.1030100@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> Message-ID: <5653067A.1000709@redhat.com> On 11/23/2015 01:11 PM, Jan Cholasta wrote: > On 23.11.2015 12:53, Tomas Babej wrote: >> Hi, >> >> If the code within the private_ccache contextmanager does not >> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >> will cause unnecessary termination of the code flow. >> >> Make sure the KRB5CCNAME is popped out of os.environ only if present. >> >> Tomas > > NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. Yeah, well, both ways are equivalent, I found the if statement more explicit. We can go with the suggested version, if it's more pleasing though - patch is attached. > > Also I don't think the comment is necessary, it's quite obvious what the > code does. > I don't think an explanatory comment can hurt, ever. Worst thing that happens is that somebody is assured that he understands the code correctly. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0386-2-private_ccache-Harden-the-removal-of-KRB5CCNAME-env-.patch Type: text/x-patch Size: 1176 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 23 12:29:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 Nov 2015 13:29:50 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <5640C827.5090002@redhat.com> References: <5640A90B.6030906@redhat.com> <5640C827.5090002@redhat.com> Message-ID: <565306BE.4000207@redhat.com> On 09.11.2015 17:21, Martin Basti wrote: > > > On 09.11.2015 15:09, Oleg Fayans wrote: >> Hi guys, >> >> Here are first two automated testcases from this (so far incomplete) >> testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >> >> Testplan review is highly appreciated >> >> >> >> > > Hello, > > I did not test patch, I just read the testplan, I have a few comments: > > I'm not sure how test plan should look to cover QA needs, so maybe my > following notes what is missing in test plan are not important. > > 1) > CA has been affected by replica promotion patches > 1a) > test if ipa-ca-install works on replica with domain level 1 (test exists) > 1b) > test if ipa-ca-install works on replica with domain level 0 (test exists) > 1c) > test if ipa-ca-install works on master with domain level 1 (test exists) > 1d) > test if ipa-ca-install works on master with domain level 0 (test exists) > 1e) > test if ipa-ca-install with replica file fails with domain level 1 on > replica > 1f) > test if ipa-ca-install fails without replica file with domain level 0 > on replica > 1g) > test if ipa-ca-install works on CA-less master with domain level 0 > (I'm not sure but probably tests exists) > 1h) > test if ipa-ca-install works on CA-less master with domain level 1 > (I'm not sure but probably tests exists) > > 2) > KRA has been affected by replica promotion patches > 2a) > test if ipa-kra-install works on replica with domain level 1 (test exists) > 2b) > test if ipa-kra-install works on replica with domain level 0 (test exists) > 2c) > test if ipa-krainstall works on master with domain level 1 (test exists) > 2d) > test if ipa-kra-install works on master with domain level 0 (test exists) > 2e) > test if ipa-kra-install with replica file fails with domain level 1 on > replica > 2f) > test if ipa-kra-install fails without replica file with domain level 0 > on replica > > 3) (not sure if this belongs to replica promotion or topology plugin > testing) > ipa-replica-manage behaves differently with domain level 1 > 3a) > ipa-replica-manage connect should nto work with domain level 1 > 3b) > ipa-replica-manage disconnect should not work with domain level 1 > > 4) > ipa-csreplica-manage behaves differently with domain level 1 > 4a) > ipa-csreplica-manage connect should not work with domain level 1 > 4b) > ipa-csreplica-manage disconnect should not work with domain level 1 > 4c) > ipa-csreplica-manage del should not work with domain level 1 > > 5) (this is not related to replica so much, but we miss this test) > 5a) > create new replica after master is restored from backup with domain > level 1 > 5b) > create new replica after master is restored from backup with domain > level 0 > > Martin^2 > > 6) installation replica with a single command (client + replica install) https://fedorahosted.org/freeipa/ticket/5310 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Nov 23 12:31:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 13:31:23 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5653067A.1000709@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> Message-ID: <5653071B.1040802@redhat.com> On 23.11.2015 13:28, Tomas Babej wrote: > > > On 11/23/2015 01:11 PM, Jan Cholasta wrote: >> On 23.11.2015 12:53, Tomas Babej wrote: >>> Hi, >>> >>> If the code within the private_ccache contextmanager does not >>> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >>> will cause unnecessary termination of the code flow. >>> >>> Make sure the KRB5CCNAME is popped out of os.environ only if present. >>> >>> Tomas >> >> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. > > Yeah, well, both ways are equivalent, I found the if statement more > explicit. We can go with the suggested version, if it's more pleasing > though - patch is attached. > >> >> Also I don't think the comment is necessary, it's quite obvious what the >> code does. >> > > I don't think an explanatory comment can hurt, ever. Worst thing that > happens is that somebody is assured that he understands the code correctly. Actually the worst thing is that someone changes the code without changing the comment. If the comment does not add any real value, it's only a maintenance burden. -- Jan Cholasta From tbabej at redhat.com Mon Nov 23 12:40:26 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 13:40:26 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5653071B.1040802@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> <5653071B.1040802@redhat.com> Message-ID: <5653093A.2080609@redhat.com> On 11/23/2015 01:31 PM, Jan Cholasta wrote: > On 23.11.2015 13:28, Tomas Babej wrote: >> >> >> On 11/23/2015 01:11 PM, Jan Cholasta wrote: >>> On 23.11.2015 12:53, Tomas Babej wrote: >>>> Hi, >>>> >>>> If the code within the private_ccache contextmanager does not >>>> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >>>> will cause unnecessary termination of the code flow. >>>> >>>> Make sure the KRB5CCNAME is popped out of os.environ only if present. >>>> >>>> Tomas >>> >>> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. >> >> Yeah, well, both ways are equivalent, I found the if statement more >> explicit. We can go with the suggested version, if it's more pleasing >> though - patch is attached. >> >>> >>> Also I don't think the comment is necessary, it's quite obvious what the >>> code does. >>> >> >> I don't think an explanatory comment can hurt, ever. Worst thing that >> happens is that somebody is assured that he understands the code >> correctly. > > Actually the worst thing is that someone changes the code without > changing the comment. If the comment does not add any real value, it's > only a maintenance burden. > Yep, that's a real issue in our code base (i.e. I recently removed such a stale comment in f05846e26787da5ef6c996abf823fcc4a7f65e0f). Making sure the comments describe the implementation properly is on the author/reviewer though. What's "added value" highly depends on your skill set, and familiarity with the code base. Particularly the familiarity with the code base can diminish over time even for the author, and those are the times where comments can come to the rescue. For a newcomer to the project, even a trivial comment (from the point of view of the experienced developer) can be valuable. Tomas From mkosek at redhat.com Mon Nov 23 12:45:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Nov 2015 13:45:18 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5653093A.2080609@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> <5653071B.1040802@redhat.com> <5653093A.2080609@redhat.com> Message-ID: <56530A5E.6030308@redhat.com> On 11/23/2015 01:40 PM, Tomas Babej wrote: > > > On 11/23/2015 01:31 PM, Jan Cholasta wrote: >> On 23.11.2015 13:28, Tomas Babej wrote: >>> >>> >>> On 11/23/2015 01:11 PM, Jan Cholasta wrote: >>>> On 23.11.2015 12:53, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> If the code within the private_ccache contextmanager does not >>>>> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >>>>> will cause unnecessary termination of the code flow. >>>>> >>>>> Make sure the KRB5CCNAME is popped out of os.environ only if present. >>>>> >>>>> Tomas >>>> >>>> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. >>> >>> Yeah, well, both ways are equivalent, I found the if statement more >>> explicit. We can go with the suggested version, if it's more pleasing >>> though - patch is attached. >>> >>>> >>>> Also I don't think the comment is necessary, it's quite obvious what the >>>> code does. >>>> >>> >>> I don't think an explanatory comment can hurt, ever. Worst thing that >>> happens is that somebody is assured that he understands the code >>> correctly. >> >> Actually the worst thing is that someone changes the code without >> changing the comment. If the comment does not add any real value, it's >> only a maintenance burden. >> > > Yep, that's a real issue in our code base (i.e. I recently removed such > a stale comment in f05846e26787da5ef6c996abf823fcc4a7f65e0f). Making > sure the comments describe the implementation properly is on the > author/reviewer though. > > What's "added value" highly depends on your skill set, and familiarity > with the code base. Particularly the familiarity with the code base can > diminish over time even for the author, and those are the times where > comments can come to the rescue. > > For a newcomer to the project, even a trivial comment (from the point of > view of the experienced developer) can be valuable. While I agree with Tomas in general, in this particular case I also do not see the value of the comment. All is said in the 4 lines of code, no deep FreeIPA knowledge required: if original_value is not None: os.environ['KRB5CCNAME'] = original_value else: - os.environ.pop('KRB5CCNAME') + # No value was set originally, make sure no value is set now + os.environ.pop('KRB5CCNAME', None) I hope the discussion around the comment does not expand too much, there is enough work in 4.3 to do... From jcholast at redhat.com Mon Nov 23 12:50:40 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 13:50:40 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5653093A.2080609@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> <5653071B.1040802@redhat.com> <5653093A.2080609@redhat.com> Message-ID: <56530BA0.6070400@redhat.com> On 23.11.2015 13:40, Tomas Babej wrote: > > > On 11/23/2015 01:31 PM, Jan Cholasta wrote: >> On 23.11.2015 13:28, Tomas Babej wrote: >>> >>> >>> On 11/23/2015 01:11 PM, Jan Cholasta wrote: >>>> On 23.11.2015 12:53, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> If the code within the private_ccache contextmanager does not >>>>> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >>>>> will cause unnecessary termination of the code flow. >>>>> >>>>> Make sure the KRB5CCNAME is popped out of os.environ only if present. >>>>> >>>>> Tomas >>>> >>>> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. >>> >>> Yeah, well, both ways are equivalent, I found the if statement more >>> explicit. We can go with the suggested version, if it's more pleasing >>> though - patch is attached. >>> >>>> >>>> Also I don't think the comment is necessary, it's quite obvious what the >>>> code does. >>>> >>> >>> I don't think an explanatory comment can hurt, ever. Worst thing that >>> happens is that somebody is assured that he understands the code >>> correctly. >> >> Actually the worst thing is that someone changes the code without >> changing the comment. If the comment does not add any real value, it's >> only a maintenance burden. >> > > Yep, that's a real issue in our code base (i.e. I recently removed such > a stale comment in f05846e26787da5ef6c996abf823fcc4a7f65e0f). Making > sure the comments describe the implementation properly is on the > author/reviewer though. > > What's "added value" highly depends on your skill set, and familiarity > with the code base. Particularly the familiarity with the code base can > diminish over time even for the author, and those are the times where > comments can come to the rescue. Let's take a look at the code: if original_value is not None: os.environ['KRB5CCNAME'] = original_value else: os.environ.pop('KRB5CCNAME', None) Can you tell me what in there couldn't be obvious to a person with even the most basic skill set? IMHO a docstring for private_cccache would add some real value, but this comment alone does not. > > For a newcomer to the project, even a trivial comment (from the point of > view of the experienced developer) can be valuable. Following this logic, there should be a comment for every line of our code, which is ridiculous. -- Jan Cholasta From tbabej at redhat.com Mon Nov 23 13:27:53 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 14:27:53 +0100 Subject: [Freeipa-devel] [PATCH 0064] Check if IPA is configured before attempting a winsync migration In-Reply-To: <5652F463.8070909@redhat.com> References: <564F5A02.2060302@redhat.com> <5652F463.8070909@redhat.com> Message-ID: <56531459.30501@redhat.com> On 11/23/2015 12:11 PM, Martin Babinsky wrote: > On 11/20/2015 07:10 PM, Gabe Alford wrote: >> Thanks. Updated patch attached. >> >> >> Gabe >> >> On Fri, Nov 20, 2015 at 10:36 AM, Martin Babinsky > > wrote: >> >> On 11/20/2015 04:02 PM, Gabe Alford wrote: >> >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5470 >> >> Thanks, >> >> Gabe >> >> >> Hi Gabe, >> >> patch looks good. IMHO it would be better if you moved the check >> before API initialization like so: >> >> """ >> @@ -340,6 +340,12 @@ class WinsyncMigrate(admintool.AdminTool): >> the plumbing. >> """ >> >> + # Check if the IPA server is configured before attempting >> to migrate >> + try: >> + installutils.check_server_configuration() >> + except RuntimeError as e: >> + sys.exit(e) >> + >> # Finalize API >> api.bootstrap(in_server=True, context='server') >> api.finalize() >> """ >> >> There's no point in initializing API if there is no server installed. >> >> -- >> Martin^3 Babinsky >> >> > Thanks, ACK. > Pushed to: master: 84e479edaaeb64567f4cfc847aa735bbd106220d ipa-4-2: dbc442cc608a49726bcca9749b01dcd363b3ed8f From tbabej at redhat.com Mon Nov 23 13:35:22 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 14:35:22 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <56530BA0.6070400@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> <5653071B.1040802@redhat.com> <5653093A.2080609@redhat.com> <56530BA0.6070400@redhat.com> Message-ID: <5653161A.4080308@redhat.com> On 11/23/2015 01:50 PM, Jan Cholasta wrote: > On 23.11.2015 13:40, Tomas Babej wrote: >> >> >> On 11/23/2015 01:31 PM, Jan Cholasta wrote: >>> On 23.11.2015 13:28, Tomas Babej wrote: >>>> >>>> >>>> On 11/23/2015 01:11 PM, Jan Cholasta wrote: >>>>> On 23.11.2015 12:53, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> If the code within the private_ccache contextmanager does not >>>>>> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >>>>>> will cause unnecessary termination of the code flow. >>>>>> >>>>>> Make sure the KRB5CCNAME is popped out of os.environ only if present. >>>>>> >>>>>> Tomas >>>>> >>>>> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. >>>> >>>> Yeah, well, both ways are equivalent, I found the if statement more >>>> explicit. We can go with the suggested version, if it's more pleasing >>>> though - patch is attached. >>>> >>>>> >>>>> Also I don't think the comment is necessary, it's quite obvious >>>>> what the >>>>> code does. >>>>> >>>> >>>> I don't think an explanatory comment can hurt, ever. Worst thing that >>>> happens is that somebody is assured that he understands the code >>>> correctly. >>> >>> Actually the worst thing is that someone changes the code without >>> changing the comment. If the comment does not add any real value, it's >>> only a maintenance burden. >>> >> >> Yep, that's a real issue in our code base (i.e. I recently removed such >> a stale comment in f05846e26787da5ef6c996abf823fcc4a7f65e0f). Making >> sure the comments describe the implementation properly is on the >> author/reviewer though. >> >> What's "added value" highly depends on your skill set, and familiarity >> with the code base. Particularly the familiarity with the code base can >> diminish over time even for the author, and those are the times where >> comments can come to the rescue. > > Let's take a look at the code: > > if original_value is not None: > os.environ['KRB5CCNAME'] = original_value > else: > os.environ.pop('KRB5CCNAME', None) > > Can you tell me what in there couldn't be obvious to a person with even > the most basic skill set? > > IMHO a docstring for private_cccache would add some real value, but this > comment alone does not. > >> >> For a newcomer to the project, even a trivial comment (from the point of >> view of the experienced developer) can be valuable. > > Following this logic, there should be a comment for every line of our > code, which is ridiculous. > Here's the version of the patch with the comment removed. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0386-3-private_ccache-Harden-the-removal-of-KRB5CCNAME-env-.patch Type: text/x-patch Size: 1100 bytes Desc: not available URL: From tbabej at redhat.com Mon Nov 23 13:47:12 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Nov 2015 14:47:12 +0100 Subject: [Freeipa-devel] [PATCHES 151-153] ipasam: fix wrong usage of talloc_new() In-Reply-To: <20151118115903.GY9605@redhat.com> References: <20151118114546.GH21891@p.redhat.com> <20151118115903.GY9605@redhat.com> Message-ID: <565318E0.40003@redhat.com> On 11/18/2015 12:59 PM, Alexander Bokovoy wrote: > On Wed, 18 Nov 2015, Sumit Bose wrote: >> Hi, >> >> please find attached 3 small patches for ipasam. The first fixes >> https://fedorahosted.org/freeipa/ticket/5457 . The second is related >> because if the compat tree is enabled the lookup will still fails >> because the group is found twice. >> >> The third patch fixes an issue valgrind found while I was checking the >> other issue. > ACK for all three, they are obvious fixes (now ;). > > We should also commit them to 4.1 and 4.2. > Pushed to: ipa-4-2: 181d2542a00faaff3d8773536d88901acdefefb9 ipa-4-1: 47df94943ab9fac75fce429078528a2113c463d3 master: 657cf958c6fc6767d09cfbd2d84046d5b84e9f80 From fskola at redhat.com Mon Nov 23 13:59:34 2015 From: fskola at redhat.com (Filip =?UTF-8?B?xaBrb2xh?=) Date: Mon, 23 Nov 2015 14:59:34 +0100 Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin In-Reply-To: <20151120135636.71171d5c@vor2.netbox.priv> References: <20151120135636.71171d5c@vor2.netbox.priv> Message-ID: <20151123145934.36901470@dhcp-25-21.brq.redhat.com> Found couple of issues (broke some dependencies). NACK F. On Fri, 20 Nov 2015 13:56:36 +0100 Filip ?kola wrote: > Another one. > > F. From dkupka at redhat.com Mon Nov 23 14:17:04 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 23 Nov 2015 15:17:04 +0100 Subject: [Freeipa-devel] [PATCH 0067, 0068] ipa-{cacert-renew, otptoken-import}: Fix connection to ldap. In-Reply-To: <5652D7B8.8040200@redhat.com> References: <564DF8C5.9090706@redhat.com> <564ECBEB.2090505@redhat.com> <5652C5F7.2060006@redhat.com> <5652D7B8.8040200@redhat.com> Message-ID: <56531FE0.3020808@redhat.com> On 23/11/15 10:09, Jan Cholasta wrote: > On 23.11.2015 08:53, David Kupka wrote: >> On 20/11/15 08:29, Jan Cholasta wrote: >>> On 19.11.2015 17:28, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/5468 >>> >>> ipa-cacert-manage is not the only code which uses ldap2 this way. >>> >>> It would be better to find the root cause of this rather than working >>> around it. >>> >> >> The root cause is that some scripts are creating custom connection to >> LDAP and using api which is not connected to LDAP. >> As we discussed personally ipa-cacert-manage and ipa-otptoken-import >> have this issue. >> Updated patch and new one for ipa-otptoken-import attached. > > The patches do not apply on ipa-4-2. > You're right, rebased patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0067.1_ipa42-ipa-cacert-renew-Fix-connection-to-ldap.patch Type: text/x-patch Size: 4471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0068_ipa42-ipa-otptoken-import-Fix-connection-to-ldap.patch Type: text/x-patch Size: 1490 bytes Desc: not available URL: From rcritten at redhat.com Mon Nov 23 14:19:58 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Nov 2015 09:19:58 -0500 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5653161A.4080308@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> <5653071B.1040802@redhat.com> <5653093A.2080609@redhat.com> <56530BA0.6070400@redhat.com> <5653161A.4080308@redhat.com> Message-ID: <5653208E.1060405@redhat.com> Tomas Babej wrote: > > > On 11/23/2015 01:50 PM, Jan Cholasta wrote: >> On 23.11.2015 13:40, Tomas Babej wrote: >>> >>> >>> On 11/23/2015 01:31 PM, Jan Cholasta wrote: >>>> On 23.11.2015 13:28, Tomas Babej wrote: >>>>> >>>>> >>>>> On 11/23/2015 01:11 PM, Jan Cholasta wrote: >>>>>> On 23.11.2015 12:53, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> If the code within the private_ccache contextmanager does not >>>>>>> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >>>>>>> will cause unnecessary termination of the code flow. >>>>>>> >>>>>>> Make sure the KRB5CCNAME is popped out of os.environ only if present. >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. >>>>> >>>>> Yeah, well, both ways are equivalent, I found the if statement more >>>>> explicit. We can go with the suggested version, if it's more pleasing >>>>> though - patch is attached. >>>>> >>>>>> >>>>>> Also I don't think the comment is necessary, it's quite obvious >>>>>> what the >>>>>> code does. >>>>>> >>>>> >>>>> I don't think an explanatory comment can hurt, ever. Worst thing that >>>>> happens is that somebody is assured that he understands the code >>>>> correctly. >>>> >>>> Actually the worst thing is that someone changes the code without >>>> changing the comment. If the comment does not add any real value, it's >>>> only a maintenance burden. >>>> >>> >>> Yep, that's a real issue in our code base (i.e. I recently removed such >>> a stale comment in f05846e26787da5ef6c996abf823fcc4a7f65e0f). Making >>> sure the comments describe the implementation properly is on the >>> author/reviewer though. >>> >>> What's "added value" highly depends on your skill set, and familiarity >>> with the code base. Particularly the familiarity with the code base can >>> diminish over time even for the author, and those are the times where >>> comments can come to the rescue. >> >> Let's take a look at the code: >> >> if original_value is not None: >> os.environ['KRB5CCNAME'] = original_value >> else: >> os.environ.pop('KRB5CCNAME', None) >> >> Can you tell me what in there couldn't be obvious to a person with even >> the most basic skill set? >> >> IMHO a docstring for private_cccache would add some real value, but this >> comment alone does not. >> >>> >>> For a newcomer to the project, even a trivial comment (from the point of >>> view of the experienced developer) can be valuable. >> >> Following this logic, there should be a comment for every line of our >> code, which is ridiculous. >> > > Here's the version of the patch with the comment removed. IMHO the comment should have been something like "ensure no KRB5CCNAME otherwise it blows up in ..." If it took you 20 minutes to track down a one-line change then a comment might save the next guy who changes the behavior. rob From simo at redhat.com Mon Nov 23 14:34:49 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Nov 2015 09:34:49 -0500 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <5652C63E.5090206@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> <1448038723.5132.59.camel@redhat.com> <5652C63E.5090206@redhat.com> Message-ID: <1448289289.7892.13.camel@redhat.com> On Mon, 2015-11-23 at 08:54 +0100, Jan Cholasta wrote: > On 20.11.2015 17:58, Simo Sorce wrote: > > On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote: > >> On 19.11.2015 17:43, Simo Sorce wrote: > > [..] > >>> On the patches > >>> -- > >>> 509: > >>> - commit says only: "aci: add IPA servers host group 'ipaservers'" > >>> but it does other things like changing how CA renewal certificate acis > >>> are added, I think that must be separated in another patch. > >>> > >>> - Why "Manage Host Keytab" aci has been changed to exclude ipaservers ? > >> > >> To allow only members of the admins group to manage keytabs of IPA > >> servers. This is analogous to how only members of the admins group can > >> change passwords of other admins. > > > > I guess there is an interaction between ACIs I am not getting here, can > > you give a small overview of how we end up here ? > > This ACI allows admins to modify keytab of any host: > > aci: (targetattr = "krbPrincipalKey || krbLastPwdChange")(target = > "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl > "Admins can manage host keytab";allow (write) groupdn = > "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > > The original "Manage Host Keytab" ACI allows any user with the > corresponding permission to modify keytab of any host. > > The modified "Manage Host Keytab" ACI allows any user with the > correcponding permission to modify keytab of any host except for members > of ipaservers. > > The result is that the user has to be member of admins to be able to > modify keytab of IPA servers. > > > If IPAservers are not supposed to access those attributes, why are they > > added to the permissions at all ? > > The effect of the change is not to limit access of IPA servers, but to > limit access of non-admin users *to* IPA servers. Ah, thanks for explaining, this makes a lot of sense. > > Wouldn't it make sense to have 2 set of permissions ? > > One for admin type users (with access to all attributes) and one for > > less privileged users ? > > There already is a separate ACI which allows admins full access to the > attributes, see above. > > > > >>> - Why adding the host to the ipaservers group is done in the > >>> krbinstance ? I would expect LDAP ops to be mostly done in the > >>> DSinstance. > >> > >> It is the same place where the host entry is created. > > > > I will translate this with "historical" :-) > > > >>> - I do not see where the host is added to the ipaservers group on > >>> upgrade. > >> > >> It's in install/updates/20-ipaservers_hostgroup.update: > >> > >> add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX > > > > Ahh, I missed that, thanks! > > > >>> 510: > >>> - We should probably tightenup the ACI to allos host X to only add > >>> memberPrincipal = X and no other value, also the host should not be > >>> allowed to change the memberPrincipal attribute only the keys. > >>> If we can't express this in ACIs we can live with the ones you propose > >>> though. > >> > >> I think this can be done. > >> > >> memberPrincipal is included in the ACI because KEMLdap.set_key() touches > >> it. Perhaps it is not intentional? > > > > Yeah, it is a bug in set_key(), of course we need to add memberPrincipal > > when creating a whole new entry, but we should not modify it on existing > > entries. > > I though so, I will fix that. > > > > >>> 511: > >>> ack, but I think you should catch potential exceptions from the > >>> os.rmdir, as it will throw if there is some other file in the dir (for > >>> whatever reason). The exception can be safely ignored, we just do not > >>> want to blow up with a traceback here. > >> > >> OK. > >> > >>> > >>> 512: > >>> - I do not think this is correct, it seem to me you are overriding the > >>> local ccache (if any) with the host keytab. If I read this right, this > >>> means that if you run kinit admin && ipa-replica-install then you will > >>> kind your admin credentials gone and a host TGT instead. Am I reading > >>> this change correctly ? > >> > >> No. :-) Temporary ccache is now used for the install and the host is > >> kinited into it. The initial ccache is used only for connection check > >> (and adding the host to ipaservers in patch 514). Your kinit admin will > >> not be lost. > > > > Ok, got it. > > > >>> > >>> 513: > >>> Nack > >>> - Should be folded into 510 > >> > >> These ACIs are required only for patch 514. > > > > Yes, but they are close and will give a full picture of the change > > required for the feature if they are together. They won't hurt anything > > even if unused until a few patches later (IIUC). > > OK, makes sense. > > > > >>> - Should not allow all hosts in the domain but only ipaservers for aal > >>> three changes > >> > >> If the host isn't member of ipaservers before ipa-replica-install is > >> run, the "Check that we don't already have a replication agreement", > >> "Detect if the other master can handle replication managers" and "Find > >> if any server has a CA" steps will fail without these ACIs, which breaks > >> patch 514. > > > > Yes I understood that, but it is intentional, these are administrative > > checks, they need to be done as admin or with a host account that has > > been pre-added to the ipaservers group. We do not want to expose > > information to all other hosts in the domain as replication agreements > > can include passwords in some cases, or other access information the > > admin may not want to make available to random hosts. > > The access is limited to objectclass and cn only, so the hosts will be > able to see only if the entry exists. > > Additionaly, for replication agreements, only the host with the hostname > corresponding to the replication agreement can access the entry. I am not sure I really like to allow every host to find out the topology (by checking replication agreements on each master), but it is probably ok for now. > >>> 514: > >>> - Should be folded in 512, they are completely interdependent changes. > >> > >> Patch 512 works fine without this patch, but the host has to be member > >> of ipaservers before ipa-replica-install is run. > > > > Yeah, this is a problem, we do not want admins to have to do that, > > right ? > > > >>> - I do not understand how this works. promote_check() runs before > >>> promote() and will fail if the host is not already in the ipaservers > >>> group, so you will never be able to actually add the host to the group ? > >>> sounds like chicken-egg ... or what am I missing ? > >> > >> The chicken-egg is solved by the ACIs from patch 513. They allow any > >> host to perform the checks necessary for promote_check() to succeed, so > >> the host can be added to ipaservers in promote(). > > > > I do not see how ACIs solve the problem where the code check if the > > server is already in ipaservers, and the server isn't. My reading is > > this please tell me where I am wrong: > > > > Admin, out of the blue, run ipa-replica-install on a random client. > > promote_check(): > > checks if host is in ipaservers > > host is not in ipaservers and we bail --> end of the story here ? > > promote(): > > add itself to ipaserver <-- how do we get here ? > > It's: > > promote_check(): > check if host is in ipaservers > if host is not in ipaservers: > if the user can't modify ipaserver we bail --> end of story here I found out that I misread the check you did on the [member] attribute, now it all makes sense to me, thanks. > do a bunch of other checks (these require the ACIs if the host is not > in ipaservers) > promote(): > add the host to ipaservers (if it's not already in and the user can > modify ipaservers) HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Nov 23 14:37:56 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 15:37:56 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <1448289289.7892.13.camel@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> <1448038723.5132.59.camel@redhat.com> <5652C63E.5090206@redhat.com> <1448289289.7892.13.camel@redhat.com> Message-ID: <565324C4.1090007@redhat.com> On 23.11.2015 15:34, Simo Sorce wrote: > On Mon, 2015-11-23 at 08:54 +0100, Jan Cholasta wrote: >> On 20.11.2015 17:58, Simo Sorce wrote: >>> On Fri, 2015-11-20 at 16:49 +0100, Jan Cholasta wrote: >>>> On 19.11.2015 17:43, Simo Sorce wrote: >>> [..] >>>>> On the patches >>>>> -- >>>>> 509: >>>>> - commit says only: "aci: add IPA servers host group 'ipaservers'" >>>>> but it does other things like changing how CA renewal certificate acis >>>>> are added, I think that must be separated in another patch. >>>>> >>>>> - Why "Manage Host Keytab" aci has been changed to exclude ipaservers ? >>>> >>>> To allow only members of the admins group to manage keytabs of IPA >>>> servers. This is analogous to how only members of the admins group can >>>> change passwords of other admins. >>> >>> I guess there is an interaction between ACIs I am not getting here, can >>> you give a small overview of how we end up here ? >> >> This ACI allows admins to modify keytab of any host: >> >> aci: (targetattr = "krbPrincipalKey || krbLastPwdChange")(target = >> "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl >> "Admins can manage host keytab";allow (write) groupdn = >> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) >> >> The original "Manage Host Keytab" ACI allows any user with the >> corresponding permission to modify keytab of any host. >> >> The modified "Manage Host Keytab" ACI allows any user with the >> correcponding permission to modify keytab of any host except for members >> of ipaservers. >> >> The result is that the user has to be member of admins to be able to >> modify keytab of IPA servers. >> >>> If IPAservers are not supposed to access those attributes, why are they >>> added to the permissions at all ? >> >> The effect of the change is not to limit access of IPA servers, but to >> limit access of non-admin users *to* IPA servers. > > Ah, thanks for explaining, this makes a lot of sense. > >>> Wouldn't it make sense to have 2 set of permissions ? >>> One for admin type users (with access to all attributes) and one for >>> less privileged users ? >> >> There already is a separate ACI which allows admins full access to the >> attributes, see above. >> >>> >>>>> - Why adding the host to the ipaservers group is done in the >>>>> krbinstance ? I would expect LDAP ops to be mostly done in the >>>>> DSinstance. >>>> >>>> It is the same place where the host entry is created. >>> >>> I will translate this with "historical" :-) >>> >>>>> - I do not see where the host is added to the ipaservers group on >>>>> upgrade. >>>> >>>> It's in install/updates/20-ipaservers_hostgroup.update: >>>> >>>> add: member: fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX >>> >>> Ahh, I missed that, thanks! >>> >>>>> 510: >>>>> - We should probably tightenup the ACI to allos host X to only add >>>>> memberPrincipal = X and no other value, also the host should not be >>>>> allowed to change the memberPrincipal attribute only the keys. >>>>> If we can't express this in ACIs we can live with the ones you propose >>>>> though. >>>> >>>> I think this can be done. >>>> >>>> memberPrincipal is included in the ACI because KEMLdap.set_key() touches >>>> it. Perhaps it is not intentional? >>> >>> Yeah, it is a bug in set_key(), of course we need to add memberPrincipal >>> when creating a whole new entry, but we should not modify it on existing >>> entries. >> >> I though so, I will fix that. >> >>> >>>>> 511: >>>>> ack, but I think you should catch potential exceptions from the >>>>> os.rmdir, as it will throw if there is some other file in the dir (for >>>>> whatever reason). The exception can be safely ignored, we just do not >>>>> want to blow up with a traceback here. >>>> >>>> OK. >>>> >>>>> >>>>> 512: >>>>> - I do not think this is correct, it seem to me you are overriding the >>>>> local ccache (if any) with the host keytab. If I read this right, this >>>>> means that if you run kinit admin && ipa-replica-install then you will >>>>> kind your admin credentials gone and a host TGT instead. Am I reading >>>>> this change correctly ? >>>> >>>> No. :-) Temporary ccache is now used for the install and the host is >>>> kinited into it. The initial ccache is used only for connection check >>>> (and adding the host to ipaservers in patch 514). Your kinit admin will >>>> not be lost. >>> >>> Ok, got it. >>> >>>>> >>>>> 513: >>>>> Nack >>>>> - Should be folded into 510 >>>> >>>> These ACIs are required only for patch 514. >>> >>> Yes, but they are close and will give a full picture of the change >>> required for the feature if they are together. They won't hurt anything >>> even if unused until a few patches later (IIUC). >> >> OK, makes sense. >> >>> >>>>> - Should not allow all hosts in the domain but only ipaservers for aal >>>>> three changes >>>> >>>> If the host isn't member of ipaservers before ipa-replica-install is >>>> run, the "Check that we don't already have a replication agreement", >>>> "Detect if the other master can handle replication managers" and "Find >>>> if any server has a CA" steps will fail without these ACIs, which breaks >>>> patch 514. >>> >>> Yes I understood that, but it is intentional, these are administrative >>> checks, they need to be done as admin or with a host account that has >>> been pre-added to the ipaservers group. We do not want to expose >>> information to all other hosts in the domain as replication agreements >>> can include passwords in some cases, or other access information the >>> admin may not want to make available to random hosts. >> >> The access is limited to objectclass and cn only, so the hosts will be >> able to see only if the entry exists. >> >> Additionaly, for replication agreements, only the host with the hostname >> corresponding to the replication agreement can access the entry. > > I am not sure I really like to allow every host to find out the topology > (by checking replication agreements on each master), but it is probably > ok for now. Ad alternative is to add the host to ipaservers before the checks are done and remove it again if any of them fail. > >>>>> 514: >>>>> - Should be folded in 512, they are completely interdependent changes. >>>> >>>> Patch 512 works fine without this patch, but the host has to be member >>>> of ipaservers before ipa-replica-install is run. >>> >>> Yeah, this is a problem, we do not want admins to have to do that, >>> right ? >>> >>>>> - I do not understand how this works. promote_check() runs before >>>>> promote() and will fail if the host is not already in the ipaservers >>>>> group, so you will never be able to actually add the host to the group ? >>>>> sounds like chicken-egg ... or what am I missing ? >>>> >>>> The chicken-egg is solved by the ACIs from patch 513. They allow any >>>> host to perform the checks necessary for promote_check() to succeed, so >>>> the host can be added to ipaservers in promote(). >>> >>> I do not see how ACIs solve the problem where the code check if the >>> server is already in ipaservers, and the server isn't. My reading is >>> this please tell me where I am wrong: >>> >>> Admin, out of the blue, run ipa-replica-install on a random client. >>> promote_check(): >>> checks if host is in ipaservers >>> host is not in ipaservers and we bail --> end of the story here ? >>> promote(): >>> add itself to ipaserver <-- how do we get here ? >> >> It's: >> >> promote_check(): >> check if host is in ipaservers >> if host is not in ipaservers: >> if the user can't modify ipaserver we bail --> end of story here > > I found out that I misread the check you did on the [member] attribute, > now it all makes sense to me, thanks. > >> do a bunch of other checks (these require the ACIs if the host is not >> in ipaservers) >> promote(): >> add the host to ipaservers (if it's not already in and the user can >> modify ipaservers) > > HTH, > Simo. > -- Jan Cholasta From simo at redhat.com Mon Nov 23 14:47:04 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Nov 2015 09:47:04 -0500 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <565324C4.1090007@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> <1448038723.5132.59.camel@redhat.com> <5652C63E.5090206@redhat.com> <1448289289.7892.13.camel@redhat.com> <565324C4.1090007@redhat.com> Message-ID: <1448290024.7892.15.camel@redhat.com> On Mon, 2015-11-23 at 15:37 +0100, Jan Cholasta wrote: > > Ad alternative is to add the host to ipaservers before the checks are > done and remove it again if any of them fail. Too error prone, I am ok with the current way in your patches until/unless I can think of a fail safe way. :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Nov 23 14:52:15 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 15:52:15 +0100 Subject: [Freeipa-devel] [PATCH 0067, 0068] ipa-{cacert-renew, otptoken-import}: Fix connection to ldap. In-Reply-To: <56531FE0.3020808@redhat.com> References: <564DF8C5.9090706@redhat.com> <564ECBEB.2090505@redhat.com> <5652C5F7.2060006@redhat.com> <5652D7B8.8040200@redhat.com> <56531FE0.3020808@redhat.com> Message-ID: <5653281F.4060904@redhat.com> On 23.11.2015 15:17, David Kupka wrote: > On 23/11/15 10:09, Jan Cholasta wrote: >> On 23.11.2015 08:53, David Kupka wrote: >>> On 20/11/15 08:29, Jan Cholasta wrote: >>>> On 19.11.2015 17:28, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5468 >>>> >>>> ipa-cacert-manage is not the only code which uses ldap2 this way. >>>> >>>> It would be better to find the root cause of this rather than working >>>> around it. >>>> >>> >>> The root cause is that some scripts are creating custom connection to >>> LDAP and using api which is not connected to LDAP. >>> As we discussed personally ipa-cacert-manage and ipa-otptoken-import >>> have this issue. >>> Updated patch and new one for ipa-otptoken-import attached. >> >> The patches do not apply on ipa-4-2. >> > > You're right, rebased patches attached. Thanks, ACK. Pushed to: master: 2ef1eb0ae75270d37dcbb106e431a98eb02f0993 ipa-4-2: 8d59f7752c2539378d4383871f13a17b048edcc6 -- Jan Cholasta From jcholast at redhat.com Mon Nov 23 15:43:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Nov 2015 16:43:55 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <5652FD85.3050105@redhat.com> References: <5652FD85.3050105@redhat.com> Message-ID: <5653343B.6020200@redhat.com> Hi, On 23.11.2015 12:50, Tomas Babej wrote: > Hi, > > this patch implements the single command replica promotion&enrollment > for #5310. > > Tomas > > https://fedorahosted.org/freeipa/ticket/5310 1) ensure_enrolled() should be called from promote_check() after the client check is done: client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE) if not client_fstore.has_files(): ensure_enrolled(installer) 2) + server_name = Knob( + str, None, + description="fully qualified name of IPA server to enrooll to", + cli_name='server', + ) Please use the same identifier ipa-client-install uses, i.e. s/server_name/server/. Also there is typo in the description: "enrooll". 3) + host_name = Knob( + str, None, + description="fully qualified name of this host", + cli_name='hostname', + ) This knob is already defined in BaseServer, there's no need to redefine it here (just remove the "host_name = None"). If you want to change the description, change it in BaseServer. 4) + keytab = Knob( + str, None, + description="path to backed up keytab from previous enrollment", + cli_name='keytab', + ) ipa-client-install uses the short name -k for the keytab option, it should be used here as well. 5) The replica file argument conflicts with the --realm, --domain, --server, --admin-password and --principal options. This should be checked in Replica.__init__(). The --hostname option should either be conflicting as well or be implemented properly for legacy replica install. 6) I think --admin-password should be renamed to --password and the description changed, since it now also allows OTP enrollment. Honza -- Jan Cholasta From fskola at redhat.com Mon Nov 23 15:42:49 2015 From: fskola at redhat.com (Filip =?UTF-8?B?xaBrb2xh?=) Date: Mon, 23 Nov 2015 16:42:49 +0100 Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin In-Reply-To: <20151123145934.36901470@dhcp-25-21.brq.redhat.com> References: <20151120135636.71171d5c@vor2.netbox.priv> <20151123145934.36901470@dhcp-25-21.brq.redhat.com> Message-ID: <20151123164249.4a576706@dhcp-25-21.brq.redhat.com> Sending updated patch. F. On Mon, 23 Nov 2015 14:59:34 +0100 Filip ?kola wrote: > Found couple of issues (broke some dependencies). > > NACK > > F. > > On Fri, 20 Nov 2015 13:56:36 +0100 > Filip ?kola wrote: > > > Another one. > > > > F. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0002-2-Refactor-test_group_plugin.patch Type: text/x-patch Size: 84195 bytes Desc: not available URL: From ofayans at redhat.com Mon Nov 23 17:51:47 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 23 Nov 2015 18:51:47 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion Message-ID: <56535233.1020207@redhat.com> Hi all, Here is a draft of the Replica Promotion test plan http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From simo at redhat.com Mon Nov 23 18:49:35 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Nov 2015 13:49:35 -0500 Subject: [Freeipa-devel] [PATCH] Remove des3/arcfour from default enctypes Message-ID: <1448304575.7892.27.camel@redhat.com> Note, this does not touch the trust code because apparently we use only arcfour there. CCing Alexander to give me a comment about that, probably worth opening a ticket specific to trusts. Otherwise addresses #4740 Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-554-1-Use-only-AES-enctypes-by-default.patch Type: text/x-patch Size: 2216 bytes Desc: not available URL: From simo at redhat.com Mon Nov 23 20:18:51 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Nov 2015 15:18:51 -0500 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file Message-ID: <1448309931.7892.31.camel@redhat.com> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not provided on the command line. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-555-1-Support-sourcing-the-IPA-server-name-from-config.patch Type: text/x-patch Size: 6717 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 24 06:32:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 07:32:10 +0100 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <1448309931.7892.31.camel@redhat.com> References: <1448309931.7892.31.camel@redhat.com> Message-ID: <5654046A.3040002@redhat.com> On 23.11.2015 21:18, Simo Sorce wrote: > Fixes #2203 by reading the server name from /etc/ipa/default.conf if not > provided on the command line. > > Simo. Just a thought: it would be nice if we had libipaconfig and used it everywhere (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are at least 3 ipa config parser implementations now, each with its own quirks. Honza -- Jan Cholasta From ftweedal at redhat.com Tue Nov 24 07:37:54 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 24 Nov 2015 17:37:54 +1000 Subject: [Freeipa-devel] [PATCH] 0044-0045 Add profiles and default CA ACL on migration In-Reply-To: <5652D6DC.9050205@redhat.com> References: <20151123055423.GM5336@dhcp-40-8.bne.redhat.com> <5652D6DC.9050205@redhat.com> Message-ID: <20151124073753.GX5336@dhcp-40-8.bne.redhat.com> On Mon, Nov 23, 2015 at 10:05:32AM +0100, Jan Cholasta wrote: > On 23.11.2015 06:54, Fraser Tweedale wrote: > >Hi all, > > > >The attached patches fix #5459[1]: Default CA ACL rule is not > >created during ipa-replica-install. > > > >These patches apply on branch ipa-4-2. There is a (trivial) > >conflict in imports when applying to master. > > When a patch does not apply cleanly on all the target branches, you should > attach a rebased patch as well. > > > > >I strongly recommend review / testing of these patches with patches > >0042-0043[2] due to the prevalence of the other issue. > > > >[1] https://fedorahosted.org/freeipa/ticket/5459 > >[2] https://www.redhat.com/archives/freeipa-devel/2015-November/msg00298.html > > Patch 0044: ACK > > Patch 0045: > > 1) The check in caacl_del could be better, please take a look at how the > admins group is handled in ipalib/plugins/group.py for an example. You > should at least raise ProtectedEntryError rather than ValidationError. > > 2) _add_default_caacl() should be located in > ipaserver/install/cainstance.py. > > 3) Rather than calling the cainstance functions in replicainstall.install(), > they should be called from CAInstance.configure_instance() to make them > effective in ipa-ca-install and replica promotion as well. > > Honza > Updated patches for ipa-4-2 and master branches attached. The new patch 0045 is somewhat more intrusive; I have tested server install, replica install (with CA) from 3.0 and 4.2 master and ipa-ca-install with replica file from 3.0 master... but more testing would be no bad thing! I'll be offline for a few hours but will check back later tonight; see where things are at. Thanks, Fraser -------------- next part -------------- From 354796196f029865e4f5a652900288e043d9c03a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 23 Nov 2015 12:09:32 +1100 Subject: [PATCH 44/45] Do not erroneously reinit NSS in Dogtag interface The Dogtag interface always attempts to (re)init NSS, which can fail with SEC_ERROR_BUSY. Do not reinitialise NSS when it has already been initialised with the given dbdir. Part of: https://fedorahosted.org/freeipa/ticket/5459 --- ipapython/dogtag.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 71de96dc6889ca677db2cf7bb4f2d7b56df832f6..0436d5f464aac20c6b3c7db7b1c3a972d3533823 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -265,7 +265,8 @@ def https_request(host, port, url, secdir, password, nickname, """ def connection_factory(host, port): - conn = nsslib.NSSConnection(host, port, dbdir=secdir, + no_init = secdir == nsslib.current_dbdir + conn = nsslib.NSSConnection(host, port, dbdir=secdir, no_init=no_init, tls_version_min=api.env.tls_version_min, tls_version_max=api.env.tls_version_max) conn.set_debuglevel(0) -- 2.4.3 -------------- next part -------------- From c0234a507fada45eb64a00e1d3e6ed39321564bc Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 23 Nov 2015 12:09:32 +1100 Subject: [PATCH 44/45] Do not erroneously reinit NSS in Dogtag interface The Dogtag interface always attempts to (re)init NSS, which can fail with SEC_ERROR_BUSY. Do not reinitialise NSS when it has already been initialised with the given dbdir. Part of: https://fedorahosted.org/freeipa/ticket/5459 --- ipapython/dogtag.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 26b2de6ca77202fa9ccc61ee16ed7623e10ecb5f..8996902ba92f0fdd6106e2650c2decde375c593b 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -255,7 +255,8 @@ def https_request(host, port, url, secdir, password, nickname, """ def connection_factory(host, port): - conn = nsslib.NSSConnection(host, port, dbdir=secdir, + no_init = secdir == nsslib.current_dbdir + conn = nsslib.NSSConnection(host, port, dbdir=secdir, no_init=no_init, tls_version_min=api.env.tls_version_min, tls_version_max=api.env.tls_version_max) conn.set_debuglevel(0) -- 2.4.3 -------------- next part -------------- From 81d939ad6755ab80b7db2e592d08730d88f1e06b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 23 Nov 2015 12:09:32 +1100 Subject: [PATCH 45/45] Add profiles and default CA ACL on migration Profiles and the default CA ACL were not being added during replica install from pre-4.2 servers. Update ipa-replica-install to add these if they are missing. Also update the caacl plugin to prevent deletion of the default CA ACL and instruct the administrator to disable it instead. To ensure that the cainstance installation can add profiles, supply the RA certificate as part of the instance configuration. Certmonger renewal setup is avoided at this point because the NSSDB gets reinitialised later in installation procedure. Also move the addition of the default CA ACL from dsinstance installation to cainstance installation. Fixes: https://fedorahosted.org/freeipa/ticket/5459 --- install/share/Makefile.am | 1 - install/share/default-caacl.ldif | 11 --- install/updates/50-dogtag10-migration.update | 1 + ipalib/plugins/caacl.py | 8 +++ ipaserver/install/ca.py | 5 +- ipaserver/install/cainstance.py | 100 ++++++++++++++++++++------- ipaserver/install/dsinstance.py | 4 -- ipaserver/install/server/replicainstall.py | 3 + ipaserver/install/server/upgrade.py | 13 +--- 9 files changed, 90 insertions(+), 56 deletions(-) delete mode 100644 install/share/default-caacl.ldif diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 92508a9bab864fdfd3d299e52296f37580cabd2b..42f3972e1061fda5bfd23b2fa8f63d675f92f5ba 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -31,7 +31,6 @@ app_DATA = \ caJarSigningCert.cfg.template \ custodia.conf.template \ default-aci.ldif \ - default-caacl.ldif \ default-hbac.ldif \ default-smb-group.ldif \ default-trust-view.ldif \ diff --git a/install/share/default-caacl.ldif b/install/share/default-caacl.ldif deleted file mode 100644 index f3cd5b4d4e3a79bc6638dc1ffdd7028596ded254..0000000000000000000000000000000000000000 --- a/install/share/default-caacl.ldif +++ /dev/null @@ -1,11 +0,0 @@ -# default CA ACL that grants use of caIPAserviceCert on top-level CA to all hosts and services -dn: ipauniqueid=autogenerate,cn=caacls,cn=ca,$SUFFIX -changetype: add -objectclass: ipaassociation -objectclass: ipacaacl -ipauniqueid: autogenerate -cn: hosts_services_caIPAserviceCert -ipaenabledflag: TRUE -ipamembercertprofile: cn=caIPAserviceCert,cn=certprofiles,cn=ca,$SUFFIX -hostcategory: all -servicecategory: all diff --git a/install/updates/50-dogtag10-migration.update b/install/updates/50-dogtag10-migration.update index 2ab9d15bd220540dbc6b3fcd7928fc15c42caf80..0070c308aefc39aa4c27a046d185ce6d268e6270 100644 --- a/install/updates/50-dogtag10-migration.update +++ b/install/updates/50-dogtag10-migration.update @@ -16,3 +16,4 @@ addifexist:resourceACLS:certServer.ca.groups:execute:allow (execute) group="Admi addifexist:resourceACLS:certServer.ca.users:execute:allow (execute) group="Administrators":Admins may execute user operations replace:resourceACLS:certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group":Anybody is allowed to read domain.xml but only Subsystem group is allowed to modify the domain.xml::certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" || group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise RA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml replace:resourceACLS:certServer.ca.connectorInfo:read,modify:allow (modify,read) group="Enterprise KRA Administrators":Only Enterprise Administrators are allowed to update the connector information::certServer.ca.connectorInfo:read,modify:allow (read) group="Enterprise KRA Administrators";allow (modify) group="Enterprise KRA Administrators" || group="Subsystem Group":Only Enterprise Administrators and Subsystem Group are allowed to update the connector information +addifexist:resourceACLS:certServer.profile.configuration:read,modify:allow (read,modify) group="Certificate Manager Agents":Certificate Manager agents may modify (create/update/delete) and read profiles diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py index 247d6df143aef1fba9f0ee74a9f7d8386bef5180..64dbec16e11e9fa2a67287b195b4bd1180a379e7 100644 --- a/ipalib/plugins/caacl.py +++ b/ipalib/plugins/caacl.py @@ -307,6 +307,14 @@ class caacl_del(LDAPDelete): msg_summary = _('Deleted CA ACL "%(value)s"') + def pre_callback(self, ldap, dn, *keys, **options): + if keys[0] == 'hosts_services_caIPAserviceCert': + raise errors.ProtectedEntryError( + label=_("CA ACL"), + key=keys[0], + reason=_("default CA ACL can be only disabled")) + return dn + @register() class caacl_mod(LDAPUpdate): diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py index 8d0252cbb3c4141c882a252a7c65f062b1cb1447..51871f2dc18ae3b890dcd17656bef1914a658fee 100644 --- a/ipaserver/install/ca.py +++ b/ipaserver/install/ca.py @@ -138,9 +138,10 @@ def install_step_0(standalone, replica_config, options): if standalone: api.Backend.ldap2.disconnect() - cainstance.install_replica_ca(replica_config, postinstall) + cainstance.install_replica_ca(replica_config, postinstall, + ra_p12=getattr(options, 'ra_p12', None)) - if standalone: + if standalone and not api.Backend.ldap2.isconnected(): api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')), bind_pw=dm_password) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 448e42e2bab8370c0ec7caa2a189d2a1b33eaa18..90edb362f496b89f433532bf8786c29da3902de9 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -410,7 +410,7 @@ class CAInstance(DogtagInstance): cert_file=None, cert_chain_file=None, master_replication_port=None, subject_base=None, ca_signing_algorithm=None, - ca_type=None): + ca_type=None, ra_p12=None): """Create a CA instance. For Dogtag 9, this may involve creating the pki-ca instance. @@ -484,7 +484,10 @@ class CAInstance(DogtagInstance): self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) self.step("adding RA agent as a trusted user", self.__create_ca_agent) - self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) + elif ra_p12 is not None: + self.step("importing RA certificate from PKCS #12 file", + lambda: self.import_ra_cert(ra_p12, configure_renewal=False)) + self.step("authorizing RA to modify profiles", configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -492,9 +495,12 @@ class CAInstance(DogtagInstance): self.step("configure Server-Cert certificate renewal", self.track_servercert) self.step("Configure HTTP to proxy connections", self.http_proxy) - if not self.clone: - self.step("restarting certificate server", self.restart_instance) - self.step("Importing IPA certificate profiles", import_included_profiles) + self.step("restarting certificate server", self.restart_instance) + self.step("migrating certificate profiles to LDAP", + migrate_profiles_to_ldap) + self.step("importing IPA certificate profiles", + import_included_profiles) + self.step("adding default CA ACL", ensure_default_caacl) self.start_creation(runtime=210) @@ -921,7 +927,7 @@ class CAInstance(DogtagInstance): export_kra_agent_pem() - def import_ra_cert(self, rafile): + def import_ra_cert(self, rafile, configure_renewal=True): """ Cloned RAs will use the same RA agent cert as the master so we need to import from a PKCS#12 file. @@ -937,7 +943,8 @@ class CAInstance(DogtagInstance): finally: os.remove(agent_name) - self.configure_agent_renewal() + if configure_renewal: + self.configure_agent_renewal() export_kra_agent_pem() @@ -987,10 +994,6 @@ class CAInstance(DogtagInstance): conn.disconnect() - def __configure_profiles_acl(self): - """Allow the Certificate Manager Agents group to modify profiles.""" - configure_profiles_acl() - def __run_certutil(self, args, database=None, pwd_file=None, stdin=None): if not database: database = self.ra_agent_db @@ -1654,7 +1657,7 @@ def replica_ca_install_check(config): exit('IPA schema missing on master CA directory server') -def install_replica_ca(config, postinstall=False): +def install_replica_ca(config, postinstall=False, ra_p12=None): """ Install a CA on a replica. @@ -1691,7 +1694,7 @@ def install_replica_ca(config, postinstall=False): ca.create_ra_agent_db = False ca.configure_instance(config.host_name, config.dirman_password, config.dirman_password, - pkcs12_info=(cafile,), + pkcs12_info=(cafile,), ra_p12=ra_p12, master_host=config.master_host_name, master_replication_port=config.ca_ds_port, subject_base=config.subject_base) @@ -1816,6 +1819,14 @@ def update_people_entry(dercert): return True def ensure_ldap_profiles_container(): + ensure_entry( + DN(('ou', 'certificateProfiles'), ('ou', 'ca'), ('o', 'ipaca')), + objectclass=['top', 'organizationalUnit'], + ou=['certificateProfiles'], + ) + + +def ensure_entry(dn, **attrs): server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id @@ -1823,40 +1834,39 @@ def ensure_ldap_profiles_container(): if not conn.isconnected(): conn.connect(autobind=True) - dn = DN(('ou', 'certificateProfiles'), ('ou', 'ca'), ('o', 'ipaca')) try: conn.get_entry(dn) except errors.NotFound: # entry doesn't exist; add it - entry = conn.make_entry( - dn, - objectclass=['top', 'organizationalUnit'], - ou=['certificateProfiles'], - ) + entry = conn.make_entry(dn, **attrs) conn.add_entry(entry) conn.disconnect() def configure_profiles_acl(): + """Allow the Certificate Manager Agents group to modify profiles.""" server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id updated = False dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) - rule = ( + new_rules = [ 'certServer.profile.configuration:read,modify:allow (read,modify) ' 'group="Certificate Manager Agents":' - 'Certificate Manager agents may modify (create/update/delete) and read profiles' - ) - modlist = [(ldap.MOD_ADD, 'resourceACLS', [rule])] + 'Certificate Manager agents may modify (create/update/delete) and read profiles', + + 'certServer.ca.account:login,logout:allow (login,logout) ' + 'user="anybody":Anybody can login and logout', + ] conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) if not conn.isconnected(): conn.connect(autobind=True) - rules = conn.get_entry(dn).get('resourceACLS', []) - if rule not in rules: - conn.conn.modify_s(str(dn), modlist) + cur_rules = conn.get_entry(dn).get('resourceACLS', []) + add_rules = [rule for rule in new_rules if rule not in cur_rules] + if add_rules: + conn.conn.modify_s(str(dn), [(ldap.MOD_ADD, 'resourceACLS', add_rules)]) updated = True conn.disconnect() @@ -1876,6 +1886,17 @@ def import_included_profiles(): if not conn.isconnected(): conn.connect(autobind=True) + ensure_entry( + DN(('cn', 'ca'), api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['ca'], + ) + ensure_entry( + DN(api.env.container_certprofile, api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['certprofiles'], + ) + api.Backend.ra_certprofile._read_password() api.Backend.ra_certprofile.override_port = 8443 @@ -1981,6 +2002,33 @@ def _create_dogtag_profile(profile_id, profile_data): "(it is probably already enabled)") +def ensure_default_caacl(): + """Add the default CA ACL if missing.""" + if not api.Backend.ldap2.isconnected(): + try: + api.Backend.ldap2.connect(autobind=True) + except errors.PublicError as e: + root_logger.error("Cannot connect to LDAP to add CA ACLs: %s", e) + return + + ensure_entry( + DN(('cn', 'ca'), api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['ca'], + ) + ensure_entry( + DN(api.env.container_caacl, api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['certprofiles'], + ) + + if not api.Command.caacl_find()['result']: + api.Command.caacl_add(u'hosts_services_caIPAserviceCert', + hostcategory=u'all', servicecategory=u'all') + api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', + certprofile=(u'caIPAserviceCert',)) + + if __name__ == "__main__": standard_logging_setup("install.log") ds = dsinstance.DsInstance() diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 7bdcaea31dcdf593d1de3b98a2ddfb926c2ea990..c980ebf4e01c7524e34c41d064580c17a64f5f07 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -332,7 +332,6 @@ class DsInstance(service.Service): self.step("adding range check plugin", self.__add_range_check_plugin) if hbac_allow: self.step("creating default HBAC rule allow_all", self.add_hbac) - self.step("creating default CA ACL rule", self.add_caacl) self.step("adding sasl mappings to the directory", self.__configure_sasl_mappings) self.step("adding entries for topology management", self.__add_topology_entries) @@ -874,9 +873,6 @@ class DsInstance(service.Service): def add_hbac(self): self._ldap_mod("default-hbac.ldif", self.sub_dict) - def add_caacl(self): - self._ldap_mod("default-caacl.ldif", self.sub_dict) - def change_admin_password(self, password): root_logger.debug("Changing admin password") dirname = config_dirname(self.serverid) diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py index 5ce9eb7092b5349cc9db13b465b3d5b033538ab6..492ea72d88665cce50f359d15d3c45e267ed2f41 100644 --- a/ipaserver/install/server/replicainstall.py +++ b/ipaserver/install/server/replicainstall.py @@ -672,6 +672,9 @@ def install(installer): options.domain_name = config.domain_name options.host_name = config.host_name + if ipautil.file_exists(config.dir + "/cacert.p12"): + options.ra_p12 = config.dir + "/ra.p12" + ca.install(False, config, options) krb = install_krb(config, setup_pkinit=not options.no_pkinit) diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index b9621a39d6d5afc0f0e6eada7a635c98ee2f8e21..84339b0a26f1f45b668392739d014f051118c503 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1328,18 +1328,7 @@ def add_default_caacl(ca): return if ca.is_configured(): - if not api.Backend.ldap2.isconnected(): - try: - api.Backend.ldap2.connect(autobind=True) - except ipalib.errors.PublicError as e: - root_logger.error("Cannot connect to LDAP to add CA ACLs: %s", e) - return - - if not api.Command.caacl_find()['result']: - api.Command.caacl_add(u'hosts_services_caIPAserviceCert', - hostcategory=u'all', servicecategory=u'all') - api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', - certprofile=(u'caIPAserviceCert',)) + cainstance.ensure_default_caacl() sysupgrade.set_upgrade_state('caacl', 'add_default_caacl', True) -- 2.4.3 -------------- next part -------------- From b9523d1d101f39cd56bc23c8bb3bc782f44ca7b4 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 23 Nov 2015 12:09:32 +1100 Subject: [PATCH 45/45] Add profiles and default CA ACL on migration Profiles and the default CA ACL were not being added during replica install from pre-4.2 servers. Update ipa-replica-install to add these if they are missing. Also update the caacl plugin to prevent deletion of the default CA ACL and instruct the administrator to disable it instead. To ensure that the cainstance installation can add profiles, supply the RA certificate as part of the instance configuration. Certmonger renewal setup is avoided at this point because the NSSDB gets reinitialised later in installation procedure. Also move the addition of the default CA ACL from dsinstance installation to cainstance installation. Fixes: https://fedorahosted.org/freeipa/ticket/5459 --- install/share/Makefile.am | 1 - install/share/default-caacl.ldif | 11 --- install/updates/50-dogtag10-migration.update | 1 + ipalib/plugins/caacl.py | 8 +++ ipaserver/install/ca.py | 5 +- ipaserver/install/cainstance.py | 100 ++++++++++++++++++++------- ipaserver/install/dsinstance.py | 4 -- ipaserver/install/server/replicainstall.py | 3 + ipaserver/install/server/upgrade.py | 13 +--- 9 files changed, 90 insertions(+), 56 deletions(-) delete mode 100644 install/share/default-caacl.ldif diff --git a/install/share/Makefile.am b/install/share/Makefile.am index d68c40e693a1d86c70d8ccd81ef2c915b2e1f61e..e4cca8708ab0042d6cb37eba31341e53e3cdac4d 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -29,7 +29,6 @@ app_DATA = \ bootstrap-template.ldif \ caJarSigningCert.cfg.template \ default-aci.ldif \ - default-caacl.ldif \ default-hbac.ldif \ default-smb-group.ldif \ default-trust-view.ldif \ diff --git a/install/share/default-caacl.ldif b/install/share/default-caacl.ldif deleted file mode 100644 index f3cd5b4d4e3a79bc6638dc1ffdd7028596ded254..0000000000000000000000000000000000000000 --- a/install/share/default-caacl.ldif +++ /dev/null @@ -1,11 +0,0 @@ -# default CA ACL that grants use of caIPAserviceCert on top-level CA to all hosts and services -dn: ipauniqueid=autogenerate,cn=caacls,cn=ca,$SUFFIX -changetype: add -objectclass: ipaassociation -objectclass: ipacaacl -ipauniqueid: autogenerate -cn: hosts_services_caIPAserviceCert -ipaenabledflag: TRUE -ipamembercertprofile: cn=caIPAserviceCert,cn=certprofiles,cn=ca,$SUFFIX -hostcategory: all -servicecategory: all diff --git a/install/updates/50-dogtag10-migration.update b/install/updates/50-dogtag10-migration.update index 2ab9d15bd220540dbc6b3fcd7928fc15c42caf80..0070c308aefc39aa4c27a046d185ce6d268e6270 100644 --- a/install/updates/50-dogtag10-migration.update +++ b/install/updates/50-dogtag10-migration.update @@ -16,3 +16,4 @@ addifexist:resourceACLS:certServer.ca.groups:execute:allow (execute) group="Admi addifexist:resourceACLS:certServer.ca.users:execute:allow (execute) group="Administrators":Admins may execute user operations replace:resourceACLS:certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group":Anybody is allowed to read domain.xml but only Subsystem group is allowed to modify the domain.xml::certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" || group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise RA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml replace:resourceACLS:certServer.ca.connectorInfo:read,modify:allow (modify,read) group="Enterprise KRA Administrators":Only Enterprise Administrators are allowed to update the connector information::certServer.ca.connectorInfo:read,modify:allow (read) group="Enterprise KRA Administrators";allow (modify) group="Enterprise KRA Administrators" || group="Subsystem Group":Only Enterprise Administrators and Subsystem Group are allowed to update the connector information +addifexist:resourceACLS:certServer.profile.configuration:read,modify:allow (read,modify) group="Certificate Manager Agents":Certificate Manager agents may modify (create/update/delete) and read profiles diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py index 247d6df143aef1fba9f0ee74a9f7d8386bef5180..64dbec16e11e9fa2a67287b195b4bd1180a379e7 100644 --- a/ipalib/plugins/caacl.py +++ b/ipalib/plugins/caacl.py @@ -307,6 +307,14 @@ class caacl_del(LDAPDelete): msg_summary = _('Deleted CA ACL "%(value)s"') + def pre_callback(self, ldap, dn, *keys, **options): + if keys[0] == 'hosts_services_caIPAserviceCert': + raise errors.ProtectedEntryError( + label=_("CA ACL"), + key=keys[0], + reason=_("default CA ACL can be only disabled")) + return dn + @register() class caacl_mod(LDAPUpdate): diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py index 39f4435e2d8f1b66b4b1acf2f2219c33120707dc..84cbf423246534259cd6b7a8cca25caa16e5594f 100644 --- a/ipaserver/install/ca.py +++ b/ipaserver/install/ca.py @@ -134,9 +134,10 @@ def install_step_0(standalone, replica_config, options): if standalone: api.Backend.ldap2.disconnect() - cainstance.install_replica_ca(replica_config, postinstall) + cainstance.install_replica_ca(replica_config, postinstall, + ra_p12=getattr(options, 'ra_p12', None)) - if standalone: + if standalone and not api.Backend.ldap2.isconnected(): api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')), bind_pw=dm_password) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 3e3dce93de2b8ca48a3fe3ea5994ee92a1b0ce49..189876f3c0d980e78165d73eed86b2830ac8c5b8 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -391,7 +391,7 @@ class CAInstance(DogtagInstance): cert_file=None, cert_chain_file=None, master_replication_port=None, subject_base=None, ca_signing_algorithm=None, - ca_type=None): + ca_type=None, ra_p12=None): """Create a CA instance. For Dogtag 9, this may involve creating the pki-ca instance. @@ -465,7 +465,10 @@ class CAInstance(DogtagInstance): self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) self.step("adding RA agent as a trusted user", self.__create_ca_agent) - self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) + elif ra_p12 is not None: + self.step("importing RA certificate from PKCS #12 file", + lambda: self.import_ra_cert(ra_p12, configure_renewal=False)) + self.step("authorizing RA to modify profiles", configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -473,9 +476,12 @@ class CAInstance(DogtagInstance): self.step("configure Server-Cert certificate renewal", self.track_servercert) self.step("Configure HTTP to proxy connections", self.http_proxy) - if not self.clone: - self.step("restarting certificate server", self.restart_instance) - self.step("Importing IPA certificate profiles", import_included_profiles) + self.step("restarting certificate server", self.restart_instance) + self.step("migrating certificate profiles to LDAP", + migrate_profiles_to_ldap) + self.step("importing IPA certificate profiles", + import_included_profiles) + self.step("adding default CA ACL", ensure_default_caacl) self.start_creation(runtime=210) @@ -887,7 +893,7 @@ class CAInstance(DogtagInstance): export_kra_agent_pem() - def import_ra_cert(self, rafile): + def import_ra_cert(self, rafile, configure_renewal=True): """ Cloned RAs will use the same RA agent cert as the master so we need to import from a PKCS#12 file. @@ -903,7 +909,8 @@ class CAInstance(DogtagInstance): finally: os.remove(agent_name) - self.configure_agent_renewal() + if configure_renewal: + self.configure_agent_renewal() export_kra_agent_pem() @@ -953,10 +960,6 @@ class CAInstance(DogtagInstance): conn.disconnect() - def __configure_profiles_acl(self): - """Allow the Certificate Manager Agents group to modify profiles.""" - configure_profiles_acl() - def __run_certutil(self, args, database=None, pwd_file=None, stdin=None): if not database: database = self.ra_agent_db @@ -1491,7 +1494,7 @@ def replica_ca_install_check(config): exit('IPA schema missing on master CA directory server') -def install_replica_ca(config, postinstall=False): +def install_replica_ca(config, postinstall=False, ra_p12=None): """ Install a CA on a replica. @@ -1533,7 +1536,7 @@ def install_replica_ca(config, postinstall=False): ca.create_ra_agent_db = False ca.configure_instance(config.host_name, config.domain_name, config.dirman_password, config.dirman_password, - pkcs12_info=(cafile,), + pkcs12_info=(cafile,), ra_p12=ra_p12, master_host=config.master_host_name, master_replication_port=config.ca_ds_port, subject_base=config.subject_base) @@ -1658,6 +1661,14 @@ def update_people_entry(dercert): return True def ensure_ldap_profiles_container(): + ensure_entry( + DN(('ou', 'certificateProfiles'), ('ou', 'ca'), ('o', 'ipaca')), + objectclass=['top', 'organizationalUnit'], + ou=['certificateProfiles'], + ) + + +def ensure_entry(dn, **attrs): server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id @@ -1665,40 +1676,39 @@ def ensure_ldap_profiles_container(): if not conn.isconnected(): conn.connect(autobind=True) - dn = DN(('ou', 'certificateProfiles'), ('ou', 'ca'), ('o', 'ipaca')) try: conn.get_entry(dn) except errors.NotFound: # entry doesn't exist; add it - entry = conn.make_entry( - dn, - objectclass=['top', 'organizationalUnit'], - ou=['certificateProfiles'], - ) + entry = conn.make_entry(dn, **attrs) conn.add_entry(entry) conn.disconnect() def configure_profiles_acl(): + """Allow the Certificate Manager Agents group to modify profiles.""" server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id updated = False dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) - rule = ( + new_rules = [ 'certServer.profile.configuration:read,modify:allow (read,modify) ' 'group="Certificate Manager Agents":' - 'Certificate Manager agents may modify (create/update/delete) and read profiles' - ) - modlist = [(ldap.MOD_ADD, 'resourceACLS', [rule])] + 'Certificate Manager agents may modify (create/update/delete) and read profiles', + + 'certServer.ca.account:login,logout:allow (login,logout) ' + 'user="anybody":Anybody can login and logout', + ] conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) if not conn.isconnected(): conn.connect(autobind=True) - rules = conn.get_entry(dn).get('resourceACLS', []) - if rule not in rules: - conn.conn.modify_s(str(dn), modlist) + cur_rules = conn.get_entry(dn).get('resourceACLS', []) + add_rules = [rule for rule in new_rules if rule not in cur_rules] + if add_rules: + conn.conn.modify_s(str(dn), [(ldap.MOD_ADD, 'resourceACLS', add_rules)]) updated = True conn.disconnect() @@ -1718,6 +1728,17 @@ def import_included_profiles(): if not conn.isconnected(): conn.connect(autobind=True) + ensure_entry( + DN(('cn', 'ca'), api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['ca'], + ) + ensure_entry( + DN(api.env.container_certprofile, api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['certprofiles'], + ) + api.Backend.ra_certprofile._read_password() api.Backend.ra_certprofile.override_port = 8443 @@ -1823,6 +1844,33 @@ def _create_dogtag_profile(profile_id, profile_data): "(it is probably already enabled)") +def ensure_default_caacl(): + """Add the default CA ACL if missing.""" + if not api.Backend.ldap2.isconnected(): + try: + api.Backend.ldap2.connect(autobind=True) + except errors.PublicError as e: + root_logger.error("Cannot connect to LDAP to add CA ACLs: %s", e) + return + + ensure_entry( + DN(('cn', 'ca'), api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['ca'], + ) + ensure_entry( + DN(api.env.container_caacl, api.env.basedn), + objectclass=['top', 'nsContainer'], + cn=['certprofiles'], + ) + + if not api.Command.caacl_find()['result']: + api.Command.caacl_add(u'hosts_services_caIPAserviceCert', + hostcategory=u'all', servicecategory=u'all') + api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', + certprofile=(u'caIPAserviceCert',)) + + if __name__ == "__main__": standard_logging_setup("install.log") ds = dsinstance.DsInstance() diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index f33a9e03a4148dde69fc61441c878f5126f8e455..d78158532c4c88d9aa9acf3c65d278f5151458d8 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -310,7 +310,6 @@ class DsInstance(service.Service): self.step("adding range check plugin", self.__add_range_check_plugin) if hbac_allow: self.step("creating default HBAC rule allow_all", self.add_hbac) - self.step("creating default CA ACL rule", self.add_caacl) self.step("adding entries for topology management", self.__add_topology_entries) self.__common_post_setup() @@ -745,9 +744,6 @@ class DsInstance(service.Service): def add_hbac(self): self._ldap_mod("default-hbac.ldif", self.sub_dict) - def add_caacl(self): - self._ldap_mod("default-caacl.ldif", self.sub_dict) - def change_admin_password(self, password): root_logger.debug("Changing admin password") dirname = config_dirname(self.serverid) diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py index c1edd3e48d36c8ad62c6a72e988604b59c574c0c..4cb0fa7902903f976ea1f7d3ec9614dc93acd4a7 100644 --- a/ipaserver/install/server/replicainstall.py +++ b/ipaserver/install/server/replicainstall.py @@ -575,6 +575,9 @@ def install(installer): options.domain_name = config.domain_name options.host_name = config.host_name + if ipautil.file_exists(config.dir + "/cacert.p12"): + options.ra_p12 = config.dir + "/ra.p12" + ca.install(False, config, options) krb = install_krb(config, setup_pkinit=not options.no_pkinit) diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index c8f744c392c7b859459bda63c1f397226553d4ba..945cb3ebd63767cb1d57083e1da7c5605ac5a2f9 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1321,18 +1321,7 @@ def add_default_caacl(ca): return if ca.is_configured(): - if not api.Backend.ldap2.isconnected(): - try: - api.Backend.ldap2.connect(autobind=True) - except ipalib.errors.PublicError as e: - root_logger.error("Cannot connect to LDAP to add CA ACLs: %s", e) - return - - if not api.Command.caacl_find()['result']: - api.Command.caacl_add(u'hosts_services_caIPAserviceCert', - hostcategory=u'all', servicecategory=u'all') - api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', - certprofile=(u'caIPAserviceCert',)) + cainstance.ensure_default_caacl() sysupgrade.set_upgrade_state('caacl', 'add_default_caacl', True) -- 2.4.3 From pspacek at redhat.com Tue Nov 24 08:06:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Nov 2015 09:06:21 +0100 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <5654046A.3040002@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> Message-ID: <56541A7D.4070002@redhat.com> On 24.11.2015 07:32, Jan Cholasta wrote: > On 23.11.2015 21:18, Simo Sorce wrote: >> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not >> provided on the command line. >> >> Simo. > > Just a thought: it would be nice if we had libipaconfig and used it everywhere > (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are > at least 3 ipa config parser implementations now, each with its own quirks. Yeah, define a Augeas grammar for IPA config and call it. There is C and Python binding in RHEL 7.2 already. -- Petr^2 Spacek From jcholast at redhat.com Tue Nov 24 08:14:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 09:14:05 +0100 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <56541A7D.4070002@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> Message-ID: <56541C4D.2020904@redhat.com> On 24.11.2015 09:06, Petr Spacek wrote: > On 24.11.2015 07:32, Jan Cholasta wrote: >> On 23.11.2015 21:18, Simo Sorce wrote: >>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not >>> provided on the command line. >>> >>> Simo. >> >> Just a thought: it would be nice if we had libipaconfig and used it everywhere >> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are >> at least 3 ipa config parser implementations now, each with its own quirks. > > Yeah, define a Augeas grammar for IPA config and call it. There is C and > Python binding in RHEL 7.2 already. This won't be sufficient, as it should go beyond just parsing the config file - there are dynamic defaults and backward compatiblity support which should be the same everywhere too. -- Jan Cholasta From pspacek at redhat.com Tue Nov 24 08:56:55 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Nov 2015 09:56:55 +0100 Subject: [Freeipa-devel] [PATCH 0067] ipa-client-install: add support for Ed25519 SSH keys (RFC 7479) Message-ID: <56542657.9090304@redhat.com> Hello, ipa-client-install: add support for Ed25519 SSH keys (RFC 7479) https://fedorahosted.org/freeipa/ticket/5471 -- Petr^2 Spacek From pspacek at redhat.com Tue Nov 24 08:58:07 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Nov 2015 09:58:07 +0100 Subject: [Freeipa-devel] [PATCH 0067] ipa-client-install: add support for Ed25519 SSH keys (RFC 7479) In-Reply-To: <56542657.9090304@redhat.com> References: <56542657.9090304@redhat.com> Message-ID: <5654269F.80105@redhat.com> On 24.11.2015 09:56, Petr Spacek wrote: > Hello, > > ipa-client-install: add support for Ed25519 SSH keys (RFC 7479) > > https://fedorahosted.org/freeipa/ticket/5471 > Once again ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0067-ipa-client-install-add-support-for-Ed25519-SSH-keys-.patch Type: text/x-patch Size: 881 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 24 09:13:28 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 10:13:28 +0100 Subject: [Freeipa-devel] [PATCH] 0044-0045 Add profiles and default CA ACL on migration In-Reply-To: <20151124073753.GX5336@dhcp-40-8.bne.redhat.com> References: <20151123055423.GM5336@dhcp-40-8.bne.redhat.com> <5652D6DC.9050205@redhat.com> <20151124073753.GX5336@dhcp-40-8.bne.redhat.com> Message-ID: <56542A38.9090907@redhat.com> On 24.11.2015 08:37, Fraser Tweedale wrote: > On Mon, Nov 23, 2015 at 10:05:32AM +0100, Jan Cholasta wrote: >> On 23.11.2015 06:54, Fraser Tweedale wrote: >>> Hi all, >>> >>> The attached patches fix #5459[1]: Default CA ACL rule is not >>> created during ipa-replica-install. >>> >>> These patches apply on branch ipa-4-2. There is a (trivial) >>> conflict in imports when applying to master. >> >> When a patch does not apply cleanly on all the target branches, you should >> attach a rebased patch as well. >> >>> >>> I strongly recommend review / testing of these patches with patches >>> 0042-0043[2] due to the prevalence of the other issue. >>> >>> [1] https://fedorahosted.org/freeipa/ticket/5459 >>> [2] https://www.redhat.com/archives/freeipa-devel/2015-November/msg00298.html >> >> Patch 0044: ACK >> >> Patch 0045: >> >> 1) The check in caacl_del could be better, please take a look at how the >> admins group is handled in ipalib/plugins/group.py for an example. You >> should at least raise ProtectedEntryError rather than ValidationError. >> >> 2) _add_default_caacl() should be located in >> ipaserver/install/cainstance.py. >> >> 3) Rather than calling the cainstance functions in replicainstall.install(), >> they should be called from CAInstance.configure_instance() to make them >> effective in ipa-ca-install and replica promotion as well. >> >> Honza >> > Updated patches for ipa-4-2 and master branches attached. > > The new patch 0045 is somewhat more intrusive; I have tested server > install, replica install (with CA) from 3.0 and 4.2 master and > ipa-ca-install with replica file from 3.0 master... but more testing > would be no bad thing! Works for me, ACK. Pushed to: master: 620036d26e98fdcefff00168e9e5463a8257d49c ipa-4-2: a2371f38e4fb027aeacaf0ab6f2b35ae49fa41ea -- Jan Cholasta From mbasti at redhat.com Tue Nov 24 09:15:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 Nov 2015 10:15:49 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <564ED304.4020000@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> <564C7C74.3030607@redhat.com> <564DBBD5.6040805@redhat.com> <564DCA0E.40304@redhat.com> <564DCAFB.3050602@redhat.com> <564ED304.4020000@redhat.com> Message-ID: <56542AC5.4020804@redhat.com> On 20.11.2015 09:00, Jan Cholasta wrote: > On 19.11.2015 14:13, Jan Cholasta wrote: >> On 19.11.2015 14:09, Martin Babinsky wrote: >>> On 11/19/2015 01:08 PM, Martin Basti wrote: >>>> >>>> >>>> On 18.11.2015 14:26, Martin Basti wrote: >>>>> >>>>> >>>>> On 18.11.2015 14:24, Martin Kosek wrote: >>>>>> On 11/18/2015 02:18 PM, Martin Basti wrote: >>>>>>> >>>>>>> On 18.11.2015 13:55, Martin Kosek wrote: >>>>>>>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>>>>>>> + DEFAULT_TIME_LIMIT = -1.0 >>>>>>>>> + DEFAULT_SIZE_LIMIT = 0 >>>>>>>> ... >>>>>>>>> if time_limit is None or time_limit == 0: >>>>>>>>> - time_limit = -1.0 >>>>>>>>> + if self.time_limit is not None and self.time_limit >>>>>>>>> != 0: >>>>>>>>> + time_limit = self.time_limit >>>>>>>>> + else: >>>>>>>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>>>>>>> + >>>>>>>> I wonder why is the -1 default time limit a float number, I would >>>>>>>> expect that >>>>>>>> some trouble may emerge out of it. Maybe Rob knows? >>>>>>>> >>>>>>> Python LDAP allows to have smaller granularity than seconds and it >>>>>>> internally >>>>>>> convert time limit values to float. >>>>>> Hm, ok. I was just curious since the value we expose in API is Int >>>>>> and the >>>>>> default does not use the smaller granularity, so I was thinking "Why >>>>>> bother?". >>>>>> If it is fixed in your patch, good. If not, good also, no need to >>>>>> bikeshed here >>>>>> I suppose. >>>>> I just keep the original values there, I do not want to touch it with >>>>> this patch >>>>> >>>> Updated patch attached, the original one has wrong default limit for >>>> ldap2 >>>> >>>> >>> ACK >> >> Hold your horses. > > 1) The upgrade_ldapsearch_limit option is not very useful, either add > generic search_time_limit and search_records_limit options, or don't > add any options at all (which, incidentally, is exactly what the > ticket asks for). > > 2) The limits are not passed to the connection using __init__() > anywhere, so there is no need to have arguments for them. > > 3) Rather than adding layers of if statements everywhere, implement > the time_limit and size_limit attributes as properties. > > 4) Use config_entry.single_value when setting defaults in > ldap2.get_ipa_config(). > > BTW, add comments only when it's not obvious what the code does - a > comment saying "set defaults" above two .setdefault() calls is pretty > redundant. > Updated patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0350.3-Upgrade-increase-time-limit-for-upgrades.patch Type: text/x-patch Size: 8070 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 24 09:21:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 Nov 2015 10:21:59 +0100 Subject: [Freeipa-devel] [PATCH 0355-0365] Prevent using replica file with ipa-ca-install and domain Message-ID: <56542C37.9000603@redhat.com> https://fedorahosted.org/freeipa/ticket/5455 Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0355-ipa-ca-install-error-when-replica-file-is-passed-wit.patch Type: text/x-patch Size: 1125 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0356-KRA-install-show-installation-message-only-if-instal.patch Type: text/x-patch Size: 1700 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 24 09:24:51 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 10:24:51 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <5653343B.6020200@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> Message-ID: <56542CE3.6060001@redhat.com> On 23.11.2015 16:43, Jan Cholasta wrote: > Hi, > > On 23.11.2015 12:50, Tomas Babej wrote: >> Hi, >> >> this patch implements the single command replica promotion&enrollment >> for #5310. >> >> Tomas >> >> https://fedorahosted.org/freeipa/ticket/5310 > > 1) ensure_enrolled() should be called from promote_check() after the > client check is done: > > client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE) > if not client_fstore.has_files(): > ensure_enrolled(installer) > > > 2) > > + server_name = Knob( > + str, None, > + description="fully qualified name of IPA server to enrooll to", > + cli_name='server', > + ) > > Please use the same identifier ipa-client-install uses, i.e. > s/server_name/server/. > > Also there is typo in the description: "enrooll". > > > 3) > > + host_name = Knob( > + str, None, > + description="fully qualified name of this host", > + cli_name='hostname', > + ) > > This knob is already defined in BaseServer, there's no need to redefine > it here (just remove the "host_name = None"). > > If you want to change the description, change it in BaseServer. > > > 4) > > + keytab = Knob( > + str, None, > + description="path to backed up keytab from previous enrollment", > + cli_name='keytab', > + ) > > ipa-client-install uses the short name -k for the keytab option, it > should be used here as well. > > > 5) The replica file argument conflicts with the --realm, --domain, > --server, --admin-password and --principal options. This should be > checked in Replica.__init__(). > > The --hostname option should either be conflicting as well or be > implemented properly for legacy replica install. Actually, it should be conflicting, as it is provided by the replica file too. > > > 6) I think --admin-password should be renamed to --password and the > description changed, since it now also allows OTP enrollment. > > > Honza > -- Jan Cholasta From pvoborni at redhat.com Tue Nov 24 09:33:19 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Nov 2015 10:33:19 +0100 Subject: [Freeipa-devel] [PATCH 0355-0365] Prevent using replica file with ipa-ca-install and domain In-Reply-To: <56542C37.9000603@redhat.com> References: <56542C37.9000603@redhat.com> Message-ID: <56542EDF.5030504@redhat.com> On 11/24/2015 10:21 AM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5455 > > Patches attached. > A question/proposal which Martin K.raises during triage, adding here so it won't be overlooked: """ Do we want to keep replica file as optional with DL or reject it? Maybe it could be there as a workaround, if Custodia-based installation fails. """ I would reject it: since domain level 1 replica files should not be possible to create. Accepting old replica files would only complicate implementation and will create more paths which are needed to test and which can fail. -- Petr Vobornik From jcholast at redhat.com Tue Nov 24 09:37:56 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 10:37:56 +0100 Subject: [Freeipa-devel] [PATCH 0355-0365] Prevent using replica file with ipa-ca-install and domain In-Reply-To: <56542EDF.5030504@redhat.com> References: <56542C37.9000603@redhat.com> <56542EDF.5030504@redhat.com> Message-ID: <56542FF4.7050508@redhat.com> On 24.11.2015 10:33, Petr Vobornik wrote: > On 11/24/2015 10:21 AM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5455 >> >> Patches attached. >> > > A question/proposal which Martin K.raises during triage, adding here so > it won't be overlooked: > """ > Do we want to keep replica file as optional with DL or reject it? Maybe > it could be there as a workaround, if Custodia-based installation fails. > """ > > I would reject it: since domain level 1 replica files should not be > possible to create. Accepting old replica files would only complicate > implementation and will create more paths which are needed to test and > which can fail. +1 on rejecting it. -- Jan Cholasta From lkrispen at redhat.com Tue Nov 24 11:10:34 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 24 Nov 2015 12:10:34 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization In-Reply-To: <564F3577.9090207@redhat.com> References: <564F3577.9090207@redhat.com> Message-ID: <565445AA.4070404@redhat.com> Hi Petr, I'm testing these patches.Two observations so far: - in Topology->IPA Servers I see a table of my servers and the managed suffix column I see both suffixes, ipaca and the realm, but if I select one of the servers I Only see the realm suffix, this was different in the demo video - the graph layou is not stable. If I arrange it and the try some actions on a segment, eg try to remove one (which is rejected), the graph does change again- Ludwig On 11/20/2015 04:00 PM, Petr Vobornik wrote: > Patches 928-931 are prerequisites. > > Patches 932-934 implements the visualization > > Patches 935-936 adds 'add' and 'remove' segment functionality to the > visualization page. > > https://fedorahosted.org/freeipa/ticket/4286 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Nov 24 11:17:55 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Nov 2015 12:17:55 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization In-Reply-To: <565445AA.4070404@redhat.com> References: <564F3577.9090207@redhat.com> <565445AA.4070404@redhat.com> Message-ID: <56544763.2090905@redhat.com> On 11/24/2015 12:10 PM, Ludwig Krispenz wrote: > Hi Petr, > > I'm testing these patches.Two observations so far: > - in Topology->IPA Servers I see a table of my servers and the managed > suffix column I see both suffixes, ipaca and the realm, > but if I select one of the servers I Only see the realm suffix, this was > different in the demo video implemented in patch 927 (separate thread) > - the graph layou is not stable. If I arrange it and the try some > actions on a segment, eg try to remove one (which is rejected), the > graph does change again- Not sure if I understand it correctly. One can set static position to a node by double clicking on it (this needs to be somehow communicated) otherwise it is random - each refresh. Maybe we should not refresh on failed operation because there is no change. > > Ludwig > > On 11/20/2015 04:00 PM, Petr Vobornik wrote: >> Patches 928-931 are prerequisites. >> >> Patches 932-934 implements the visualization >> >> Patches 935-936 adds 'add' and 'remove' segment functionality to the >> visualization page. >> >> https://fedorahosted.org/freeipa/ticket/4286 >> >> > > > > -- Petr Vobornik From tbabej at redhat.com Tue Nov 24 11:37:28 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 24 Nov 2015 12:37:28 +0100 Subject: [Freeipa-devel] [DRAFT] FreeIPA 4.1.5 release notes Message-ID: <56544BF8.2050002@redhat.com> Hello all, Given the numerous stabilization and Fedora bug fixes, we have agreed to release a new FreeIPA 4.1 for Fedora 22. I prepared the release notes on FreeIPA.org wiki: http://www.freeipa.org/page/Releases/4.1.5 Updates or improvements to release notes page welcome. Particularly if you think some bug fixes/improvements deserves to be noted out as a highlight, please give a suggestion or edit the page directly :) Thanks, Tomas From mbasti at redhat.com Tue Nov 24 12:58:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 Nov 2015 13:58:14 +0100 Subject: [Freeipa-devel] [PATCH 0357] Installer: force service-add during replica install Message-ID: <56545EE6.5000202@redhat.com> https://fedorahosted.org/freeipa/ticket/5420 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0357-Install-Force-service-add-during-replica-promotion.patch Type: text/x-patch Size: 2192 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Nov 24 13:09:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 Nov 2015 14:09:29 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization In-Reply-To: <56544763.2090905@redhat.com> References: <564F3577.9090207@redhat.com> <565445AA.4070404@redhat.com> <56544763.2090905@redhat.com> Message-ID: <56546189.9010505@redhat.com> On 11/24/2015 12:17 PM, Petr Vobornik wrote: > On 11/24/2015 12:10 PM, Ludwig Krispenz wrote: >> Hi Petr, >> >> I'm testing these patches.Two observations so far: >> - in Topology->IPA Servers I see a table of my servers and the managed >> suffix column I see both suffixes, ipaca and the realm, >> but if I select one of the servers I Only see the realm suffix, this was >> different in the demo video > > implemented in patch 927 (separate thread) > >> - the graph layou is not stable. If I arrange it and the try some >> actions on a segment, eg try to remove one (which is rejected), the >> graph does change again- > > Not sure if I understand it correctly. One can set static position to a > node by double clicking on it (this needs to be somehow communicated) > otherwise it is random - each refresh. > > Maybe we should not refresh on failed operation because there is no change. +1, failed operations on segments should not trigger graph redraws. > >> >> Ludwig >> >> On 11/20/2015 04:00 PM, Petr Vobornik wrote: >>> Patches 928-931 are prerequisites. >>> >>> Patches 932-934 implements the visualization >>> >>> Patches 935-936 adds 'add' and 'remove' segment functionality to the >>> visualization page. >>> >>> https://fedorahosted.org/freeipa/ticket/4286 >>> >>> >> >> >> >> > > I have tested the new feature a bit (I have looked also on the code, but I do not speak JavaScript very well) and so far I have found these issues: 1.) If you first setup topology w/ domain level 0 and try to render topology graph, you are correctly informed that managed topology is available on domain level 1 only. IF you raise your domainlevel and click refresh, you get the same error message, probably because the request to get domainlevel is sent only in the beginning of session. You have to logout and then login back to see the graph. 2.) If I add a new segment using Add dialog and clicking 'Add & edit' button, I get the following error: """ IPA Error 3007: RequirementError 'topologysuffixcn' is required """ However the segment is created normally. I guess that there is some bug when viewing the segment immediately after creation. 3.) The key with suffix colors should be more descriptive. I would like to propose the following format: """ Color coding of segments by suffix: {suffix_name} ({suffix_dn}) e.g. ipaca (o=ipaca) realm (dc=ipa,dc=test) """ 4.) It would be nice if the graph canvas could be dynamically resized based on the container size, but I am not sure how difficult it is to implement it. (Graphical nitpick: I would change the color of nodes, green does not fit very well with the bluish/grey palette of other WebUI elements) Otherwise I think that it is a good start and additional features can be built on top of this patchset. -- Martin^3 Babinsky From lkrispen at redhat.com Tue Nov 24 13:33:04 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 24 Nov 2015 14:33:04 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization In-Reply-To: <56544763.2090905@redhat.com> References: <564F3577.9090207@redhat.com> <565445AA.4070404@redhat.com> <56544763.2090905@redhat.com> Message-ID: <56546710.1060002@redhat.com> On 11/24/2015 12:17 PM, Petr Vobornik wrote: > On 11/24/2015 12:10 PM, Ludwig Krispenz wrote: >> Hi Petr, >> >> I'm testing these patches.Two observations so far: >> - in Topology->IPA Servers I see a table of my servers and the managed >> suffix column I see both suffixes, ipaca and the realm, >> but if I select one of the servers I Only see the realm suffix, this was >> different in the demo video > > implemented in patch 927 (separate thread) thanks had missed this, shows up now > >> - the graph layou is not stable. If I arrange it and the try some >> actions on a segment, eg try to remove one (which is rejected), the >> graph does change again- > > Not sure if I understand it correctly. One can set static position to > a node by double clicking on it this works, but it is not obvious > (this needs to be somehow communicated) otherwise it is random - each > refresh. > > Maybe we should not refresh on failed operation because there is no > change. > >> >> Ludwig >> >> On 11/20/2015 04:00 PM, Petr Vobornik wrote: >>> Patches 928-931 are prerequisites. >>> >>> Patches 932-934 implements the visualization >>> >>> Patches 935-936 adds 'add' and 'remove' segment functionality to the >>> visualization page. >>> >>> https://fedorahosted.org/freeipa/ticket/4286 >>> >>> >> >> >> >> > > From simo at redhat.com Tue Nov 24 13:34:03 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 08:34:03 -0500 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <5654046A.3040002@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> Message-ID: <1448372043.7892.52.camel@redhat.com> On Tue, 2015-11-24 at 07:32 +0100, Jan Cholasta wrote: > On 23.11.2015 21:18, Simo Sorce wrote: > > Fixes #2203 by reading the server name from /etc/ipa/default.conf if not > > provided on the command line. > > > > Simo. > > Just a thought: it would be nice if we had libipaconfig and used it > everywhere (the framework, ipa-getkeytab, certmonger, ...). I don't like > that there are at least 3 ipa config parser implementations now, each > with its own quirks. Well I did not implement a new parser, merely used one that can be called from C code, ding-libs on which we already depend as sssd uses them. We could make python bindings for them perhaps, but I do not think it is really worth it yet. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Nov 24 13:53:57 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Nov 2015 08:53:57 -0500 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <56541A7D.4070002@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> Message-ID: <56546BF5.90507@redhat.com> Petr Spacek wrote: > On 24.11.2015 07:32, Jan Cholasta wrote: >> On 23.11.2015 21:18, Simo Sorce wrote: >>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not >>> provided on the command line. >>> >>> Simo. >> >> Just a thought: it would be nice if we had libipaconfig and used it everywhere >> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are >> at least 3 ipa config parser implementations now, each with its own quirks. > > Yeah, define a Augeas grammar for IPA config and call it. There is C and > Python binding in RHEL 7.2 already. > For what? It's a standard INI-format file. I don't know what quirks Honza is referring to unless he means the merging of context-specific files but that is an API-level construct so it doesn't apply to external entities. And note that this format was chosen specifically so we wouldn't be inventing our own format. rob From dkupka at redhat.com Tue Nov 24 13:58:41 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 24 Nov 2015 14:58:41 +0100 Subject: [Freeipa-devel] [PATCH 507] install: drop support for Dogtag 9 In-Reply-To: <5641B047.3050909@redhat.com> References: <5641AABD.7010809@redhat.com> <5641B047.3050909@redhat.com> Message-ID: <56546D11.2070602@redhat.com> On 10/11/15 09:52, Jan Cholasta wrote: > On 10.11.2015 09:28, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Actually working patch attached. > > > Hi, thanks for the patch. It works for me but needs trivial rebase. ACK when rebased. -- David Kupka From mbabinsk at redhat.com Tue Nov 24 14:26:32 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 Nov 2015 15:26:32 +0100 Subject: [Freeipa-devel] [PATCH 0102] disconnect ldap2 backend after adding default CA ACL profiles Message-ID: <56547398.3000002@redhat.com> This patch fixes the server/replica installer crash caused by leaking ldap2 connection introduced by commit 620036d26e98fdcefff00168e9e5463a8257d49c during fixing https://fedorahosted.org/freeipa/ticket/5459 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0102-disconnect-ldap2-backend-after-adding-default-CA-ACL.patch Type: text/x-patch Size: 1176 bytes Desc: not available URL: From tbabej at redhat.com Tue Nov 24 14:39:06 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 24 Nov 2015 15:39:06 +0100 Subject: [Freeipa-devel] [PATCH 0102] disconnect ldap2 backend after adding default CA ACL profiles In-Reply-To: <56547398.3000002@redhat.com> References: <56547398.3000002@redhat.com> Message-ID: <5654768A.5020109@redhat.com> On 11/24/2015 03:26 PM, Martin Babinsky wrote: > This patch fixes the server/replica installer crash caused by leaking > ldap2 connection introduced by commit > 620036d26e98fdcefff00168e9e5463a8257d49c during fixing > https://fedorahosted.org/freeipa/ticket/5459 > > > ACK. Pushed to: master: 341406d16540b1edc0d2792fe2cd9db75590f88e ipa-4-2: 0f39612730448993190b07708ad4c4956b214a81 From jseverance at redhat.com Tue Nov 24 14:27:42 2015 From: jseverance at redhat.com (Jenny Severance) Date: Tue, 24 Nov 2015 09:27:42 -0500 (EST) Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <56535233.1020207@redhat.com> References: <56535233.1020207@redhat.com> Message-ID: <413453403.23785908.1448375262186.JavaMail.zimbra@redhat.com> Hi, Is anyone providing feedback? At first glance (quick read through), it looks like it is just to see if commands work. Is there any functional followup testing after promotion to check if the replica is actually working. Object replication and authentication requests? Certificate functions, DNS etc ... ----- Original Message ----- > Hi all, > > Here is a draft of the Replica Promotion test plan > http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan > > > -- > Oleg Fayans > Quality Engineer > FreeIPA team > RedHat. > > -- Jenny Severance Manager, Quality Assurance From tbabej at redhat.com Tue Nov 24 14:56:49 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 24 Nov 2015 15:56:49 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <5653343B.6020200@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> Message-ID: <56547AB1.5030405@redhat.com> On 11/23/2015 04:43 PM, Jan Cholasta wrote: > Hi, > > On 23.11.2015 12:50, Tomas Babej wrote: >> Hi, >> >> this patch implements the single command replica promotion&enrollment >> for #5310. >> >> Tomas >> >> https://fedorahosted.org/freeipa/ticket/5310 > > 1) ensure_enrolled() should be called from promote_check() after the > client check is done: > > client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE) > if not client_fstore.has_files(): > ensure_enrolled(installer) > > > 2) > > + server_name = Knob( > + str, None, > + description="fully qualified name of IPA server to enrooll to", > + cli_name='server', > + ) > > Please use the same identifier ipa-client-install uses, i.e. > s/server_name/server/. > > Also there is typo in the description: "enrooll". Fixed. > > > 3) > > + host_name = Knob( > + str, None, > + description="fully qualified name of this host", > + cli_name='hostname', > + ) > > This knob is already defined in BaseServer, there's no need to redefine > it here (just remove the "host_name = None"). > > If you want to change the description, change it in BaseServer. Yep, that was the reasoning here. Changed in BaseServer. > > > 4) > > + keytab = Knob( > + str, None, > + description="path to backed up keytab from previous enrollment", > + cli_name='keytab', > + ) > > ipa-client-install uses the short name -k for the keytab option, it > should be used here as well. > Added. > > 5) The replica file argument conflicts with the --realm, --domain, > --server, --admin-password and --principal options. This should be > checked in Replica.__init__(). > > The --hostname option should either be conflicting as well or be > implemented properly for legacy replica install. > All of them now conflict --replica-file. > > 6) I think --admin-password should be renamed to --password and the > description changed, since it now also allows OTP enrollment. > I changed the requirements to mandate --principal when --password is used, as we discussed. The name of the option cannot really be changed, as it is already taken by the dm_password. > > Honza > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0385-2-replicainstall-Add-possiblity-to-install-client-in-o.patch Type: text/x-patch Size: 7536 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Nov 24 15:44:08 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 Nov 2015 16:44:08 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs Message-ID: <565485C8.7060606@redhat.com> https://fedorahosted.org/freeipa/ticket/5459 -- Martin^3 Babinsky From jcholast at redhat.com Tue Nov 24 15:48:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 16:48:10 +0100 Subject: [Freeipa-devel] [PATCH 0355-0365] Prevent using replica file with ipa-ca-install and domain In-Reply-To: <56542C37.9000603@redhat.com> References: <56542C37.9000603@redhat.com> Message-ID: <565486BA.7050104@redhat.com> On 24.11.2015 10:21, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5455 > > Patches attached. + def run(self): + self._run() Wouldn't it be better to rename _run() to run() instead? -- Jan Cholasta From mbabinsk at redhat.com Tue Nov 24 15:48:53 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 Nov 2015 16:48:53 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <565485C8.7060606@redhat.com> References: <565485C8.7060606@redhat.com> Message-ID: <565486E5.1060501@redhat.com> On 11/24/2015 04:44 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5459 > forgot to attach the actual file *slaps himself* -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0104-do-not-disconnect-when-using-existing-connection-to-.patch Type: text/x-patch Size: 1345 bytes Desc: not available URL: From mbasti at redhat.com Tue Nov 24 15:52:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 Nov 2015 16:52:51 +0100 Subject: [Freeipa-devel] [PATCH 0358] ipa-getkeytab: do not return error if translations cannot be loaded Message-ID: <565487D3.9000301@redhat.com> https://fedorahosted.org/freeipa/ticket/5483 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0358-ipa-getkeytab-do-not-return-error-when-translations-.patch Type: text/x-patch Size: 863 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 24 15:58:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 16:58:06 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <565486E5.1060501@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> Message-ID: <5654890E.2090001@redhat.com> On 24.11.2015 16:48, Martin Babinsky wrote: > On 11/24/2015 04:44 PM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5459 >> > forgot to attach the actual file *slaps himself* ipaserver/install/cainstance.py:1849: [E1101(no-member), ensure_default_caacl] Instance of 'API' has no 'Backed' member) -- Jan Cholasta From mbabinsk at redhat.com Tue Nov 24 16:01:56 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 Nov 2015 17:01:56 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <5654890E.2090001@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> Message-ID: <565489F4.2010204@redhat.com> On 11/24/2015 04:58 PM, Jan Cholasta wrote: > On 24.11.2015 16:48, Martin Babinsky wrote: >> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5459 >>> >> forgot to attach the actual file *slaps himself* > > ipaserver/install/cainstance.py:1849: [E1101(no-member), > ensure_default_caacl] Instance of 'API' has no 'Backed' member) > Fixed -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0104.1-do-not-disconnect-when-using-existing-connection-to-.patch Type: text/x-patch Size: 1346 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Nov 24 16:10:32 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 Nov 2015 17:10:32 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <565489F4.2010204@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> Message-ID: <56548BF8.50700@redhat.com> On 11/24/2015 05:01 PM, Martin Babinsky wrote: > On 11/24/2015 04:58 PM, Jan Cholasta wrote: >> On 24.11.2015 16:48, Martin Babinsky wrote: >>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5459 >>>> >>> forgot to attach the actual file *slaps himself* >> >> ipaserver/install/cainstance.py:1849: [E1101(no-member), >> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >> > > Fixed > > > Also attaching rebased patch for ipa-4-2 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0104-do-not-disconnect-when-using-existing-connection-to-.patch Type: text/x-patch Size: 1376 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Nov 24 16:17:46 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 24 Nov 2015 17:17:46 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <56548BF8.50700@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> Message-ID: <56548DAA.6090603@redhat.com> On 11/24/2015 05:10 PM, Martin Babinsky wrote: > On 11/24/2015 05:01 PM, Martin Babinsky wrote: >> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>> >>>> forgot to attach the actual file *slaps himself* >>> >>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>> >> >> Fixed >> >> >> > Also attaching rebased patch for ipa-4-2 > > > Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. -- Martin^3 Babinsky From pviktori at redhat.com Tue Nov 24 16:21:07 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 24 Nov 2015 17:21:07 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run In-Reply-To: <5652E174.50301@redhat.com> References: <5638B8F9.6010703@redhat.com> <564D0FD9.4070505@redhat.com> <5652B5AC.2040508@redhat.com> <5652E174.50301@redhat.com> Message-ID: <56548E73.1090105@redhat.com> On 11/23/2015 10:50 AM, Jan Cholasta wrote: > On 23.11.2015 07:43, Jan Cholasta wrote: >> On 19.11.2015 00:55, Petr Viktorin wrote: >>> On 11/03/2015 02:39 PM, Petr Viktorin wrote: >>>> Hello, >>>> Python 3's strings are Unicode, so data coming to or leaving a Python >>>> program needs to be decoded/encoded if it's to be handled as a string. >>>> One of the boundaries where encoding is necessary is external programs, >>>> specifically, ipautil.run. >>>> Unfortunately there's no one set of options that would work for all >>>> run() invocations, so I went through them all and specified the >>>> stdin/stdout/stderr encoding where necessary. I've also updated the >>>> call >>>> sites to make it clearer if the return values are used or not. >>>> If an encoding is not set, run() will accept/return bytes. (This is a >>>> fail-safe setting, since it can't raise errors, and using bytes where >>>> strings are expected generally fails loudly in py3.) >>>> >>>> Note that the changes are not effective under Python 2. >>> >>> ping, >>> Could someone look at this patch? >> >> Looking. > > 1) I think a better approach would be to use str for stdin/stdout/stderr > by default in both Python 2 and 3, i.e. do nothing in Python 2 and > encode/decode using locale.getpreferredencoding() in Python 3. This is > consistent with sys.std{in,out,err} in both Python 2 and 3. Using bytes > or different encoding should be opt-in. > > Note that different encoding should be used only if the LC_ALL or LANG > variables are overriden in the command's environment. That would assume the output of *everything* run via ipautil.run can be decoded using the locale encoding. Any stray invalid byte would make IPA crash, even in cases where we don't care about the output. IPA calls too many weird tools to assume they all output text. > 2) The str() here is wrong: > > + arg_string = nolog_replace(' '.join(str(shell_quote(a)) for a in > args), nolog) > > It converts b'data' to "b'data'" in Python 3. > > Popen accepts both bytes and text in both Python 2 and 3, so there is > nothing to be done for bytes arguments. Right, the logging for bytes arguments could be better. Changed. > 3) I think the "surrogateescape" error handler would be better for > non-strict decoding, as the text can be encoded back to bytes without > loss of information. Non-strict decoding is meant for logging, so we want backslash escapes rather than invalid surrogates. If you need round-tripping then you should use bytes. I've changed the error strategy to 'replace' though, as I realized 'backslashreplace' doesn't work for decoding. > 4) There are direct calls to subprocess.Popen() in a few places, have > you checked them as well? No. I'll do it in another patch; thanks for remembering that. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0748.2-Handle-encoding-for-ipautil.run.patch Type: text/x-patch Size: 55905 bytes Desc: not available URL: From simo at redhat.com Tue Nov 24 16:25:26 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 11:25:26 -0500 Subject: [Freeipa-devel] [PATCH 0358] ipa-getkeytab: do not return error if translations cannot be loaded In-Reply-To: <565487D3.9000301@redhat.com> References: <565487D3.9000301@redhat.com> Message-ID: <1448382326.7892.63.camel@redhat.com> On Tue, 2015-11-24 at 16:52 +0100, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5483 > > Patch attached. > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code LGTM. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Nov 24 16:30:15 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 11:30:15 -0500 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <56541C4D.2020904@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> <56541C4D.2020904@redhat.com> Message-ID: <1448382615.7892.65.camel@redhat.com> On Tue, 2015-11-24 at 09:14 +0100, Jan Cholasta wrote: > On 24.11.2015 09:06, Petr Spacek wrote: > > On 24.11.2015 07:32, Jan Cholasta wrote: > >> On 23.11.2015 21:18, Simo Sorce wrote: > >>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not > >>> provided on the command line. > >>> > >>> Simo. > >> > >> Just a thought: it would be nice if we had libipaconfig and used it everywhere > >> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are > >> at least 3 ipa config parser implementations now, each with its own quirks. > > > > Yeah, define a Augeas grammar for IPA config and call it. There is C and > > Python binding in RHEL 7.2 already. > > This won't be sufficient, as it should go beyond just parsing the config > file - there are dynamic defaults and backward compatiblity support > which should be the same everywhere too. This is a much bigger task, that someone keen on big refactoring may undertake, but I do not think we should delay this useful feature for that. It will be really easy to change this code to use whatever other ipa library when it materializes. For now this patch stands IMHO. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Nov 24 16:33:53 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 17:33:53 +0100 Subject: [Freeipa-devel] [PATCH 0358] ipa-getkeytab: do not return error if translations cannot be loaded In-Reply-To: <565487D3.9000301@redhat.com> References: <565487D3.9000301@redhat.com> Message-ID: <56549171.3010304@redhat.com> On 24.11.2015 16:52, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5483 > > Patch attached. Doesn't init_gettext() itself already print to stderr on failure? -- Jan Cholasta From jcholast at redhat.com Tue Nov 24 16:34:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 17:34:10 +0100 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <1448382615.7892.65.camel@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> <56541C4D.2020904@redhat.com> <1448382615.7892.65.camel@redhat.com> Message-ID: <56549182.40503@redhat.com> On 24.11.2015 17:30, Simo Sorce wrote: > On Tue, 2015-11-24 at 09:14 +0100, Jan Cholasta wrote: >> On 24.11.2015 09:06, Petr Spacek wrote: >>> On 24.11.2015 07:32, Jan Cholasta wrote: >>>> On 23.11.2015 21:18, Simo Sorce wrote: >>>>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not >>>>> provided on the command line. >>>>> >>>>> Simo. >>>> >>>> Just a thought: it would be nice if we had libipaconfig and used it everywhere >>>> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are >>>> at least 3 ipa config parser implementations now, each with its own quirks. >>> >>> Yeah, define a Augeas grammar for IPA config and call it. There is C and >>> Python binding in RHEL 7.2 already. >> >> This won't be sufficient, as it should go beyond just parsing the config >> file - there are dynamic defaults and backward compatiblity support >> which should be the same everywhere too. > > This is a much bigger task, that someone keen on big refactoring may > undertake, but I do not think we should delay this useful feature for > that. It will be really easy to change this code to use whatever other > ipa library when it materializes. > > For now this patch stands IMHO. Sure, I'm not suggesting otherwise. -- Jan Cholasta From jcholast at redhat.com Tue Nov 24 16:38:45 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Nov 2015 17:38:45 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <56548DAA.6090603@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> Message-ID: <56549295.6010004@redhat.com> On 24.11.2015 17:17, Martin Babinsky wrote: > On 11/24/2015 05:10 PM, Martin Babinsky wrote: >> On 11/24/2015 05:01 PM, Martin Babinsky wrote: >>> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>>> >>>>> forgot to attach the actual file *slaps himself* >>>> >>>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>>> >>> >>> Fixed >>> >>> >>> >> Also attaching rebased patch for ipa-4-2 >> >> >> > Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. Thanks, ACK. Pushed to: master: ed830af693c596b286b30959eb3166b59cc030c6 ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a -- Jan Cholasta From mbasti at redhat.com Tue Nov 24 16:38:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 Nov 2015 17:38:41 +0100 Subject: [Freeipa-devel] [PATCH 0358] ipa-getkeytab: do not return error if translations cannot be loaded In-Reply-To: <56549171.3010304@redhat.com> References: <565487D3.9000301@redhat.com> <56549171.3010304@redhat.com> Message-ID: <56549291.50200@redhat.com> On 24.11.2015 17:33, Jan Cholasta wrote: > On 24.11.2015 16:52, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5483 >> >> Patch attached. > > Doesn't init_gettext() itself already print to stderr on failure? > Nope From nsoman at redhat.com Tue Nov 24 17:33:16 2015 From: nsoman at redhat.com (Namita Krishnan) Date: Tue, 24 Nov 2015 12:33:16 -0500 (EST) Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <413453403.23785908.1448375262186.JavaMail.zimbra@redhat.com> References: <56535233.1020207@redhat.com> <413453403.23785908.1448375262186.JavaMail.zimbra@redhat.com> Message-ID: <1836567960.23993242.1448386396037.JavaMail.zimbra@redhat.com> > Hi, > Is anyone providing feedback? Yes, it is on DQE's plate (and on freeipa devel) This was an outcome of the retrospective we had that DQE will be involved as UQE writes test plan, and the subject header is as proposed to catch the attn :) But currently, are busy with Update1 activities. So Oleg, hoping to get back to you next week. > At first glance (quick read through), it looks > like it is just to see if commands work. Is there any functional followup > testing after promotion to check if the replica is actually working. Object > replication and authentication requests? Certificate functions, DNS etc ... Thanks, Jenny for the initial feedback :) > > > ----- Original Message ----- > > Hi all, > > > > Here is a draft of the Replica Promotion test plan > > http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan > > > > > > -- > > Oleg Fayans > > Quality Engineer > > FreeIPA team > > RedHat. > > > > > > -- > Jenny Severance > Manager, Quality Assurance > > From tbabej at redhat.com Tue Nov 24 17:38:16 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 24 Nov 2015 18:38:16 +0100 Subject: [Freeipa-devel] [PATCH 0357] Installer: force service-add during replica install In-Reply-To: <56545EE6.5000202@redhat.com> References: <56545EE6.5000202@redhat.com> Message-ID: <5654A088.6060209@redhat.com> On 11/24/2015 01:58 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5420 > > Patch attached. > > ACK. Pushed to master: 5427e7a8c7216b0aa54159a668951d71fb009139 From ofayans at redhat.com Tue Nov 24 19:00:55 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 24 Nov 2015 20:00:55 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <413453403.23785908.1448375262186.JavaMail.zimbra@redhat.com> References: <56535233.1020207@redhat.com> <413453403.23785908.1448375262186.JavaMail.zimbra@redhat.com> Message-ID: <5654B3E7.3010209@redhat.com> Hi Jenny, We have numerous tests checking the functionality of replicas. The tests are adapted to the new replica installation workflow (promotion), which means that there is presumably no need to create any additional tests. Our goal is to test the bits that were directly affected by the feature, i.e., upgrades between domain levels, ipa-replica-manage, etc. On 11/24/2015 03:27 PM, Jenny Severance wrote: > Hi, > Is anyone providing feedback? At first glance (quick read through), it looks like it is just to see if commands work. Is there any functional followup testing after promotion to check if the replica is actually working. Object replication and authentication requests? Certificate functions, DNS etc ... > > > ----- Original Message ----- >> Hi all, >> >> Here is a draft of the Replica Promotion test plan >> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >> >> >> -- >> Oleg Fayans >> Quality Engineer >> FreeIPA team >> RedHat. >> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From simo at redhat.com Tue Nov 24 19:36:17 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 14:36:17 -0500 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <56549182.40503@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> <56541C4D.2020904@redhat.com> <1448382615.7892.65.camel@redhat.com> <56549182.40503@redhat.com> Message-ID: <1448393777.29102.6.camel@redhat.com> On Tue, 2015-11-24 at 17:34 +0100, Jan Cholasta wrote: > On 24.11.2015 17:30, Simo Sorce wrote: > > On Tue, 2015-11-24 at 09:14 +0100, Jan Cholasta wrote: > >> On 24.11.2015 09:06, Petr Spacek wrote: > >>> On 24.11.2015 07:32, Jan Cholasta wrote: > >>>> On 23.11.2015 21:18, Simo Sorce wrote: > >>>>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not > >>>>> provided on the command line. > >>>>> > >>>>> Simo. > >>>> > >>>> Just a thought: it would be nice if we had libipaconfig and used it everywhere > >>>> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are > >>>> at least 3 ipa config parser implementations now, each with its own quirks. > >>> > >>> Yeah, define a Augeas grammar for IPA config and call it. There is C and > >>> Python binding in RHEL 7.2 already. > >> > >> This won't be sufficient, as it should go beyond just parsing the config > >> file - there are dynamic defaults and backward compatiblity support > >> which should be the same everywhere too. > > > > This is a much bigger task, that someone keen on big refactoring may > > undertake, but I do not think we should delay this useful feature for > > that. It will be really easy to change this code to use whatever other > > ipa library when it materializes. > > > > For now this patch stands IMHO. > > Sure, I'm not suggesting otherwise. Rebased patch that includes proper spec file buildrequires. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-555-2-Support-sourcing-the-IPA-server-name-from-config.patch Type: text/x-patch Size: 7201 bytes Desc: not available URL: From simo at redhat.com Tue Nov 24 19:42:32 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 14:42:32 -0500 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations Message-ID: <1448394152.29102.10.camel@redhat.com> Since some time we use the getkeytab operation to fetch keytabs on newer clients. According to bug #232 setkeytab can be used to circumvent password quality controls so it needs to be slowly retired. The attached patches implement #5485 in 2 parts. The first introduces the option DisableSetKeytab which globally disables the setkeytab extended operation. This is set to false by default for backwards compatibility. The second introduces an option called DisableUserSetKeytab, which is active by default in new installs (but not in upgraded ones), and only disables the use of setkeytab for ipa suers, but not for hosts/services. This is because user's are the ones that may abuse the interface to escape password policies and users also normally do not acquire keytabs, so it is a safe bet to disable just them by default in new installs. (Testing in progress) Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-556-1-Introduce-option-to-disable-the-SetKeytab-exop.patch Type: text/x-patch Size: 3224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-557-1-Disable-User-s-ability-to-use-the-setkeytab-exop.patch Type: text/x-patch Size: 4848 bytes Desc: not available URL: From simo at redhat.com Tue Nov 24 19:57:18 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 14:57:18 -0500 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <1448394152.29102.10.camel@redhat.com> References: <1448394152.29102.10.camel@redhat.com> Message-ID: <1448395038.29102.11.camel@redhat.com> On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote: > Since some time we use the getkeytab operation to fetch keytabs on newer > clients. According to bug #232 setkeytab can be used to circumvent > password quality controls so it needs to be slowly retired. > > The attached patches implement #5485 in 2 parts. > > The first introduces the option DisableSetKeytab which globally disables > the setkeytab extended operation. This is set to false by default for > backwards compatibility. > > The second introduces an option called DisableUserSetKeytab, which is > active by default in new installs (but not in upgraded ones), and only > disables the use of setkeytab for ipa suers, but not for hosts/services. > This is because user's are the ones that may abuse the interface to > escape password policies and users also normally do not acquire keytabs, > so it is a safe bet to disable just them by default in new installs. > > (Testing in progress) Tested and working as expected. Simo. > Simo. > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Simo Sorce * Red Hat, Inc * New York From jseverance at redhat.com Tue Nov 24 20:47:12 2015 From: jseverance at redhat.com (Jenny Severance) Date: Tue, 24 Nov 2015 15:47:12 -0500 (EST) Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <5654B3E7.3010209@redhat.com> References: <56535233.1020207@redhat.com> <413453403.23785908.1448375262186.JavaMail.zimbra@redhat.com> <5654B3E7.3010209@redhat.com> Message-ID: <63538302.24103752.1448398032152.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Jenny, > > We have numerous tests checking the functionality of replicas. The tests > are adapted to the new replica installation workflow (promotion), which > means that there is presumably no need to create any additional tests. > Our goal is to test the bits that were directly affected by the feature, > i.e., upgrades between domain levels, ipa-replica-manage, etc. Thanks for the clarification Oleg. So I presume that functional testing on the system after promotion will be handled by downstream QE and that's okay as long as we know what is tested and what we should cover. ~Jenny > > On 11/24/2015 03:27 PM, Jenny Severance wrote: > > Hi, > > Is anyone providing feedback? At first glance (quick read through), it > > looks like it is just to see if commands work. Is there any functional > > followup testing after promotion to check if the replica is actually > > working. Object replication and authentication requests? Certificate > > functions, DNS etc ... > > > > > > ----- Original Message ----- > >> Hi all, > >> > >> Here is a draft of the Replica Promotion test plan > >> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan > >> > >> > >> -- > >> Oleg Fayans > >> Quality Engineer > >> FreeIPA team > >> RedHat. > >> > >> > > > > -- > Oleg Fayans > Quality Engineer > FreeIPA team > RedHat. > > -- Jenny Severance Manager, Quality Assurance From simo at redhat.com Tue Nov 24 21:17:28 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 16:17:28 -0500 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <1448395038.29102.11.camel@redhat.com> References: <1448394152.29102.10.camel@redhat.com> <1448395038.29102.11.camel@redhat.com> Message-ID: <1448399848.29102.13.camel@redhat.com> On Tue, 2015-11-24 at 14:57 -0500, Simo Sorce wrote: > On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote: > > Since some time we use the getkeytab operation to fetch keytabs on newer > > clients. According to bug #232 setkeytab can be used to circumvent > > password quality controls so it needs to be slowly retired. > > > > The attached patches implement #5485 in 2 parts. > > > > The first introduces the option DisableSetKeytab which globally disables > > the setkeytab extended operation. This is set to false by default for > > backwards compatibility. > > > > The second introduces an option called DisableUserSetKeytab, which is > > active by default in new installs (but not in upgraded ones), and only > > disables the use of setkeytab for ipa suers, but not for hosts/services. > > This is because user's are the ones that may abuse the interface to > > escape password policies and users also normally do not acquire keytabs, > > so it is a safe bet to disable just them by default in new installs. > > > > (Testing in progress) > > Tested and working as expected. I realized that adding options to ipaConfig require to add them in the UI as well, attached patches add options in API.txt and config.py Make now complain I should change API Major or Minor, but it is not clear to me why given this are additional values and no real change or new function is introduced. What's the recommendation ? Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-556-2-Introduce-option-to-disable-the-SetKeytab-exop.patch Type: text/x-patch Size: 5183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-557-2-Disable-User-s-ability-to-use-the-setkeytab-exop.patch Type: text/x-patch Size: 6930 bytes Desc: not available URL: From simo at redhat.com Tue Nov 24 21:20:58 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 16:20:58 -0500 Subject: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names Message-ID: <1448400058.29102.17.camel@redhat.com> This addresses #3860, giving admins the option to not require preauth for Hosts and services. I did not add this option by default, although it does reduce the load on the KDC as well as speed up TGT acquisition for service principal accounts that acquire TGTs. Tested and working as expected (SPNs are not returned PREAUTH_NEEDED error while normal users are). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-558-1-Allow-admins-to-disable-preauth-for-SPNs.patch Type: text/x-patch Size: 6582 bytes Desc: not available URL: From simo at redhat.com Tue Nov 24 22:32:27 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 17:32:27 -0500 Subject: [Freeipa-devel] [PATCH 559] Fix kadmin for new users Message-ID: <1448404347.29102.23.camel@redhat.com> Ticket #937 was reopened a while ago because one corner case, new users that have never been assigned a password cause kadmin/kadmin.local to throw a fit when they try to visualize information about those user's principals. This patch fakes up modification information when no krbExtraData is available for the principal so that kadmin is happy. Tested and working as designed. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-559-1-Return-default-TL_DATA-is-krbExtraData-is-missing.patch Type: text/x-patch Size: 2260 bytes Desc: not available URL: From simo at redhat.com Tue Nov 24 23:09:30 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 18:09:30 -0500 Subject: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user Message-ID: <1448406570.29102.26.camel@redhat.com> This patch is untested and mostly an RFC. I think it is all we need to allow to specify authz data types per user and by setting the attribute to NONE preventing a user from getting MS-PAC data in their ticket. Alexander you changed quite a bit the code around here so I'd like to know if you think the change I made in the KDC will cause any issue with the special PACs we generate for master's principals. As far as I can tell it shouldn't. Any opinion is welcome. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-560-1-Allow-to-specify-Kerberos-authz-data-type-per-user.patch Type: text/x-patch Size: 3611 bytes Desc: not available URL: From simo at redhat.com Tue Nov 24 23:41:36 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Nov 2015 18:41:36 -0500 Subject: [Freeipa-devel] [PATCH 561] Catch up with upstream kerberos.ldif schema Message-ID: <1448408496.29102.31.camel@redhat.com> Not much action here, but it will close a ticket (#2086) and get us on par with upstream. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-561-1-Sync-kerberos-LDAP-schema-with-upstream.patch Type: text/x-patch Size: 5908 bytes Desc: not available URL: From ftweedal at redhat.com Wed Nov 25 04:34:40 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 25 Nov 2015 14:34:40 +1000 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <1448393777.29102.6.camel@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> <56541C4D.2020904@redhat.com> <1448382615.7892.65.camel@redhat.com> <56549182.40503@redhat.com> <1448393777.29102.6.camel@redhat.com> Message-ID: <20151125043440.GZ5336@dhcp-40-8.bne.redhat.com> On Tue, Nov 24, 2015 at 02:36:17PM -0500, Simo Sorce wrote: > On Tue, 2015-11-24 at 17:34 +0100, Jan Cholasta wrote: > > On 24.11.2015 17:30, Simo Sorce wrote: > > > On Tue, 2015-11-24 at 09:14 +0100, Jan Cholasta wrote: > > >> On 24.11.2015 09:06, Petr Spacek wrote: > > >>> On 24.11.2015 07:32, Jan Cholasta wrote: > > >>>> On 23.11.2015 21:18, Simo Sorce wrote: > > >>>>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not > > >>>>> provided on the command line. > > >>>>> > > >>>>> Simo. > > >>>> > > >>>> Just a thought: it would be nice if we had libipaconfig and used it everywhere > > >>>> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are > > >>>> at least 3 ipa config parser implementations now, each with its own quirks. > > >>> > > >>> Yeah, define a Augeas grammar for IPA config and call it. There is C and > > >>> Python binding in RHEL 7.2 already. > > >> > > >> This won't be sufficient, as it should go beyond just parsing the config > > >> file - there are dynamic defaults and backward compatiblity support > > >> which should be the same everywhere too. > > > > > > This is a much bigger task, that someone keen on big refactoring may > > > undertake, but I do not think we should delay this useful feature for > > > that. It will be really easy to change this code to use whatever other > > > ipa library when it materializes. > > > > > > For now this patch stands IMHO. > > > > Sure, I'm not suggesting otherwise. > > Rebased patch that includes proper spec file buildrequires. > > Simo. > Tested and works as expected (great usability win IMO). Man page should be updated accordingly. Cheers, Fraser From ftweedal at redhat.com Wed Nov 25 04:56:32 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 25 Nov 2015 14:56:32 +1000 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <56549295.6010004@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> Message-ID: <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: > On 24.11.2015 17:17, Martin Babinsky wrote: > >On 11/24/2015 05:10 PM, Martin Babinsky wrote: > >>On 11/24/2015 05:01 PM, Martin Babinsky wrote: > >>>On 11/24/2015 04:58 PM, Jan Cholasta wrote: > >>>>On 24.11.2015 16:48, Martin Babinsky wrote: > >>>>>On 11/24/2015 04:44 PM, Martin Babinsky wrote: > >>>>>>https://fedorahosted.org/freeipa/ticket/5459 > >>>>>> > >>>>>forgot to attach the actual file *slaps himself* > >>>> > >>>>ipaserver/install/cainstance.py:1849: [E1101(no-member), > >>>>ensure_default_caacl] Instance of 'API' has no 'Backed' member) > >>>> > >>> > >>>Fixed > >>> > >>> > >>> > >>Also attaching rebased patch for ipa-4-2 > >> > >> > >> > >Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. > > Thanks, ACK. > > Pushed to: > master: ed830af693c596b286b30959eb3166b59cc030c6 > ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a > Thanks for anaysing and fixing these connection issues which were presumably introduced by my patches. I did not hit these in my testing. Admittedly I was focused on the ipa-4-2 branch and my testing was mainly done there. Brittle LDAP connection logic in install and upgrade is an ongoing problem. What shall we do to improve the situation? Push connection details into the Backend and let it connect if/when needed, rather than managing connection state from the outside? I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 Thanks, Fraser From jcholast at redhat.com Wed Nov 25 06:21:25 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 07:21:25 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> Message-ID: <56555365.7050200@redhat.com> On 25.11.2015 05:56, Fraser Tweedale wrote: > On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: >> On 24.11.2015 17:17, Martin Babinsky wrote: >>> On 11/24/2015 05:10 PM, Martin Babinsky wrote: >>>> On 11/24/2015 05:01 PM, Martin Babinsky wrote: >>>>> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>>>>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>>>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>>>>> >>>>>>> forgot to attach the actual file *slaps himself* >>>>>> >>>>>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>>>>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>>>>> >>>>> >>>>> Fixed >>>>> >>>>> >>>>> >>>> Also attaching rebased patch for ipa-4-2 >>>> >>>> >>>> >>> Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. >> >> Thanks, ACK. >> >> Pushed to: >> master: ed830af693c596b286b30959eb3166b59cc030c6 >> ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a >> > Thanks for anaysing and fixing these connection issues which were > presumably introduced by my patches. I did not hit these in my > testing. Admittedly I was focused on the ipa-4-2 branch and my > testing was mainly done there. > > Brittle LDAP connection logic in install and upgrade is an ongoing > problem. What shall we do to improve the situation? Push > connection details into the Backend and let it connect if/when > needed, rather than managing connection state from the outside? > > I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 I don't think we need to be smart about it, everyone just needs to make sure that when an ad-hoc connection is opened somewhere, it is also closed in the same place. The same applies for any other resource. > > Thanks, > Fraser > -- Jan Cholasta From jcholast at redhat.com Wed Nov 25 06:52:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 07:52:55 +0100 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <1448399848.29102.13.camel@redhat.com> References: <1448394152.29102.10.camel@redhat.com> <1448395038.29102.11.camel@redhat.com> <1448399848.29102.13.camel@redhat.com> Message-ID: <56555AC7.2000908@redhat.com> On 24.11.2015 22:17, Simo Sorce wrote: > On Tue, 2015-11-24 at 14:57 -0500, Simo Sorce wrote: >> On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote: >>> Since some time we use the getkeytab operation to fetch keytabs on newer >>> clients. According to bug #232 setkeytab can be used to circumvent >>> password quality controls so it needs to be slowly retired. >>> >>> The attached patches implement #5485 in 2 parts. >>> >>> The first introduces the option DisableSetKeytab which globally disables >>> the setkeytab extended operation. This is set to false by default for >>> backwards compatibility. >>> >>> The second introduces an option called DisableUserSetKeytab, which is >>> active by default in new installs (but not in upgraded ones), and only >>> disables the use of setkeytab for ipa suers, but not for hosts/services. >>> This is because user's are the ones that may abuse the interface to >>> escape password policies and users also normally do not acquire keytabs, >>> so it is a safe bet to disable just them by default in new installs. >>> >>> (Testing in progress) >> >> Tested and working as expected. > > I realized that adding options to ipaConfig require to add them in the > UI as well, attached patches add options in API.txt and config.py > Make now complain I should change API Major or Minor, but it is not > clear to me why given this are additional values and no real change or > new function is introduced. What's the recommendation ? When does make complain? It is supposed to complain only when API.txt does not match code. Anyway, we usually bump minor version even for backward compatible changes, see e.g. commit 9549a59. -- Jan Cholasta From jcholast at redhat.com Wed Nov 25 07:09:00 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 08:09:00 +0100 Subject: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user In-Reply-To: <1448406570.29102.26.camel@redhat.com> References: <1448406570.29102.26.camel@redhat.com> Message-ID: <56555E8C.5020608@redhat.com> On 25.11.2015 00:09, Simo Sorce wrote: > This patch is untested and mostly an RFC. > > I think it is all we need to allow to specify authz data types per user > and by setting the attribute to NONE preventing a user from getting > MS-PAC data in their ticket. > > Alexander you changed quite a bit the code around here so I'd like to > know if you think the change I made in the KDC will cause any issue with > the special PACs we generate for master's principals. As far as I can > tell it shouldn't. > > Any opinion is welcome. Before your change, the server entry was checked for AS requests, now only the client entry is checked for AS requests. I'm not very familiar with ipa-kdb, but shouldn't the server entry still be checked as a fallback when there is no authorization data in the client entry? The attribute is exposed in the service plugin, shouldn't it be exposed in the user plugin as well? Nitpick: don't remove the space character here: "( uid )". -- Jan Cholasta From jcholast at redhat.com Wed Nov 25 08:01:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 09:01:06 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <56547AB1.5030405@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> <56547AB1.5030405@redhat.com> Message-ID: <56556AC2.1090302@redhat.com> On 24.11.2015 15:56, Tomas Babej wrote: > > > On 11/23/2015 04:43 PM, Jan Cholasta wrote: >> Hi, >> >> On 23.11.2015 12:50, Tomas Babej wrote: >>> Hi, >>> >>> this patch implements the single command replica promotion&enrollment >>> for #5310. >>> >>> Tomas >>> >>> https://fedorahosted.org/freeipa/ticket/5310 >> >> 1) ensure_enrolled() should be called from promote_check() after the >> client check is done: >> >> client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE) >> if not client_fstore.has_files(): >> ensure_enrolled(installer) Also it should no longer be decorated with @common_cleanup. >> >> >> 2) >> >> + server_name = Knob( >> + str, None, >> + description="fully qualified name of IPA server to enrooll to", >> + cli_name='server', >> + ) >> >> Please use the same identifier ipa-client-install uses, i.e. >> s/server_name/server/. >> >> Also there is typo in the description: "enrooll". > > Fixed. You don't need to set cli_name anymore, as it's the same as the default. > >> >> >> 3) >> >> + host_name = Knob( >> + str, None, >> + description="fully qualified name of this host", >> + cli_name='hostname', >> + ) >> >> This knob is already defined in BaseServer, there's no need to redefine >> it here (just remove the "host_name = None"). >> >> If you want to change the description, change it in BaseServer. > > Yep, that was the reasoning here. Changed in BaseServer. > >> >> >> 4) >> >> + keytab = Knob( >> + str, None, >> + description="path to backed up keytab from previous enrollment", >> + cli_name='keytab', >> + ) >> >> ipa-client-install uses the short name -k for the keytab option, it >> should be used here as well. >> > > Added. You don't need to set cli_name here as well. > >> >> 5) The replica file argument conflicts with the --realm, --domain, >> --server, --admin-password and --principal options. This should be >> checked in Replica.__init__(). >> >> The --hostname option should either be conflicting as well or be >> implemented properly for legacy replica install. >> > > All of them now conflict --replica-file. Replica file is not an option but rather an argument in ipa-replica-install. I think the error message should use the same wording which is used for --forwarder vs. --no-forwarder and --reverse-zone vs. --no-reverse: "You cannot specify a --something option together with replica file". > >> >> 6) I think --admin-password should be renamed to --password and the >> description changed, since it now also allows OTP enrollment. >> > > I changed the requirements to mandate --principal when --password is > used, as we discussed. I was wrong here, sorry. ipa-replica-install assumes "admin" for principal by default, so we just need to make sure ipa-client-install is called with --principal when password is used, whether it's the provided principal or the default "admin". > > The name of the option cannot really be changed, as it is already taken > by the dm_password. Right. -- Jan Cholasta From jcholast at redhat.com Wed Nov 25 08:04:22 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 09:04:22 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <5653208E.1060405@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> <5653071B.1040802@redhat.com> <5653093A.2080609@redhat.com> <56530BA0.6070400@redhat.com> <5653161A.4080308@redhat.com> <5653208E.1060405@redhat.com> Message-ID: <56556B86.6020909@redhat.com> On 23.11.2015 15:19, Rob Crittenden wrote: > Tomas Babej wrote: >> >> >> On 11/23/2015 01:50 PM, Jan Cholasta wrote: >>> On 23.11.2015 13:40, Tomas Babej wrote: >>>> >>>> >>>> On 11/23/2015 01:31 PM, Jan Cholasta wrote: >>>>> On 23.11.2015 13:28, Tomas Babej wrote: >>>>>> >>>>>> >>>>>> On 11/23/2015 01:11 PM, Jan Cholasta wrote: >>>>>>> On 23.11.2015 12:53, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> If the code within the private_ccache contextmanager does not >>>>>>>> set/removes the KRB5CCNAME, the pop method will raise KeyError, which >>>>>>>> will cause unnecessary termination of the code flow. >>>>>>>> >>>>>>>> Make sure the KRB5CCNAME is popped out of os.environ only if present. >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. >>>>>> >>>>>> Yeah, well, both ways are equivalent, I found the if statement more >>>>>> explicit. We can go with the suggested version, if it's more pleasing >>>>>> though - patch is attached. >>>>>> >>>>>>> >>>>>>> Also I don't think the comment is necessary, it's quite obvious >>>>>>> what the >>>>>>> code does. >>>>>>> >>>>>> >>>>>> I don't think an explanatory comment can hurt, ever. Worst thing that >>>>>> happens is that somebody is assured that he understands the code >>>>>> correctly. >>>>> >>>>> Actually the worst thing is that someone changes the code without >>>>> changing the comment. If the comment does not add any real value, it's >>>>> only a maintenance burden. >>>>> >>>> >>>> Yep, that's a real issue in our code base (i.e. I recently removed such >>>> a stale comment in f05846e26787da5ef6c996abf823fcc4a7f65e0f). Making >>>> sure the comments describe the implementation properly is on the >>>> author/reviewer though. >>>> >>>> What's "added value" highly depends on your skill set, and familiarity >>>> with the code base. Particularly the familiarity with the code base can >>>> diminish over time even for the author, and those are the times where >>>> comments can come to the rescue. >>> >>> Let's take a look at the code: >>> >>> if original_value is not None: >>> os.environ['KRB5CCNAME'] = original_value >>> else: >>> os.environ.pop('KRB5CCNAME', None) >>> >>> Can you tell me what in there couldn't be obvious to a person with even >>> the most basic skill set? >>> >>> IMHO a docstring for private_cccache would add some real value, but this >>> comment alone does not. >>> >>>> >>>> For a newcomer to the project, even a trivial comment (from the point of >>>> view of the experienced developer) can be valuable. >>> >>> Following this logic, there should be a comment for every line of our >>> code, which is ridiculous. >>> >> >> Here's the version of the patch with the comment removed. > > IMHO the comment should have been something like "ensure no KRB5CCNAME > otherwise it blows up in ..." If it took you 20 minutes to track down a > one-line change then a comment might save the next guy who changes the > behavior. As I wrote earlier, I think it would make more sense to put this into the docstring of private_ccache(). ACK on the patch. -- Jan Cholasta From jcholast at redhat.com Wed Nov 25 08:06:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 09:06:05 +0100 Subject: [Freeipa-devel] [PATCH 507] install: drop support for Dogtag 9 In-Reply-To: <56546D11.2070602@redhat.com> References: <5641AABD.7010809@redhat.com> <5641B047.3050909@redhat.com> <56546D11.2070602@redhat.com> Message-ID: <56556BED.1010102@redhat.com> On 24.11.2015 14:58, David Kupka wrote: > On 10/11/15 09:52, Jan Cholasta wrote: >> On 10.11.2015 09:28, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Actually working patch attached. >> >> >> > Hi, thanks for the patch. It works for me but needs trivial rebase. ACK > when rebased. > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-507.2-install-drop-support-for-Dogtag-9.patch Type: text/x-patch Size: 121053 bytes Desc: not available URL: From jcholast at redhat.com Wed Nov 25 08:13:07 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 09:13:07 +0100 Subject: [Freeipa-devel] [PATCH 507] install: drop support for Dogtag 9 In-Reply-To: <56556BED.1010102@redhat.com> References: <5641AABD.7010809@redhat.com> <5641B047.3050909@redhat.com> <56546D11.2070602@redhat.com> <56556BED.1010102@redhat.com> Message-ID: <56556D93.9040507@redhat.com> On 25.11.2015 09:06, Jan Cholasta wrote: > On 24.11.2015 14:58, David Kupka wrote: >> On 10/11/15 09:52, Jan Cholasta wrote: >>> On 10.11.2015 09:28, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>> >>> Actually working patch attached. >>> >>> >>> >> Hi, thanks for the patch. It works for me but needs trivial rebase. ACK >> when rebased. Thanks. Rebased patch attached in the previous message. Pushed to master: aeffe2da42734655cbaedb2c4d4f9e28bd2df1c0 -- Jan Cholasta From mbabinsk at redhat.com Wed Nov 25 08:28:27 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 25 Nov 2015 09:28:27 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <56555365.7050200@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> <56555365.7050200@redhat.com> Message-ID: <5655712B.2040304@redhat.com> On 11/25/2015 07:21 AM, Jan Cholasta wrote: > On 25.11.2015 05:56, Fraser Tweedale wrote: >> On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: >>> On 24.11.2015 17:17, Martin Babinsky wrote: >>>> On 11/24/2015 05:10 PM, Martin Babinsky wrote: >>>>> On 11/24/2015 05:01 PM, Martin Babinsky wrote: >>>>>> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>>>>>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>>>>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>>>>>> >>>>>>>> forgot to attach the actual file *slaps himself* >>>>>>> >>>>>>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>>>>>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>>>>>> >>>>>> >>>>>> Fixed >>>>>> >>>>>> >>>>>> >>>>> Also attaching rebased patch for ipa-4-2 >>>>> >>>>> >>>>> >>>> Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. >>> >>> Thanks, ACK. >>> >>> Pushed to: >>> master: ed830af693c596b286b30959eb3166b59cc030c6 >>> ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a >>> >> Thanks for anaysing and fixing these connection issues which were >> presumably introduced by my patches. I did not hit these in my >> testing. Admittedly I was focused on the ipa-4-2 branch and my >> testing was mainly done there. >> >> Brittle LDAP connection logic in install and upgrade is an ongoing >> problem. What shall we do to improve the situation? Push >> connection details into the Backend and let it connect if/when >> needed, rather than managing connection state from the outside? >> >> I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 > > I don't think we need to be smart about it, everyone just needs to make > sure that when an ad-hoc connection is opened somewhere, it is also > closed in the same place. The same applies for any other resource. > >> >> Thanks, >> Fraser >> > > Maybe it would be a good idea to implement some decorator/context manager to connect/disconnect from specified connection and wrap the CRUD code. Example usage: """ decorator: @connected(api.Backend.ldap2, ldapi=True) def do_magic(api, *args, **kwargs): # do stuff context manager: with connected(api.Backend.ldap2, ccache=example_ccache): do_some_other_magic() """ I remember Jan having some objections against this so it would be nice to hear why this is not a good idea. -- Martin^3 Babinsky From jcholast at redhat.com Wed Nov 25 08:56:57 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 09:56:57 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <5655712B.2040304@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> <56555365.7050200@redhat.com> <5655712B.2040304@redhat.com> Message-ID: <565577D9.9050406@redhat.com> On 25.11.2015 09:28, Martin Babinsky wrote: > On 11/25/2015 07:21 AM, Jan Cholasta wrote: >> On 25.11.2015 05:56, Fraser Tweedale wrote: >>> On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: >>>> On 24.11.2015 17:17, Martin Babinsky wrote: >>>>> On 11/24/2015 05:10 PM, Martin Babinsky wrote: >>>>>> On 11/24/2015 05:01 PM, Martin Babinsky wrote: >>>>>>> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>>>>>>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>>>>>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>>>>>>> >>>>>>>>> forgot to attach the actual file *slaps himself* >>>>>>>> >>>>>>>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>>>>>>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>>>>>>> >>>>>>> >>>>>>> Fixed >>>>>>> >>>>>>> >>>>>>> >>>>>> Also attaching rebased patch for ipa-4-2 >>>>>> >>>>>> >>>>>> >>>>> Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. >>>> >>>> Thanks, ACK. >>>> >>>> Pushed to: >>>> master: ed830af693c596b286b30959eb3166b59cc030c6 >>>> ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a >>>> >>> Thanks for anaysing and fixing these connection issues which were >>> presumably introduced by my patches. I did not hit these in my >>> testing. Admittedly I was focused on the ipa-4-2 branch and my >>> testing was mainly done there. >>> >>> Brittle LDAP connection logic in install and upgrade is an ongoing >>> problem. What shall we do to improve the situation? Push >>> connection details into the Backend and let it connect if/when >>> needed, rather than managing connection state from the outside? >>> >>> I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 >> >> I don't think we need to be smart about it, everyone just needs to make >> sure that when an ad-hoc connection is opened somewhere, it is also >> closed in the same place. The same applies for any other resource. >> >>> >>> Thanks, >>> Fraser >>> >> >> > > Maybe it would be a good idea to implement some decorator/context > manager to connect/disconnect from specified connection and wrap the > CRUD code. Example usage: > > """ > decorator: > @connected(api.Backend.ldap2, ldapi=True) > def do_magic(api, *args, **kwargs): > # do stuff > > context manager: > > with connected(api.Backend.ldap2, ccache=example_ccache): > do_some_other_magic() > """ > > I remember Jan having some objections against this so it would be nice > to hear why this is not a good idea. a) For ad-hoc connection objects, LDAPClient should be used instead of ldap2. It already supports the context manager protocol: with LDAPClient(uri) as conn: conn.gssapi_bind() ... b) The api.Backend.ldap2 object should be connected and disconnected exactly once per api object per command. This is not done ATM and the usual workaround is to connect it manually, which has lead to the mess we have now. Also, only GSSAPI authentication with valid IPA user credentials should be used with ldap2, even for ldapi connections. -- Jan Cholasta From akasurde at redhat.com Wed Nov 25 09:08:59 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 25 Nov 2015 14:38:59 +0530 Subject: [Freeipa-devel] [pytest-multihost-devel][PATCH] Functions for handling various file and directory operations Message-ID: <56557AAB.5020100@redhat.com> Hi All, Please find the patch for pytest-multihost-plugin. Fixes : https://fedorahosted.org/python-pytest-multihost/ticket/2 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: pytest-multihost-akasurde-0001-Added-functions-for-handling-various-file-operations.patch Type: text/x-patch Size: 3159 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Nov 25 09:19:31 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 25 Nov 2015 10:19:31 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <565577D9.9050406@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> <56555365.7050200@redhat.com> <5655712B.2040304@redhat.com> <565577D9.9050406@redhat.com> Message-ID: <56557D23.3060808@redhat.com> On 11/25/2015 09:56 AM, Jan Cholasta wrote: > On 25.11.2015 09:28, Martin Babinsky wrote: >> On 11/25/2015 07:21 AM, Jan Cholasta wrote: >>> On 25.11.2015 05:56, Fraser Tweedale wrote: >>>> On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: >>>>> On 24.11.2015 17:17, Martin Babinsky wrote: >>>>>> On 11/24/2015 05:10 PM, Martin Babinsky wrote: >>>>>>> On 11/24/2015 05:01 PM, Martin Babinsky wrote: >>>>>>>> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>>>>>>>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>>>>>>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>>>>>>>> >>>>>>>>>> forgot to attach the actual file *slaps himself* >>>>>>>>> >>>>>>>>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>>>>>>>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>>>>>>>> >>>>>>>> >>>>>>>> Fixed >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Also attaching rebased patch for ipa-4-2 >>>>>>> >>>>>>> >>>>>>> >>>>>> Ignore the rebased patch, the original 104.1 applies on 4-2 just >>>>>> fine. >>>>> >>>>> Thanks, ACK. >>>>> >>>>> Pushed to: >>>>> master: ed830af693c596b286b30959eb3166b59cc030c6 >>>>> ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a >>>>> >>>> Thanks for anaysing and fixing these connection issues which were >>>> presumably introduced by my patches. I did not hit these in my >>>> testing. Admittedly I was focused on the ipa-4-2 branch and my >>>> testing was mainly done there. >>>> >>>> Brittle LDAP connection logic in install and upgrade is an ongoing >>>> problem. What shall we do to improve the situation? Push >>>> connection details into the Backend and let it connect if/when >>>> needed, rather than managing connection state from the outside? >>>> >>>> I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 >>> >>> I don't think we need to be smart about it, everyone just needs to make >>> sure that when an ad-hoc connection is opened somewhere, it is also >>> closed in the same place. The same applies for any other resource. >>> >>>> >>>> Thanks, >>>> Fraser >>>> >>> >>> >> >> Maybe it would be a good idea to implement some decorator/context >> manager to connect/disconnect from specified connection and wrap the >> CRUD code. Example usage: >> >> """ >> decorator: >> @connected(api.Backend.ldap2, ldapi=True) >> def do_magic(api, *args, **kwargs): >> # do stuff >> >> context manager: >> >> with connected(api.Backend.ldap2, ccache=example_ccache): >> do_some_other_magic() >> """ >> >> I remember Jan having some objections against this so it would be nice >> to hear why this is not a good idea. > > a) For ad-hoc connection objects, LDAPClient should be used instead of > ldap2. It already supports the context manager protocol: > > with LDAPClient(uri) as conn: > conn.gssapi_bind() > ... > I didn't know that you can and should use LDAPClient this way. We should document it somewhere and encourage other contributors to use this approach. > b) The api.Backend.ldap2 object should be connected and disconnected > exactly once per api object per command. This is not done ATM and the > usual workaround is to connect it manually, which has lead to the mess > we have now. > Then we should find time to implement this behavior so that we can stop shooting ourselves in the foot when messing around with API commands. > Also, only GSSAPI authentication with valid IPA user credentials should > be used with ldap2, even for ldapi connections. > -- Martin^3 Babinsky From jcholast at redhat.com Wed Nov 25 09:25:21 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 10:25:21 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <564F4105.1040204@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> Message-ID: <56557E81.1020202@redhat.com> On 20.11.2015 16:49, Jan Cholasta wrote: > On 19.11.2015 17:43, Simo Sorce wrote: >> 510: >> - We should probably tightenup the ACI to allos host X to only add >> memberPrincipal = X and no other value, also the host should not be >> allowed to change the memberPrincipal attribute only the keys. >> If we can't express this in ACIs we can live with the ones you propose >> though. > > I think this can be done. Turns out this can be done only if member (or some other DN attribute) is used instead of memberPrincipal. So, to reiterate: >>> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? >>> >>> If 'member' was used instead, we would gain referential integrity and >>> the ability to add ACIs based on the attribute (think >>> userattr="member#USERDN"). >> >> To avoid referential integrity and mixup with other group objects, it >> was intentional. Why is referential integrity a problem? Mixup with other group objects can be solved by using a different attribute. -- Jan Cholasta From sbose at redhat.com Wed Nov 25 09:24:18 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 25 Nov 2015 10:24:18 +0100 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <1448394152.29102.10.camel@redhat.com> References: <1448394152.29102.10.camel@redhat.com> Message-ID: <20151125092418.GA4085@p.redhat.com> On Tue, Nov 24, 2015 at 02:42:32PM -0500, Simo Sorce wrote: > Since some time we use the getkeytab operation to fetch keytabs on newer > clients. According to bug #232 setkeytab can be used to circumvent > password quality controls so it needs to be slowly retired. ipasam uses this exop to create the cross-realm TGT principal objects, krbtgt/DOM.A at DOM.B. What should be used instead to make sure that setkeytab can safely be disabled? bye, Sumit > > The attached patches implement #5485 in 2 parts. > > The first introduces the option DisableSetKeytab which globally disables > the setkeytab extended operation. This is set to false by default for > backwards compatibility. > > The second introduces an option called DisableUserSetKeytab, which is > active by default in new installs (but not in upgraded ones), and only > disables the use of setkeytab for ipa suers, but not for hosts/services. > This is because user's are the ones that may abuse the interface to > escape password policies and users also normally do not acquire keytabs, > so it is a safe bet to disable just them by default in new installs. > > (Testing in progress) > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Wed Nov 25 09:24:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 10:24:47 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <56535233.1020207@redhat.com> References: <56535233.1020207@redhat.com> Message-ID: <56557E5F.7020809@redhat.com> On 23.11.2015 18:51, Oleg Fayans wrote: > Hi all, > > Here is a draft of the Replica Promotion test plan > http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan > > Hello, Test case: ipa-replica-manage is deprecated in domain level 1 I would be more specific in this test case, deprecated is only connect and disconnect subcommand You have tests for replica manage, but as I wrote in different thread[1] on freeipa-devel, also ipa-csreplica-manage works different with domain level 1. 4) ipa-csreplica-manage behaves differently with domain level 1 4a) ipa-csreplica-manage connect should not work with domain level 1 4b) ipa-csreplica-manage disconnect should not work with domain level 1 4c) ipa-csreplica-manage del should not work with domain level 1 IMO we should have also tests for ipa-replica-manage and ipa-csreplica-manage with domain level 0, AFAIK we do not have any of them, and domain level 0 will be supported for very long time. Test case: Replica created using old workflow is functional after domain upgrade It is nice, but I would like to extend it to install another replica to existing topology after the domain level is raised. Also we had IRC chat about ipa-ca-install. We found out that we do not have tests for standalone call of ipa-ca-install on replica. So I miss these testcases, as I wrote before in original thread[1]: 1) CA has been affected by replica promotion patches 1a) test if ipa-ca-install works on replica with domain level 1 1b) test if ipa-ca-install works on replica with domain level 0 Martin [1] https://www.redhat.com/archives/freeipa-devel/2015-November/msg00106.html From mbabinsk at redhat.com Wed Nov 25 09:33:24 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 25 Nov 2015 10:33:24 +0100 Subject: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names In-Reply-To: <1448400058.29102.17.camel@redhat.com> References: <1448400058.29102.17.camel@redhat.com> Message-ID: <56558064.7010600@redhat.com> On 11/24/2015 10:20 PM, Simo Sorce wrote: > This addresses #3860, giving admins the option to not require preauth > for Hosts and services. > > I did not add this option by default, although it does reduce the load > on the KDC as well as speed up TGT acquisition for service principal > accounts that acquire TGTs. > > Tested and working as expected (SPNs are not returned PREAUTH_NEEDED > error while normal users are). > > HTH, > Simo. > > > Hi Simo, I was not able to apply the patch on current master branch: """ git am ../review/ssorce/3860/freeipa-simo-558-1-Allow-admins-to-disable-preauth-for-SPNs.patch -3 Applying: Allow admins to disable preauth for SPNs. error: invalid object 100644 a6b4d4349a9ac6de453d9ad3c679ec32add4e43b for 'ipalib/plugins/config.py' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Allow admins to disable preauth for SPNs. """ It seems that I nedd to apply some of your other patches first (which one?) -- Martin^3 Babinsky From ftweedal at redhat.com Wed Nov 25 09:40:13 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 25 Nov 2015 19:40:13 +1000 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <5655712B.2040304@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> <56555365.7050200@redhat.com> <5655712B.2040304@redhat.com> Message-ID: <20151125094013.GB5336@dhcp-40-8.bne.redhat.com> On Wed, Nov 25, 2015 at 09:28:27AM +0100, Martin Babinsky wrote: > On 11/25/2015 07:21 AM, Jan Cholasta wrote: > >On 25.11.2015 05:56, Fraser Tweedale wrote: > >>On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: > >>>On 24.11.2015 17:17, Martin Babinsky wrote: > >>>>On 11/24/2015 05:10 PM, Martin Babinsky wrote: > >>>>>On 11/24/2015 05:01 PM, Martin Babinsky wrote: > >>>>>>On 11/24/2015 04:58 PM, Jan Cholasta wrote: > >>>>>>>On 24.11.2015 16:48, Martin Babinsky wrote: > >>>>>>>>On 11/24/2015 04:44 PM, Martin Babinsky wrote: > >>>>>>>>>https://fedorahosted.org/freeipa/ticket/5459 > >>>>>>>>> > >>>>>>>>forgot to attach the actual file *slaps himself* > >>>>>>> > >>>>>>>ipaserver/install/cainstance.py:1849: [E1101(no-member), > >>>>>>>ensure_default_caacl] Instance of 'API' has no 'Backed' member) > >>>>>>> > >>>>>> > >>>>>>Fixed > >>>>>> > >>>>>> > >>>>>> > >>>>>Also attaching rebased patch for ipa-4-2 > >>>>> > >>>>> > >>>>> > >>>>Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. > >>> > >>>Thanks, ACK. > >>> > >>>Pushed to: > >>>master: ed830af693c596b286b30959eb3166b59cc030c6 > >>>ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a > >>> > >>Thanks for anaysing and fixing these connection issues which were > >>presumably introduced by my patches. I did not hit these in my > >>testing. Admittedly I was focused on the ipa-4-2 branch and my > >>testing was mainly done there. > >> > >>Brittle LDAP connection logic in install and upgrade is an ongoing > >>problem. What shall we do to improve the situation? Push > >>connection details into the Backend and let it connect if/when > >>needed, rather than managing connection state from the outside? > >> > >>I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 > > > >I don't think we need to be smart about it, everyone just needs to make > >sure that when an ad-hoc connection is opened somewhere, it is also > >closed in the same place. The same applies for any other resource. > > > >> > >>Thanks, > >>Fraser > >> > > > > > > Maybe it would be a good idea to implement some decorator/context manager to > connect/disconnect from specified connection and wrap the CRUD code. Example > usage: > > """ > decorator: > @connected(api.Backend.ldap2, ldapi=True) > def do_magic(api, *args, **kwargs): > # do stuff > > context manager: > > with connected(api.Backend.ldap2, ccache=example_ccache): > do_some_other_magic() > """ > > I remember Jan having some objections against this so it would be nice to > hear why this is not a good idea. > This would not handle a connection loss (e.g. due to DS restart) but would still a useful and relatively non-intrusive measure. Furthermore it will make it easier for developer to do the Right Thing and reviewer to verify (i.e. it's easy to see when patch does LDAP things but is not using the context manager). Jan, it is well and good to say "developer just has to remember to open and close the connection" - and I accept that I have been the main culprit recently - but let us make it as easy as possible to get right, and hard for a patch that does not do the proper resource management to slip through. Cheers, Fraser From jcholast at redhat.com Wed Nov 25 09:43:27 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 10:43:27 +0100 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <20151125094013.GB5336@dhcp-40-8.bne.redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> <56555365.7050200@redhat.com> <5655712B.2040304@redhat.com> <20151125094013.GB5336@dhcp-40-8.bne.redhat.com> Message-ID: <565582BF.9010304@redhat.com> On 25.11.2015 10:40, Fraser Tweedale wrote: > On Wed, Nov 25, 2015 at 09:28:27AM +0100, Martin Babinsky wrote: >> On 11/25/2015 07:21 AM, Jan Cholasta wrote: >>> On 25.11.2015 05:56, Fraser Tweedale wrote: >>>> On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: >>>>> On 24.11.2015 17:17, Martin Babinsky wrote: >>>>>> On 11/24/2015 05:10 PM, Martin Babinsky wrote: >>>>>>> On 11/24/2015 05:01 PM, Martin Babinsky wrote: >>>>>>>> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>>>>>>>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>>>>>>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>>>>>>>> >>>>>>>>>> forgot to attach the actual file *slaps himself* >>>>>>>>> >>>>>>>>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>>>>>>>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>>>>>>>> >>>>>>>> >>>>>>>> Fixed >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Also attaching rebased patch for ipa-4-2 >>>>>>> >>>>>>> >>>>>>> >>>>>> Ignore the rebased patch, the original 104.1 applies on 4-2 just fine. >>>>> >>>>> Thanks, ACK. >>>>> >>>>> Pushed to: >>>>> master: ed830af693c596b286b30959eb3166b59cc030c6 >>>>> ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a >>>>> >>>> Thanks for anaysing and fixing these connection issues which were >>>> presumably introduced by my patches. I did not hit these in my >>>> testing. Admittedly I was focused on the ipa-4-2 branch and my >>>> testing was mainly done there. >>>> >>>> Brittle LDAP connection logic in install and upgrade is an ongoing >>>> problem. What shall we do to improve the situation? Push >>>> connection details into the Backend and let it connect if/when >>>> needed, rather than managing connection state from the outside? >>>> >>>> I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 >>> >>> I don't think we need to be smart about it, everyone just needs to make >>> sure that when an ad-hoc connection is opened somewhere, it is also >>> closed in the same place. The same applies for any other resource. >>> >>>> >>>> Thanks, >>>> Fraser >>>> >>> >>> >> >> Maybe it would be a good idea to implement some decorator/context manager to >> connect/disconnect from specified connection and wrap the CRUD code. Example >> usage: >> >> """ >> decorator: >> @connected(api.Backend.ldap2, ldapi=True) >> def do_magic(api, *args, **kwargs): >> # do stuff >> >> context manager: >> >> with connected(api.Backend.ldap2, ccache=example_ccache): >> do_some_other_magic() >> """ >> >> I remember Jan having some objections against this so it would be nice to >> hear why this is not a good idea. >> > This would not handle a connection loss (e.g. due to DS restart) but > would still a useful and relatively non-intrusive measure. > Furthermore it will make it easier for developer to do the Right > Thing and reviewer to verify (i.e. it's easy to see when patch does > LDAP things but is not using the context manager). > > Jan, it is well and good to say "developer just has to remember to > open and close the connection" - and I accept that I have been the > main culprit recently - but let us make it as easy as possible to > get right, and hard for a patch that does not do the proper resource > management to slip through. See the other thread. -- Jan Cholasta From mbasti at redhat.com Wed Nov 25 09:42:28 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 10:42:28 +0100 Subject: [Freeipa-devel] [PATCH 0359] Fix forwardzone upgrade Message-ID: <56558284.7050605@redhat.com> When original zone belongs to realmdomains, upgrade will fail. The attached patch solve the issue. https://fedorahosted.org/freeipa/ticket/5472 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0359-Fix-upgrade-of-forwardzones-when-zone-is-in-realmdom.patch Type: text/x-patch Size: 1259 bytes Desc: not available URL: From jcholast at redhat.com Wed Nov 25 10:04:30 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 11:04:30 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run In-Reply-To: <56548E73.1090105@redhat.com> References: <5638B8F9.6010703@redhat.com> <564D0FD9.4070505@redhat.com> <5652B5AC.2040508@redhat.com> <5652E174.50301@redhat.com> <56548E73.1090105@redhat.com> Message-ID: <565587AE.2070303@redhat.com> On 24.11.2015 17:21, Petr Viktorin wrote: > On 11/23/2015 10:50 AM, Jan Cholasta wrote: >> On 23.11.2015 07:43, Jan Cholasta wrote: >>> On 19.11.2015 00:55, Petr Viktorin wrote: >>>> On 11/03/2015 02:39 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> Python 3's strings are Unicode, so data coming to or leaving a Python >>>>> program needs to be decoded/encoded if it's to be handled as a string. >>>>> One of the boundaries where encoding is necessary is external programs, >>>>> specifically, ipautil.run. >>>>> Unfortunately there's no one set of options that would work for all >>>>> run() invocations, so I went through them all and specified the >>>>> stdin/stdout/stderr encoding where necessary. I've also updated the >>>>> call >>>>> sites to make it clearer if the return values are used or not. >>>>> If an encoding is not set, run() will accept/return bytes. (This is a >>>>> fail-safe setting, since it can't raise errors, and using bytes where >>>>> strings are expected generally fails loudly in py3.) >>>>> >>>>> Note that the changes are not effective under Python 2. >>>> >>>> ping, >>>> Could someone look at this patch? >>> >>> Looking. >> >> 1) I think a better approach would be to use str for stdin/stdout/stderr >> by default in both Python 2 and 3, i.e. do nothing in Python 2 and >> encode/decode using locale.getpreferredencoding() in Python 3. This is >> consistent with sys.std{in,out,err} in both Python 2 and 3. Using bytes >> or different encoding should be opt-in. >> >> Note that different encoding should be used only if the LC_ALL or LANG >> variables are overriden in the command's environment. > > That would assume the output of *everything* run via ipautil.run can be > decoded using the locale encoding. Any stray invalid byte would make IPA > crash, even in cases where we don't care about the output. IPA calls too > many weird tools to assume they all output text. Such a stray invalid byte may bubble through our code and cause havoc somewhere else, which is much harder to troubleshoot than a crash in ipautil.run(), where you can see that it was a misbehaving command that caused the crash and exactly what command it was. If we don't care about output somewhere, we should not capture it there at all. >> 3) I think the "surrogateescape" error handler would be better for >> non-strict decoding, as the text can be encoded back to bytes without >> loss of information. > > Non-strict decoding is meant for logging, so we want backslash escapes > rather than invalid surrogates. If you need round-tripping then you > should use bytes. I see. There is no guarantee that non-strict output will be used only for logging though. I think it might be better to return raw output and let the caller use a decode-for-logging utility function instead. The logger already escapes invalid bytes itself, so the function would have to be used only when raising exceptions. > I've changed the error strategy to 'replace' though, as I realized > 'backslashreplace' doesn't work for decoding. -- Jan Cholasta From mbasti at redhat.com Wed Nov 25 11:12:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 12:12:10 +0100 Subject: [Freeipa-devel] [PATCH 0360] Make dns-resolve command deprecated Message-ID: <5655978A.5080404@redhat.com> https://fedorahosted.org/freeipa/ticket/5466 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0360-Make-command-dns-resolve-deprecated.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: From mbasti at redhat.com Wed Nov 25 11:47:31 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 12:47:31 +0100 Subject: [Freeipa-devel] [PATCH 0361] Remove invalid error message from topology upgrade Message-ID: <56559FD3.7010607@redhat.com> https://fedorahosted.org/freeipa/ticket/5482 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0361-Remove-invalid-error-messages-from-topology-upgrade.patch Type: text/x-patch Size: 1897 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 25 12:14:46 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Nov 2015 13:14:46 +0100 Subject: [Freeipa-devel] [PATCH 0360] Make dns-resolve command deprecated In-Reply-To: <5655978A.5080404@redhat.com> References: <5655978A.5080404@redhat.com> Message-ID: <5655A636.8050806@redhat.com> On 25.11.2015 12:12, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5466 > > Patch attached. Please fix missing space after ',' and typo in 'choosen'. Otherwise it works, so cond-ACK. -- Petr^2 Spacek From tbabej at redhat.com Wed Nov 25 12:24:17 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 13:24:17 +0100 Subject: [Freeipa-devel] [PATCH 0381] admintool: Remove the option to override the log file In-Reply-To: <5641EFB2.4080705@redhat.com> References: <5641EFB2.4080705@redhat.com> Message-ID: <5655A871.5020209@redhat.com> On 11/10/2015 02:22 PM, Tomas Babej wrote: > Hi, > > This has been rarely used, and can be replaced by proper shell output > redirection. > > https://fedorahosted.org/freeipa/ticket/5408 > Here's an updated version of the patch that gets rid of one missed occurrence of log_file usage. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0381-2-admintool-Remove-the-option-to-override-the-log-file.patch Type: text/x-patch Size: 4797 bytes Desc: not available URL: From jcholast at redhat.com Wed Nov 25 12:29:40 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 13:29:40 +0100 Subject: [Freeipa-devel] [PATCH 0381] admintool: Remove the option to override the log file In-Reply-To: <5655A871.5020209@redhat.com> References: <5641EFB2.4080705@redhat.com> <5655A871.5020209@redhat.com> Message-ID: <5655A9B4.8070506@redhat.com> On 25.11.2015 13:24, Tomas Babej wrote: > On 11/10/2015 02:22 PM, Tomas Babej wrote: >> Hi, >> >> This has been rarely used, and can be replaced by proper shell output >> redirection. >> >> https://fedorahosted.org/freeipa/ticket/5408 >> > > Here's an updated version of the patch that gets rid of one missed > occurrence of log_file usage. The ticket seems unrelated to the change. Shouldn't the option be kept in the respective commands for backward compatibility? See how the debug option is handled in AdminTool. -- Jan Cholasta From pspacek at redhat.com Wed Nov 25 12:36:12 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Nov 2015 13:36:12 +0100 Subject: [Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records In-Reply-To: <564D9EDE.9040001@redhat.com> References: <563A2158.80009@redhat.com> <56404F9E.4090606@redhat.com> <56448D06.3020700@redhat.com> <564CB661.9040106@redhat.com> <564D9EDE.9040001@redhat.com> Message-ID: <5655AB3C.20109@redhat.com> On 19.11.2015 11:05, Martin Basti wrote: > > > On 18.11.2015 18:33, Petr Spacek wrote: >> On 12.11.2015 13:58, Martin Basti wrote: >>> >>> On 09.11.2015 08:47, Petr Spacek wrote: >>>> On 4.11.2015 16:16, Martin Basti wrote: >>>>> Patch attached. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5421 >>>> I'm not entirely sure how this patch will interact with magic included in >>>> ipalib/plugins/dns.py:class dns_resolve(Command). >>>> >>>> I would like to delete the 'normalization' from at least one of these places. >>>> >>>> Also, as you know, DNS names are not strings and should be manipulated using >>>> python-dns so all crazy things in DNS names do not break in weird corner >>>> cases. >>>> >>> Updated patch attached. >> Hmm, you bravely ignored my comment about class dns_resolve(Command) above, >> sooo: NACK. >> >> As far as I can tell ipalib/plugins/dns.py:class dns_resolve(Command) behaves >> in the same brain-dead way as original is_host_resolvable() function. Please >> fix both, not just one. >> > If you are sure that the behavior of the dns-resolve is bad, then updated > patch that removes the code which appending the api.env.domain to query. > > Patch attached. ACK -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 25 12:36:19 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Nov 2015 13:36:19 +0100 Subject: [Freeipa-devel] [PATCH 0351] call directly is_host_resolvable function to verify addresses in NS records In-Reply-To: <564DA038.7020404@redhat.com> References: <564DA038.7020404@redhat.com> Message-ID: <5655AB43.4090909@redhat.com> On 19.11.2015 11:11, Martin Basti wrote: > Testing if address is resolvable can be done by directly call of > is_host_resovable, instead of call the dns-resolve command which is doing the > same (works as proxy). > > Patch attached. ACK -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 25 12:36:26 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Nov 2015 13:36:26 +0100 Subject: [Freeipa-devel] [PATCH 0359] Fix forwardzone upgrade In-Reply-To: <56558284.7050605@redhat.com> References: <56558284.7050605@redhat.com> Message-ID: <5655AB4A.2090209@redhat.com> On 25.11.2015 10:42, Martin Basti wrote: > When original zone belongs to realmdomains, upgrade will fail. > > The attached patch solve the issue. > > https://fedorahosted.org/freeipa/ticket/5472 ACK -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 25 12:36:31 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Nov 2015 13:36:31 +0100 Subject: [Freeipa-devel] [PATCH 0360] Make dns-resolve command deprecated In-Reply-To: <5655978A.5080404@redhat.com> References: <5655978A.5080404@redhat.com> Message-ID: <5655AB4F.6060605@redhat.com> On 25.11.2015 12:12, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5466 > > Patch attached. ACK -- Petr^2 Spacek From jcholast at redhat.com Wed Nov 25 12:40:07 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 13:40:07 +0100 Subject: [Freeipa-devel] [PATCH 0359] Fix forwardzone upgrade In-Reply-To: <5655AB4A.2090209@redhat.com> References: <56558284.7050605@redhat.com> <5655AB4A.2090209@redhat.com> Message-ID: <5655AC27.5050006@redhat.com> On 25.11.2015 13:36, Petr Spacek wrote: > On 25.11.2015 10:42, Martin Basti wrote: >> When original zone belongs to realmdomains, upgrade will fail. >> >> The attached patch solve the issue. >> >> https://fedorahosted.org/freeipa/ticket/5472 > > ACK Pushed to: master: 6eeb4e4f2a9fb6fe5cf83e6b84c737ad3e295de1 ipa-4-2: 8b0f60fbfb5192a8dde2b459d9d15ab11337cf66 -- Jan Cholasta From tbabej at redhat.com Wed Nov 25 12:49:16 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 13:49:16 +0100 Subject: [Freeipa-devel] [PATCH 0381] admintool: Remove the option to override the log file In-Reply-To: <5655A9B4.8070506@redhat.com> References: <5641EFB2.4080705@redhat.com> <5655A871.5020209@redhat.com> <5655A9B4.8070506@redhat.com> Message-ID: <5655AE4C.2000303@redhat.com> On 11/25/2015 01:29 PM, Jan Cholasta wrote: > On 25.11.2015 13:24, Tomas Babej wrote: >> On 11/10/2015 02:22 PM, Tomas Babej wrote: >>> Hi, >>> >>> This has been rarely used, and can be replaced by proper shell output >>> redirection. >>> >>> https://fedorahosted.org/freeipa/ticket/5408 >>> >> >> Here's an updated version of the patch that gets rid of one missed >> occurrence of log_file usage. > > The ticket seems unrelated to the change. > > Shouldn't the option be kept in the respective commands for backward > compatibility? See how the debug option is handled in AdminTool. > Yeah, the correct ticket is: https://fedorahosted.org/freeipa/ticket/5385 I'm curious, in what manner do you envision the backward compatibility? The debug option is being replaced with verbose, but here we're removing existing functionality since it does not work properly and is of little use anyway. So there are two possiblities I see: 1.) We remove the functionality and keep the option, just to be able to say that this option is deprecated and bail out. 2.) We keep the functionality, and keep the option, just issue a warning when it's being used. >From my point of view: I did not do (1), but imho we can add it, albeit it's a marginal usability improvement. As far as (2) goes, it does not solve the underlying problem. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0381-3-admintool-Remove-the-option-to-override-the-log-file.patch Type: text/x-patch Size: 4797 bytes Desc: not available URL: From tbabej at redhat.com Wed Nov 25 12:52:11 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 13:52:11 +0100 Subject: [Freeipa-devel] [PATCH 0386] private_ccache: Harden the removal of KRB5CCNAME env variable In-Reply-To: <56556B86.6020909@redhat.com> References: <5652FE24.2040004@redhat.com> <5653025B.1030100@redhat.com> <5653067A.1000709@redhat.com> <5653071B.1040802@redhat.com> <5653093A.2080609@redhat.com> <56530BA0.6070400@redhat.com> <5653161A.4080308@redhat.com> <5653208E.1060405@redhat.com> <56556B86.6020909@redhat.com> Message-ID: <5655AEFB.6050005@redhat.com> On 11/25/2015 09:04 AM, Jan Cholasta wrote: > On 23.11.2015 15:19, Rob Crittenden wrote: >> Tomas Babej wrote: >>> >>> >>> On 11/23/2015 01:50 PM, Jan Cholasta wrote: >>>> On 23.11.2015 13:40, Tomas Babej wrote: >>>>> >>>>> >>>>> On 11/23/2015 01:31 PM, Jan Cholasta wrote: >>>>>> On 23.11.2015 13:28, Tomas Babej wrote: >>>>>>> >>>>>>> >>>>>>> On 11/23/2015 01:11 PM, Jan Cholasta wrote: >>>>>>>> On 23.11.2015 12:53, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> If the code within the private_ccache contextmanager does not >>>>>>>>> set/removes the KRB5CCNAME, the pop method will raise KeyError, >>>>>>>>> which >>>>>>>>> will cause unnecessary termination of the code flow. >>>>>>>>> >>>>>>>>> Make sure the KRB5CCNAME is popped out of os.environ only if >>>>>>>>> present. >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> >>>>>>>> NACK, use os.environ.pop('KRB5CCNAME', None) to safely remove it. >>>>>>> >>>>>>> Yeah, well, both ways are equivalent, I found the if statement more >>>>>>> explicit. We can go with the suggested version, if it's more >>>>>>> pleasing >>>>>>> though - patch is attached. >>>>>>> >>>>>>>> >>>>>>>> Also I don't think the comment is necessary, it's quite obvious >>>>>>>> what the >>>>>>>> code does. >>>>>>>> >>>>>>> >>>>>>> I don't think an explanatory comment can hurt, ever. Worst thing >>>>>>> that >>>>>>> happens is that somebody is assured that he understands the code >>>>>>> correctly. >>>>>> >>>>>> Actually the worst thing is that someone changes the code without >>>>>> changing the comment. If the comment does not add any real value, >>>>>> it's >>>>>> only a maintenance burden. >>>>>> >>>>> >>>>> Yep, that's a real issue in our code base (i.e. I recently removed >>>>> such >>>>> a stale comment in f05846e26787da5ef6c996abf823fcc4a7f65e0f). Making >>>>> sure the comments describe the implementation properly is on the >>>>> author/reviewer though. >>>>> >>>>> What's "added value" highly depends on your skill set, and familiarity >>>>> with the code base. Particularly the familiarity with the code base >>>>> can >>>>> diminish over time even for the author, and those are the times where >>>>> comments can come to the rescue. >>>> >>>> Let's take a look at the code: >>>> >>>> if original_value is not None: >>>> os.environ['KRB5CCNAME'] = original_value >>>> else: >>>> os.environ.pop('KRB5CCNAME', None) >>>> >>>> Can you tell me what in there couldn't be obvious to a person with even >>>> the most basic skill set? >>>> >>>> IMHO a docstring for private_cccache would add some real value, but >>>> this >>>> comment alone does not. >>>> >>>>> >>>>> For a newcomer to the project, even a trivial comment (from the >>>>> point of >>>>> view of the experienced developer) can be valuable. >>>> >>>> Following this logic, there should be a comment for every line of our >>>> code, which is ridiculous. >>>> >>> >>> Here's the version of the patch with the comment removed. >> >> IMHO the comment should have been something like "ensure no KRB5CCNAME >> otherwise it blows up in ..." If it took you 20 minutes to track down a >> one-line change then a comment might save the next guy who changes the >> behavior. > > As I wrote earlier, I think it would make more sense to put this into > the docstring of private_ccache(). > > ACK on the patch. > Pushed to master: 1904d7cc3ab33046428dbdcb7c6f521f9e083287 From tbabej at redhat.com Wed Nov 25 12:58:36 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 13:58:36 +0100 Subject: [Freeipa-devel] [PATCH 0361] Remove invalid error message from topology upgrade In-Reply-To: <56559FD3.7010607@redhat.com> References: <56559FD3.7010607@redhat.com> Message-ID: <5655B07C.1050105@redhat.com> On 11/25/2015 12:47 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5482 > > Patch attached. > > ACK. From tbabej at redhat.com Wed Nov 25 12:58:53 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 13:58:53 +0100 Subject: [Freeipa-devel] [PATCH 0361] Remove invalid error message from topology upgrade In-Reply-To: <5655B07C.1050105@redhat.com> References: <56559FD3.7010607@redhat.com> <5655B07C.1050105@redhat.com> Message-ID: <5655B08D.4070506@redhat.com> On 11/25/2015 01:58 PM, Tomas Babej wrote: > > > On 11/25/2015 12:47 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5482 >> >> Patch attached. >> >> > > ACK. > Pushed to master: 801672cc6618947f5cc4607910871e695587fcbf From mbabinsk at redhat.com Wed Nov 25 13:00:48 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 25 Nov 2015 14:00:48 +0100 Subject: [Freeipa-devel] [PATCH 559] Fix kadmin for new users In-Reply-To: <1448404347.29102.23.camel@redhat.com> References: <1448404347.29102.23.camel@redhat.com> Message-ID: <5655B100.90403@redhat.com> On 11/24/2015 11:32 PM, Simo Sorce wrote: > Ticket #937 was reopened a while ago because one corner case, new users > that have never been assigned a password cause kadmin/kadmin.local to > throw a fit when they try to visualize information about those user's > principals. > > This patch fakes up modification information when no krbExtraData is > available for the principal so that kadmin is happy. > > Tested and working as designed. > > Simo. > > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Wed Nov 25 13:09:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 14:09:55 +0100 Subject: [Freeipa-devel] [PATCH 0360] Make dns-resolve command deprecated In-Reply-To: <5655AB4F.6060605@redhat.com> References: <5655978A.5080404@redhat.com> <5655AB4F.6060605@redhat.com> Message-ID: <5655B323.2070601@redhat.com> On 25.11.2015 13:36, Petr Spacek wrote: > On 25.11.2015 12:12, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5466 >> >> Patch attached. > ACK > updated and pushed Pushed to master: 749dfc3917cd5b3d0f222d144e8fc96e08308e10 From mbasti at redhat.com Wed Nov 25 13:11:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 14:11:42 +0100 Subject: [Freeipa-devel] [PATCH 0351] call directly is_host_resolvable function to verify addresses in NS records In-Reply-To: <5655AB43.4090909@redhat.com> References: <564DA038.7020404@redhat.com> <5655AB43.4090909@redhat.com> Message-ID: <5655B38E.5020908@redhat.com> On 25.11.2015 13:36, Petr Spacek wrote: > On 19.11.2015 11:11, Martin Basti wrote: >> Testing if address is resolvable can be done by directly call of >> is_host_resovable, instead of call the dns-resolve command which is doing the >> same (works as proxy). >> >> Patch attached. > ACK > Pushed to master: 7acfaee8abc7f4dc7f09e975147b96944231db5b From tbabej at redhat.com Wed Nov 25 13:13:05 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 14:13:05 +0100 Subject: [Freeipa-devel] [PATCH 559] Fix kadmin for new users In-Reply-To: <5655B100.90403@redhat.com> References: <1448404347.29102.23.camel@redhat.com> <5655B100.90403@redhat.com> Message-ID: <5655B3E1.4050107@redhat.com> On 11/25/2015 02:00 PM, Martin Babinsky wrote: > On 11/24/2015 11:32 PM, Simo Sorce wrote: >> Ticket #937 was reopened a while ago because one corner case, new users >> that have never been assigned a password cause kadmin/kadmin.local to >> throw a fit when they try to visualize information about those user's >> principals. >> >> This patch fakes up modification information when no krbExtraData is >> available for the principal so that kadmin is happy. >> >> Tested and working as designed. >> >> Simo. >> >> >> > ACK > Pushed to master: 0f52eddd1d2781ccc1941c191e9ab6e3ccf6919d From tbabej at redhat.com Wed Nov 25 13:13:32 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 14:13:32 +0100 Subject: [Freeipa-devel] [PATCH 559] Fix kadmin for new users In-Reply-To: <5655B3E1.4050107@redhat.com> References: <1448404347.29102.23.camel@redhat.com> <5655B100.90403@redhat.com> <5655B3E1.4050107@redhat.com> Message-ID: <5655B3FC.6060707@redhat.com> On 11/25/2015 02:13 PM, Tomas Babej wrote: > > > On 11/25/2015 02:00 PM, Martin Babinsky wrote: >> On 11/24/2015 11:32 PM, Simo Sorce wrote: >>> Ticket #937 was reopened a while ago because one corner case, new users >>> that have never been assigned a password cause kadmin/kadmin.local to >>> throw a fit when they try to visualize information about those user's >>> principals. >>> >>> This patch fakes up modification information when no krbExtraData is >>> available for the principal so that kadmin is happy. >>> >>> Tested and working as designed. >>> >>> Simo. >>> >>> >>> >> ACK >> > > Pushed to master: 0f52eddd1d2781ccc1941c191e9ab6e3ccf6919d > On a related note, should we backport this to later branches? From jcholast at redhat.com Wed Nov 25 13:15:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Nov 2015 14:15:23 +0100 Subject: [Freeipa-devel] [PATCH 0381] admintool: Remove the option to override the log file In-Reply-To: <5655AE4C.2000303@redhat.com> References: <5641EFB2.4080705@redhat.com> <5655A871.5020209@redhat.com> <5655A9B4.8070506@redhat.com> <5655AE4C.2000303@redhat.com> Message-ID: <5655B46B.4040407@redhat.com> On 25.11.2015 13:49, Tomas Babej wrote: > > > On 11/25/2015 01:29 PM, Jan Cholasta wrote: >> On 25.11.2015 13:24, Tomas Babej wrote: >>> On 11/10/2015 02:22 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> This has been rarely used, and can be replaced by proper shell output >>>> redirection. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5408 >>>> >>> >>> Here's an updated version of the patch that gets rid of one missed >>> occurrence of log_file usage. >> >> The ticket seems unrelated to the change. >> >> Shouldn't the option be kept in the respective commands for backward >> compatibility? See how the debug option is handled in AdminTool. >> > > Yeah, the correct ticket is: https://fedorahosted.org/freeipa/ticket/5385 > > I'm curious, in what manner do you envision the backward compatibility? > The debug option is being replaced with verbose, but here we're removing > existing functionality since it does not work properly and is of little > use anyway. > > So there are two possiblities I see: > > 1.) We remove the functionality and keep the option, just to be able to > say that this option is deprecated and bail out. > > 2.) We keep the functionality, and keep the option, just issue a warning > when it's being used. > > From my point of view: I did not do (1), but imho we can add it, albeit > it's a marginal usability improvement. As far as (2) goes, it does not > solve the underlying problem. Add log_file_option=False argument to add_options(), if it's True, add the option to the parser. Set it to True in commands which currently have the option. In _setup_logging(), if the option value is not None, add a handler for the file to the log manager (untested): user_file_handler = dict( name='user_file', filename=self.options.log_file, filemode=log_file_mode, permission=0600, level='debug', format=ipa_log_manager.LOGGING_FORMAT_STANDARD_FILE, ) ipa_log_manager.log_mgr.create_log_handlers([user_file_handler], None, None) This way it will log into both the standard location and the user-specified file. -- Jan Cholasta From mbasti at redhat.com Wed Nov 25 13:14:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 14:14:44 +0100 Subject: [Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records In-Reply-To: <5655AB3C.20109@redhat.com> References: <563A2158.80009@redhat.com> <56404F9E.4090606@redhat.com> <56448D06.3020700@redhat.com> <564CB661.9040106@redhat.com> <564D9EDE.9040001@redhat.com> <5655AB3C.20109@redhat.com> Message-ID: <5655B444.3020606@redhat.com> On 25.11.2015 13:36, Petr Spacek wrote: > On 19.11.2015 11:05, Martin Basti wrote: >> >> On 18.11.2015 18:33, Petr Spacek wrote: >>> On 12.11.2015 13:58, Martin Basti wrote: >>>> On 09.11.2015 08:47, Petr Spacek wrote: >>>>> On 4.11.2015 16:16, Martin Basti wrote: >>>>>> Patch attached. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5421 >>>>> I'm not entirely sure how this patch will interact with magic included in >>>>> ipalib/plugins/dns.py:class dns_resolve(Command). >>>>> >>>>> I would like to delete the 'normalization' from at least one of these places. >>>>> >>>>> Also, as you know, DNS names are not strings and should be manipulated using >>>>> python-dns so all crazy things in DNS names do not break in weird corner >>>>> cases. >>>>> >>>> Updated patch attached. >>> Hmm, you bravely ignored my comment about class dns_resolve(Command) above, >>> sooo: NACK. >>> >>> As far as I can tell ipalib/plugins/dns.py:class dns_resolve(Command) behaves >>> in the same brain-dead way as original is_host_resolvable() function. Please >>> fix both, not just one. >>> >> If you are sure that the behavior of the dns-resolve is bad, then updated >> patch that removes the code which appending the api.env.domain to query. >> >> Patch attached. > ACK > Pushed to master: 800c7023241fd6182da300cf120870072e6ca602 From tbabej at redhat.com Wed Nov 25 13:29:11 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 14:29:11 +0100 Subject: [Freeipa-devel] [PATCH 0102] update idrange tests to reflect disabled modification of local ID ranges In-Reply-To: <5652FF75.4000008@redhat.com> References: <564F36E3.90807@redhat.com> <564F5B39.7060804@redhat.com> <5652FF75.4000008@redhat.com> Message-ID: <5655B7A7.7090706@redhat.com> On 11/23/2015 12:58 PM, Tomas Babej wrote: > > > On 11/20/2015 06:41 PM, Milan Kub?k wrote: >> On 11/20/2015 04:06 PM, Martin Babinsky wrote: >>> When I fixed https://fedorahosted.org/freeipa/ticket/4826 I forgot to >>> fix the corresponding xmlrpc tests. >>> >>> This oversight bit me today when I ran in-tree tests on my VM. >>> >>> Here is the patch that makes idrange tests green and shiny again. >>> >> Tests are now passing, ACK >> > > Tests are now passing, however, the code paths that have been checked by > these tests are no longer executed (as an modifications to the local > ranges are prohibited now). > > This essentially means that we are testing the same thing multiple times > (i.e. local range cannot be dealt with), and the test names are > misleading currently. > > I think we should either reduce the set of (effectively) duplicate > tests, or, better, introduce their replacements that are using allowed > range types, if possible. > > Tomas > I created a ticket so that this does not get lost: https://fedorahosted.org/freeipa/ticket/5493 From tbabej at redhat.com Wed Nov 25 13:31:13 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 14:31:13 +0100 Subject: [Freeipa-devel] [PATCH 0358] ipa-getkeytab: do not return error if translations cannot be loaded In-Reply-To: <56549291.50200@redhat.com> References: <565487D3.9000301@redhat.com> <56549171.3010304@redhat.com> <56549291.50200@redhat.com> Message-ID: <5655B821.60400@redhat.com> On 11/24/2015 05:38 PM, Martin Basti wrote: > > > On 24.11.2015 17:33, Jan Cholasta wrote: >> On 24.11.2015 16:52, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5483 >>> >>> Patch attached. >> >> Doesn't init_gettext() itself already print to stderr on failure? >> > Nope > ACK, works fine. Failed to load translations Keytab successfully retrieved and stored in: test.keytab From tbabej at redhat.com Wed Nov 25 13:31:57 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Nov 2015 14:31:57 +0100 Subject: [Freeipa-devel] [PATCH 0358] ipa-getkeytab: do not return error if translations cannot be loaded In-Reply-To: <5655B821.60400@redhat.com> References: <565487D3.9000301@redhat.com> <56549171.3010304@redhat.com> <56549291.50200@redhat.com> <5655B821.60400@redhat.com> Message-ID: <5655B84D.7080108@redhat.com> On 11/25/2015 02:31 PM, Tomas Babej wrote: > > > On 11/24/2015 05:38 PM, Martin Basti wrote: >> >> >> On 24.11.2015 17:33, Jan Cholasta wrote: >>> On 24.11.2015 16:52, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5483 >>>> >>>> Patch attached. >>> >>> Doesn't init_gettext() itself already print to stderr on failure? >>> >> Nope >> > > ACK, works fine. > > Failed to load translations > Keytab successfully retrieved and stored in: test.keytab > Pushed to: master: d43c3becbd406d145426d0409b8fe2a36ee6c63c ipa-4-2: 34db8888b42c51ce17a450e41f998e2b3f30682c From mbabinsk at redhat.com Wed Nov 25 13:33:21 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 25 Nov 2015 14:33:21 +0100 Subject: [Freeipa-devel] [PATCH 0349] baseuser.py compare objectclasses as case insensitive In-Reply-To: <564B05DE.8020908@redhat.com> References: <564B05DE.8020908@redhat.com> Message-ID: <5655B8A1.6000500@redhat.com> On 11/17/2015 11:47 AM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5456 > > Patch attached. > > ACK but please fix a typo in the commit message before pushing. -- Martin^3 Babinsky From pspacek at redhat.com Wed Nov 25 13:58:01 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Nov 2015 14:58:01 +0100 Subject: [Freeipa-devel] [PATCH 0381] admintool: Remove the option to override the log file In-Reply-To: <5655B46B.4040407@redhat.com> References: <5641EFB2.4080705@redhat.com> <5655A871.5020209@redhat.com> <5655A9B4.8070506@redhat.com> <5655AE4C.2000303@redhat.com> <5655B46B.4040407@redhat.com> Message-ID: <5655BE69.4030703@redhat.com> On 25.11.2015 14:15, Jan Cholasta wrote: > On 25.11.2015 13:49, Tomas Babej wrote: >> >> >> On 11/25/2015 01:29 PM, Jan Cholasta wrote: >>> On 25.11.2015 13:24, Tomas Babej wrote: >>>> On 11/10/2015 02:22 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> This has been rarely used, and can be replaced by proper shell output >>>>> redirection. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5408 >>>>> >>>> >>>> Here's an updated version of the patch that gets rid of one missed >>>> occurrence of log_file usage. >>> >>> The ticket seems unrelated to the change. >>> >>> Shouldn't the option be kept in the respective commands for backward >>> compatibility? See how the debug option is handled in AdminTool. >>> >> >> Yeah, the correct ticket is: https://fedorahosted.org/freeipa/ticket/5385 >> >> I'm curious, in what manner do you envision the backward compatibility? >> The debug option is being replaced with verbose, but here we're removing >> existing functionality since it does not work properly and is of little >> use anyway. >> >> So there are two possiblities I see: >> >> 1.) We remove the functionality and keep the option, just to be able to >> say that this option is deprecated and bail out. This is such a minor thing that I would throw it away completely. It is not worth the bytes :-) User will get a message that the option does not exist which seems functionally equivalent to the 'say that this option is deprecated and bail out'. Petr^2 Spacek >> >> 2.) We keep the functionality, and keep the option, just issue a warning >> when it's being used. >> >> From my point of view: I did not do (1), but imho we can add it, albeit >> it's a marginal usability improvement. As far as (2) goes, it does not >> solve the underlying problem. > > Add log_file_option=False argument to add_options(), if it's True, add the > option to the parser. Set it to True in commands which currently have the option. > > In _setup_logging(), if the option value is not None, add a handler for the > file to the log manager (untested): > > user_file_handler = dict( > name='user_file', > filename=self.options.log_file, > filemode=log_file_mode, > permission=0600, > level='debug', > format=ipa_log_manager.LOGGING_FORMAT_STANDARD_FILE, > ) > ipa_log_manager.log_mgr.create_log_handlers([user_file_handler], None, None) > > This way it will log into both the standard location and the user-specified file. From rcritten at redhat.com Wed Nov 25 14:02:03 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Nov 2015 09:02:03 -0500 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <56555AC7.2000908@redhat.com> References: <1448394152.29102.10.camel@redhat.com> <1448395038.29102.11.camel@redhat.com> <1448399848.29102.13.camel@redhat.com> <56555AC7.2000908@redhat.com> Message-ID: <5655BF5B.6020405@redhat.com> Jan Cholasta wrote: > On 24.11.2015 22:17, Simo Sorce wrote: >> On Tue, 2015-11-24 at 14:57 -0500, Simo Sorce wrote: >>> On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote: >>>> Since some time we use the getkeytab operation to fetch keytabs on >>>> newer >>>> clients. According to bug #232 setkeytab can be used to circumvent >>>> password quality controls so it needs to be slowly retired. >>>> >>>> The attached patches implement #5485 in 2 parts. >>>> >>>> The first introduces the option DisableSetKeytab which globally >>>> disables >>>> the setkeytab extended operation. This is set to false by default for >>>> backwards compatibility. >>>> >>>> The second introduces an option called DisableUserSetKeytab, which is >>>> active by default in new installs (but not in upgraded ones), and only >>>> disables the use of setkeytab for ipa suers, but not for >>>> hosts/services. >>>> This is because user's are the ones that may abuse the interface to >>>> escape password policies and users also normally do not acquire >>>> keytabs, >>>> so it is a safe bet to disable just them by default in new installs. >>>> >>>> (Testing in progress) >>> >>> Tested and working as expected. >> >> I realized that adding options to ipaConfig require to add them in the >> UI as well, attached patches add options in API.txt and config.py >> Make now complain I should change API Major or Minor, but it is not >> clear to me why given this are additional values and no real change or >> new function is introduced. What's the recommendation ? > > When does make complain? It is supposed to complain only when API.txt > does not match code. > > Anyway, we usually bump minor version even for backward compatible > changes, see e.g. commit 9549a59. > The point of API.txt (and the heavy client) was to save a round-trip. Being able to pass in an invalid option would void that rule hence having to update the API when new values are added. rob From mbasti at redhat.com Wed Nov 25 14:02:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 15:02:05 +0100 Subject: [Freeipa-devel] [PATCH 0349] baseuser.py compare objectclasses as case insensitive In-Reply-To: <5655B8A1.6000500@redhat.com> References: <564B05DE.8020908@redhat.com> <5655B8A1.6000500@redhat.com> Message-ID: <5655BF5D.90706@redhat.com> On 25.11.2015 14:33, Martin Babinsky wrote: > On 11/17/2015 11:47 AM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5456 >> >> Patch attached. >> >> > ACK but please fix a typo in the commit message before pushing. > Fixed Pushed to master: 6bbde3e0f7d661fa559ed5e3365381d2ba113dce From rcritten at redhat.com Wed Nov 25 14:05:31 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Nov 2015 09:05:31 -0500 Subject: [Freeipa-devel] [PATCH 0104] do not disconnect when using existing connection to check default CA ACLs In-Reply-To: <56557D23.3060808@redhat.com> References: <565485C8.7060606@redhat.com> <565486E5.1060501@redhat.com> <5654890E.2090001@redhat.com> <565489F4.2010204@redhat.com> <56548BF8.50700@redhat.com> <56548DAA.6090603@redhat.com> <56549295.6010004@redhat.com> <20151125045631.GA5336@dhcp-40-8.bne.redhat.com> <56555365.7050200@redhat.com> <5655712B.2040304@redhat.com> <565577D9.9050406@redhat.com> <56557D23.3060808@redhat.com> Message-ID: <5655C02B.4080704@redhat.com> Martin Babinsky wrote: > On 11/25/2015 09:56 AM, Jan Cholasta wrote: >> On 25.11.2015 09:28, Martin Babinsky wrote: >>> On 11/25/2015 07:21 AM, Jan Cholasta wrote: >>>> On 25.11.2015 05:56, Fraser Tweedale wrote: >>>>> On Tue, Nov 24, 2015 at 05:38:45PM +0100, Jan Cholasta wrote: >>>>>> On 24.11.2015 17:17, Martin Babinsky wrote: >>>>>>> On 11/24/2015 05:10 PM, Martin Babinsky wrote: >>>>>>>> On 11/24/2015 05:01 PM, Martin Babinsky wrote: >>>>>>>>> On 11/24/2015 04:58 PM, Jan Cholasta wrote: >>>>>>>>>> On 24.11.2015 16:48, Martin Babinsky wrote: >>>>>>>>>>> On 11/24/2015 04:44 PM, Martin Babinsky wrote: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5459 >>>>>>>>>>>> >>>>>>>>>>> forgot to attach the actual file *slaps himself* >>>>>>>>>> >>>>>>>>>> ipaserver/install/cainstance.py:1849: [E1101(no-member), >>>>>>>>>> ensure_default_caacl] Instance of 'API' has no 'Backed' member) >>>>>>>>>> >>>>>>>>> >>>>>>>>> Fixed >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Also attaching rebased patch for ipa-4-2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Ignore the rebased patch, the original 104.1 applies on 4-2 just >>>>>>> fine. >>>>>> >>>>>> Thanks, ACK. >>>>>> >>>>>> Pushed to: >>>>>> master: ed830af693c596b286b30959eb3166b59cc030c6 >>>>>> ipa-4-2: c5faaede276f3052517ddf86e64cb228e95dca2a >>>>>> >>>>> Thanks for anaysing and fixing these connection issues which were >>>>> presumably introduced by my patches. I did not hit these in my >>>>> testing. Admittedly I was focused on the ipa-4-2 branch and my >>>>> testing was mainly done there. >>>>> >>>>> Brittle LDAP connection logic in install and upgrade is an ongoing >>>>> problem. What shall we do to improve the situation? Push >>>>> connection details into the Backend and let it connect if/when >>>>> needed, rather than managing connection state from the outside? >>>>> >>>>> I filed a ticket: https://fedorahosted.org/freeipa/ticket/5491 >>>> >>>> I don't think we need to be smart about it, everyone just needs to make >>>> sure that when an ad-hoc connection is opened somewhere, it is also >>>> closed in the same place. The same applies for any other resource. >>>> >>>>> >>>>> Thanks, >>>>> Fraser >>>>> >>>> >>>> >>> >>> Maybe it would be a good idea to implement some decorator/context >>> manager to connect/disconnect from specified connection and wrap the >>> CRUD code. Example usage: >>> >>> """ >>> decorator: >>> @connected(api.Backend.ldap2, ldapi=True) >>> def do_magic(api, *args, **kwargs): >>> # do stuff >>> >>> context manager: >>> >>> with connected(api.Backend.ldap2, ccache=example_ccache): >>> do_some_other_magic() >>> """ >>> >>> I remember Jan having some objections against this so it would be nice >>> to hear why this is not a good idea. >> >> a) For ad-hoc connection objects, LDAPClient should be used instead of >> ldap2. It already supports the context manager protocol: >> >> with LDAPClient(uri) as conn: >> conn.gssapi_bind() >> ... >> > I didn't know that you can and should use LDAPClient this way. We should > document it somewhere and encourage other contributors to use this > approach. > >> b) The api.Backend.ldap2 object should be connected and disconnected >> exactly once per api object per command. This is not done ATM and the >> usual workaround is to connect it manually, which has lead to the mess >> we have now. >> > Then we should find time to implement this behavior so that we can stop > shooting ourselves in the foot when messing around with API commands. I'm not sure I follow. Are we still talking about tools or did this shift to requests? It used to be at a single connection was created for each request and used everywhere internally. There is probably nothing to prevent you from doing something similar in the tools but given that restarts are common I hardly see the point. >> Also, only GSSAPI authentication with valid IPA user credentials should >> be used with ldap2, even for ldapi connections. IIRC we kept the old IPAdmin class around in the old days for this very reason. rob From pvoborni at redhat.com Wed Nov 25 14:28:13 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Nov 2015 15:28:13 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization In-Reply-To: <56546189.9010505@redhat.com> References: <564F3577.9090207@redhat.com> <565445AA.4070404@redhat.com> <56544763.2090905@redhat.com> <56546189.9010505@redhat.com> Message-ID: <5655C57D.6090904@redhat.com> On 11/24/2015 02:09 PM, Martin Babinsky wrote: > On 11/24/2015 12:17 PM, Petr Vobornik wrote: >> On 11/24/2015 12:10 PM, Ludwig Krispenz wrote: >>> Hi Petr, >>> >>> I'm testing these patches.Two observations so far: >>> - in Topology->IPA Servers I see a table of my servers and the managed >>> suffix column I see both suffixes, ipaca and the realm, >>> but if I select one of the servers I Only see the realm suffix, this was >>> different in the demo video >> >> implemented in patch 927 (separate thread) >> >>> - the graph layou is not stable. If I arrange it and the try some >>> actions on a segment, eg try to remove one (which is rejected), the >>> graph does change again- >> >> Not sure if I understand it correctly. One can set static position to a >> node by double clicking on it (this needs to be somehow communicated) >> otherwise it is random - each refresh. >> >> Maybe we should not refresh on failed operation because there is no >> change. > +1, failed operations on segments should not trigger graph redraws. Fixed in patch 936-1. > >> >>> >>> Ludwig >>> >>> On 11/20/2015 04:00 PM, Petr Vobornik wrote: >>>> Patches 928-931 are prerequisites. >>>> >>>> Patches 932-934 implements the visualization >>>> >>>> Patches 935-936 adds 'add' and 'remove' segment functionality to the >>>> visualization page. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4286 >> > > I have tested the new feature a bit (I have looked also on the code, but > I do not speak JavaScript very well) and so far I have found these issues: > > 1.) If you first setup topology w/ domain level 0 and try to render > topology graph, you are correctly informed that managed topology is > available on domain level 1 only. IF you raise your domainlevel and > click refresh, you get the same error message, probably because the > request to get domainlevel is sent only in the beginning of session. You > have to logout and then login back to see the graph. Login/Logout should not be required. Refresh of UI(F5) should be sufficient. Anyway, fixed in new patch 937. > > 2.) If I add a new segment using Add dialog and clicking 'Add & edit' > button, I get the following error: > > """ > IPA Error 3007: RequirementError > > 'topologysuffixcn' is required > """ > > However the segment is created normally. I guess that there is some bug > when viewing the segment immediately after creation. Fixed in patch 935-1. > > 3.) The key with suffix colors should be more descriptive. I would like > to propose the following format: > > """ > Color coding of segments by suffix: > {suffix_name} ({suffix_dn}) > e.g. > ipaca (o=ipaca) > realm (dc=ipa,dc=test) > """ > > 4.) It would be nice if the graph canvas could be dynamically resized > based on the container size, but I am not sure how difficult it is to > implement it. > (Graphical nitpick: I would change the color of nodes, green does not > fit very well with the bluish/grey palette of other WebUI elements) I would like this, #3 and #4 to go trough additional designer review and therefore fixed in other patch. Right now I'm not sure what is the correct behavior for the re-sizing. Atm the canvas size is fixed: 960x500. 1. What should be the canvas size when size of the container is very small, e.g. 330x90? With static positions, nodes would not be visible. 2. Similar issue when nodes are put into corners and then the window is shrunk. Probably there could be a minimum size and then enlarge the cavas when nodes are dragged. > > Otherwise I think that it is a good start and additional features can be > built on top of this patchset. > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0937-webui-update-topology-graph-after-raising-domain-lev.patch Type: text/x-patch Size: 3863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0936-1-webui-remove-segments-on-topology-graph-page.patch Type: text/x-patch Size: 4701 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0935-1-webui-add-segments-on-topology-graph-page.patch Type: text/x-patch Size: 7449 bytes Desc: not available URL: From ssorce at redhat.com Wed Nov 25 14:32:28 2015 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 25 Nov 2015 09:32:28 -0500 Subject: [Freeipa-devel] [PATCH 559] Fix kadmin for new users In-Reply-To: <5655B3FC.6060707@redhat.com> References: <1448404347.29102.23.camel@redhat.com> <5655B100.90403@redhat.com> <5655B3E1.4050107@redhat.com> <5655B3FC.6060707@redhat.com> Message-ID: <1448461948.29102.41.camel@redhat.com> On Wed, 2015-11-25 at 14:13 +0100, Tomas Babej wrote: > > On 11/25/2015 02:13 PM, Tomas Babej wrote: > > > > > > On 11/25/2015 02:00 PM, Martin Babinsky wrote: > >> On 11/24/2015 11:32 PM, Simo Sorce wrote: > >>> Ticket #937 was reopened a while ago because one corner case, new users > >>> that have never been assigned a password cause kadmin/kadmin.local to > >>> throw a fit when they try to visualize information about those user's > >>> principals. > >>> > >>> This patch fakes up modification information when no krbExtraData is > >>> available for the principal so that kadmin is happy. > >>> > >>> Tested and working as designed. > >>> > >>> Simo. > >>> > >>> > >>> > >> ACK > >> > > > > Pushed to master: 0f52eddd1d2781ccc1941c191e9ab6e3ccf6919d > > > > On a related note, should we backport this to later branches? It wouldn't hurt, it should apply straight to any 4.x and probably latest 3.x branches too. Simo. From mbasti at redhat.com Wed Nov 25 14:39:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 15:39:17 +0100 Subject: [Freeipa-devel] [PATCH 0362] KRA: do not stop certmonger during standalone uninstall Message-ID: <5655C815.5090105@redhat.com> https://fedorahosted.org/freeipa/ticket/5477 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0362-KRA-do-not-stop-certmonger-during-standalone-uninsta.patch Type: text/x-patch Size: 845 bytes Desc: not available URL: From mkosek at redhat.com Wed Nov 25 14:41:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Nov 2015 15:41:01 +0100 Subject: [Freeipa-devel] [PATCH 559] Fix kadmin for new users In-Reply-To: <1448461948.29102.41.camel@redhat.com> References: <1448404347.29102.23.camel@redhat.com> <5655B100.90403@redhat.com> <5655B3E1.4050107@redhat.com> <5655B3FC.6060707@redhat.com> <1448461948.29102.41.camel@redhat.com> Message-ID: <5655C87D.3000802@redhat.com> On 11/25/2015 03:32 PM, Simo Sorce wrote: > On Wed, 2015-11-25 at 14:13 +0100, Tomas Babej wrote: >> >> On 11/25/2015 02:13 PM, Tomas Babej wrote: >>> >>> >>> On 11/25/2015 02:00 PM, Martin Babinsky wrote: >>>> On 11/24/2015 11:32 PM, Simo Sorce wrote: >>>>> Ticket #937 was reopened a while ago because one corner case, new users >>>>> that have never been assigned a password cause kadmin/kadmin.local to >>>>> throw a fit when they try to visualize information about those user's >>>>> principals. >>>>> >>>>> This patch fakes up modification information when no krbExtraData is >>>>> available for the principal so that kadmin is happy. >>>>> >>>>> Tested and working as designed. >>>>> >>>>> Simo. >>>>> >>>>> >>>>> >>>> ACK >>>> >>> >>> Pushed to master: 0f52eddd1d2781ccc1941c191e9ab6e3ccf6919d >>> >> >> On a related note, should we backport this to later branches? > > It wouldn't hurt, it should apply straight to any 4.x and probably > latest 3.x branches too. I would not fix anything older than FreeIPA 4.1.x which is in F22, which is the oldest supported Fedora (or rather fill be, one month after F23 GA). From simo at redhat.com Wed Nov 25 14:44:09 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 25 Nov 2015 09:44:09 -0500 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <20151125043440.GZ5336@dhcp-40-8.bne.redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> <56541C4D.2020904@redhat.com> <1448382615.7892.65.camel@redhat.com> <56549182.40503@redhat.com> <1448393777.29102.6.camel@redhat.com> <20151125043440.GZ5336@dhcp-40-8.bne.redhat.com> Message-ID: <1448462649.29102.43.camel@redhat.com> On Wed, 2015-11-25 at 14:34 +1000, Fraser Tweedale wrote: > On Tue, Nov 24, 2015 at 02:36:17PM -0500, Simo Sorce wrote: > > On Tue, 2015-11-24 at 17:34 +0100, Jan Cholasta wrote: > > > On 24.11.2015 17:30, Simo Sorce wrote: > > > > On Tue, 2015-11-24 at 09:14 +0100, Jan Cholasta wrote: > > > >> On 24.11.2015 09:06, Petr Spacek wrote: > > > >>> On 24.11.2015 07:32, Jan Cholasta wrote: > > > >>>> On 23.11.2015 21:18, Simo Sorce wrote: > > > >>>>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not > > > >>>>> provided on the command line. > > > >>>>> > > > >>>>> Simo. > > > >>>> > > > >>>> Just a thought: it would be nice if we had libipaconfig and used it everywhere > > > >>>> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are > > > >>>> at least 3 ipa config parser implementations now, each with its own quirks. > > > >>> > > > >>> Yeah, define a Augeas grammar for IPA config and call it. There is C and > > > >>> Python binding in RHEL 7.2 already. > > > >> > > > >> This won't be sufficient, as it should go beyond just parsing the config > > > >> file - there are dynamic defaults and backward compatiblity support > > > >> which should be the same everywhere too. > > > > > > > > This is a much bigger task, that someone keen on big refactoring may > > > > undertake, but I do not think we should delay this useful feature for > > > > that. It will be really easy to change this code to use whatever other > > > > ipa library when it materializes. > > > > > > > > For now this patch stands IMHO. > > > > > > Sure, I'm not suggesting otherwise. > > > > Rebased patch that includes proper spec file buildrequires. > > > > Simo. > > > Tested and works as expected (great usability win IMO). > > Man page should be updated accordingly. > > Cheers, > Fraser Attached new patch that includes manpage changes. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-555-3-Support-sourcing-the-IPA-server-name-from-config.patch Type: text/x-patch Size: 9815 bytes Desc: not available URL: From simo at redhat.com Wed Nov 25 14:47:33 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 25 Nov 2015 09:47:33 -0500 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <5655BF5B.6020405@redhat.com> References: <1448394152.29102.10.camel@redhat.com> <1448395038.29102.11.camel@redhat.com> <1448399848.29102.13.camel@redhat.com> <56555AC7.2000908@redhat.com> <5655BF5B.6020405@redhat.com> Message-ID: <1448462853.29102.44.camel@redhat.com> On Wed, 2015-11-25 at 09:02 -0500, Rob Crittenden wrote: > Jan Cholasta wrote: > > On 24.11.2015 22:17, Simo Sorce wrote: > >> On Tue, 2015-11-24 at 14:57 -0500, Simo Sorce wrote: > >>> On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote: > >>>> Since some time we use the getkeytab operation to fetch keytabs on > >>>> newer > >>>> clients. According to bug #232 setkeytab can be used to circumvent > >>>> password quality controls so it needs to be slowly retired. > >>>> > >>>> The attached patches implement #5485 in 2 parts. > >>>> > >>>> The first introduces the option DisableSetKeytab which globally > >>>> disables > >>>> the setkeytab extended operation. This is set to false by default for > >>>> backwards compatibility. > >>>> > >>>> The second introduces an option called DisableUserSetKeytab, which is > >>>> active by default in new installs (but not in upgraded ones), and only > >>>> disables the use of setkeytab for ipa suers, but not for > >>>> hosts/services. > >>>> This is because user's are the ones that may abuse the interface to > >>>> escape password policies and users also normally do not acquire > >>>> keytabs, > >>>> so it is a safe bet to disable just them by default in new installs. > >>>> > >>>> (Testing in progress) > >>> > >>> Tested and working as expected. > >> > >> I realized that adding options to ipaConfig require to add them in the > >> UI as well, attached patches add options in API.txt and config.py > >> Make now complain I should change API Major or Minor, but it is not > >> clear to me why given this are additional values and no real change or > >> new function is introduced. What's the recommendation ? > > > > When does make complain? It is supposed to complain only when API.txt > > does not match code. > > > > Anyway, we usually bump minor version even for backward compatible > > changes, see e.g. commit 9549a59. > > > > The point of API.txt (and the heavy client) was to save a round-trip. > Being able to pass in an invalid option would void that rule hence > having to update the API when new values are added. > > rob Ok added version change to the second patch (so we bump it only once given these are basically related changes. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-557-3-Disable-User-s-ability-to-use-the-setkeytab-exop.patch Type: text/x-patch Size: 7482 bytes Desc: not available URL: From pviktori at redhat.com Wed Nov 25 14:47:36 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Nov 2015 15:47:36 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run In-Reply-To: <565587AE.2070303@redhat.com> References: <5638B8F9.6010703@redhat.com> <564D0FD9.4070505@redhat.com> <5652B5AC.2040508@redhat.com> <5652E174.50301@redhat.com> <56548E73.1090105@redhat.com> <565587AE.2070303@redhat.com> Message-ID: <5655CA08.8090701@redhat.com> On 11/25/2015 11:04 AM, Jan Cholasta wrote: > On 24.11.2015 17:21, Petr Viktorin wrote: >> On 11/23/2015 10:50 AM, Jan Cholasta wrote: >>> On 23.11.2015 07:43, Jan Cholasta wrote: >>>> On 19.11.2015 00:55, Petr Viktorin wrote: >>>>> On 11/03/2015 02:39 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> Python 3's strings are Unicode, so data coming to or leaving a Python >>>>>> program needs to be decoded/encoded if it's to be handled as a >>>>>> string. >>>>>> One of the boundaries where encoding is necessary is external >>>>>> programs, >>>>>> specifically, ipautil.run. >>>>>> Unfortunately there's no one set of options that would work for all >>>>>> run() invocations, so I went through them all and specified the >>>>>> stdin/stdout/stderr encoding where necessary. I've also updated the >>>>>> call >>>>>> sites to make it clearer if the return values are used or not. >>>>>> If an encoding is not set, run() will accept/return bytes. (This is a >>>>>> fail-safe setting, since it can't raise errors, and using bytes where >>>>>> strings are expected generally fails loudly in py3.) >>>>>> >>>>>> Note that the changes are not effective under Python 2. >>>>> >>>>> ping, >>>>> Could someone look at this patch? >>>> >>>> Looking. >>> >>> 1) I think a better approach would be to use str for stdin/stdout/stderr >>> by default in both Python 2 and 3, i.e. do nothing in Python 2 and >>> encode/decode using locale.getpreferredencoding() in Python 3. This is >>> consistent with sys.std{in,out,err} in both Python 2 and 3. Using bytes >>> or different encoding should be opt-in. >>> >>> Note that different encoding should be used only if the LC_ALL or LANG >>> variables are overriden in the command's environment. >> >> That would assume the output of *everything* run via ipautil.run can be >> decoded using the locale encoding. Any stray invalid byte would make IPA >> crash, even in cases where we don't care about the output. IPA calls too >> many weird tools to assume they all output text. > > Such a stray invalid byte may bubble through our code and cause havoc > somewhere else, which is much harder to troubleshoot than a crash in > ipautil.run(), where you can see that it was a misbehaving command that > caused the crash and exactly what command it was. The invalid byte can't bubble through code, because if you don't specify an encoding you get bytes back. You'll get a crash when you try using it as a string. locale.getpreferredencoding() is not used consistently in all software, especially if it's not written in Python. For instance, wget won't magically re-encode the data it fetches for us. It's better to explicitly specify the encoding every time. > If we don't care about output somewhere, we should not capture it there > at all. Then people need to remember to put "capture_output=True" everywhere (except that also disables logging of the output, so we'd need an additional option). >>> 3) I think the "surrogateescape" error handler would be better for >>> non-strict decoding, as the text can be encoded back to bytes without >>> loss of information. >> >> Non-strict decoding is meant for logging, so we want backslash escapes >> rather than invalid surrogates. If you need round-tripping then you >> should use bytes. > > I see. There is no guarantee that non-strict output will be used only > for logging though. > > I think it might be better to return raw output and let the caller use a > decode-for-logging utility function instead. The logger already escapes > invalid bytes itself, so the function would have to be used only when > raising exceptions. It's also used for logging at a higher level (info-critical). But this makes sense; changed. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0748.3-Handle-encoding-for-ipautil.run.patch Type: text/x-patch Size: 59069 bytes Desc: not available URL: From simo at redhat.com Wed Nov 25 14:54:13 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 25 Nov 2015 09:54:13 -0500 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <20151125092418.GA4085@p.redhat.com> References: <1448394152.29102.10.camel@redhat.com> <20151125092418.GA4085@p.redhat.com> Message-ID: <1448463253.29102.47.camel@redhat.com> On Wed, 2015-11-25 at 10:24 +0100, Sumit Bose wrote: > On Tue, Nov 24, 2015 at 02:42:32PM -0500, Simo Sorce wrote: > > Since some time we use the getkeytab operation to fetch keytabs on newer > > clients. According to bug #232 setkeytab can be used to circumvent > > password quality controls so it needs to be slowly retired. > > ipasam uses this exop to create the cross-realm TGT principal objects, > krbtgt/DOM.A at DOM.B. What should be used instead to make sure that > setkeytab can safely be disabled? It must use the new getkeytab extended operation. Can you open a ticket to fix this and assign it to me ? Simo. > bye, > Sumit > > > > > The attached patches implement #5485 in 2 parts. > > > > The first introduces the option DisableSetKeytab which globally disables > > the setkeytab extended operation. This is set to false by default for > > backwards compatibility. > > > > The second introduces an option called DisableUserSetKeytab, which is > > active by default in new installs (but not in upgraded ones), and only > > disables the use of setkeytab for ipa suers, but not for hosts/services. > > This is because user's are the ones that may abuse the interface to > > escape password policies and users also normally do not acquire keytabs, > > so it is a safe bet to disable just them by default in new installs. > > > > (Testing in progress) > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Nov 25 14:57:10 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Nov 2015 15:57:10 +0100 Subject: [Freeipa-devel] [pytest-multihost-devel][PATCH] Functions for handling various file and directory operations In-Reply-To: <56557AAB.5020100@redhat.com> References: <56557AAB.5020100@redhat.com> Message-ID: <5655CC46.7020207@redhat.com> On 11/25/2015 10:08 AM, Abhijeet Kasurde wrote: > Hi All, > > Please find the patch for pytest-multihost-plugin. > > Fixes : https://fedorahosted.org/python-pytest-multihost/ticket/2 Thanks! These will be useful. ACK, pushed as e7bf95b3ba4ca84b73abffda1abcf6187c5c8a67 I wrote some tests for the file operations as well: 5e76908430bbb56ca981b04a88f12359c73c7e1f I plan to do a release (and update the Fedora package) after IPA starts testing under Python 3. Let me know if an earlier release would help you. -- Petr Viktorin From redhatrises at gmail.com Wed Nov 25 15:33:04 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 25 Nov 2015 08:33:04 -0700 Subject: [Freeipa-devel] [PATCH 0384] ipa-client-automount: Leverage IPAChangeConf to configure the idmapd In-Reply-To: <56434F15.6070600@redhat.com> References: <56434F15.6070600@redhat.com> Message-ID: Ack. Gabe On Wed, Nov 11, 2015 at 7:22 AM, Tomas Babej wrote: > Hi, > > Simple regexp substitution caused that the domain directive fell under > an inapprorpiate section, if the domain directive was not present. Hence > the idmapd.conf file was not properly parsed. > > Use IPAChangeConf to put the directive in its correct place even if it > the domain directive is missing. > > https://fedorahosted.org/freeipa/ticket/5069 > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed Nov 25 15:36:39 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 25 Nov 2015 08:36:39 -0700 Subject: [Freeipa-devel] [PATCH 0015] mod_auth_gssapi: Remove ntlmssp support and restrict, mechanism to krb5 In-Reply-To: <1874088905.2398755.1437572990514.JavaMail.zimbra@redhat.com> References: <55AF9B8B.4030509@redhat.com> <1874088905.2398755.1437572990514.JavaMail.zimbra@redhat.com> Message-ID: Bump for push. May need a rebase. On Wed, Jul 22, 2015 at 7:49 AM, Simo Sorce wrote: > ----- Original Message ----- > > From: "Christian Heimes" > > To: "freeipa-devel" > > Sent: Wednesday, July 22, 2015 9:32:59 AM > > Subject: [Freeipa-devel] [PATCH 0015] mod_auth_gssapi: Remove ntlmssp > support and restrict, mechanism to krb5 > > > > By default mod_auth_gssapi allows all locally available mechanisms. If > > the gssntlmssp package is installed, it also offers ntlmssp. This has > > the annoying side effect that some browser will pop up a > > username/password request dialog if no Krb5 credentials are available. > > > > The patch restricts the mechanism to krb5 and removes ntlmssp and > > iakerb support from Apache's ipa.conf. > > > > The new feature was added to mod_auth_gssapi 1.3.0. > > > > https://fedorahosted.org/freeipa/ticket/5114 > > LGTM > > Simo. > > -- > Simo Sorce * Red Hat, Inc. * New York > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Wed Nov 25 15:44:01 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 25 Nov 2015 16:44:01 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <564CA530.3060006@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> Message-ID: <5655D741.4010402@redhat.com> Hi, Here is the updated version of the patch (more tests + fixed the issues of the first one) + patch 0017, that implements the necessary changes in the background code, i. e. patch 16 does not work without patch 17 On 11/18/2015 05:20 PM, Martin Basti wrote: > > > On 09.11.2015 15:09, Oleg Fayans wrote: >> Hi guys, >> >> Here are first two automated testcases from this (so far incomplete) >> testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >> >> Testplan review is highly appreciated >> >> >> >> > PATCH 16: NACK > > 1) > What is the reason to add an unused parameter to 'domain_level' to > install_topo()? > Also it is good practise to add new option as the last parameter. > > 2) > cab you in both tests specify a domain level with constant instead of > number literal? > > 3) > both test call install_topo with custom domain level, but it cannot work > because 1) (did you run the test?) > > 4) > How the test "TestLevel1" is supposed to work? > Respectively why there is call of install_topo() that installs replica. > As this test just tests that ipa-replica-prepare is not working anymore, > is it worth to spend 20 minutes with installing replica and then just no > tot use it? IMO to install master in install step is enough. > > Martin^2 > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0016.1-First-part-of-replica-promotion-tests.patch Type: text/x-patch Size: 7466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0017-Enabled-setting-domain_level-per-class.patch Type: text/x-patch Size: 3283 bytes Desc: not available URL: From sbose at redhat.com Wed Nov 25 15:52:23 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 25 Nov 2015 16:52:23 +0100 Subject: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations In-Reply-To: <1448463253.29102.47.camel@redhat.com> References: <1448394152.29102.10.camel@redhat.com> <20151125092418.GA4085@p.redhat.com> <1448463253.29102.47.camel@redhat.com> Message-ID: <20151125155223.GH4085@p.redhat.com> On Wed, Nov 25, 2015 at 09:54:13AM -0500, Simo Sorce wrote: > On Wed, 2015-11-25 at 10:24 +0100, Sumit Bose wrote: > > On Tue, Nov 24, 2015 at 02:42:32PM -0500, Simo Sorce wrote: > > > Since some time we use the getkeytab operation to fetch keytabs on newer > > > clients. According to bug #232 setkeytab can be used to circumvent > > > password quality controls so it needs to be slowly retired. > > > > ipasam uses this exop to create the cross-realm TGT principal objects, > > krbtgt/DOM.A at DOM.B. What should be used instead to make sure that > > setkeytab can safely be disabled? > > It must use the new getkeytab extended operation. > > Can you open a ticket to fix this and assign it to me ? Here you are https://fedorahosted.org/freeipa/ticket/5495 bye, Sumit > > Simo. > > > bye, > > Sumit > > > > > > > > The attached patches implement #5485 in 2 parts. > > > > > > The first introduces the option DisableSetKeytab which globally disables > > > the setkeytab extended operation. This is set to false by default for > > > backwards compatibility. > > > > > > The second introduces an option called DisableUserSetKeytab, which is > > > active by default in new installs (but not in upgraded ones), and only > > > disables the use of setkeytab for ipa suers, but not for hosts/services. > > > This is because user's are the ones that may abuse the interface to > > > escape password policies and users also normally do not acquire keytabs, > > > so it is a safe bet to disable just them by default in new installs. > > > > > > (Testing in progress) > > > > > > Simo. > > > > > > -- > > > Simo Sorce * Red Hat, Inc * New York > > > -- > Simo Sorce * Red Hat, Inc * New York > From mbabinsk at redhat.com Wed Nov 25 16:05:02 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 25 Nov 2015 17:05:02 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization In-Reply-To: <5655C57D.6090904@redhat.com> References: <564F3577.9090207@redhat.com> <565445AA.4070404@redhat.com> <56544763.2090905@redhat.com> <56546189.9010505@redhat.com> <5655C57D.6090904@redhat.com> Message-ID: <5655DC2E.4050707@redhat.com> On 11/25/2015 03:28 PM, Petr Vobornik wrote: > On 11/24/2015 02:09 PM, Martin Babinsky wrote: >> On 11/24/2015 12:17 PM, Petr Vobornik wrote: >>> On 11/24/2015 12:10 PM, Ludwig Krispenz wrote: >>>> Hi Petr, >>>> >>>> I'm testing these patches.Two observations so far: >>>> - in Topology->IPA Servers I see a table of my servers and the managed >>>> suffix column I see both suffixes, ipaca and the realm, >>>> but if I select one of the servers I Only see the realm suffix, this >>>> was >>>> different in the demo video >>> >>> implemented in patch 927 (separate thread) >>> >>>> - the graph layou is not stable. If I arrange it and the try some >>>> actions on a segment, eg try to remove one (which is rejected), the >>>> graph does change again- >>> >>> Not sure if I understand it correctly. One can set static position to a >>> node by double clicking on it (this needs to be somehow communicated) >>> otherwise it is random - each refresh. >>> >>> Maybe we should not refresh on failed operation because there is no >>> change. >> +1, failed operations on segments should not trigger graph redraws. > > Fixed in patch 936-1. > Confirmed. >> >>> >>>> >>>> Ludwig >>>> >>>> On 11/20/2015 04:00 PM, Petr Vobornik wrote: >>>>> Patches 928-931 are prerequisites. >>>>> >>>>> Patches 932-934 implements the visualization >>>>> >>>>> Patches 935-936 adds 'add' and 'remove' segment functionality to the >>>>> visualization page. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4286 >>> >> >> I have tested the new feature a bit (I have looked also on the code, but >> I do not speak JavaScript very well) and so far I have found these >> issues: >> >> 1.) If you first setup topology w/ domain level 0 and try to render >> topology graph, you are correctly informed that managed topology is >> available on domain level 1 only. IF you raise your domainlevel and >> click refresh, you get the same error message, probably because the >> request to get domainlevel is sent only in the beginning of session. You >> have to logout and then login back to see the graph. > > Login/Logout should not be required. Refresh of UI(F5) should be > sufficient. > > Anyway, fixed in new patch 937. > Confirmed works as advertised. >> >> 2.) If I add a new segment using Add dialog and clicking 'Add & edit' >> button, I get the following error: >> >> """ >> IPA Error 3007: RequirementError >> >> 'topologysuffixcn' is required >> """ >> >> However the segment is created normally. I guess that there is some bug >> when viewing the segment immediately after creation. > > Fixed in patch 935-1. > Indeed. >> >> 3.) The key with suffix colors should be more descriptive. I would like >> to propose the following format: >> >> """ >> Color coding of segments by suffix: >> {suffix_name} ({suffix_dn}) >> e.g. >> ipaca (o=ipaca) >> realm (dc=ipa,dc=test) >> """ >> >> 4.) It would be nice if the graph canvas could be dynamically resized >> based on the container size, but I am not sure how difficult it is to >> implement it. >> (Graphical nitpick: I would change the color of nodes, green does not >> fit very well with the bluish/grey palette of other WebUI elements) > > I would like this, #3 and #4 to go trough additional designer review and > therefore fixed in other patch. > I'm OK with that, it is a cosmetic change anyway so we shouldn't bikeshed over it. > Right now I'm not sure what is the correct behavior for the re-sizing. > > Atm the canvas size is fixed: 960x500. > > 1. What should be the canvas size when size of the container is very > small, e.g. 330x90? With static positions, nodes would not be visible. > 2. Similar issue when nodes are put into corners and then the window is > shrunk. > > Probably there could be a minimum size and then enlarge the cavas when > nodes are dragged. > Minimum canvas size makes sense IMHO. I'm not sure about the behavior of the auto-resize during node manipulation. I would begin with a canvas that has some reasonable minimal size and expands to the size of the container/facet (not sure about the terminology here) during resize with some reasonable padding added. Then we can implement some zooming/panning feature on top. >> >> Otherwise I think that it is a good start and additional features can be >> built on top of this patchset. >> All in all I think that all these points can be addressed in followup patches after discussion with UX people. If nobody else objects I would ACK these patches. -- Martin^3 Babinsky From slaznick at redhat.com Wed Nov 25 16:18:16 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 25 Nov 2015 17:18:16 +0100 Subject: [Freeipa-devel] [PATCH] Removed duplicate domain name validation function Message-ID: <5655DF48.4060302@redhat.com> There were two functions for the same purpose. Removed one. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0010-Removed-duplicate-domain-name-validating-function.patch Type: text/x-patch Size: 9033 bytes Desc: not available URL: From simo at redhat.com Wed Nov 25 17:43:16 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 25 Nov 2015 12:43:16 -0500 Subject: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user In-Reply-To: <56555E8C.5020608@redhat.com> References: <1448406570.29102.26.camel@redhat.com> <56555E8C.5020608@redhat.com> Message-ID: <1448473396.17462.4.camel@redhat.com> On Wed, 2015-11-25 at 08:09 +0100, Jan Cholasta wrote: > On 25.11.2015 00:09, Simo Sorce wrote: > > This patch is untested and mostly an RFC. > > > > I think it is all we need to allow to specify authz data types per user > > and by setting the attribute to NONE preventing a user from getting > > MS-PAC data in their ticket. > > > > Alexander you changed quite a bit the code around here so I'd like to > > know if you think the change I made in the KDC will cause any issue with > > the special PACs we generate for master's principals. As far as I can > > tell it shouldn't. > > > > Any opinion is welcome. > > Before your change, the server entry was checked for AS requests, now > only the client entry is checked for AS requests. I'm not very familiar > with ipa-kdb, but shouldn't the server entry still be checked as a > fallback when there is no authorization data in the client entry? This is partly why I CCed Alexander, the way the get function works is that it will get policy on the entry itself and if nothing is there it will try with the global policy, so in both cases the global policy is sourced as fallback. For AS requests though you are generally asking for a TGT so the "server" is the krbtgt entry that has no policy. It is through though that a client *can* ask for a ticket directly via an AS request, that is uncommon and it is unclear to me what we should do in that case if client and server have incompatible options. Well this is why it is a RFC after all :) > The attribute is exposed in the service plugin, shouldn't it be exposed > in the user plugin as well? I didn't do it on purpose yet but eventually we may want to expose it, indeed. The reason I didn't is that we may want to use something like CoS to populate the attribute based on group membership and I am not sure we want to expose it per user, up top debate. > Nitpick: don't remove the space character here: "( uid )". noted. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Nov 25 17:46:02 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 25 Nov 2015 12:46:02 -0500 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <56557E81.1020202@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> <56557E81.1020202@redhat.com> Message-ID: <1448473562.17462.6.camel@redhat.com> On Wed, 2015-11-25 at 10:25 +0100, Jan Cholasta wrote: > On 20.11.2015 16:49, Jan Cholasta wrote: > > On 19.11.2015 17:43, Simo Sorce wrote: > >> 510: > >> - We should probably tightenup the ACI to allos host X to only add > >> memberPrincipal = X and no other value, also the host should not be > >> allowed to change the memberPrincipal attribute only the keys. > >> If we can't express this in ACIs we can live with the ones you propose > >> though. > > > > I think this can be done. > > Turns out this can be done only if member (or some other DN attribute) > is used instead of memberPrincipal. > > So, to reiterate: > > >>> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? > >>> > >>> If 'member' was used instead, we would gain referential integrity and > >>> the ability to add ACIs based on the attribute (think > >>> userattr="member#USERDN"). > >> > >> To avoid referential integrity and mixup with other group objects, it > >> was intentional. > > Why is referential integrity a problem? Because it will remove the member if the object it references goes away, and I do not want an "orphaned" entry for custodia. > Mixup with other group objects can be solved by using a different attribute. There is also the fact in future we may want to use this with "external" principals (like in IPA-IPA trusts or similar) so I didn't want to have to come up with bogus DNs in that case. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Wed Nov 25 18:42:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Nov 2015 19:42:44 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <5655D741.4010402@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> Message-ID: <56560124.4060904@redhat.com> Hi, 0) Note Please be aware of https://fedorahosted.org/freeipa/ticket/5469 during KRA testing 1) Please do not use MIN and MAX_DOMAIN_LEVEL constants, this may change over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain level 0 and 1 2) Why uninstall KRA then server, is not enough just uninstall server which covers KRA uninstall? + def teardown_method(self, method): + for host in self.replicas: + host.run_command(self.kra_uninstall, raiseonerr=False) + tasks.uninstall_master(host) 3) Can be this function more generic? It should allow specify host where KRA should be installed not just master + def test_kra_install_master(self): + self.master.run_command(self.kra_install) 4) TestLevel0(Dummy): Can be the test name more specific, something like TestReplicaPromotionLevel0 5) please remove this, the patch is on review and it will be pushed sooner than tests + @pytest.mark.xfail # Ticket N 5455 and as I mentioned in ticket #5455, I cannot reproduce it with ipa-kra-install, so please provide steps to reproduce if you insist that this still does not work as expected with KRA. 6) This is completely wrong, it removes everything that we tried to achieve with previous patches with domain level in CI [PATCH] Enabled setting domain_level per class derived from TestIntegration When I configure domain level 0 in yaml config, how is this supposed to get into install methods when you removed that code? - "--domain-level=%i" % host.config.domain_level + "--domain-level=%i" % domain_level You always use MAX_DOMAIN_LEVEL in this case or whatever is specified in domain_level option. I suggest to use domain_level=None, and when it is None use 'host.config.domain_level', if it is not None, use 'domain_level' With this we can specify domain level in config file for test that can be used for both domain levels and you can manually specify domain level for test that requires specific domain level. Also this should go away @classmethod def install(cls, mh): + if hasattr(cls, "domain_level") and cls.master: + cls.master.config.domain_level = cls.domain_level if cls.topology is None: return I do not see reason why test should override configuration in config in this case. Martin On 25.11.2015 16:44, Oleg Fayans wrote: > Hi, > > Here is the updated version of the patch (more tests + fixed the > issues of the first one) + patch 0017, that implements the necessary > changes in the background code, i. e. patch 16 does not work without > patch 17 > > On 11/18/2015 05:20 PM, Martin Basti wrote: >> >> >> On 09.11.2015 15:09, Oleg Fayans wrote: >>> Hi guys, >>> >>> Here are first two automated testcases from this (so far incomplete) >>> testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>> >>> Testplan review is highly appreciated >>> >>> >>> >>> >> PATCH 16: NACK >> >> 1) >> What is the reason to add an unused parameter to 'domain_level' to >> install_topo()? >> Also it is good practise to add new option as the last parameter. >> >> 2) >> cab you in both tests specify a domain level with constant instead of >> number literal? >> >> 3) >> both test call install_topo with custom domain level, but it cannot work >> because 1) (did you run the test?) >> >> 4) >> How the test "TestLevel1" is supposed to work? >> Respectively why there is call of install_topo() that installs replica. >> As this test just tests that ipa-replica-prepare is not working anymore, >> is it worth to spend 20 minutes with installing replica and then just no >> tot use it? IMO to install master in install step is enough. >> >> Martin^2 >> > From ofayans at redhat.com Wed Nov 25 20:35:38 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 25 Nov 2015 21:35:38 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <564DE017.4020408@redhat.com> References: <564DE017.4020408@redhat.com> Message-ID: <56561B9A.9000301@redhat.com> Hi, Should I cover ticket N 3416 in the replica promotion test plan? It should be tested, and IMO there is no sense in creating a separate test plan for just that. On 11/19/2015 03:43 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix > and . > > I worked around the issue of checking if the user is privileged to > perform replica promotion by using host credentials instead. The host > must be a member of the IPA servers host group "ipaservers" in order to > be able to promote itself. Using host credentials will also allow > replica install using one-time password. > > User credentials are still used for connection check and to > automatically add the host to ipaservers if the user is privileged to do > that. > > Simo, is this approach OK? Could you check the new ACIs in patches 510 > and 513? > > I have a couple of questions: > > 1) Why are custodia keys for the replica added to LDAP using connection > to the remote master instead of local ldapi connection? Is it to > eliminate race conditions caused by replication timeout from the replica > to the remote master? > > If the code was changed to use ldapi and wait until the key appears in > custodia on the remote master, we could lose the "IPA server hosts can > create own Custodia secrets" and "IPA server hosts can manage own > Custodia secrets" ACIs from patch 510. Not sure if it's worth the change > though. > > 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? > > If 'member' was used instead, we would gain referential integrity and > the ability to add ACIs based on the attribute (think > userattr="member#USERDN"). > > 3) Why is 'memberPrincipal' used in cn=custodia at all? > > The hostname of the replica is already in 'cn', so instead of searching > cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we > could get cn={enc,sig}/$HOSTNAME,cn=custodia directly. > > Honza > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ftweedal at redhat.com Thu Nov 26 01:11:56 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 26 Nov 2015 11:11:56 +1000 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <1448462649.29102.43.camel@redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> <56541C4D.2020904@redhat.com> <1448382615.7892.65.camel@redhat.com> <56549182.40503@redhat.com> <1448393777.29102.6.camel@redhat.com> <20151125043440.GZ5336@dhcp-40-8.bne.redhat.com> <1448462649.29102.43.camel@redhat.com> Message-ID: <20151126011156.GA23644@dhcp-40-8.bne.redhat.com> On Wed, Nov 25, 2015 at 09:44:09AM -0500, Simo Sorce wrote: > On Wed, 2015-11-25 at 14:34 +1000, Fraser Tweedale wrote: > > On Tue, Nov 24, 2015 at 02:36:17PM -0500, Simo Sorce wrote: > > > On Tue, 2015-11-24 at 17:34 +0100, Jan Cholasta wrote: > > > > On 24.11.2015 17:30, Simo Sorce wrote: > > > > > On Tue, 2015-11-24 at 09:14 +0100, Jan Cholasta wrote: > > > > >> On 24.11.2015 09:06, Petr Spacek wrote: > > > > >>> On 24.11.2015 07:32, Jan Cholasta wrote: > > > > >>>> On 23.11.2015 21:18, Simo Sorce wrote: > > > > >>>>> Fixes #2203 by reading the server name from /etc/ipa/default.conf if not > > > > >>>>> provided on the command line. > > > > >>>>> > > > > >>>>> Simo. > > > > >>>> > > > > >>>> Just a thought: it would be nice if we had libipaconfig and used it everywhere > > > > >>>> (the framework, ipa-getkeytab, certmonger, ...). I don't like that there are > > > > >>>> at least 3 ipa config parser implementations now, each with its own quirks. > > > > >>> > > > > >>> Yeah, define a Augeas grammar for IPA config and call it. There is C and > > > > >>> Python binding in RHEL 7.2 already. > > > > >> > > > > >> This won't be sufficient, as it should go beyond just parsing the config > > > > >> file - there are dynamic defaults and backward compatiblity support > > > > >> which should be the same everywhere too. > > > > > > > > > > This is a much bigger task, that someone keen on big refactoring may > > > > > undertake, but I do not think we should delay this useful feature for > > > > > that. It will be really easy to change this code to use whatever other > > > > > ipa library when it materializes. > > > > > > > > > > For now this patch stands IMHO. > > > > > > > > Sure, I'm not suggesting otherwise. > > > > > > Rebased patch that includes proper spec file buildrequires. > > > > > > Simo. > > > > > Tested and works as expected (great usability win IMO). > > > > Man page should be updated accordingly. > > > > Cheers, > > Fraser > > Attached new patch that includes manpage changes. > > Simo. > ACK From jcholast at redhat.com Thu Nov 26 06:11:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Nov 2015 07:11:23 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <56561B9A.9000301@redhat.com> References: <564DE017.4020408@redhat.com> <56561B9A.9000301@redhat.com> Message-ID: <5656A28B.5020002@redhat.com> Works for me. On 25.11.2015 21:35, Oleg Fayans wrote: > Hi, > > Should I cover ticket N 3416 in the replica promotion test plan? It > should be tested, and IMO there is no sense in creating a separate test > plan for just that. > > On 11/19/2015 03:43 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix >> and . >> >> I worked around the issue of checking if the user is privileged to >> perform replica promotion by using host credentials instead. The host >> must be a member of the IPA servers host group "ipaservers" in order to >> be able to promote itself. Using host credentials will also allow >> replica install using one-time password. >> >> User credentials are still used for connection check and to >> automatically add the host to ipaservers if the user is privileged to do >> that. >> >> Simo, is this approach OK? Could you check the new ACIs in patches 510 >> and 513? >> >> I have a couple of questions: >> >> 1) Why are custodia keys for the replica added to LDAP using connection >> to the remote master instead of local ldapi connection? Is it to >> eliminate race conditions caused by replication timeout from the replica >> to the remote master? >> >> If the code was changed to use ldapi and wait until the key appears in >> custodia on the remote master, we could lose the "IPA server hosts can >> create own Custodia secrets" and "IPA server hosts can manage own >> Custodia secrets" ACIs from patch 510. Not sure if it's worth the change >> though. >> >> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? >> >> If 'member' was used instead, we would gain referential integrity and >> the ability to add ACIs based on the attribute (think >> userattr="member#USERDN"). >> >> 3) Why is 'memberPrincipal' used in cn=custodia at all? >> >> The hostname of the replica is already in 'cn', so instead of searching >> cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we >> could get cn={enc,sig}/$HOSTNAME,cn=custodia directly. >> >> Honza >> >> >> > -- Jan Cholasta From akasurde at redhat.com Thu Nov 26 06:42:40 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 26 Nov 2015 12:12:40 +0530 Subject: [Freeipa-devel] [pytest-multihost-devel][PATCH] Functions for handling various file and directory operations In-Reply-To: <5655CC46.7020207@redhat.com> References: <56557AAB.5020100@redhat.com> <5655CC46.7020207@redhat.com> Message-ID: <5656A9E0.3090604@redhat.com> Hi Petr, On 11/25/2015 08:27 PM, Petr Viktorin wrote: > On 11/25/2015 10:08 AM, Abhijeet Kasurde wrote: >> Hi All, >> >> Please find the patch for pytest-multihost-plugin. >> >> Fixes : https://fedorahosted.org/python-pytest-multihost/ticket/2 > Thanks! These will be useful. > > ACK, pushed as e7bf95b3ba4ca84b73abffda1abcf6187c5c8a67 > I wrote some tests for the file operations as well: > 5e76908430bbb56ca981b04a88f12359c73c7e1f > Thanks for adding testcases for these functions. > I plan to do a release (and update the Fedora package) after IPA starts > testing under Python 3. Let me know if an earlier release would help you. Yes, indeed. It will be very helpful. Let me know if you need any help for my side. > > Thanks, Abhijeet Kasurde From jcholast at redhat.com Thu Nov 26 06:47:07 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Nov 2015 07:47:07 +0100 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <1448473562.17462.6.camel@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> <56557E81.1020202@redhat.com> <1448473562.17462.6.camel@redhat.com> Message-ID: <5656AAEB.1070806@redhat.com> On 25.11.2015 18:46, Simo Sorce wrote: > On Wed, 2015-11-25 at 10:25 +0100, Jan Cholasta wrote: >> On 20.11.2015 16:49, Jan Cholasta wrote: >>> On 19.11.2015 17:43, Simo Sorce wrote: >>>> 510: >>>> - We should probably tightenup the ACI to allos host X to only add >>>> memberPrincipal = X and no other value, also the host should not be >>>> allowed to change the memberPrincipal attribute only the keys. >>>> If we can't express this in ACIs we can live with the ones you propose >>>> though. >>> >>> I think this can be done. >> >> Turns out this can be done only if member (or some other DN attribute) >> is used instead of memberPrincipal. >> >> So, to reiterate: >> >>>>> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? >>>>> >>>>> If 'member' was used instead, we would gain referential integrity and >>>>> the ability to add ACIs based on the attribute (think >>>>> userattr="member#USERDN"). >>>> >>>> To avoid referential integrity and mixup with other group objects, it >>>> was intentional. >> >> Why is referential integrity a problem? > > Because it will remove the member if the object it references goes away, > and I do not want an "orphaned" entry for custodia. But without referential integrity you get an orphaned entry too, except with an extra dangling reference. IMHO that's even worse than "plain" orhpaned entry, because you can't spot it just by looking at the attribute value. > >> Mixup with other group objects can be solved by using a different attribute. > > There is also the fact in future we may want to use this with "external" > principals (like in IPA-IPA trusts or similar) so I didn't want to have > to come up with bogus DNs in that case. IIRC Alexander was working on something like exposing external principals in LDAP using the compat plugin, in order to allow external users to run IPA commands. Alternatively, it could do what groups do - use DN for internal references and string (be it principal or something else) for external references. Anyway, either memberPrincipal is replaced with a member-like attribute, or the ACI stays as it is. I would prefer a member-like attribute, because I feel that's the way LDAP entries should reference each other, but I will leave the decision to you. -- Jan Cholasta From jcholast at redhat.com Thu Nov 26 08:01:43 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Nov 2015 09:01:43 +0100 Subject: [Freeipa-devel] [PATCH 0064-0065] ipa-dns-install offers IP addresses from resolv.conf as default forwarder In-Reply-To: <5643505A.7000800@redhat.com> References: <56421416.8060104@redhat.com> <5642EA7B.1060505@redhat.com> <5642FBE4.8040501@redhat.com> <5642FD27.1050103@redhat.com> <5642FDF2.3060609@redhat.com> <5643505A.7000800@redhat.com> Message-ID: <5656BC67.7070202@redhat.com> On 11.11.2015 15:27, Petr Spacek wrote: > On 11.11.2015 09:36, Martin Babinsky wrote: >> On 11/11/2015 09:32 AM, Jan Cholasta wrote: >>> On 11.11.2015 09:27, Martin Babinsky wrote: >>>> On 11/11/2015 08:12 AM, Jan Cholasta wrote: >>>>> On 10.11.2015 16:58, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> Patch 64: >>>>>> ipa-dns-install offer IP addresses from resolv.conf as default >>>>>> forwarders >>>>>> >>>>>> In non-interactive more option --auto-forwarders can be used to do the >>>>>> same. --forward option can be used to supply additional IP addresses. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5438 >>>>> >>>>> IMO it's perverse to add option which effectively means "use default >>>>> value" instead of actually using the value as default. This is >>>>> inconsistent with every other option and I don't see what makes >>>>> forwarders so special to require this. >>>>> >>>>> NACK unless you have a strong justification for this. > > Motivation: > /etc/resolv.conf holds nearest DNS servers. On the other hand, you want to > have backup forwarder which may not be local but could work even if local ones > fail. > > Option --default-forwarders reads list of "local" servers from resolv.conf and > --forwarder option allows you to add additional IP addresses to it. > > So your Ansible script can contain call like: > ipa-server-install --setup-dns --default-forwarder > --forwarder= > and you do not need to worry about mapping sites to nearest servers etc. > >>>> Is it possible to use default_getter decorator to fetch defaults for the >>>> 'forwarders' knob from the resolver if it is avaliable like so (warning: >>>> untested and possibly wrong)? >>> >>> Yes, this is exactly how it should be used (although the exception >>> handling could be better). >>> >> That was just a quick example off the top of my head without much thought >> going into it. >> >> Anyway, when running in interactive mode the installer can inform the user >> that he found these forwarders as defaults and prompt whether they shoud be used. > > After discussion in person we decided to not use default_getter decorator > because that would change current behavior in an unexpected way. > > Original option --auto-forwarders was renamed to --default-forwarders because > it sounds nicer :-D Turns out I misunderstood the intent here and after another discussion in person we decided to go with the --auto-forwarders option. ACK on the original patch. Petr, could you please rebase patch 65 on top of current master? -- Jan Cholasta From ofayans at redhat.com Thu Nov 26 09:04:59 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 26 Nov 2015 10:04:59 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <56560124.4060904@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> <56560124.4060904@redhat.com> Message-ID: <5656CB3B.8010000@redhat.com> Hi Martin, I agree to all your points but one. please, see my comment below On 11/25/2015 07:42 PM, Martin Basti wrote: > Hi, > > 0) Note > Please be aware of https://fedorahosted.org/freeipa/ticket/5469 during > KRA testing > > 1) > Please do not use MIN and MAX_DOMAIN_LEVEL constants, this may change > over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain level 0 and 1 > > 2) > Why uninstall KRA then server, is not enough just uninstall server which > covers KRA uninstall? > > + def teardown_method(self, method): > + for host in self.replicas: > + host.run_command(self.kra_uninstall, raiseonerr=False) > + tasks.uninstall_master(host) > > > 3) > Can be this function more generic? It should allow specify host where > KRA should be installed not just master > > + def test_kra_install_master(self): > + self.master.run_command(self.kra_install) > > > 4) > > TestLevel0(Dummy): > Can be the test name more specific, something like > TestReplicaPromotionLevel0 > > > 5) > please remove this, the patch is on review and it will be pushed sooner > than tests > + @pytest.mark.xfail # Ticket N 5455 > > and as I mentioned in ticket #5455, I cannot reproduce it with > ipa-kra-install, so please provide steps to reproduce if you insist that > this still does not work as expected with KRA. > > 6) This is completely wrong, it removes everything that we tried to > achieve with previous patches with domain level in CI Actually, being able to configure domain level per class is WAY more convenient, than to always have to think which domain level is appropriate for which particular test during jenkins job configuration. In fact, I should have thought about it from the very beginning. For example, in test_replica_promotion.py we have on class, which intiates with domain level = 1, while others - with domain level 0. With config-based approach, we would have to implement a separate step that raises domain level. Overall, I am against the approach, when you have to remember to set certain domain level in config for any particular test. The tests themselves should be aware of the domain level they need. > > [PATCH] Enabled setting domain_level per class derived from TestIntegration > > When I configure domain level 0 in yaml config, how is this supposed to > get into install methods when you removed that code? > > - "--domain-level=%i" % host.config.domain_level > + "--domain-level=%i" % domain_level > > > You always use MAX_DOMAIN_LEVEL in this case or whatever is specified in > domain_level option. > I suggest to use domain_level=None, and when it is None use > 'host.config.domain_level', if it is not None, use 'domain_level' > > With this we can specify domain level in config file for test that can > be used for both domain levels and you can manually specify domain level > for test that requires specific domain level. > > Also this should go away > > @classmethod > def install(cls, mh): > + if hasattr(cls, "domain_level") and cls.master: > + cls.master.config.domain_level = cls.domain_level > if cls.topology is None: > return > > I do not see reason why test should override configuration in config in > this case. > > Martin > > On 25.11.2015 16:44, Oleg Fayans wrote: >> Hi, >> >> Here is the updated version of the patch (more tests + fixed the >> issues of the first one) + patch 0017, that implements the necessary >> changes in the background code, i. e. patch 16 does not work without >> patch 17 >> >> On 11/18/2015 05:20 PM, Martin Basti wrote: >>> >>> >>> On 09.11.2015 15:09, Oleg Fayans wrote: >>>> Hi guys, >>>> >>>> Here are first two automated testcases from this (so far incomplete) >>>> testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>>> >>>> Testplan review is highly appreciated >>>> >>>> >>>> >>>> >>> PATCH 16: NACK >>> >>> 1) >>> What is the reason to add an unused parameter to 'domain_level' to >>> install_topo()? >>> Also it is good practise to add new option as the last parameter. >>> >>> 2) >>> cab you in both tests specify a domain level with constant instead of >>> number literal? >>> >>> 3) >>> both test call install_topo with custom domain level, but it cannot work >>> because 1) (did you run the test?) >>> >>> 4) >>> How the test "TestLevel1" is supposed to work? >>> Respectively why there is call of install_topo() that installs replica. >>> As this test just tests that ipa-replica-prepare is not working anymore, >>> is it worth to spend 20 minutes with installing replica and then just no >>> tot use it? IMO to install master in install step is enough. >>> >>> Martin^2 >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Thu Nov 26 09:44:56 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 26 Nov 2015 10:44:56 +0100 Subject: [Freeipa-devel] [PATCH 0362] KRA: do not stop certmonger during standalone uninstall In-Reply-To: <5655C815.5090105@redhat.com> References: <5655C815.5090105@redhat.com> Message-ID: <5656D498.3080506@redhat.com> On 11/25/2015 03:39 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5477 > > Patch attached. > > easyACK. -- Martin^3 Babinsky From mbasti at redhat.com Thu Nov 26 09:50:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 Nov 2015 10:50:38 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <5656CB3B.8010000@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> <56560124.4060904@redhat.com> <5656CB3B.8010000@redhat.com> Message-ID: <5656D5EE.7010208@redhat.com> On 26.11.2015 10:04, Oleg Fayans wrote: > Hi Martin, > > I agree to all your points but one. please, see my comment below > > On 11/25/2015 07:42 PM, Martin Basti wrote: >> Hi, >> >> 0) Note >> Please be aware of https://fedorahosted.org/freeipa/ticket/5469 during >> KRA testing >> >> 1) >> Please do not use MIN and MAX_DOMAIN_LEVEL constants, this may change >> over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain level 0 >> and 1 >> >> 2) >> Why uninstall KRA then server, is not enough just uninstall server which >> covers KRA uninstall? >> >> + def teardown_method(self, method): >> + for host in self.replicas: >> + host.run_command(self.kra_uninstall, raiseonerr=False) >> + tasks.uninstall_master(host) >> >> >> 3) >> Can be this function more generic? It should allow specify host where >> KRA should be installed not just master >> >> + def test_kra_install_master(self): >> + self.master.run_command(self.kra_install) >> >> >> 4) >> >> TestLevel0(Dummy): >> Can be the test name more specific, something like >> TestReplicaPromotionLevel0 >> >> >> 5) >> please remove this, the patch is on review and it will be pushed sooner >> than tests >> + @pytest.mark.xfail # Ticket N 5455 >> >> and as I mentioned in ticket #5455, I cannot reproduce it with >> ipa-kra-install, so please provide steps to reproduce if you insist that >> this still does not work as expected with KRA. >> >> 6) This is completely wrong, it removes everything that we tried to >> achieve with previous patches with domain level in CI > > Actually, being able to configure domain level per class is WAY more > convenient, than to always have to think which domain level is > appropriate for which particular test during jenkins job > configuration. In fact, I should have thought about it from the very > beginning. For example, in test_replica_promotion.py we have on class, > which intiates with domain level = 1, while others - with domain level > 0. With config-based approach, we would have to implement a separate > step that raises domain level. Overall, I am against the approach, > when you have to remember to set certain domain level in config for > any particular test. The tests themselves should be aware of the > domain level they need. I do not say that we should not have something that overrides settings in from config in a particular test case, I say your patch is doing it wrong. I agree it is useful to have param domain_level in install_master, and intall_topo methods, but is cannot be MAX_DOMAIN_LEVEL by default, because with your current patch the domain_level in config is not used at all, it will be always MAX_DOMAIN_LEVEL For example I want to achieve this goal: test_vault.py, this test suite can run on domain level1 and on domain level0, so with one test we can test 2 domain levels just with putting domain level into config file. I agree that with extraordinary test like replica promotion test is, we need something that allows override the config file. As I said bellow, domain_level default value should be None in install_master and install_topo plugin. If domain level was specified use the specified one, if not (value is None) use the domain level from config file. Martin > >> >> [PATCH] Enabled setting domain_level per class derived from >> TestIntegration >> >> When I configure domain level 0 in yaml config, how is this supposed to >> get into install methods when you removed that code? >> >> - "--domain-level=%i" % host.config.domain_level >> + "--domain-level=%i" % domain_level >> >> >> You always use MAX_DOMAIN_LEVEL in this case or whatever is specified in >> domain_level option. >> I suggest to use domain_level=None, and when it is None use >> 'host.config.domain_level', if it is not None, use 'domain_level' >> >> With this we can specify domain level in config file for test that can >> be used for both domain levels and you can manually specify domain level >> for test that requires specific domain level. >> >> Also this should go away >> >> @classmethod >> def install(cls, mh): >> + if hasattr(cls, "domain_level") and cls.master: >> + cls.master.config.domain_level = cls.domain_level >> if cls.topology is None: >> return >> >> I do not see reason why test should override configuration in config in >> this case. >> >> Martin >> >> On 25.11.2015 16:44, Oleg Fayans wrote: >>> Hi, >>> >>> Here is the updated version of the patch (more tests + fixed the >>> issues of the first one) + patch 0017, that implements the necessary >>> changes in the background code, i. e. patch 16 does not work without >>> patch 17 >>> >>> On 11/18/2015 05:20 PM, Martin Basti wrote: >>>> >>>> >>>> On 09.11.2015 15:09, Oleg Fayans wrote: >>>>> Hi guys, >>>>> >>>>> Here are first two automated testcases from this (so far incomplete) >>>>> testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>>>> >>>>> Testplan review is highly appreciated >>>>> >>>>> >>>>> >>>>> >>>> PATCH 16: NACK >>>> >>>> 1) >>>> What is the reason to add an unused parameter to 'domain_level' to >>>> install_topo()? >>>> Also it is good practise to add new option as the last parameter. >>>> >>>> 2) >>>> cab you in both tests specify a domain level with constant instead of >>>> number literal? >>>> >>>> 3) >>>> both test call install_topo with custom domain level, but it cannot >>>> work >>>> because 1) (did you run the test?) >>>> >>>> 4) >>>> How the test "TestLevel1" is supposed to work? >>>> Respectively why there is call of install_topo() that installs >>>> replica. >>>> As this test just tests that ipa-replica-prepare is not working >>>> anymore, >>>> is it worth to spend 20 minutes with installing replica and then >>>> just no >>>> tot use it? IMO to install master in install step is enough. >>>> >>>> Martin^2 >>>> >>> >> > From mbabinsk at redhat.com Thu Nov 26 09:56:26 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 26 Nov 2015 10:56:26 +0100 Subject: [Freeipa-devel] [PATCH 0100] replica promotion: modify default.conf even if DS configuration fails In-Reply-To: <564EEC12.5090107@redhat.com> References: <564EE58E.6080605@redhat.com> <564EEC12.5090107@redhat.com> Message-ID: <5656D74A.9040108@redhat.com> On 11/20/2015 10:46 AM, Martin Babinsky wrote: > On 11/20/2015 10:19 AM, Martin Babinsky wrote: >> Fixes https://fedorahosted.org/freeipa/ticket/5417 >> > Sorry forgot to add the patch. > > > Attaching new version of patch rebased for current master and bumping for review. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0100.1-replica-promotion-modify-default.conf-even-if-DS-con.patch Type: text/x-patch Size: 3870 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Nov 26 10:01:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 26 Nov 2015 11:01:05 +0100 Subject: [Freeipa-devel] [PATCH 0105] fix a typo in replica DS creation code Message-ID: <5656D861.1020004@redhat.com> My OCD self cringes every time I see "retriving DS Certificate" so I here's a patch that fixes this. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0105-fix-a-typo-in-replica-DS-creation-code.patch Type: text/x-patch Size: 1013 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 26 10:05:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 Nov 2015 11:05:58 +0100 Subject: [Freeipa-devel] [PATCH 0105] fix a typo in replica DS creation code In-Reply-To: <5656D861.1020004@redhat.com> References: <5656D861.1020004@redhat.com> Message-ID: <5656D986.3070803@redhat.com> On 26.11.2015 11:01, Martin Babinsky wrote: > > My OCD self cringes every time I see "retriving DS Certificate" so I > here's a patch that fixes this. > > > A C K Pushed to master: b543c9a1374dabbbcfecec87c59f9995911f1cfd -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Nov 26 10:45:26 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Nov 2015 11:45:26 +0100 Subject: [Freeipa-devel] [pytest-multihost-devel][PATCH] Functions for handling various file and directory operations In-Reply-To: <5656A9E0.3090604@redhat.com> References: <56557AAB.5020100@redhat.com> <5655CC46.7020207@redhat.com> <5656A9E0.3090604@redhat.com> Message-ID: <5656E2C6.1090700@redhat.com> On 11/26/2015 07:42 AM, Abhijeet Kasurde wrote: > Hi Petr, > > On 11/25/2015 08:27 PM, Petr Viktorin wrote: >> On 11/25/2015 10:08 AM, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> Please find the patch for pytest-multihost-plugin. >>> >>> Fixes : https://fedorahosted.org/python-pytest-multihost/ticket/2 >> Thanks! These will be useful. >> >> ACK, pushed as e7bf95b3ba4ca84b73abffda1abcf6187c5c8a67 >> I wrote some tests for the file operations as well: >> 5e76908430bbb56ca981b04a88f12359c73c7e1f >> > Thanks for adding testcases for these functions. >> I plan to do a release (and update the Fedora package) after IPA starts >> testing under Python 3. Let me know if an earlier release would help you. > Yes, indeed. It will be very helpful. Let me know if you need any help > for my side. OK, the 0.9 release of python-pytest-multihost is now on PyPI and in Rawhide. For Fedora 23 you can provide karma here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-f8ecd33065 -- Petr Viktorin From jcholast at redhat.com Thu Nov 26 10:52:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Nov 2015 11:52:55 +0100 Subject: [Freeipa-devel] [PATCH] 0749 Package ipapython, ipalib, ipaplatform, ipatests for Python 3 In-Reply-To: <563C9810.1050604@redhat.com> References: <563C9810.1050604@redhat.com> Message-ID: <5656E487.8050703@redhat.com> Hi, On 6.11.2015 13:07, Petr Viktorin wrote: > Hello, > The Python 3 port is not 100% done, but I think the time has come to > start packaging the py3 bits. This will make it easier to plug into CI. > > The existing Python 2 packages should not change, except I've added > "freeipa-common" with files that aren't Python-specific. > > The new packages follow Fedora's Python guidelines a bit better. The > main thing is the names: python3-ipalib, python3-ipatests, > python3-ipap11helper. > The pure-Python ones are built as noarch. > > > The Makefiles are reorganized a bit, but they don't support building for > both py versions at once -- you need to do `make` followed by `make > PYTHON=/usr/bin/python3`. (The latter currently only works in the > directories that are ported so far, though.) Thanks for the patch. 1) The freeipa-common subpackage is not necessary: /etc/ipa/dnssec should be owned by freeipa-server and everything else in /etc/ipa currently owned by freeipa-python should be owned by freeipa-client. This should be a separate patch. I have prepared one, see attachment. 2) IMO this patch does too much, it should only add the Python 3 equivalent of freeipa-python - python3-ipalib - but none of the other packages/provides. 3) Speaking of freeipa-python, it should be renamed to python-ipalib, for consistency. This should also be a separate patch, again see attachment. 4) There should be a python3-devel (and also other python3- equivalents of python- packages) BuildRequires when Python 3 support is enabled. 5) This line in ipapython/ipap11helper/Makefile uses a Python 2 print statement: PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; print get_python_lib()") 6) The ipalib Makefile is missing the "check" target (see ipapython Makefile). Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-516-spec-file-remove-non-Python-files-from-freeipa-pytho.patch Type: text/x-patch Size: 3600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-517-spec-file-rename-freeipa-python-to-python-ipalib.patch Type: text/x-patch Size: 4710 bytes Desc: not available URL: From tbabej at redhat.com Thu Nov 26 11:22:15 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 26 Nov 2015 12:22:15 +0100 Subject: [Freeipa-devel] [PATCH 0384] ipa-client-automount: Leverage IPAChangeConf to configure the idmapd In-Reply-To: References: <56434F15.6070600@redhat.com> Message-ID: <5656EB67.4020900@redhat.com> On 11/25/2015 04:33 PM, Gabe Alford wrote: > Ack. > > Gabe > > On Wed, Nov 11, 2015 at 7:22 AM, Tomas Babej > wrote: > > Hi, > > Simple regexp substitution caused that the domain directive fell under > an inapprorpiate section, if the domain directive was not present. Hence > the idmapd.conf file was not properly parsed. > > Use IPAChangeConf to put the directive in its correct place even if it > the domain directive is missing. > > https://fedorahosted.org/freeipa/ticket/5069 > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > Pushed to master: 8403bd9d15a7817a15b85d8e108cad1c155aadbc From jcholast at redhat.com Thu Nov 26 12:33:44 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Nov 2015 13:33:44 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <56556AC2.1090302@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> <56547AB1.5030405@redhat.com> <56556AC2.1090302@redhat.com> Message-ID: <5656FC28.6000009@redhat.com> On 25.11.2015 09:01, Jan Cholasta wrote: > On 24.11.2015 15:56, Tomas Babej wrote: >> >> >> On 11/23/2015 04:43 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 23.11.2015 12:50, Tomas Babej wrote: >>>> Hi, >>>> >>>> this patch implements the single command replica promotion&enrollment >>>> for #5310. >>>> >>>> Tomas >>>> >>>> https://fedorahosted.org/freeipa/ticket/5310 >>> >>> 1) ensure_enrolled() should be called from promote_check() after the >>> client check is done: >>> >>> client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE) >>> if not client_fstore.has_files(): >>> ensure_enrolled(installer) > > Also it should no longer be decorated with @common_cleanup. > >>> >>> >>> 2) >>> >>> + server_name = Knob( >>> + str, None, >>> + description="fully qualified name of IPA server to enrooll to", >>> + cli_name='server', >>> + ) >>> >>> Please use the same identifier ipa-client-install uses, i.e. >>> s/server_name/server/. >>> >>> Also there is typo in the description: "enrooll". >> >> Fixed. > > You don't need to set cli_name anymore, as it's the same as the default. > >> >>> >>> >>> 3) >>> >>> + host_name = Knob( >>> + str, None, >>> + description="fully qualified name of this host", >>> + cli_name='hostname', >>> + ) >>> >>> This knob is already defined in BaseServer, there's no need to redefine >>> it here (just remove the "host_name = None"). >>> >>> If you want to change the description, change it in BaseServer. >> >> Yep, that was the reasoning here. Changed in BaseServer. >> >>> >>> >>> 4) >>> >>> + keytab = Knob( >>> + str, None, >>> + description="path to backed up keytab from previous >>> enrollment", >>> + cli_name='keytab', >>> + ) >>> >>> ipa-client-install uses the short name -k for the keytab option, it >>> should be used here as well. >>> >> >> Added. > > You don't need to set cli_name here as well. > >> >>> >>> 5) The replica file argument conflicts with the --realm, --domain, >>> --server, --admin-password and --principal options. This should be >>> checked in Replica.__init__(). >>> >>> The --hostname option should either be conflicting as well or be >>> implemented properly for legacy replica install. >>> >> >> All of them now conflict --replica-file. > > Replica file is not an option but rather an argument in > ipa-replica-install. > > I think the error message should use the same wording which is used for > --forwarder vs. --no-forwarder and --reverse-zone vs. --no-reverse: "You > cannot specify a --something option together with replica file". > >> >>> >>> 6) I think --admin-password should be renamed to --password and the >>> description changed, since it now also allows OTP enrollment. >>> >> >> I changed the requirements to mandate --principal when --password is >> used, as we discussed. > > I was wrong here, sorry. > > ipa-replica-install assumes "admin" for principal by default, so we just > need to make sure ipa-client-install is called with --principal when > password is used, whether it's the provided principal or the default > "admin". > >> >> The name of the option cannot really be changed, as it is already taken >> by the dm_password. > > Right. > One more thing I remembered: 7) When you try replica promotion on domain level 0, ipa-replica-install will install the client, then do the domain level check and fail, leaving the client installed. The check should be done as soon as possible, i.e. in ipa-client-install, so that nothing is installed in that case. This can be a separate patch though. -- Jan Cholasta From pspacek at redhat.com Thu Nov 26 13:17:51 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 26 Nov 2015 14:17:51 +0100 Subject: [Freeipa-devel] default / unexpressed / implicit values in LDAP and elsewhere Message-ID: <5657067F.5080404@redhat.com> Hello, The Problem =========== During work on DNSSEC patches for FreeIPA it repeatedly happened that I had to hard-code default values for optional LDAP attributes to various places. A constant in code is a nice thing, but it does not help to CLI/WebUI/API users because they do not see the default in ipa dnszone-show output etc. Moreover, even the constant does not help when multiple code-bases are using the default value, e.g. bind-dyndb-ldap (written in C) and FreeIPA framework (written in Python). What next? ========== I do not know :-) Following text is just boiling pure water. Simplest thing to do would be to create a Python module like ipa.defaults and create a dictionary with defaults for each object class. I can imagine something like: idnszone = { 'idnssecinlinesigning': False } Then in Python code it would be easy to do complete_object = ipa.defaults.idnszone.copy().update(object_from_LDAP) And now the complete_object contains everything including optional (but in fact not present) attributes which has a default value defined. We might want to have some metadata for each attribute for various reasons. E.g. some values should be only shown in WebUI and the attribute will be populated, e.g. uid attribute is generated from first and last name when user submits the form with empty 'uid' field. In other words, this default makes sense on object creation but on when reading existing objects from LDAP. The example with uid obviously calls for something more fancy. When one attribute is generated from other attributes of the same object, it might be sufficient to define a regex based on other attributes. Regex is easy to evaluate in C, Python and Javascript, if we limit ourselves to intersection of regex languages supported by libraries of our choice. Now, we can take this dictionary and generate #define strings from it ... The open question is how to handle defaults taken from another object, e.g. when idnsallowtransfer attribute is inherited from global DNS configuration entry. Any ideas? -- Petr^2 Spacek From tbabej at redhat.com Thu Nov 26 13:36:47 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 26 Nov 2015 14:36:47 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <5656FC28.6000009@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> <56547AB1.5030405@redhat.com> <56556AC2.1090302@redhat.com> <5656FC28.6000009@redhat.com> Message-ID: <56570AEF.7040607@redhat.com> On 11/26/2015 01:33 PM, Jan Cholasta wrote: > On 25.11.2015 09:01, Jan Cholasta wrote: >> On 24.11.2015 15:56, Tomas Babej wrote: >>> >>> >>> On 11/23/2015 04:43 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 23.11.2015 12:50, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> this patch implements the single command replica promotion&enrollment >>>>> for #5310. >>>>> >>>>> Tomas >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5310 >>>> >>>> 1) ensure_enrolled() should be called from promote_check() after the >>>> client check is done: >>>> >>>> client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE) >>>> if not client_fstore.has_files(): >>>> ensure_enrolled(installer) >> >> Also it should no longer be decorated with @common_cleanup. >> >>>> >>>> >>>> 2) >>>> >>>> + server_name = Knob( >>>> + str, None, >>>> + description="fully qualified name of IPA server to enrooll >>>> to", >>>> + cli_name='server', >>>> + ) >>>> >>>> Please use the same identifier ipa-client-install uses, i.e. >>>> s/server_name/server/. >>>> >>>> Also there is typo in the description: "enrooll". >>> >>> Fixed. >> >> You don't need to set cli_name anymore, as it's the same as the default. >> >>> >>>> >>>> >>>> 3) >>>> >>>> + host_name = Knob( >>>> + str, None, >>>> + description="fully qualified name of this host", >>>> + cli_name='hostname', >>>> + ) >>>> >>>> This knob is already defined in BaseServer, there's no need to redefine >>>> it here (just remove the "host_name = None"). >>>> >>>> If you want to change the description, change it in BaseServer. >>> >>> Yep, that was the reasoning here. Changed in BaseServer. >>> >>>> >>>> >>>> 4) >>>> >>>> + keytab = Knob( >>>> + str, None, >>>> + description="path to backed up keytab from previous >>>> enrollment", >>>> + cli_name='keytab', >>>> + ) >>>> >>>> ipa-client-install uses the short name -k for the keytab option, it >>>> should be used here as well. >>>> >>> >>> Added. >> >> You don't need to set cli_name here as well. >> >>> >>>> >>>> 5) The replica file argument conflicts with the --realm, --domain, >>>> --server, --admin-password and --principal options. This should be >>>> checked in Replica.__init__(). >>>> >>>> The --hostname option should either be conflicting as well or be >>>> implemented properly for legacy replica install. >>>> >>> >>> All of them now conflict --replica-file. >> >> Replica file is not an option but rather an argument in >> ipa-replica-install. >> >> I think the error message should use the same wording which is used for >> --forwarder vs. --no-forwarder and --reverse-zone vs. --no-reverse: "You >> cannot specify a --something option together with replica file". >> >>> >>>> >>>> 6) I think --admin-password should be renamed to --password and the >>>> description changed, since it now also allows OTP enrollment. >>>> >>> >>> I changed the requirements to mandate --principal when --password is >>> used, as we discussed. >> >> I was wrong here, sorry. >> >> ipa-replica-install assumes "admin" for principal by default, so we just >> need to make sure ipa-client-install is called with --principal when >> password is used, whether it's the provided principal or the default >> "admin". >> >>> >>> The name of the option cannot really be changed, as it is already taken >>> by the dm_password. >> >> Right. >> > > One more thing I remembered: > > 7) When you try replica promotion on domain level 0, ipa-replica-install > will install the client, then do the domain level check and fail, > leaving the client installed. The check should be done as soon as > possible, i.e. in ipa-client-install, so that nothing is installed in > that case. > > This can be a separate patch though. > Here's updated version of 385. I'll deal with (7) in a follow-up patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0385-4-replicainstall-Add-possiblity-to-install-client-in-o.patch Type: text/x-patch Size: 7461 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 26 13:39:52 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Nov 2015 14:39:52 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <56535233.1020207@redhat.com> References: <56535233.1020207@redhat.com> Message-ID: <56570BA8.6080002@redhat.com> On 11/23/2015 06:51 PM, Oleg Fayans wrote: > Hi all, > > Here is a draft of the Replica Promotion test plan > http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan > > == Test case: Unprivileged users are not allowed to enroll and promote clients == User credentials are passed there through -p $principal and -w $password options. It is correct atm because it is required for connection check. But end goal of replica promotion is the avoid it. See https://fedorahosted.org/freeipa/ticket/5497 and https://fedorahosted.org/freeipa/ticket/5498 for more information. == Missing test cases == 1. ipa-replica-install works on CA-less master with with both domain levels 2. ipa-server-install works with --setup-dns option with both domain levels 3. ipa-server-install works with externally signed CA cert with both domain levels 4. ipa-replica-install with options(and their combination): --setup-ca --setup-dns --setup-kra works with both domain levels Note: Not sure if #2 and #3 belongs here, but should be tested. Maybe tests for domain level 0 already exist. -- Petr Vobornik From jcholast at redhat.com Thu Nov 26 13:58:02 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Nov 2015 14:58:02 +0100 Subject: [Freeipa-devel] default / unexpressed / implicit values in LDAP and elsewhere In-Reply-To: <5657067F.5080404@redhat.com> References: <5657067F.5080404@redhat.com> Message-ID: <56570FEA.6070305@redhat.com> Hi, On 26.11.2015 14:17, Petr Spacek wrote: > Hello, > > The Problem > =========== > During work on DNSSEC patches for FreeIPA it repeatedly happened that I had to > hard-code default values for optional LDAP attributes to various places. > > A constant in code is a nice thing, but it does not help to CLI/WebUI/API > users because they do not see the default in ipa dnszone-show output etc. > > Moreover, even the constant does not help when multiple code-bases are using > the default value, e.g. bind-dyndb-ldap (written in C) and FreeIPA framework > (written in Python). > > What next? > ========== > I do not know :-) Following text is just boiling pure water. > > Simplest thing to do would be to create a Python module like > ipa.defaults and create a dictionary with defaults for each object class. > > I can imagine something like: > > idnszone = { > 'idnssecinlinesigning': False > } > > Then in Python code it would be easy to do > complete_object = ipa.defaults.idnszone.copy().update(object_from_LDAP) > And now the complete_object contains everything including optional (but in > fact not present) attributes which has a default value defined. This would be very alien in the framework. > > We might want to have some metadata for each attribute for various reasons. > E.g. some values should be only shown in WebUI and the attribute will be > populated, e.g. uid attribute is generated from first and last name when user > submits the form with empty 'uid' field. In other words, this default makes > sense on object creation but on when reading existing objects from LDAP. > > The example with uid obviously calls for something more fancy. When one > attribute is generated from other attributes of the same object, it might be > sufficient to define a regex based on other attributes. Regex is easy to > evaluate in C, Python and Javascript, if we limit ourselves to intersection of > regex languages supported by libraries of our choice. > > Now, we can take this dictionary and generate #define strings from it ... Dynamic defaults would have to be fetched from the server with an API call. This will likely be part of the thin client / API compatibility feature. > > > The open question is how to handle defaults taken from another object, e.g. > when idnsallowtransfer attribute is inherited from global DNS configuration entry. > > Any ideas? Is api.Object.dnszone.get_default() not sufficient? Honza -- Jan Cholasta From mbasti at redhat.com Thu Nov 26 14:00:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 Nov 2015 15:00:55 +0100 Subject: [Freeipa-devel] [PATCH 0355-0356] Prevent using replica file with ipa-ca-install and domain In-Reply-To: <565486BA.7050104@redhat.com> References: <56542C37.9000603@redhat.com> <565486BA.7050104@redhat.com> Message-ID: <56571097.9050102@redhat.com> On 24.11.2015 16:48, Jan Cholasta wrote: > On 24.11.2015 10:21, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5455 >> >> Patches attached. > > + def run(self): > + self._run() > > Wouldn't it be better to rename _run() to run() instead? > Updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0355.2-ipa-ca-install-error-when-replica-file-is-passed-wit.patch Type: text/x-patch Size: 1125 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0356.2-KRA-install-show-installation-message-only-if-instal.patch Type: text/x-patch Size: 1951 bytes Desc: not available URL: From dkupka at redhat.com Thu Nov 26 14:01:12 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 26 Nov 2015 15:01:12 +0100 Subject: [Freeipa-devel] [PATCH 0069] ipa-replica-install support caless install with promotion. Message-ID: <565710A8.1020306@redhat.com> https://fedorahosted.org/freeipa/ticket/5441 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0069-ipa-replica-install-support-caless-install-with-prom.patch Type: text/x-patch Size: 14307 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 26 14:07:37 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Nov 2015 15:07:37 +0100 Subject: [Freeipa-devel] [PATCH 0100] replica promotion: modify default.conf even if DS configuration fails In-Reply-To: <5656D74A.9040108@redhat.com> References: <564EE58E.6080605@redhat.com> <564EEC12.5090107@redhat.com> <5656D74A.9040108@redhat.com> Message-ID: <56571229.4000004@redhat.com> On 11/26/2015 10:56 AM, Martin Babinsky wrote: > On 11/20/2015 10:46 AM, Martin Babinsky wrote: >> On 11/20/2015 10:19 AM, Martin Babinsky wrote: >>> Fixes https://fedorahosted.org/freeipa/ticket/5417 >>> >> Sorry forgot to add the patch. >> >> >> > Attaching new version of patch rebased for current master and bumping > for review. > ACK -- Petr Vobornik From pspacek at redhat.com Thu Nov 26 14:12:37 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 26 Nov 2015 15:12:37 +0100 Subject: [Freeipa-devel] default / unexpressed / implicit values in LDAP and elsewhere In-Reply-To: <56570FEA.6070305@redhat.com> References: <5657067F.5080404@redhat.com> <56570FEA.6070305@redhat.com> Message-ID: <56571355.2010506@redhat.com> On 26.11.2015 14:58, Jan Cholasta wrote: > Hi, > > On 26.11.2015 14:17, Petr Spacek wrote: >> Hello, >> >> The Problem >> =========== >> During work on DNSSEC patches for FreeIPA it repeatedly happened that I had to >> hard-code default values for optional LDAP attributes to various places. >> >> A constant in code is a nice thing, but it does not help to CLI/WebUI/API >> users because they do not see the default in ipa dnszone-show output etc. >> >> Moreover, even the constant does not help when multiple code-bases are using >> the default value, e.g. bind-dyndb-ldap (written in C) and FreeIPA framework >> (written in Python). >> >> What next? >> ========== >> I do not know :-) Following text is just boiling pure water. >> >> Simplest thing to do would be to create a Python module like >> ipa.defaults and create a dictionary with defaults for each object class. >> >> I can imagine something like: >> >> idnszone = { >> 'idnssecinlinesigning': False >> } >> >> Then in Python code it would be easy to do >> complete_object = ipa.defaults.idnszone.copy().update(object_from_LDAP) >> And now the complete_object contains everything including optional (but in >> fact not present) attributes which has a default value defined. > > This would be very alien in the framework. > >> >> We might want to have some metadata for each attribute for various reasons. >> E.g. some values should be only shown in WebUI and the attribute will be >> populated, e.g. uid attribute is generated from first and last name when user >> submits the form with empty 'uid' field. In other words, this default makes >> sense on object creation but on when reading existing objects from LDAP. >> >> The example with uid obviously calls for something more fancy. When one >> attribute is generated from other attributes of the same object, it might be >> sufficient to define a regex based on other attributes. Regex is easy to >> evaluate in C, Python and Javascript, if we limit ourselves to intersection of >> regex languages supported by libraries of our choice. >> >> Now, we can take this dictionary and generate #define strings from it ... > > Dynamic defaults would have to be fetched from the server with an API call. > This will likely be part of the thin client / API compatibility feature. > >> >> >> The open question is how to handle defaults taken from another object, e.g. >> when idnsallowtransfer attribute is inherited from global DNS configuration >> entry. >> >> Any ideas? > > Is api.Object.dnszone.get_default() not sufficient? Good! I wanted something like this :-) We can dig into it later. -- Petr^2 Spacek From dkupka at redhat.com Thu Nov 26 14:13:10 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 26 Nov 2015 15:13:10 +0100 Subject: [Freeipa-devel] [PATCH 0069] ipa-replica-install support caless install with promotion. In-Reply-To: <565710A8.1020306@redhat.com> References: <565710A8.1020306@redhat.com> Message-ID: <56571376.6020209@redhat.com> On 26/11/15 15:01, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/5441 > > Replaced accidentally inserted tabs. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0069.1-ipa-replica-install-support-caless-install-with-prom.patch Type: text/x-patch Size: 14382 bytes Desc: not available URL: From mbasti at redhat.com Thu Nov 26 14:21:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 26 Nov 2015 15:21:44 +0100 Subject: [Freeipa-devel] [PATCH 0015] mod_auth_gssapi: Remove ntlmssp support and restrict, mechanism to krb5 In-Reply-To: References: <55AF9B8B.4030509@redhat.com> <1874088905.2398755.1437572990514.JavaMail.zimbra@redhat.com> Message-ID: <56571578.6060306@redhat.com> On 25.11.2015 16:36, Gabe Alford wrote: > Bump for push. May need a rebase. Thank you, rebased. Pushed to master: b6c893aae63b6b77871c775d062a5c7e1c470ad9 > > On Wed, Jul 22, 2015 at 7:49 AM, Simo Sorce > wrote: > > ----- Original Message ----- > > From: "Christian Heimes" > > > To: "freeipa-devel" > > > Sent: Wednesday, July 22, 2015 9:32:59 AM > > Subject: [Freeipa-devel] [PATCH 0015] mod_auth_gssapi: Remove > ntlmssp support and restrict, mechanism to krb5 > > > > By default mod_auth_gssapi allows all locally available > mechanisms. If > > the gssntlmssp package is installed, it also offers ntlmssp. > This has > > the annoying side effect that some browser will pop up a > > username/password request dialog if no Krb5 credentials are > available. > > > > The patch restricts the mechanism to krb5 and removes ntlmssp and > > iakerb support from Apache's ipa.conf. > > > > The new feature was added to mod_auth_gssapi 1.3.0. > > > > https://fedorahosted.org/freeipa/ticket/5114 > > LGTM > > Simo. > > -- > Simo Sorce * Red Hat, Inc. * New York > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Thu Nov 26 14:22:51 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 26 Nov 2015 15:22:51 +0100 Subject: [Freeipa-devel] [PATCH 0069] ipa-replica-install support caless install with promotion. In-Reply-To: <56571376.6020209@redhat.com> References: <565710A8.1020306@redhat.com> <56571376.6020209@redhat.com> Message-ID: <565715BB.9020200@redhat.com> On 26/11/15 15:13, David Kupka wrote: > On 26/11/15 15:01, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/5441 >> >> > Replaced accidentally inserted tabs. > > > Fixed indentation I screwed up when replacing tabs :-/ -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0069.2-ipa-replica-install-support-caless-install-with-prom.patch Type: text/x-patch Size: 14276 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 26 16:15:14 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Nov 2015 17:15:14 +0100 Subject: [Freeipa-devel] rename topology suffixes Message-ID: <56573012.2040803@redhat.com> New topology management gives names to managed suffixes: ipaca: o=ipaca realm: dc=example,dc=com We already had several offline discussions to change the names because they could be better. It would be difficult to change them after release of 4.3. New proposals: ca for o=ipaca domain for dc=example,dc=com What do you think? -- Petr Vobornik From jcholast at redhat.com Fri Nov 27 06:05:50 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Nov 2015 07:05:50 +0100 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <56573012.2040803@redhat.com> References: <56573012.2040803@redhat.com> Message-ID: <5657F2BE.4020304@redhat.com> On 26.11.2015 17:15, Petr Vobornik wrote: > New topology management gives names to managed suffixes: > > ipaca: o=ipaca > realm: dc=example,dc=com > > We already had several offline discussions to change the names because > they could be better. It would be difficult to change them after release > of 4.3. > > New proposals: > ca for o=ipaca > domain for dc=example,dc=com > > What do you think? +1 -- Jan Cholasta From dkupka at redhat.com Fri Nov 27 06:57:06 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 27 Nov 2015 07:57:06 +0100 Subject: [Freeipa-devel] [PATCH 0069] ipa-replica-install support caless install with promotion. In-Reply-To: <565715BB.9020200@redhat.com> References: <565710A8.1020306@redhat.com> <56571376.6020209@redhat.com> <565715BB.9020200@redhat.com> Message-ID: <5657FEC2.3080503@redhat.com> On 26/11/15 15:22, David Kupka wrote: > On 26/11/15 15:13, David Kupka wrote: >> On 26/11/15 15:01, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/5441 >>> >>> >> Replaced accidentally inserted tabs. >> >> >> > Fixed indentation I screwed up when replacing tabs :-/ > > > Hello everyone! I did not realize that not many people know how to verify this. You need (at least) 2 servers, master and replica and certificates for them. Easiest way to get the certificates is to use Honza's almighty script (attached). Before you run it, edit variables on first few lines to match your environment. When it is run it creates directory (nssdb in your `pwd` by default) populated by various certificate. Both certificates used (replica.p12 and server.p12) must be signed by the same CA (located in the same ca* subdirectory). To install CA-less IPA server on master: [master] # ipa-server-install -r EXAMPLE.TEST --http-cert-file /path/to//server.p12 --http-pin password --dirsrv-cert-file /path/to/server.p12 --dirsrv-pin password Since domain-level is set to 1 ipa-client must be installed first on future replica. [replica] # ipa-client-install Note: In case client can't auto-discover IPA server you need to provide --domain and --server options. After successful installation of ipa-client you can promote it to master: [replica] # ipa-replica-install --http-cert-file /path/to/replica.p12 --http-pin password --dirsrv-cert-file /path/to/replica.p12 --dirsrv-pin password -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: makepki.sh Type: application/x-shellscript Size: 4886 bytes Desc: not available URL: From mkosek at redhat.com Fri Nov 27 07:33:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Nov 2015 08:33:18 +0100 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <5657F2BE.4020304@redhat.com> References: <56573012.2040803@redhat.com> <5657F2BE.4020304@redhat.com> Message-ID: <5658073E.3060402@redhat.com> On 11/27/2015 07:05 AM, Jan Cholasta wrote: > On 26.11.2015 17:15, Petr Vobornik wrote: >> New topology management gives names to managed suffixes: >> >> ipaca: o=ipaca >> realm: dc=example,dc=com >> >> We already had several offline discussions to change the names because >> they could be better. It would be difficult to change them after release >> of 4.3. >> >> New proposals: >> ca for o=ipaca >> domain for dc=example,dc=com >> >> What do you think? > > +1 ca is probably fine. Domain also, although the original realm name is OK with me too, domain has too many meanings and can be confused with DNS domain. From jcholast at redhat.com Fri Nov 27 08:00:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Nov 2015 09:00:55 +0100 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <5658073E.3060402@redhat.com> References: <56573012.2040803@redhat.com> <5657F2BE.4020304@redhat.com> <5658073E.3060402@redhat.com> Message-ID: <56580DB7.7010604@redhat.com> On 27.11.2015 08:33, Martin Kosek wrote: > On 11/27/2015 07:05 AM, Jan Cholasta wrote: >> On 26.11.2015 17:15, Petr Vobornik wrote: >>> New topology management gives names to managed suffixes: >>> >>> ipaca: o=ipaca >>> realm: dc=example,dc=com >>> >>> We already had several offline discussions to change the names because >>> they could be better. It would be difficult to change them after release >>> of 4.3. >>> >>> New proposals: >>> ca for o=ipaca >>> domain for dc=example,dc=com >>> >>> What do you think? >> >> +1 > > ca is probably fine. Domain also, although the original realm name is OK > with me too, domain has too many meanings and can be confused with DNS > domain. Realm is too Kerberos-specific. The names are visible only in topology context, so I don't think it would be confusing. When you say "the domain suffix", it describes the suffix pretty correctly IMHO. -- Jan Cholasta From mbasti at redhat.com Fri Nov 27 09:32:39 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 10:32:39 +0100 Subject: [Freeipa-devel] [PATCH 0100] replica promotion: modify default.conf even if DS configuration fails In-Reply-To: <56571229.4000004@redhat.com> References: <564EE58E.6080605@redhat.com> <564EEC12.5090107@redhat.com> <5656D74A.9040108@redhat.com> <56571229.4000004@redhat.com> Message-ID: <56582337.1090303@redhat.com> On 26.11.2015 15:07, Petr Vobornik wrote: > On 11/26/2015 10:56 AM, Martin Babinsky wrote: >> On 11/20/2015 10:46 AM, Martin Babinsky wrote: >>> On 11/20/2015 10:19 AM, Martin Babinsky wrote: >>>> Fixes https://fedorahosted.org/freeipa/ticket/5417 >>>> >>> Sorry forgot to add the patch. >>> >>> >>> >> Attaching new version of patch rebased for current master and bumping >> for review. >> > > ACK Works for me too Pushed to master: 7978c214731edfa4e05d64ffd2079d327e7b34d4 From pspacek at redhat.com Fri Nov 27 11:46:29 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Nov 2015 12:46:29 +0100 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <56580DB7.7010604@redhat.com> References: <56573012.2040803@redhat.com> <5657F2BE.4020304@redhat.com> <5658073E.3060402@redhat.com> <56580DB7.7010604@redhat.com> Message-ID: <56584295.4030700@redhat.com> On 27.11.2015 09:00, Jan Cholasta wrote: > On 27.11.2015 08:33, Martin Kosek wrote: >> On 11/27/2015 07:05 AM, Jan Cholasta wrote: >>> On 26.11.2015 17:15, Petr Vobornik wrote: >>>> New topology management gives names to managed suffixes: >>>> >>>> ipaca: o=ipaca >>>> realm: dc=example,dc=com >>>> >>>> We already had several offline discussions to change the names because >>>> they could be better. It would be difficult to change them after release >>>> of 4.3. >>>> >>>> New proposals: >>>> ca for o=ipaca >>>> domain for dc=example,dc=com >>>> >>>> What do you think? >>> >>> +1 >> >> ca is probably fine. Domain also, although the original realm name is OK >> with me too, domain has too many meanings and can be confused with DNS >> domain. > > Realm is too Kerberos-specific. The names are visible only in topology > context, so I don't think it would be confusing. When you say "the domain > suffix", it describes the suffix pretty correctly IMHO. Here I agree with Martin that domain is too overloaded term, so I would prefer realm or so. Also, I do not think that 'Realm is too Kerberos-specific' is a valid argument because 'domain is too DNS-centric' :-) -- Petr^2 Spacek From pvoborni at redhat.com Fri Nov 27 12:10:38 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Nov 2015 13:10:38 +0100 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <56584295.4030700@redhat.com> References: <56573012.2040803@redhat.com> <5657F2BE.4020304@redhat.com> <5658073E.3060402@redhat.com> <56580DB7.7010604@redhat.com> <56584295.4030700@redhat.com> Message-ID: <5658483E.1040405@redhat.com> On 11/27/2015 12:46 PM, Petr Spacek wrote: > On 27.11.2015 09:00, Jan Cholasta wrote: >> On 27.11.2015 08:33, Martin Kosek wrote: >>> On 11/27/2015 07:05 AM, Jan Cholasta wrote: >>>> On 26.11.2015 17:15, Petr Vobornik wrote: >>>>> New topology management gives names to managed suffixes: >>>>> >>>>> ipaca: o=ipaca >>>>> realm: dc=example,dc=com >>>>> >>>>> We already had several offline discussions to change the names because >>>>> they could be better. It would be difficult to change them after release >>>>> of 4.3. >>>>> >>>>> New proposals: >>>>> ca for o=ipaca >>>>> domain for dc=example,dc=com >>>>> >>>>> What do you think? >>>> >>>> +1 >>> >>> ca is probably fine. Domain also, although the original realm name is OK >>> with me too, domain has too many meanings and can be confused with DNS >>> domain. >> >> Realm is too Kerberos-specific. The names are visible only in topology >> context, so I don't think it would be confusing. When you say "the domain >> suffix", it describes the suffix pretty correctly IMHO. > > Here I agree with Martin that domain is too overloaded term, so I would prefer > realm or so. > > Also, I do not think that 'Realm is too Kerberos-specific' is a valid argument > because 'domain is too DNS-centric' :-) > I guess we could find arguments for both 'domain' and 'realm'. :) I don't have strong opinions on any. Actually, DN of the suffix consist of several 'DC' RDNs. DC is an initialism of "domain component". Several components create a domain so domain is correct ;) -- Petr Vobornik From jcholast at redhat.com Fri Nov 27 12:39:26 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Nov 2015 13:39:26 +0100 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <5658483E.1040405@redhat.com> References: <56573012.2040803@redhat.com> <5657F2BE.4020304@redhat.com> <5658073E.3060402@redhat.com> <56580DB7.7010604@redhat.com> <56584295.4030700@redhat.com> <5658483E.1040405@redhat.com> Message-ID: <56584EFE.2070508@redhat.com> On 27.11.2015 13:10, Petr Vobornik wrote: > On 11/27/2015 12:46 PM, Petr Spacek wrote: >> On 27.11.2015 09:00, Jan Cholasta wrote: >>> On 27.11.2015 08:33, Martin Kosek wrote: >>>> On 11/27/2015 07:05 AM, Jan Cholasta wrote: >>>>> On 26.11.2015 17:15, Petr Vobornik wrote: >>>>>> New topology management gives names to managed suffixes: >>>>>> >>>>>> ipaca: o=ipaca >>>>>> realm: dc=example,dc=com >>>>>> >>>>>> We already had several offline discussions to change the names >>>>>> because >>>>>> they could be better. It would be difficult to change them after >>>>>> release >>>>>> of 4.3. >>>>>> >>>>>> New proposals: >>>>>> ca for o=ipaca >>>>>> domain for dc=example,dc=com >>>>>> >>>>>> What do you think? >>>>> >>>>> +1 >>>> >>>> ca is probably fine. Domain also, although the original realm name >>>> is OK >>>> with me too, domain has too many meanings and can be confused with DNS >>>> domain. >>> >>> Realm is too Kerberos-specific. The names are visible only in topology >>> context, so I don't think it would be confusing. When you say "the >>> domain >>> suffix", it describes the suffix pretty correctly IMHO. >> >> Here I agree with Martin that domain is too overloaded term, so I >> would prefer >> realm or so. >> >> Also, I do not think that 'Realm is too Kerberos-specific' is a valid >> argument >> because 'domain is too DNS-centric' :-) >> > > I guess we could find arguments for both 'domain' and 'realm'. :) I > don't have strong opinions on any. > > Actually, DN of the suffix consist of several 'DC' RDNs. DC is an > initialism of "domain component". Several components create a domain so > domain is correct ;) "Domain" is also used by AD and in our documentation IIRC. -- Jan Cholasta From pviktori at redhat.com Fri Nov 27 12:46:05 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 27 Nov 2015 13:46:05 +0100 Subject: [Freeipa-devel] [PATCH] 0749 Package ipapython, ipalib, ipaplatform, ipatests for Python 3 In-Reply-To: <5656E487.8050703@redhat.com> References: <563C9810.1050604@redhat.com> <5656E487.8050703@redhat.com> Message-ID: <5658508D.1020105@redhat.com> On 11/26/2015 11:52 AM, Jan Cholasta wrote: > Hi, > > On 6.11.2015 13:07, Petr Viktorin wrote: >> Hello, >> The Python 3 port is not 100% done, but I think the time has come to >> start packaging the py3 bits. This will make it easier to plug into CI. >> >> The existing Python 2 packages should not change, except I've added >> "freeipa-common" with files that aren't Python-specific. >> >> The new packages follow Fedora's Python guidelines a bit better. The >> main thing is the names: python3-ipalib, python3-ipatests, >> python3-ipap11helper. >> The pure-Python ones are built as noarch. >> >> >> The Makefiles are reorganized a bit, but they don't support building for >> both py versions at once -- you need to do `make` followed by `make >> PYTHON=/usr/bin/python3`. (The latter currently only works in the >> directories that are ported so far, though.) > > Thanks for the patch. > > > 1) The freeipa-common subpackage is not necessary: /etc/ipa/dnssec > should be owned by freeipa-server and everything else in /etc/ipa > currently owned by freeipa-python should be owned by freeipa-client. If the common files are in freeipa-server or freeipa-client, then the Python 3 packages would need to depend on those. I'd like to avoid that. > This should be a separate patch. I have prepared one, see attachment. > > > 2) IMO this patch does too much, it should only add the Python 3 > equivalent of freeipa-python - python3-ipalib - but none of the other > packages/provides. My reasoning for the new packages: - python3-ipalib is the main point - freeipa-common contains files that both the py2 and py3 versions need - python-ipap11helper has compiled code: with this pulled out, python3-ipalib can be noarch - python3-ipatests is needed if we want to start testing the py3 packages in CI As for new provides, Fedora's Python packaging guidelines say: """ Using a fictional module named "example", the subpackage containing the python2 version must provide python2-example. This is of course always the case if the subpackage is named python2-example [...] If the subpackage has some other name then then Provides: python2-example must be added explicitly (but see the %python_provide macro below). The python3 subpackage must provide python3-example. However, as the naming guidelines mandate that the python3 subpackage be named python3-example, this will happen automatically. """ so I'm now adding Provides for the top-level modules. > 3) Speaking of freeipa-python, it should be renamed to python-ipalib, > for consistency. > > This should also be a separate patch, again see attachment. I think that would just be unnecessary churn. Python 3 gives us a chance for a fresh start, so I'm taking advantage of that, but renaming existing packages is a pain. With the right Provides, "dnf install python-ipalib" (or python2-ipalib) will do the right thing, and I thing that's enough. > 4) There should be a python3-devel (and also other python3- equivalents > of python- packages) BuildRequires when Python 3 support is enabled. I did miss that somehow. Thanks for checking. I added python3-devel; the others are unnecessary because pylint is not currently run on the Python3 version. > 5) This line in ipapython/ipap11helper/Makefile uses a Python 2 print > statement: > > PYTHONLIBDIR ?= $(shell $(PYTHON) -c "from distutils.sysconfig import *; > print get_python_lib()") Thanks, fixed > 6) The ipalib Makefile is missing the "check" target (see ipapython > Makefile). Also fixed. -- Petr Viktorin From mbabinsk at redhat.com Fri Nov 27 12:52:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 Nov 2015 13:52:58 +0100 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <56584EFE.2070508@redhat.com> References: <56573012.2040803@redhat.com> <5657F2BE.4020304@redhat.com> <5658073E.3060402@redhat.com> <56580DB7.7010604@redhat.com> <56584295.4030700@redhat.com> <5658483E.1040405@redhat.com> <56584EFE.2070508@redhat.com> Message-ID: <5658522A.4070506@redhat.com> On 11/27/2015 01:39 PM, Jan Cholasta wrote: > On 27.11.2015 13:10, Petr Vobornik wrote: >> On 11/27/2015 12:46 PM, Petr Spacek wrote: >>> On 27.11.2015 09:00, Jan Cholasta wrote: >>>> On 27.11.2015 08:33, Martin Kosek wrote: >>>>> On 11/27/2015 07:05 AM, Jan Cholasta wrote: >>>>>> On 26.11.2015 17:15, Petr Vobornik wrote: >>>>>>> New topology management gives names to managed suffixes: >>>>>>> >>>>>>> ipaca: o=ipaca >>>>>>> realm: dc=example,dc=com >>>>>>> >>>>>>> We already had several offline discussions to change the names >>>>>>> because >>>>>>> they could be better. It would be difficult to change them after >>>>>>> release >>>>>>> of 4.3. >>>>>>> >>>>>>> New proposals: >>>>>>> ca for o=ipaca >>>>>>> domain for dc=example,dc=com >>>>>>> >>>>>>> What do you think? >>>>>> >>>>>> +1 >>>>> >>>>> ca is probably fine. Domain also, although the original realm name >>>>> is OK >>>>> with me too, domain has too many meanings and can be confused with DNS >>>>> domain. >>>> >>>> Realm is too Kerberos-specific. The names are visible only in topology >>>> context, so I don't think it would be confusing. When you say "the >>>> domain >>>> suffix", it describes the suffix pretty correctly IMHO. >>> >>> Here I agree with Martin that domain is too overloaded term, so I >>> would prefer >>> realm or so. >>> >>> Also, I do not think that 'Realm is too Kerberos-specific' is a valid >>> argument >>> because 'domain is too DNS-centric' :-) >>> >> >> I guess we could find arguments for both 'domain' and 'realm'. :) I >> don't have strong opinions on any. >> >> Actually, DN of the suffix consist of several 'DC' RDNs. DC is an >> initialism of "domain component". Several components create a domain so >> domain is correct ;) > > "Domain" is also used by AD and in our documentation IIRC. > We also have "domain levels" and not "realm levels" and IPA domain level has very little to do with DNS. -- Martin^3 Babinsky From mbasti at redhat.com Fri Nov 27 13:05:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 14:05:29 +0100 Subject: [Freeipa-devel] [PATCH 0355-0356, 0363] Prevent using replica file with ipa-ca-install and domain In-Reply-To: <56571097.9050102@redhat.com> References: <56542C37.9000603@redhat.com> <565486BA.7050104@redhat.com> <56571097.9050102@redhat.com> Message-ID: <56585519.5070806@redhat.com> On 26.11.2015 15:00, Martin Basti wrote: > > > On 24.11.2015 16:48, Jan Cholasta wrote: >> On 24.11.2015 10:21, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5455 >>> >>> Patches attached. >> >> + def run(self): >> + self._run() >> >> Wouldn't it be better to rename _run() to run() instead? >> > Updated patches attached. > > Updated patches attached, thanks to Oleg I was able to reproduce KRA issue too (patch 363) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0355.3-ipa-ca-install-error-when-replica-file-is-passed-wit.patch Type: text/x-patch Size: 1181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0356.3-KRA-install-show-installation-message-only-if-instal.patch Type: text/x-patch Size: 1951 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0363.3-ipa-kra-install-error-when-replica-file-is-passed-wi.patch Type: text/x-patch Size: 1447 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 27 13:50:28 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 Nov 2015 14:50:28 +0100 Subject: [Freeipa-devel] [PATCH] 927 topology: treat server suffix as multivalued attribute in API In-Reply-To: <564F34A5.60208@redhat.com> References: <564F34A5.60208@redhat.com> Message-ID: <56585FA4.3020205@redhat.com> On 11/20/2015 03:56 PM, Petr Vobornik wrote: > > > ACK -- Martin^3 Babinsky From pvoborni at redhat.com Fri Nov 27 13:51:29 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Nov 2015 14:51:29 +0100 Subject: [Freeipa-devel] [PATCH] 924 use starttls in CSReplicationManager connection again In-Reply-To: <562A4AED.8090801@redhat.com> References: <562A2A96.1080101@redhat.com> <562A4AED.8090801@redhat.com> Message-ID: <56585FE1.6020505@redhat.com> On 10/23/2015 04:57 PM, Simo Sorce wrote: > On 23/10/15 08:39, Petr Vobornik wrote: >> not sure if the change in2606f5aecd6ac0db31abb515b691529bb7eaf14e was a >> mistake or done on purpose. >> >> Anyway: >> commit 2606f5aecd6ac0db31abb515b691529bb7eaf14e >> >> has: >> - realm, hostname, dirman_passwd, port, starttls=True) >> + realm, hostname, dirman_passwd, port) >> >> In CSReplicationManager >> >> which causes, e.g.: >> >> ipa-csreplica-manage -p Secret123 list ipa.example.com >> cannot connect to 'ldaps://ipa.example.com:389': TLS error >> -5938:Encountered end of file >> >> Attached patch reverts it. > > I am not sure it was a mistake, we have changed replication from using > TLS to always use LDAP+GSSAPI, so why is ipa-csreplica-manage depending > on ldaps anyway ? > > It may need to when dealing with very old domains where we have split > instances for CS and IPA, but not in anything modern. I would rather > change the command to cope with using LDAP+GSSAPI. > > A simple revert may break something in replica promotion, would need to > be tested with a full master+replica install. I had this patch applied in branch while developing Topology graph - promotion of several replicas worked. Replica promotion uses new CAReplicationManager - not CSReplicationManager so it shouldn't be affected. CSReplicationManager is used only in get_cs_replication_manager call. This call is used only in ipa-csreplica-manage and ipa_restore.py. Without this patch the related functionality in both ipa-csreplica-manage and ipa_restore.py (see https://fedorahosted.org/freeipa/ticket/5479#comment:2 ) doesn't work. I don't think that changing ipa-csreplica-manage is worth the effort given that we want to deprecate the tool. Therefore I propose to go with this patch. -- Petr Vobornik From mbabinsk at redhat.com Fri Nov 27 13:58:31 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 Nov 2015 14:58:31 +0100 Subject: [Freeipa-devel] [PATCH 0098-0099] domain level 1 topology checks during IPA server uninstall In-Reply-To: <564E04BE.1020304@redhat.com> References: <564E04BE.1020304@redhat.com> Message-ID: <56586187.5090402@redhat.com> On 11/19/2015 06:19 PM, Martin Babinsky wrote: > These two patches fix the following tickets: > > https://fedorahosted.org/freeipa/ticket/5377 > https://fedorahosted.org/freeipa/ticket/5409 > > I have added a new option '--ignore-disconnected-topology' which forces > IPA master uninstall despite reported errors in topology. I'm not quite > sure if we want to flood ipa-server-install with uninstall-specific > options, maybe it is better to skip the check in unattended mode and > just print a warning about disconnected topology and what to do about it. > > I would like to hear your opinions about this. > > > Attaching rebased and updated patches. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0099.1-implement-domain-level-1-specific-topology-checks-in.patch Type: text/x-patch Size: 11219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0098.1-extract-domain-level-1-topology-checking-code-from-i.patch Type: text/x-patch Size: 10435 bytes Desc: not available URL: From ofayans at redhat.com Fri Nov 27 14:04:22 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 27 Nov 2015 15:04:22 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <5656D5EE.7010208@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> <56560124.4060904@redhat.com> <5656CB3B.8010000@redhat.com> <5656D5EE.7010208@redhat.com> Message-ID: <565862E6.4020100@redhat.com> Hi Martin, All your suggestions were taken into account. Both patches are updated. Thank you for your help! On 11/26/2015 10:50 AM, Martin Basti wrote: > > > On 26.11.2015 10:04, Oleg Fayans wrote: >> Hi Martin, >> >> I agree to all your points but one. please, see my comment below >> >> On 11/25/2015 07:42 PM, Martin Basti wrote: >>> Hi, >>> >>> 0) Note >>> Please be aware of https://fedorahosted.org/freeipa/ticket/5469 during >>> KRA testing >>> >>> 1) >>> Please do not use MIN and MAX_DOMAIN_LEVEL constants, this may change >>> over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain level 0 >>> and 1 >>> >>> 2) >>> Why uninstall KRA then server, is not enough just uninstall server which >>> covers KRA uninstall? >>> >>> + def teardown_method(self, method): >>> + for host in self.replicas: >>> + host.run_command(self.kra_uninstall, raiseonerr=False) >>> + tasks.uninstall_master(host) >>> >>> >>> 3) >>> Can be this function more generic? It should allow specify host where >>> KRA should be installed not just master >>> >>> + def test_kra_install_master(self): >>> + self.master.run_command(self.kra_install) >>> >>> >>> 4) >>> >>> TestLevel0(Dummy): >>> Can be the test name more specific, something like >>> TestReplicaPromotionLevel0 >>> >>> >>> 5) >>> please remove this, the patch is on review and it will be pushed sooner >>> than tests >>> + @pytest.mark.xfail # Ticket N 5455 >>> >>> and as I mentioned in ticket #5455, I cannot reproduce it with >>> ipa-kra-install, so please provide steps to reproduce if you insist that >>> this still does not work as expected with KRA. >>> >>> 6) This is completely wrong, it removes everything that we tried to >>> achieve with previous patches with domain level in CI >> >> Actually, being able to configure domain level per class is WAY more >> convenient, than to always have to think which domain level is >> appropriate for which particular test during jenkins job >> configuration. In fact, I should have thought about it from the very >> beginning. For example, in test_replica_promotion.py we have on class, >> which intiates with domain level = 1, while others - with domain level >> 0. With config-based approach, we would have to implement a separate >> step that raises domain level. Overall, I am against the approach, >> when you have to remember to set certain domain level in config for >> any particular test. The tests themselves should be aware of the >> domain level they need. > I do not say that we should not have something that overrides settings > in from config in a particular test case, I say your patch is doing it > wrong. > > I agree it is useful to have param domain_level in install_master, and > intall_topo methods, but is cannot be MAX_DOMAIN_LEVEL by default, > because with your current patch the domain_level in config is not used > at all, it will be always MAX_DOMAIN_LEVEL > > For example I want to achieve this goal: > test_vault.py, this test suite can run on domain level1 and on domain > level0, so with one test we can test 2 domain levels just with putting > domain level into config file. > > I agree that with extraordinary test like replica promotion test is, we > need something that allows override the config file. > > As I said bellow, domain_level default value should be None in > install_master and install_topo plugin. If domain level was specified > use the specified one, if not (value is None) use the domain level from > config file. Agreed :) > > Martin >> >>> >>> [PATCH] Enabled setting domain_level per class derived from >>> TestIntegration >>> >>> When I configure domain level 0 in yaml config, how is this supposed to >>> get into install methods when you removed that code? >>> >>> - "--domain-level=%i" % host.config.domain_level >>> + "--domain-level=%i" % domain_level >>> >>> >>> You always use MAX_DOMAIN_LEVEL in this case or whatever is specified in >>> domain_level option. >>> I suggest to use domain_level=None, and when it is None use >>> 'host.config.domain_level', if it is not None, use 'domain_level' >>> >>> With this we can specify domain level in config file for test that can >>> be used for both domain levels and you can manually specify domain level >>> for test that requires specific domain level. >>> >>> Also this should go away >>> >>> @classmethod >>> def install(cls, mh): >>> + if hasattr(cls, "domain_level") and cls.master: >>> + cls.master.config.domain_level = cls.domain_level >>> if cls.topology is None: >>> return >>> >>> I do not see reason why test should override configuration in config in >>> this case. >>> >>> Martin >>> >>> On 25.11.2015 16:44, Oleg Fayans wrote: >>>> Hi, >>>> >>>> Here is the updated version of the patch (more tests + fixed the >>>> issues of the first one) + patch 0017, that implements the necessary >>>> changes in the background code, i. e. patch 16 does not work without >>>> patch 17 >>>> >>>> On 11/18/2015 05:20 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 09.11.2015 15:09, Oleg Fayans wrote: >>>>>> Hi guys, >>>>>> >>>>>> Here are first two automated testcases from this (so far incomplete) >>>>>> testplan: http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>>>>> >>>>>> Testplan review is highly appreciated >>>>>> >>>>>> >>>>>> >>>>>> >>>>> PATCH 16: NACK >>>>> >>>>> 1) >>>>> What is the reason to add an unused parameter to 'domain_level' to >>>>> install_topo()? >>>>> Also it is good practise to add new option as the last parameter. >>>>> >>>>> 2) >>>>> cab you in both tests specify a domain level with constant instead of >>>>> number literal? >>>>> >>>>> 3) >>>>> both test call install_topo with custom domain level, but it cannot >>>>> work >>>>> because 1) (did you run the test?) >>>>> >>>>> 4) >>>>> How the test "TestLevel1" is supposed to work? >>>>> Respectively why there is call of install_topo() that installs >>>>> replica. >>>>> As this test just tests that ipa-replica-prepare is not working >>>>> anymore, >>>>> is it worth to spend 20 minutes with installing replica and then >>>>> just no >>>>> tot use it? IMO to install master in install step is enough. >>>>> >>>>> Martin^2 >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0016.2-First-part-of-replica-promotion-tests.patch Type: text/x-patch Size: 10017 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0017.1-Enabled-setting-domain_level-per-class.patch Type: text/x-patch Size: 4941 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 27 14:05:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 15:05:22 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <56570BA8.6080002@redhat.com> References: <56535233.1020207@redhat.com> <56570BA8.6080002@redhat.com> Message-ID: <56586322.8070005@redhat.com> On 26.11.2015 14:39, Petr Vobornik wrote: > On 11/23/2015 06:51 PM, Oleg Fayans wrote: >> Hi all, >> >> Here is a draft of the Replica Promotion test plan >> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >> >> > > == Test case: Unprivileged users are not allowed to enroll and promote > clients == > User credentials are passed there through -p $principal and -w > $password options. It is correct atm because it is required for > connection check. But end goal of replica promotion is the avoid it. > See https://fedorahosted.org/freeipa/ticket/5497 and > https://fedorahosted.org/freeipa/ticket/5498 for more information. > > == Missing test cases == > 1. ipa-replica-install works on CA-less master with with both domain > levels > 2. ipa-server-install works with --setup-dns option with both domain > levels > 3. ipa-server-install works with externally signed CA cert with both > domain levels > 4. ipa-replica-install with options(and their combination): --setup-ca > --setup-dns --setup-kra works with both domain levels > > Note: Not sure if #2 and #3 belongs here, but should be tested. Maybe > tests for domain level 0 already exist. Many of them are already part of some tests. I wanted to crate install tests in one place with all combination of options, but I did not have time for it yet. I have a proof of concept test plan I can share it if you want. Martin From ofayans at redhat.com Fri Nov 27 14:24:01 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 27 Nov 2015 15:24:01 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <56586322.8070005@redhat.com> References: <56535233.1020207@redhat.com> <56570BA8.6080002@redhat.com> <56586322.8070005@redhat.com> Message-ID: <56586781.4080705@redhat.com> Hi Martin, On 11/27/2015 03:05 PM, Martin Basti wrote: > > > On 26.11.2015 14:39, Petr Vobornik wrote: >> On 11/23/2015 06:51 PM, Oleg Fayans wrote: >>> Hi all, >>> >>> Here is a draft of the Replica Promotion test plan >>> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>> >>> >> >> == Test case: Unprivileged users are not allowed to enroll and promote >> clients == >> User credentials are passed there through -p $principal and -w >> $password options. It is correct atm because it is required for >> connection check. But end goal of replica promotion is the avoid it. >> See https://fedorahosted.org/freeipa/ticket/5497 and >> https://fedorahosted.org/freeipa/ticket/5498 for more information. >> >> == Missing test cases == >> 1. ipa-replica-install works on CA-less master with with both domain >> levels >> 2. ipa-server-install works with --setup-dns option with both domain >> levels >> 3. ipa-server-install works with externally signed CA cert with both >> domain levels >> 4. ipa-replica-install with options(and their combination): --setup-ca >> --setup-dns --setup-kra works with both domain levels >> >> Note: Not sure if #2 and #3 belongs here, but should be tested. Maybe >> tests for domain level 0 already exist. > > Many of them are already part of some tests. > > I wanted to crate install tests in one place with all combination of > options, but I did not have time for it yet. > I have a proof of concept test plan I can share it if you want. It would be really helpful. Thanks for all your suggestions! > > Martin -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Fri Nov 27 14:26:15 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 15:26:15 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <565862E6.4020100@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> <56560124.4060904@redhat.com> <5656CB3B.8010000@redhat.com> <5656D5EE.7010208@redhat.com> <565862E6.4020100@redhat.com> Message-ID: <56586807.9080805@redhat.com> On 27.11.2015 15:04, Oleg Fayans wrote: > Hi Martin, > > All your suggestions were taken into account. Both patches are > updated. Thank you for your help! > > On 11/26/2015 10:50 AM, Martin Basti wrote: >> >> >> On 26.11.2015 10:04, Oleg Fayans wrote: >>> Hi Martin, >>> >>> I agree to all your points but one. please, see my comment below >>> >>> On 11/25/2015 07:42 PM, Martin Basti wrote: >>>> Hi, >>>> >>>> 0) Note >>>> Please be aware of https://fedorahosted.org/freeipa/ticket/5469 during >>>> KRA testing >>>> >>>> 1) >>>> Please do not use MIN and MAX_DOMAIN_LEVEL constants, this may change >>>> over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain level 0 >>>> and 1 >>>> >>>> 2) >>>> Why uninstall KRA then server, is not enough just uninstall server >>>> which >>>> covers KRA uninstall? >>>> >>>> + def teardown_method(self, method): >>>> + for host in self.replicas: >>>> + host.run_command(self.kra_uninstall, raiseonerr=False) >>>> + tasks.uninstall_master(host) >>>> >>>> >>>> 3) >>>> Can be this function more generic? It should allow specify host where >>>> KRA should be installed not just master >>>> >>>> + def test_kra_install_master(self): >>>> + self.master.run_command(self.kra_install) >>>> >>>> >>>> 4) >>>> >>>> TestLevel0(Dummy): >>>> Can be the test name more specific, something like >>>> TestReplicaPromotionLevel0 >>>> >>>> >>>> 5) >>>> please remove this, the patch is on review and it will be pushed >>>> sooner >>>> than tests >>>> + @pytest.mark.xfail # Ticket N 5455 >>>> >>>> and as I mentioned in ticket #5455, I cannot reproduce it with >>>> ipa-kra-install, so please provide steps to reproduce if you insist >>>> that >>>> this still does not work as expected with KRA. >>>> >>>> 6) This is completely wrong, it removes everything that we tried to >>>> achieve with previous patches with domain level in CI >>> >>> Actually, being able to configure domain level per class is WAY more >>> convenient, than to always have to think which domain level is >>> appropriate for which particular test during jenkins job >>> configuration. In fact, I should have thought about it from the very >>> beginning. For example, in test_replica_promotion.py we have on class, >>> which intiates with domain level = 1, while others - with domain level >>> 0. With config-based approach, we would have to implement a separate >>> step that raises domain level. Overall, I am against the approach, >>> when you have to remember to set certain domain level in config for >>> any particular test. The tests themselves should be aware of the >>> domain level they need. >> I do not say that we should not have something that overrides settings >> in from config in a particular test case, I say your patch is doing it >> wrong. >> >> I agree it is useful to have param domain_level in install_master, and >> intall_topo methods, but is cannot be MAX_DOMAIN_LEVEL by default, >> because with your current patch the domain_level in config is not used >> at all, it will be always MAX_DOMAIN_LEVEL >> >> For example I want to achieve this goal: >> test_vault.py, this test suite can run on domain level1 and on domain >> level0, so with one test we can test 2 domain levels just with putting >> domain level into config file. >> >> I agree that with extraordinary test like replica promotion test is, we >> need something that allows override the config file. >> >> As I said bellow, domain_level default value should be None in >> install_master and install_topo plugin. If domain level was specified >> use the specified one, if not (value is None) use the domain level from >> config file. > > Agreed :) > >> >> Martin >>> >>>> >>>> [PATCH] Enabled setting domain_level per class derived from >>>> TestIntegration >>>> >>>> When I configure domain level 0 in yaml config, how is this >>>> supposed to >>>> get into install methods when you removed that code? >>>> >>>> - "--domain-level=%i" % host.config.domain_level >>>> + "--domain-level=%i" % domain_level >>>> >>>> >>>> You always use MAX_DOMAIN_LEVEL in this case or whatever is >>>> specified in >>>> domain_level option. >>>> I suggest to use domain_level=None, and when it is None use >>>> 'host.config.domain_level', if it is not None, use 'domain_level' >>>> >>>> With this we can specify domain level in config file for test that can >>>> be used for both domain levels and you can manually specify domain >>>> level >>>> for test that requires specific domain level. >>>> >>>> Also this should go away >>>> >>>> @classmethod >>>> def install(cls, mh): >>>> + if hasattr(cls, "domain_level") and cls.master: >>>> + cls.master.config.domain_level = cls.domain_level >>>> if cls.topology is None: >>>> return >>>> >>>> I do not see reason why test should override configuration in >>>> config in >>>> this case. >>>> >>>> Martin >>>> >>>> On 25.11.2015 16:44, Oleg Fayans wrote: >>>>> Hi, >>>>> >>>>> Here is the updated version of the patch (more tests + fixed the >>>>> issues of the first one) + patch 0017, that implements the necessary >>>>> changes in the background code, i. e. patch 16 does not work without >>>>> patch 17 >>>>> >>>>> On 11/18/2015 05:20 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 09.11.2015 15:09, Oleg Fayans wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Here are first two automated testcases from this (so far >>>>>>> incomplete) >>>>>>> testplan: >>>>>>> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>>>>>> >>>>>>> Testplan review is highly appreciated >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> PATCH 16: NACK >>>>>> >>>>>> 1) >>>>>> What is the reason to add an unused parameter to 'domain_level' to >>>>>> install_topo()? >>>>>> Also it is good practise to add new option as the last parameter. >>>>>> >>>>>> 2) >>>>>> cab you in both tests specify a domain level with constant >>>>>> instead of >>>>>> number literal? >>>>>> >>>>>> 3) >>>>>> both test call install_topo with custom domain level, but it cannot >>>>>> work >>>>>> because 1) (did you run the test?) >>>>>> >>>>>> 4) >>>>>> How the test "TestLevel1" is supposed to work? >>>>>> Respectively why there is call of install_topo() that installs >>>>>> replica. >>>>>> As this test just tests that ipa-replica-prepare is not working >>>>>> anymore, >>>>>> is it worth to spend 20 minutes with installing replica and then >>>>>> just no >>>>>> tot use it? IMO to install master in install step is enough. >>>>>> >>>>>> Martin^2 >>>>>> >>>>> >>>> >>> >> > ./make-lint ************* Module ipatests.test_integration.base ipatests/test_integration/base.py:66: [E1101(no-member), IntegrationTest.install] Class 'IntegrationTest' has no 'domain_level' member) ************* Module ipatests.test_integration.test_replica_promotion ipatests/test_integration/test_replica_promotion.py:16: [E1101(no-member), Dummy.install] Class 'Dummy' has no 'domain_level' member) ipatests/test_integration/test_replica_promotion.py:117: [E1101(no-member), TestCAInstall.test_ca_install_without_replica_file] Module 'ipatests.test_integration.tasks' has no 'setup_replica' member) Is it so hard to run pylint before patch is posted for review? From mkubik at redhat.com Fri Nov 27 14:31:43 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 27 Nov 2015 15:31:43 +0100 Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package In-Reply-To: <5652DFAE.90906@redhat.com> References: <564F31CE.5010402@redhat.com> <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> <5652DFAE.90906@redhat.com> Message-ID: <5658694F.3080404@redhat.com> On 11/23/2015 10:43 AM, Lenka Doudova wrote: > NACK - there's a "typo" in ..../tracker/user_plugin.py, line 17-18: > > def get_user_dn(cn): > > return DN(('cn', cn), api.env.container_user, api.env.basedn) > > > should be > > def get_user_dn(uid): > > return DN(('uid', uid), api.env.container_user, api.env.basedn) > > > Some tests may fail because of that. > Lenka > > > On 11/20/2015 08:54 PM, Ale? Mare?ek wrote: >> Looks good. ACK. >> >> ----- Original Message ----- >>> From: "Milan Kub?k" >>> To: "freeipa-devel" >>> Cc: "Filip Skola" , "Ales Marecek" >>> >>> Sent: Friday, November 20, 2015 3:44:30 PM >>> Subject: [patch 0025] Separated Tracker implementations into >>> standalone package >>> >>> Fixes https://fedorahosted.org/freeipa/ticket/5467 >>> Patches attached. >>> >>> -- >>> Milan Kubik >>> >>> > Fixed the function and moved it into different module. Updated patches attached. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0025-2-Separated-Tracker-implementations-into-standalone-pa.patch Type: text/x-patch Size: 111976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0025-2-Separated-Tracker-implementations-into-standalone-pa.patch Type: text/x-patch Size: 111995 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 27 14:32:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 15:32:33 +0100 Subject: [Freeipa-devel] [PATCH] Removed duplicate domain name validation function In-Reply-To: <5655DF48.4060302@redhat.com> References: <5655DF48.4060302@redhat.com> Message-ID: <56586981.2010703@redhat.com> On 25.11.2015 17:18, Stanislav Laznicka wrote: > There were two functions for the same purpose. Removed one. > > Hello, I would like to have "log" param of is_host_resolvable as optional Otherwise the patch LGTM. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Nov 27 14:33:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Nov 2015 15:33:52 +0100 Subject: [Freeipa-devel] [PATCH] Removed duplicate domain name validation function In-Reply-To: <56586981.2010703@redhat.com> References: <5655DF48.4060302@redhat.com> <56586981.2010703@redhat.com> Message-ID: <565869D0.4060606@redhat.com> On 27.11.2015 15:32, Martin Basti wrote: > > > On 25.11.2015 17:18, Stanislav Laznicka wrote: >> There were two functions for the same purpose. Removed one. >> >> > Hello, > > I would like to have "log" param of is_host_resolvable as optional Is there an immediate need for the optional param? If not, I would not clutter the code. -- Petr^2 Spacek From mkubik at redhat.com Fri Nov 27 14:36:47 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 27 Nov 2015 15:36:47 +0100 Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package In-Reply-To: <5658694F.3080404@redhat.com> References: <564F31CE.5010402@redhat.com> <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> <5652DFAE.90906@redhat.com> <5658694F.3080404@redhat.com> Message-ID: <56586A7F.3070004@redhat.com> On 11/27/2015 03:31 PM, Milan Kub?k wrote: > On 11/23/2015 10:43 AM, Lenka Doudova wrote: >> NACK - there's a "typo" in ..../tracker/user_plugin.py, line 17-18: >> >> def get_user_dn(cn): >> >> return DN(('cn', cn), api.env.container_user, api.env.basedn) >> >> >> should be >> >> def get_user_dn(uid): >> >> return DN(('uid', uid), api.env.container_user, api.env.basedn) >> >> >> Some tests may fail because of that. >> Lenka >> >> >> On 11/20/2015 08:54 PM, Ale? Mare?ek wrote: >>> Looks good. ACK. >>> >>> ----- Original Message ----- >>>> From: "Milan Kub?k" >>>> To: "freeipa-devel" >>>> Cc: "Filip Skola" , "Ales Marecek" >>>> >>>> Sent: Friday, November 20, 2015 3:44:30 PM >>>> Subject: [patch 0025] Separated Tracker implementations into >>>> standalone package >>>> >>>> Fixes https://fedorahosted.org/freeipa/ticket/5467 >>>> Patches attached. >>>> >>>> -- >>>> Milan Kubik >>>> >>>> >> > Fixed the function and moved it into different module. > Updated patches attached. > > > Self nack, some imports missing -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Fri Nov 27 14:40:29 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 27 Nov 2015 15:40:29 +0100 Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package In-Reply-To: <56586A7F.3070004@redhat.com> References: <564F31CE.5010402@redhat.com> <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> <5652DFAE.90906@redhat.com> <5658694F.3080404@redhat.com> <56586A7F.3070004@redhat.com> Message-ID: <56586B5D.2040507@redhat.com> On 11/27/2015 03:36 PM, Milan Kub?k wrote: > On 11/27/2015 03:31 PM, Milan Kub?k wrote: >> On 11/23/2015 10:43 AM, Lenka Doudova wrote: >>> NACK - there's a "typo" in ..../tracker/user_plugin.py, line 17-18: >>> >>> def get_user_dn(cn): >>> >>> return DN(('cn', cn), api.env.container_user, api.env.basedn) >>> >>> >>> should be >>> >>> def get_user_dn(uid): >>> >>> return DN(('uid', uid), api.env.container_user, api.env.basedn) >>> >>> >>> Some tests may fail because of that. >>> Lenka >>> >>> >>> On 11/20/2015 08:54 PM, Ale? Mare?ek wrote: >>>> Looks good. ACK. >>>> >>>> ----- Original Message ----- >>>>> From: "Milan Kub?k" >>>>> To: "freeipa-devel" >>>>> Cc: "Filip Skola" , "Ales Marecek" >>>>> >>>>> Sent: Friday, November 20, 2015 3:44:30 PM >>>>> Subject: [patch 0025] Separated Tracker implementations into >>>>> standalone package >>>>> >>>>> Fixes https://fedorahosted.org/freeipa/ticket/5467 >>>>> Patches attached. >>>>> >>>>> -- >>>>> Milan Kubik >>>>> >>>>> >>> >> Fixed the function and moved it into different module. >> Updated patches attached. >> >> >> > Self nack, some imports missing > > -- > Milan Kubik > > Patches updated. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0025-3-Separated-Tracker-implementations-into-standalone-pa.patch Type: text/x-patch Size: 112040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0025-3-Separated-Tracker-implementations-into-standalone-pa.patch Type: text/x-patch Size: 112059 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 27 14:48:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 15:48:07 +0100 Subject: [Freeipa-devel] [PATCH] Removed duplicate domain name validation function In-Reply-To: <565869D0.4060606@redhat.com> References: <5655DF48.4060302@redhat.com> <56586981.2010703@redhat.com> <565869D0.4060606@redhat.com> Message-ID: <56586D27.4030802@redhat.com> On 27.11.2015 15:33, Petr Spacek wrote: > On 27.11.2015 15:32, Martin Basti wrote: >> >> On 25.11.2015 17:18, Stanislav Laznicka wrote: >>> There were two functions for the same purpose. Removed one. >>> >>> >> Hello, >> >> I would like to have "log" param of is_host_resolvable as optional > Is there an immediate need for the optional param? If not, I would not clutter > the code. > So at least I would like to move log param as the last param, in case of need it can be modified to optional parameter. Or log can be default as root_logger, IMO we us only root_logger everywhere, but this need investigation. Martin From pvoborni at redhat.com Fri Nov 27 14:51:57 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Nov 2015 15:51:57 +0100 Subject: [Freeipa-devel] [PATCH] 928-936 webui: topology visualization In-Reply-To: <5655DC2E.4050707@redhat.com> References: <564F3577.9090207@redhat.com> <565445AA.4070404@redhat.com> <56544763.2090905@redhat.com> <56546189.9010505@redhat.com> <5655C57D.6090904@redhat.com> <5655DC2E.4050707@redhat.com> Message-ID: <56586E0D.1050205@redhat.com> On 11/25/2015 05:05 PM, Martin Babinsky wrote: > On 11/25/2015 03:28 PM, Petr Vobornik wrote: >> On 11/24/2015 02:09 PM, Martin Babinsky wrote: >>> On 11/24/2015 12:17 PM, Petr Vobornik wrote: >>>> On 11/24/2015 12:10 PM, Ludwig Krispenz wrote: >>>>> Hi Petr, >>>>> >>>>> I'm testing these patches.Two observations so far: >>>>> - in Topology->IPA Servers I see a table of my servers and the managed >>>>> suffix column I see both suffixes, ipaca and the realm, >>>>> but if I select one of the servers I Only see the realm suffix, this >>>>> was >>>>> different in the demo video >>>> >>>> implemented in patch 927 (separate thread) >>>> >>>>> - the graph layou is not stable. If I arrange it and the try some >>>>> actions on a segment, eg try to remove one (which is rejected), the >>>>> graph does change again- >>>> >>>> Not sure if I understand it correctly. One can set static position to a >>>> node by double clicking on it (this needs to be somehow communicated) >>>> otherwise it is random - each refresh. >>>> >>>> Maybe we should not refresh on failed operation because there is no >>>> change. >>> +1, failed operations on segments should not trigger graph redraws. >> >> Fixed in patch 936-1. >> > Confirmed. >>> >>>> >>>>> >>>>> Ludwig >>>>> >>>>> On 11/20/2015 04:00 PM, Petr Vobornik wrote: >>>>>> Patches 928-931 are prerequisites. >>>>>> >>>>>> Patches 932-934 implements the visualization >>>>>> >>>>>> Patches 935-936 adds 'add' and 'remove' segment functionality to the >>>>>> visualization page. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4286 >>>> >>> >>> I have tested the new feature a bit (I have looked also on the code, but >>> I do not speak JavaScript very well) and so far I have found these >>> issues: >>> >>> 1.) If you first setup topology w/ domain level 0 and try to render >>> topology graph, you are correctly informed that managed topology is >>> available on domain level 1 only. IF you raise your domainlevel and >>> click refresh, you get the same error message, probably because the >>> request to get domainlevel is sent only in the beginning of session. You >>> have to logout and then login back to see the graph. >> >> Login/Logout should not be required. Refresh of UI(F5) should be >> sufficient. >> >> Anyway, fixed in new patch 937. >> > Confirmed works as advertised. > >>> >>> 2.) If I add a new segment using Add dialog and clicking 'Add & edit' >>> button, I get the following error: >>> >>> """ >>> IPA Error 3007: RequirementError >>> >>> 'topologysuffixcn' is required >>> """ >>> >>> However the segment is created normally. I guess that there is some bug >>> when viewing the segment immediately after creation. >> >> Fixed in patch 935-1. >> > > Indeed. > >>> >>> 3.) The key with suffix colors should be more descriptive. I would like >>> to propose the following format: >>> >>> """ >>> Color coding of segments by suffix: >>> {suffix_name} ({suffix_dn}) >>> e.g. >>> ipaca (o=ipaca) >>> realm (dc=ipa,dc=test) >>> """ >>> >>> 4.) It would be nice if the graph canvas could be dynamically resized >>> based on the container size, but I am not sure how difficult it is to >>> implement it. >>> (Graphical nitpick: I would change the color of nodes, green does not >>> fit very well with the bluish/grey palette of other WebUI elements) >> >> I would like this, #3 and #4 to go trough additional designer review and >> therefore fixed in other patch. >> > I'm OK with that, it is a cosmetic change anyway so we shouldn't > bikeshed over it. >> Right now I'm not sure what is the correct behavior for the re-sizing. >> >> Atm the canvas size is fixed: 960x500. >> >> 1. What should be the canvas size when size of the container is very >> small, e.g. 330x90? With static positions, nodes would not be visible. >> 2. Similar issue when nodes are put into corners and then the window is >> shrunk. >> >> Probably there could be a minimum size and then enlarge the cavas when >> nodes are dragged. >> > Minimum canvas size makes sense IMHO. I'm not sure about the behavior of > the auto-resize during node manipulation. I would begin with a canvas > that has some reasonable minimal size and expands to the size of the > container/facet (not sure about the terminology here) during resize with > some reasonable padding added. Then we can implement some > zooming/panning feature on top. > >>> >>> Otherwise I think that it is a good start and additional features can be >>> built on top of this patchset. >>> > > All in all I think that all these points can be addressed in followup > patches after discussion with UX people. If nobody else objects I would > ACK these patches. > pushed to master: * 148083f26a51110860f58b1610ae032f74e6465c webui: add Deferred/Promise API to rpc.command * fc4b33d05017fac255aa8600fc45b5795f9a51c6 webui: split facet header into two classes * 74b7c00365e66967fa6a7a62a3d0eaab99443824 webui: extract header and action logic from facet to separate mixins * b8059001a5c57fd06bd977f6cc2448d3b401cabd webui: allow to update action_state directly * ce1645ceeca577d1c73ba77f3eb8cb13c2bef2a1 webui: add d3 library - version 3.5.6 * 24fead79cbe5ef168a42f08da6fd99b4ec2b1bab webui: topology graph component * 68f6c2c7dc1277d9efd3e729a924d4c9cadc90ec webui: topology graph facet * eb242ac9a9cc1e8dea16788a64030adbb333a4b2 webui: add segments on topology graph page * 768d1965aaa79625b5c6e16d999d65dd7fd4372e webui: remove segments on topology graph page * b4aa222e426c2b3f294432be64d95750dd86bc03 webui: update topology graph after raising domain level -- Petr Vobornik From pvoborni at redhat.com Fri Nov 27 14:57:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Nov 2015 15:57:26 +0100 Subject: [Freeipa-devel] [PATCH] 927 topology: treat server suffix as multivalued attribute in API In-Reply-To: <56585FA4.3020205@redhat.com> References: <564F34A5.60208@redhat.com> <56585FA4.3020205@redhat.com> Message-ID: <56586F56.8020407@redhat.com> On 11/27/2015 02:50 PM, Martin Babinsky wrote: > On 11/20/2015 03:56 PM, Petr Vobornik wrote: >> >> >> > ACK > Pushed to master: c688954c27c219cb18aff968fc1f510afff93981 -- Petr Vobornik From pvoborni at redhat.com Fri Nov 27 15:00:03 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Nov 2015 16:00:03 +0100 Subject: [Freeipa-devel] [PATCH] Allow ipa-getkeytab to find server name from config file In-Reply-To: <20151126011156.GA23644@dhcp-40-8.bne.redhat.com> References: <1448309931.7892.31.camel@redhat.com> <5654046A.3040002@redhat.com> <56541A7D.4070002@redhat.com> <56541C4D.2020904@redhat.com> <1448382615.7892.65.camel@redhat.com> <56549182.40503@redhat.com> <1448393777.29102.6.camel@redhat.com> <20151125043440.GZ5336@dhcp-40-8.bne.redhat.com> <1448462649.29102.43.camel@redhat.com> <20151126011156.GA23644@dhcp-40-8.bne.redhat.com> Message-ID: <56586FF3.60901@redhat.com> On 11/26/2015 02:11 AM, Fraser Tweedale wrote: > On Wed, Nov 25, 2015 at 09:44:09AM -0500, Simo Sorce wrote: >> On Wed, 2015-11-25 at 14:34 +1000, Fraser Tweedale wrote: >> >> Attached new patch that includes manpage changes. >> >> Simo. >> > ACK > Pushed to master: f12f56fe8d607240efd7e8c8a942554bdd3b980f -- Petr Vobornik From ofayans at redhat.com Fri Nov 27 15:03:50 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 27 Nov 2015 16:03:50 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <56586807.9080805@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> <56560124.4060904@redhat.com> <5656CB3B.8010000@redhat.com> <5656D5EE.7010208@redhat.com> <565862E6.4020100@redhat.com> <56586807.9080805@redhat.com> Message-ID: <565870D6.40908@redhat.com> Hi, On 11/27/2015 03:26 PM, Martin Basti wrote: > > > On 27.11.2015 15:04, Oleg Fayans wrote: >> Hi Martin, >> >> All your suggestions were taken into account. Both patches are >> updated. Thank you for your help! >> >> On 11/26/2015 10:50 AM, Martin Basti wrote: >>> >>> >>> On 26.11.2015 10:04, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> I agree to all your points but one. please, see my comment below >>>> >>>> On 11/25/2015 07:42 PM, Martin Basti wrote: >>>>> Hi, >>>>> >>>>> 0) Note >>>>> Please be aware of https://fedorahosted.org/freeipa/ticket/5469 during >>>>> KRA testing >>>>> >>>>> 1) >>>>> Please do not use MIN and MAX_DOMAIN_LEVEL constants, this may change >>>>> over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain level 0 >>>>> and 1 >>>>> >>>>> 2) >>>>> Why uninstall KRA then server, is not enough just uninstall server >>>>> which >>>>> covers KRA uninstall? >>>>> >>>>> + def teardown_method(self, method): >>>>> + for host in self.replicas: >>>>> + host.run_command(self.kra_uninstall, raiseonerr=False) >>>>> + tasks.uninstall_master(host) >>>>> >>>>> >>>>> 3) >>>>> Can be this function more generic? It should allow specify host where >>>>> KRA should be installed not just master >>>>> >>>>> + def test_kra_install_master(self): >>>>> + self.master.run_command(self.kra_install) >>>>> >>>>> >>>>> 4) >>>>> >>>>> TestLevel0(Dummy): >>>>> Can be the test name more specific, something like >>>>> TestReplicaPromotionLevel0 >>>>> >>>>> >>>>> 5) >>>>> please remove this, the patch is on review and it will be pushed >>>>> sooner >>>>> than tests >>>>> + @pytest.mark.xfail # Ticket N 5455 >>>>> >>>>> and as I mentioned in ticket #5455, I cannot reproduce it with >>>>> ipa-kra-install, so please provide steps to reproduce if you insist >>>>> that >>>>> this still does not work as expected with KRA. >>>>> >>>>> 6) This is completely wrong, it removes everything that we tried to >>>>> achieve with previous patches with domain level in CI >>>> >>>> Actually, being able to configure domain level per class is WAY more >>>> convenient, than to always have to think which domain level is >>>> appropriate for which particular test during jenkins job >>>> configuration. In fact, I should have thought about it from the very >>>> beginning. For example, in test_replica_promotion.py we have on class, >>>> which intiates with domain level = 1, while others - with domain level >>>> 0. With config-based approach, we would have to implement a separate >>>> step that raises domain level. Overall, I am against the approach, >>>> when you have to remember to set certain domain level in config for >>>> any particular test. The tests themselves should be aware of the >>>> domain level they need. >>> I do not say that we should not have something that overrides settings >>> in from config in a particular test case, I say your patch is doing it >>> wrong. >>> >>> I agree it is useful to have param domain_level in install_master, and >>> intall_topo methods, but is cannot be MAX_DOMAIN_LEVEL by default, >>> because with your current patch the domain_level in config is not used >>> at all, it will be always MAX_DOMAIN_LEVEL >>> >>> For example I want to achieve this goal: >>> test_vault.py, this test suite can run on domain level1 and on domain >>> level0, so with one test we can test 2 domain levels just with putting >>> domain level into config file. >>> >>> I agree that with extraordinary test like replica promotion test is, we >>> need something that allows override the config file. >>> >>> As I said bellow, domain_level default value should be None in >>> install_master and install_topo plugin. If domain level was specified >>> use the specified one, if not (value is None) use the domain level from >>> config file. >> >> Agreed :) >> >>> >>> Martin >>>> >>>>> >>>>> [PATCH] Enabled setting domain_level per class derived from >>>>> TestIntegration >>>>> >>>>> When I configure domain level 0 in yaml config, how is this >>>>> supposed to >>>>> get into install methods when you removed that code? >>>>> >>>>> - "--domain-level=%i" % host.config.domain_level >>>>> + "--domain-level=%i" % domain_level >>>>> >>>>> >>>>> You always use MAX_DOMAIN_LEVEL in this case or whatever is >>>>> specified in >>>>> domain_level option. >>>>> I suggest to use domain_level=None, and when it is None use >>>>> 'host.config.domain_level', if it is not None, use 'domain_level' >>>>> >>>>> With this we can specify domain level in config file for test that can >>>>> be used for both domain levels and you can manually specify domain >>>>> level >>>>> for test that requires specific domain level. >>>>> >>>>> Also this should go away >>>>> >>>>> @classmethod >>>>> def install(cls, mh): >>>>> + if hasattr(cls, "domain_level") and cls.master: >>>>> + cls.master.config.domain_level = cls.domain_level >>>>> if cls.topology is None: >>>>> return >>>>> >>>>> I do not see reason why test should override configuration in >>>>> config in >>>>> this case. >>>>> >>>>> Martin >>>>> >>>>> On 25.11.2015 16:44, Oleg Fayans wrote: >>>>>> Hi, >>>>>> >>>>>> Here is the updated version of the patch (more tests + fixed the >>>>>> issues of the first one) + patch 0017, that implements the necessary >>>>>> changes in the background code, i. e. patch 16 does not work without >>>>>> patch 17 >>>>>> >>>>>> On 11/18/2015 05:20 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 09.11.2015 15:09, Oleg Fayans wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> Here are first two automated testcases from this (so far >>>>>>>> incomplete) >>>>>>>> testplan: >>>>>>>> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>>>>>>> >>>>>>>> Testplan review is highly appreciated >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> PATCH 16: NACK >>>>>>> >>>>>>> 1) >>>>>>> What is the reason to add an unused parameter to 'domain_level' to >>>>>>> install_topo()? >>>>>>> Also it is good practise to add new option as the last parameter. >>>>>>> >>>>>>> 2) >>>>>>> cab you in both tests specify a domain level with constant >>>>>>> instead of >>>>>>> number literal? >>>>>>> >>>>>>> 3) >>>>>>> both test call install_topo with custom domain level, but it cannot >>>>>>> work >>>>>>> because 1) (did you run the test?) >>>>>>> >>>>>>> 4) >>>>>>> How the test "TestLevel1" is supposed to work? >>>>>>> Respectively why there is call of install_topo() that installs >>>>>>> replica. >>>>>>> As this test just tests that ipa-replica-prepare is not working >>>>>>> anymore, >>>>>>> is it worth to spend 20 minutes with installing replica and then >>>>>>> just no >>>>>>> tot use it? IMO to install master in install step is enough. >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> >>>>> >>>> >>> >> > ./make-lint > ************* Module ipatests.test_integration.base > ipatests/test_integration/base.py:66: [E1101(no-member), > IntegrationTest.install] Class 'IntegrationTest' has no 'domain_level' > member) > ************* Module ipatests.test_integration.test_replica_promotion > ipatests/test_integration/test_replica_promotion.py:16: > [E1101(no-member), Dummy.install] Class 'Dummy' has no 'domain_level' > member) > ipatests/test_integration/test_replica_promotion.py:117: > [E1101(no-member), TestCAInstall.test_ca_install_without_replica_file] > Module 'ipatests.test_integration.tasks' has no 'setup_replica' member) > > > Is it so hard to run pylint before patch is posted for review? Sorry, my bad. Fixed. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0017.2-Enabled-setting-domain_level-per-class.patch Type: text/x-patch Size: 5127 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 27 15:04:41 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 Nov 2015 16:04:41 +0100 Subject: [Freeipa-devel] [PATCH 0355-0356, 0363] Prevent using replica file with ipa-ca-install and domain In-Reply-To: <56585519.5070806@redhat.com> References: <56542C37.9000603@redhat.com> <565486BA.7050104@redhat.com> <56571097.9050102@redhat.com> <56585519.5070806@redhat.com> Message-ID: <56587109.8020402@redhat.com> On 11/27/2015 02:05 PM, Martin Basti wrote: > > > On 26.11.2015 15:00, Martin Basti wrote: >> >> >> On 24.11.2015 16:48, Jan Cholasta wrote: >>> On 24.11.2015 10:21, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5455 >>>> >>>> Patches attached. >>> >>> + def run(self): >>> + self._run() >>> >>> Wouldn't it be better to rename _run() to run() instead? >>> >> Updated patches attached. >> >> > Updated patches attached, thanks to Oleg I was able to reproduce KRA > issue too (patch 363) > > ACK. -- Martin^3 Babinsky From slaznick at redhat.com Fri Nov 27 15:06:41 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 27 Nov 2015 16:06:41 +0100 Subject: [Freeipa-devel] [PATCH] Removed duplicate domain name validation function In-Reply-To: <56586D27.4030802@redhat.com> References: <5655DF48.4060302@redhat.com> <56586981.2010703@redhat.com> <565869D0.4060606@redhat.com> <56586D27.4030802@redhat.com> Message-ID: <56587181.1070004@redhat.com> Please, see the modified patch attached. Standa On 11/27/2015 03:48 PM, Martin Basti wrote: > > > On 27.11.2015 15:33, Petr Spacek wrote: >> On 27.11.2015 15:32, Martin Basti wrote: >>> >>> On 25.11.2015 17:18, Stanislav Laznicka wrote: >>>> There were two functions for the same purpose. Removed one. >>>> >>>> >>> Hello, >>> >>> I would like to have "log" param of is_host_resolvable as optional >> Is there an immediate need for the optional param? If not, I would >> not clutter >> the code. >> > So at least I would like to move log param as the last param, in case > of need it can be modified to optional parameter. > > Or log can be default as root_logger, IMO we us only root_logger > everywhere, but this need investigation. > > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0010-Removed-duplicate-domain-name-validating-function.patch Type: text/x-patch Size: 9033 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 27 15:14:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 16:14:47 +0100 Subject: [Freeipa-devel] [PATCH 0355-0356, 0363] Prevent using replica file with ipa-ca-install and domain In-Reply-To: <56587109.8020402@redhat.com> References: <56542C37.9000603@redhat.com> <565486BA.7050104@redhat.com> <56571097.9050102@redhat.com> <56585519.5070806@redhat.com> <56587109.8020402@redhat.com> Message-ID: <56587367.3000400@redhat.com> On 27.11.2015 16:04, Martin Babinsky wrote: > On 11/27/2015 02:05 PM, Martin Basti wrote: >> >> >> On 26.11.2015 15:00, Martin Basti wrote: >>> >>> >>> On 24.11.2015 16:48, Jan Cholasta wrote: >>>> On 24.11.2015 10:21, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5455 >>>>> >>>>> Patches attached. >>>> >>>> + def run(self): >>>> + self._run() >>>> >>>> Wouldn't it be better to rename _run() to run() instead? >>>> >>> Updated patches attached. >>> >>> >> Updated patches attached, thanks to Oleg I was able to reproduce KRA >> issue too (patch 363) >> >> > ACK. > Pushed to master: ab8cba61c08571e4cbce1246bcbf820d3e337506 From simo at redhat.com Fri Nov 27 15:18:47 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Nov 2015 10:18:47 -0500 Subject: [Freeipa-devel] [PATCH] 924 use starttls in CSReplicationManager connection again In-Reply-To: <56585FE1.6020505@redhat.com> References: <562A2A96.1080101@redhat.com> <562A4AED.8090801@redhat.com> <56585FE1.6020505@redhat.com> Message-ID: <1448637527.3747.17.camel@redhat.com> On Fri, 2015-11-27 at 14:51 +0100, Petr Vobornik wrote: > On 10/23/2015 04:57 PM, Simo Sorce wrote: > > On 23/10/15 08:39, Petr Vobornik wrote: > >> not sure if the change in2606f5aecd6ac0db31abb515b691529bb7eaf14e was a > >> mistake or done on purpose. > >> > >> Anyway: > >> commit 2606f5aecd6ac0db31abb515b691529bb7eaf14e > >> > >> has: > >> - realm, hostname, dirman_passwd, port, starttls=True) > >> + realm, hostname, dirman_passwd, port) > >> > >> In CSReplicationManager > >> > >> which causes, e.g.: > >> > >> ipa-csreplica-manage -p Secret123 list ipa.example.com > >> cannot connect to 'ldaps://ipa.example.com:389': TLS error > >> -5938:Encountered end of file > >> > >> Attached patch reverts it. > > > > I am not sure it was a mistake, we have changed replication from using > > TLS to always use LDAP+GSSAPI, so why is ipa-csreplica-manage depending > > on ldaps anyway ? > > > > It may need to when dealing with very old domains where we have split > > instances for CS and IPA, but not in anything modern. I would rather > > change the command to cope with using LDAP+GSSAPI. > > > > A simple revert may break something in replica promotion, would need to > > be tested with a full master+replica install. > > I had this patch applied in branch while developing Topology graph - > promotion of several replicas worked. Replica promotion uses new > CAReplicationManager - not CSReplicationManager so it shouldn't be > affected. CSReplicationManager is used only in > get_cs_replication_manager call. This call is used only in > ipa-csreplica-manage and ipa_restore.py. > > Without this patch the related functionality in both > ipa-csreplica-manage and ipa_restore.py (see > https://fedorahosted.org/freeipa/ticket/5479#comment:2 ) doesn't work. > > I don't think that changing ipa-csreplica-manage is worth the effort > given that we want to deprecate the tool. > > Therefore I propose to go with this patch. OK then, go ahead. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Fri Nov 27 15:18:50 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 Nov 2015 16:18:50 +0100 Subject: [Freeipa-devel] [PATCH 0106] perform IPA client uninstallation as a last step of server uninstall Message-ID: <5658745A.3060701@redhat.com> This patch fixes https://fedorahosted.org/freeipa/ticket/5410 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0106-perform-IPA-client-uninstallation-as-a-last-step-of-.patch Type: text/x-patch Size: 2484 bytes Desc: not available URL: From tbabej at redhat.com Fri Nov 27 15:25:11 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 27 Nov 2015 16:25:11 +0100 Subject: [Freeipa-devel] [PATCH 0387] custodia: Make sure container is created with first custodia Message-ID: <565875D7.5050102@redhat.com> Hi, If a first 4.3+ replica is installed in the domain, the custodia container does not exist. Make sure it is created to avoid failures during key generation. https://fedorahosted.org/freeipa/ticket/5474 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0387-custodia-Make-sure-container-is-created-with-first-c.patch Type: text/x-patch Size: 2507 bytes Desc: not available URL: From ofayans at redhat.com Fri Nov 27 15:26:14 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 27 Nov 2015 16:26:14 +0100 Subject: [Freeipa-devel] [PATCH] First part of the replica promotion tests + testplan In-Reply-To: <565870D6.40908@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> <56560124.4060904@redhat.com> <5656CB3B.8010000@redhat.com> <5656D5EE.7010208@redhat.com> <565862E6.4020100@redhat.com> <56586807.9080805@redhat.com> <565870D6.40908@redhat.com> Message-ID: <56587616.5030609@redhat.com> And patch N 16 passes lint too: On 11/27/2015 04:03 PM, Oleg Fayans wrote: > Hi, > > On 11/27/2015 03:26 PM, Martin Basti wrote: >> >> >> On 27.11.2015 15:04, Oleg Fayans wrote: >>> Hi Martin, >>> >>> All your suggestions were taken into account. Both patches are >>> updated. Thank you for your help! >>> >>> On 11/26/2015 10:50 AM, Martin Basti wrote: >>>> >>>> >>>> On 26.11.2015 10:04, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> I agree to all your points but one. please, see my comment below >>>>> >>>>> On 11/25/2015 07:42 PM, Martin Basti wrote: >>>>>> Hi, >>>>>> >>>>>> 0) Note >>>>>> Please be aware of https://fedorahosted.org/freeipa/ticket/5469 >>>>>> during >>>>>> KRA testing >>>>>> >>>>>> 1) >>>>>> Please do not use MIN and MAX_DOMAIN_LEVEL constants, this may change >>>>>> over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain level 0 >>>>>> and 1 >>>>>> >>>>>> 2) >>>>>> Why uninstall KRA then server, is not enough just uninstall server >>>>>> which >>>>>> covers KRA uninstall? >>>>>> >>>>>> + def teardown_method(self, method): >>>>>> + for host in self.replicas: >>>>>> + host.run_command(self.kra_uninstall, raiseonerr=False) >>>>>> + tasks.uninstall_master(host) >>>>>> >>>>>> >>>>>> 3) >>>>>> Can be this function more generic? It should allow specify host where >>>>>> KRA should be installed not just master >>>>>> >>>>>> + def test_kra_install_master(self): >>>>>> + self.master.run_command(self.kra_install) >>>>>> >>>>>> >>>>>> 4) >>>>>> >>>>>> TestLevel0(Dummy): >>>>>> Can be the test name more specific, something like >>>>>> TestReplicaPromotionLevel0 >>>>>> >>>>>> >>>>>> 5) >>>>>> please remove this, the patch is on review and it will be pushed >>>>>> sooner >>>>>> than tests >>>>>> + @pytest.mark.xfail # Ticket N 5455 >>>>>> >>>>>> and as I mentioned in ticket #5455, I cannot reproduce it with >>>>>> ipa-kra-install, so please provide steps to reproduce if you insist >>>>>> that >>>>>> this still does not work as expected with KRA. >>>>>> >>>>>> 6) This is completely wrong, it removes everything that we tried to >>>>>> achieve with previous patches with domain level in CI >>>>> >>>>> Actually, being able to configure domain level per class is WAY more >>>>> convenient, than to always have to think which domain level is >>>>> appropriate for which particular test during jenkins job >>>>> configuration. In fact, I should have thought about it from the very >>>>> beginning. For example, in test_replica_promotion.py we have on class, >>>>> which intiates with domain level = 1, while others - with domain level >>>>> 0. With config-based approach, we would have to implement a separate >>>>> step that raises domain level. Overall, I am against the approach, >>>>> when you have to remember to set certain domain level in config for >>>>> any particular test. The tests themselves should be aware of the >>>>> domain level they need. >>>> I do not say that we should not have something that overrides settings >>>> in from config in a particular test case, I say your patch is doing it >>>> wrong. >>>> >>>> I agree it is useful to have param domain_level in install_master, and >>>> intall_topo methods, but is cannot be MAX_DOMAIN_LEVEL by default, >>>> because with your current patch the domain_level in config is not used >>>> at all, it will be always MAX_DOMAIN_LEVEL >>>> >>>> For example I want to achieve this goal: >>>> test_vault.py, this test suite can run on domain level1 and on domain >>>> level0, so with one test we can test 2 domain levels just with putting >>>> domain level into config file. >>>> >>>> I agree that with extraordinary test like replica promotion test is, we >>>> need something that allows override the config file. >>>> >>>> As I said bellow, domain_level default value should be None in >>>> install_master and install_topo plugin. If domain level was specified >>>> use the specified one, if not (value is None) use the domain level from >>>> config file. >>> >>> Agreed :) >>> >>>> >>>> Martin >>>>> >>>>>> >>>>>> [PATCH] Enabled setting domain_level per class derived from >>>>>> TestIntegration >>>>>> >>>>>> When I configure domain level 0 in yaml config, how is this >>>>>> supposed to >>>>>> get into install methods when you removed that code? >>>>>> >>>>>> - "--domain-level=%i" % host.config.domain_level >>>>>> + "--domain-level=%i" % domain_level >>>>>> >>>>>> >>>>>> You always use MAX_DOMAIN_LEVEL in this case or whatever is >>>>>> specified in >>>>>> domain_level option. >>>>>> I suggest to use domain_level=None, and when it is None use >>>>>> 'host.config.domain_level', if it is not None, use 'domain_level' >>>>>> >>>>>> With this we can specify domain level in config file for test that >>>>>> can >>>>>> be used for both domain levels and you can manually specify domain >>>>>> level >>>>>> for test that requires specific domain level. >>>>>> >>>>>> Also this should go away >>>>>> >>>>>> @classmethod >>>>>> def install(cls, mh): >>>>>> + if hasattr(cls, "domain_level") and cls.master: >>>>>> + cls.master.config.domain_level = cls.domain_level >>>>>> if cls.topology is None: >>>>>> return >>>>>> >>>>>> I do not see reason why test should override configuration in >>>>>> config in >>>>>> this case. >>>>>> >>>>>> Martin >>>>>> >>>>>> On 25.11.2015 16:44, Oleg Fayans wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Here is the updated version of the patch (more tests + fixed the >>>>>>> issues of the first one) + patch 0017, that implements the necessary >>>>>>> changes in the background code, i. e. patch 16 does not work without >>>>>>> patch 17 >>>>>>> >>>>>>> On 11/18/2015 05:20 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 09.11.2015 15:09, Oleg Fayans wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> Here are first two automated testcases from this (so far >>>>>>>>> incomplete) >>>>>>>>> testplan: >>>>>>>>> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>>>>>>>> >>>>>>>>> Testplan review is highly appreciated >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> PATCH 16: NACK >>>>>>>> >>>>>>>> 1) >>>>>>>> What is the reason to add an unused parameter to 'domain_level' to >>>>>>>> install_topo()? >>>>>>>> Also it is good practise to add new option as the last parameter. >>>>>>>> >>>>>>>> 2) >>>>>>>> cab you in both tests specify a domain level with constant >>>>>>>> instead of >>>>>>>> number literal? >>>>>>>> >>>>>>>> 3) >>>>>>>> both test call install_topo with custom domain level, but it cannot >>>>>>>> work >>>>>>>> because 1) (did you run the test?) >>>>>>>> >>>>>>>> 4) >>>>>>>> How the test "TestLevel1" is supposed to work? >>>>>>>> Respectively why there is call of install_topo() that installs >>>>>>>> replica. >>>>>>>> As this test just tests that ipa-replica-prepare is not working >>>>>>>> anymore, >>>>>>>> is it worth to spend 20 minutes with installing replica and then >>>>>>>> just no >>>>>>>> tot use it? IMO to install master in install step is enough. >>>>>>>> >>>>>>>> Martin^2 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> ./make-lint >> ************* Module ipatests.test_integration.base >> ipatests/test_integration/base.py:66: [E1101(no-member), >> IntegrationTest.install] Class 'IntegrationTest' has no 'domain_level' >> member) >> ************* Module ipatests.test_integration.test_replica_promotion >> ipatests/test_integration/test_replica_promotion.py:16: >> [E1101(no-member), Dummy.install] Class 'Dummy' has no 'domain_level' >> member) >> ipatests/test_integration/test_replica_promotion.py:117: >> [E1101(no-member), TestCAInstall.test_ca_install_without_replica_file] >> Module 'ipatests.test_integration.tasks' has no 'setup_replica' member) >> >> >> Is it so hard to run pylint before patch is posted for review? > > Sorry, my bad. Fixed. > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0016.3-First-part-of-replica-promotion-tests.patch Type: text/x-patch Size: 10021 bytes Desc: not available URL: From mbasti at redhat.com Fri Nov 27 15:37:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 16:37:36 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Installation tests In-Reply-To: <56586322.8070005@redhat.com> References: <56535233.1020207@redhat.com> <56570BA8.6080002@redhat.com> <56586322.8070005@redhat.com> Message-ID: <565878C0.7050509@redhat.com> On 27.11.2015 15:05, Martin Basti wrote: > > > On 26.11.2015 14:39, Petr Vobornik wrote: >> On 11/23/2015 06:51 PM, Oleg Fayans wrote: >>> Hi all, >>> >>> Here is a draft of the Replica Promotion test plan >>> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>> >>> >> >> == Test case: Unprivileged users are not allowed to enroll and >> promote clients == >> User credentials are passed there through -p $principal and -w >> $password options. It is correct atm because it is required for >> connection check. But end goal of replica promotion is the avoid it. >> See https://fedorahosted.org/freeipa/ticket/5497 and >> https://fedorahosted.org/freeipa/ticket/5498 for more information. >> >> == Missing test cases == >> 1. ipa-replica-install works on CA-less master with with both domain >> levels >> 2. ipa-server-install works with --setup-dns option with both domain >> levels >> 3. ipa-server-install works with externally signed CA cert with both >> domain levels >> 4. ipa-replica-install with options(and their combination): >> --setup-ca --setup-dns --setup-kra works with both domain levels >> >> Note: Not sure if #2 and #3 belongs here, but should be tested. Maybe >> tests for domain level 0 already exist. > > Many of them are already part of some tests. > > I wanted to crate install tests in one place with all combination of > options, but I did not have time for it yet. > I have a proof of concept test plan I can share it if you want. > > Martin > Proof of concept test plan: Master: * ipa-server-install * ipa-server-install --setup-dns * caless ipa-server-install * ipa-server-install && ipa-dns-install * ipa-server-install && ipa-dns-install --dnssec-master * caless ipa-server-install && ipa-dns-install * caless ipa-server-install && ipa-ca-install * caless ipa-server-install && ipa-ca-install && ipa-kra-install * ipa-server-install && ipa-kra-install Replica: ipa-replica-install ipa-replica-install --setup-dns ipa-replica-install --setup-ca ipa-replica-install --setup-dns --setup-ca ipa-replica-install --setup-ca --setup-kra ipa-replica-install --setup-dns --setup-ca --setup-kra ipa-replica-install && ipa-dns-install ipa-replica-install && ipa-dns-install --dnssec-master ipa-replica-install && ipa-ca-install ipa-replica-install && ipa-ca-install && ipa-kra-install ipa-replica-install && ipa-dns-install && ipa-ca-install && ipa-kra-install caless ipa-replica-install && ipa-ca-install caless ipa-replica-install --setup-dns caless ipa-replica-install && ipa-dns-install These are basic tests, other specialized test like "install KRA first on replica then on master" should be in separate test suite IMO I'm not sure if caless install test should be covered in basic install tests. Same for DNSSEC master (this is fuly covered in dnssec tests) From mbasti at redhat.com Fri Nov 27 16:02:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Nov 2015 17:02:26 +0100 Subject: [Freeipa-devel] [PATCH 0364] ipa-kra-install: allow first KRA to be installed on replica Message-ID: <56587E92.7060008@redhat.com> https://fedorahosted.org/freeipa/ticket/5460 I tested just master, I will test ipa-4-2 later. patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0364-ipa-kra-install-allow-to-install-first-KRA-on-replic.patch Type: text/x-patch Size: 2071 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 27 16:04:27 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 Nov 2015 17:04:27 +0100 Subject: [Freeipa-devel] [PATCH 0387] custodia: Make sure container is created with first custodia In-Reply-To: <565875D7.5050102@redhat.com> References: <565875D7.5050102@redhat.com> Message-ID: <56587F0B.7010002@redhat.com> On 11/27/2015 04:25 PM, Tomas Babej wrote: > Hi, > > If a first 4.3+ replica is installed in the domain, the custodia > container does not exist. Make sure it is created to avoid failures > during key generation. > > https://fedorahosted.org/freeipa/ticket/5474 > > > The patch works as advertised, but I'm not sure about the usage of LDAPUpdater outside, well, updates. CC'ing local update guru for advice. -- Martin^3 Babinsky From tbabej at redhat.com Fri Nov 27 16:13:14 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 27 Nov 2015 17:13:14 +0100 Subject: [Freeipa-devel] [PATCH 0387] custodia: Make sure container is created with first custodia In-Reply-To: <56587F0B.7010002@redhat.com> References: <565875D7.5050102@redhat.com> <56587F0B.7010002@redhat.com> Message-ID: <5658811A.9080503@redhat.com> On 11/27/2015 05:04 PM, Martin Babinsky wrote: > On 11/27/2015 04:25 PM, Tomas Babej wrote: >> Hi, >> >> If a first 4.3+ replica is installed in the domain, the custodia >> container does not exist. Make sure it is created to avoid failures >> during key generation. >> >> https://fedorahosted.org/freeipa/ticket/5474 >> >> >> > > The patch works as advertised, but I'm not sure about the usage of > LDAPUpdater outside, well, updates. CC'ing local update guru for advice. > I'd say it's a regular pattern in the installer code, see precedences in: ipaserver/install/cainstance.py:594 ipaserver/install/dsinstance.py:679 ipaserver/install/krainstance.py:326 Tomas From mbabinsk at redhat.com Fri Nov 27 16:26:53 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 27 Nov 2015 17:26:53 +0100 Subject: [Freeipa-devel] [PATCH 0387] custodia: Make sure container is created with first custodia In-Reply-To: <5658811A.9080503@redhat.com> References: <565875D7.5050102@redhat.com> <56587F0B.7010002@redhat.com> <5658811A.9080503@redhat.com> Message-ID: <5658844D.1000808@redhat.com> On 11/27/2015 05:13 PM, Tomas Babej wrote: > > > On 11/27/2015 05:04 PM, Martin Babinsky wrote: >> On 11/27/2015 04:25 PM, Tomas Babej wrote: >>> Hi, >>> >>> If a first 4.3+ replica is installed in the domain, the custodia >>> container does not exist. Make sure it is created to avoid failures >>> during key generation. >>> >>> https://fedorahosted.org/freeipa/ticket/5474 >>> >>> >>> >> >> The patch works as advertised, but I'm not sure about the usage of >> LDAPUpdater outside, well, updates. CC'ing local update guru for advice. >> > > I'd say it's a regular pattern in the installer code, see precedences in: > > ipaserver/install/cainstance.py:594 > ipaserver/install/dsinstance.py:679 > ipaserver/install/krainstance.py:326 > > Tomas > In that case I think it's okay. ACK. -- Martin^3 Babinsky From jcholast at redhat.com Mon Nov 30 07:19:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Nov 2015 08:19:10 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <56542AC5.4020804@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> <564C7C74.3030607@redhat.com> <564DBBD5.6040805@redhat.com> <564DCA0E.40304@redhat.com> <564DCAFB.3050602@redhat.com> <564ED304.4020000@redhat.com> <56542AC5.4020804@redhat.com> Message-ID: <565BF86E.5050409@redhat.com> On 24.11.2015 10:15, Martin Basti wrote: > > > On 20.11.2015 09:00, Jan Cholasta wrote: >> On 19.11.2015 14:13, Jan Cholasta wrote: >>> On 19.11.2015 14:09, Martin Babinsky wrote: >>>> On 11/19/2015 01:08 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 18.11.2015 14:26, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 18.11.2015 14:24, Martin Kosek wrote: >>>>>>> On 11/18/2015 02:18 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> On 18.11.2015 13:55, Martin Kosek wrote: >>>>>>>>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>>>>>>>> + DEFAULT_TIME_LIMIT = -1.0 >>>>>>>>>> + DEFAULT_SIZE_LIMIT = 0 >>>>>>>>> ... >>>>>>>>>> if time_limit is None or time_limit == 0: >>>>>>>>>> - time_limit = -1.0 >>>>>>>>>> + if self.time_limit is not None and self.time_limit >>>>>>>>>> != 0: >>>>>>>>>> + time_limit = self.time_limit >>>>>>>>>> + else: >>>>>>>>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>>>>>>>> + >>>>>>>>> I wonder why is the -1 default time limit a float number, I would >>>>>>>>> expect that >>>>>>>>> some trouble may emerge out of it. Maybe Rob knows? >>>>>>>>> >>>>>>>> Python LDAP allows to have smaller granularity than seconds and it >>>>>>>> internally >>>>>>>> convert time limit values to float. >>>>>>> Hm, ok. I was just curious since the value we expose in API is Int >>>>>>> and the >>>>>>> default does not use the smaller granularity, so I was thinking "Why >>>>>>> bother?". >>>>>>> If it is fixed in your patch, good. If not, good also, no need to >>>>>>> bikeshed here >>>>>>> I suppose. >>>>>> I just keep the original values there, I do not want to touch it with >>>>>> this patch >>>>>> >>>>> Updated patch attached, the original one has wrong default limit for >>>>> ldap2 >>>>> >>>>> >>>> ACK >>> >>> Hold your horses. >> >> 1) The upgrade_ldapsearch_limit option is not very useful, either add >> generic search_time_limit and search_records_limit options, or don't >> add any options at all (which, incidentally, is exactly what the >> ticket asks for). >> >> 2) The limits are not passed to the connection using __init__() >> anywhere, so there is no need to have arguments for them. >> >> 3) Rather than adding layers of if statements everywhere, implement >> the time_limit and size_limit attributes as properties. >> >> 4) Use config_entry.single_value when setting defaults in >> ldap2.get_ipa_config(). >> >> BTW, add comments only when it's not obvious what the code does - a >> comment saying "set defaults" above two .setdefault() calls is pretty >> redundant. >> > Updated patch attached In ldap2.create_connection(), you should set self.time_limit only if time_limit is not None, ditto for size limit, instead of handling None in the properties' setters. You don't need to handle the limits in ldap2.find_entries() anymore, since it is handled by LDAPClient.find_entries(), so you can remove the related code completely from ldap2.find_entries(). -- Jan Cholasta From jcholast at redhat.com Mon Nov 30 07:59:57 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Nov 2015 08:59:57 +0100 Subject: [Freeipa-devel] [PATCH] 0748 Handle encoding for ipautil.run In-Reply-To: <5655CA08.8090701@redhat.com> References: <5638B8F9.6010703@redhat.com> <564D0FD9.4070505@redhat.com> <5652B5AC.2040508@redhat.com> <5652E174.50301@redhat.com> <56548E73.1090105@redhat.com> <565587AE.2070303@redhat.com> <5655CA08.8090701@redhat.com> Message-ID: <565C01FD.7050906@redhat.com> On 25.11.2015 15:47, Petr Viktorin wrote: > On 11/25/2015 11:04 AM, Jan Cholasta wrote: >> On 24.11.2015 17:21, Petr Viktorin wrote: >>> On 11/23/2015 10:50 AM, Jan Cholasta wrote: >>>> On 23.11.2015 07:43, Jan Cholasta wrote: >>>>> On 19.11.2015 00:55, Petr Viktorin wrote: >>>>>> On 11/03/2015 02:39 PM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> Python 3's strings are Unicode, so data coming to or leaving a Python >>>>>>> program needs to be decoded/encoded if it's to be handled as a >>>>>>> string. >>>>>>> One of the boundaries where encoding is necessary is external >>>>>>> programs, >>>>>>> specifically, ipautil.run. >>>>>>> Unfortunately there's no one set of options that would work for all >>>>>>> run() invocations, so I went through them all and specified the >>>>>>> stdin/stdout/stderr encoding where necessary. I've also updated the >>>>>>> call >>>>>>> sites to make it clearer if the return values are used or not. >>>>>>> If an encoding is not set, run() will accept/return bytes. (This is a >>>>>>> fail-safe setting, since it can't raise errors, and using bytes where >>>>>>> strings are expected generally fails loudly in py3.) >>>>>>> >>>>>>> Note that the changes are not effective under Python 2. >>>>>> >>>>>> ping, >>>>>> Could someone look at this patch? >>>>> >>>>> Looking. >>>> >>>> 1) I think a better approach would be to use str for stdin/stdout/stderr >>>> by default in both Python 2 and 3, i.e. do nothing in Python 2 and >>>> encode/decode using locale.getpreferredencoding() in Python 3. This is >>>> consistent with sys.std{in,out,err} in both Python 2 and 3. Using bytes >>>> or different encoding should be opt-in. >>>> >>>> Note that different encoding should be used only if the LC_ALL or LANG >>>> variables are overriden in the command's environment. >>> >>> That would assume the output of *everything* run via ipautil.run can be >>> decoded using the locale encoding. Any stray invalid byte would make IPA >>> crash, even in cases where we don't care about the output. IPA calls too >>> many weird tools to assume they all output text. >> >> Such a stray invalid byte may bubble through our code and cause havoc >> somewhere else, which is much harder to troubleshoot than a crash in >> ipautil.run(), where you can see that it was a misbehaving command that >> caused the crash and exactly what command it was. > > The invalid byte can't bubble through code, because if you don't specify > an encoding you get bytes back. You'll get a crash when you try using it > as a string. Invalid bytes *can* bubble through our code, into configuration files and other external places. The fact that it has not caused much grief so far suggests that it should be safe to use the locale encoding for most commands. If we do subscribe to the statement that any command can output invalid bytes at any time, I don't see a point in handling encoding in ipautil.run() at all - just always return bytes and let the caller worry about encoding and handling related errors. > > locale.getpreferredencoding() is not used consistently in all software, > especially if it's not written in Python. For instance, wget won't > magically re-encode the data it fetches for us. It's better to > explicitly specify the encoding every time. I would say it is used consistently in most software used by IPA. The wget example is obviously not relevant to this discussion, since it's returning external data. IMO setting the encoding to 'ascii' without also setting LC_ALL=C in the environment, as seen frequently in your patch, has even higher probability of breaking something than using the locale encoding. > >> If we don't care about output somewhere, we should not capture it there >> at all. > > Then people need to remember to put "capture_output=True" everywhere > (except that also disables logging of the output, so we'd need an > additional option). capture_output=True is the default and capture_output=False should be set where output is not needed. IMO the output should always be logged if possible, regardless of capture_output value. -- Jan Cholasta From jcholast at redhat.com Mon Nov 30 08:25:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Nov 2015 09:25:42 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <56570AEF.7040607@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> <56547AB1.5030405@redhat.com> <56556AC2.1090302@redhat.com> <5656FC28.6000009@redhat.com> <56570AEF.7040607@redhat.com> Message-ID: <565C0806.5090103@redhat.com> On 26.11.2015 14:36, Tomas Babej wrote: > > > On 11/26/2015 01:33 PM, Jan Cholasta wrote: >> On 25.11.2015 09:01, Jan Cholasta wrote: >>> On 24.11.2015 15:56, Tomas Babej wrote: >>>> >>>> >>>> On 11/23/2015 04:43 PM, Jan Cholasta wrote: >>>>> 3) >>>>> >>>>> + host_name = Knob( >>>>> + str, None, >>>>> + description="fully qualified name of this host", >>>>> + cli_name='hostname', >>>>> + ) >>>>> >>>>> This knob is already defined in BaseServer, there's no need to redefine >>>>> it here (just remove the "host_name = None"). >>>>> >>>>> If you want to change the description, change it in BaseServer. >>>> >>>> Yep, that was the reasoning here. Changed in BaseServer. You can remove the duplicate knob from Replica, since it is inherited from BaseServer. >>>>> 5) The replica file argument conflicts with the --realm, --domain, >>>>> --server, --admin-password and --principal options. This should be >>>>> checked in Replica.__init__(). >>>>> >>>>> The --hostname option should either be conflicting as well or be >>>>> implemented properly for legacy replica install. >>>>> >>>> >>>> All of them now conflict --replica-file. >>> >>> Replica file is not an option but rather an argument in >>> ipa-replica-install. >>> >>> I think the error message should use the same wording which is used for >>> --forwarder vs. --no-forwarder and --reverse-zone vs. --no-reverse: "You >>> cannot specify a --something option together with replica file". Nitpick: the namedtuple seems like an overkill, given it's only used in a single place. (But I'm fine with keeping it.) >>> >>>> >>>>> >>>>> 6) I think --admin-password should be renamed to --password and the >>>>> description changed, since it now also allows OTP enrollment. >>>>> >>>> >>>> I changed the requirements to mandate --principal when --password is >>>> used, as we discussed. >>> >>> I was wrong here, sorry. >>> >>> ipa-replica-install assumes "admin" for principal by default, so we just >>> need to make sure ipa-client-install is called with --principal when >>> password is used, whether it's the provided principal or the default >>> "admin". ipa-replica-install assumes "admin", but it's not the default value of --principal, so it may be None here: + if installer.admin_password: + args.extend(["--password", installer.admin_password]) + args.extend(["--principal", installer.principal]) This should be removed: + # Make sure --password is not used without principal, + # that would mean OTP join for ipa-client-install + + password_and_principal = [self.admin_password, self.principal] + if any(password_and_principal) and not all(password_and_principal): + raise RuntimeError( + "The --password and --principal options must be used " + "together." + ) -- Jan Cholasta From jcholast at redhat.com Mon Nov 30 08:59:31 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Nov 2015 09:59:31 +0100 Subject: [Freeipa-devel] [PATCH] 0749 Package ipapython, ipalib, ipaplatform, ipatests for Python 3 In-Reply-To: <5658508D.1020105@redhat.com> References: <563C9810.1050604@redhat.com> <5656E487.8050703@redhat.com> <5658508D.1020105@redhat.com> Message-ID: <565C0FF3.8040406@redhat.com> On 27.11.2015 13:46, Petr Viktorin wrote: > On 11/26/2015 11:52 AM, Jan Cholasta wrote: >> 1) The freeipa-common subpackage is not necessary: /etc/ipa/dnssec >> should be owned by freeipa-server and everything else in /etc/ipa >> currently owned by freeipa-python should be owned by freeipa-client. > > If the common files are in freeipa-server or freeipa-client, then the > Python 3 packages would need to depend on those. I'd like to avoid that. I'm not sure I follow. The files do not belong to freeipa-python, since they are used only by freeipa-server and freeipa-client. What Python 3 packages would need to depend on them? > > >> This should be a separate patch. I have prepared one, see attachment. >> >> >> 2) IMO this patch does too much, it should only add the Python 3 >> equivalent of freeipa-python - python3-ipalib - but none of the other >> packages/provides. > > My reasoning for the new packages: > - python3-ipalib is the main point Right. > - freeipa-common contains files that both the py2 and py3 versions need See above. > - python-ipap11helper has compiled code: with this pulled out, > python3-ipalib can be noarch This is not the goal here, but if you insist on doing it, do it for Python 2 as well. > - python3-ipatests is needed if we want to start testing the py3 > packages in CI Right. > > As for new provides, Fedora's Python packaging guidelines say: > > """ > Using a fictional module named "example", the subpackage containing > the python2 version must provide python2-example. This is of course > always the case if the subpackage is named python2-example [...] > If the subpackage has some other name then then Provides: python2-example > must be added explicitly (but see the %python_provide macro below). > > The python3 subpackage must provide python3-example. However, as the > naming guidelines mandate that the python3 subpackage be named > python3-example, this will happen automatically. > """ > > so I'm now adding Provides for the top-level modules. The goal of this work is to add support for Python 3, not to comply with Fedora packaging guidelines. FreeIPA on Fedora uses its own spec file anyway. Again, if you insist on doing this, do it for Python 2 as well. > >> 3) Speaking of freeipa-python, it should be renamed to python-ipalib, >> for consistency. >> >> This should also be a separate patch, again see attachment. > > I think that would just be unnecessary churn. Python 3 gives us a chance > for a fresh start, so I'm taking advantage of that, but renaming > existing packages is a pain. Something similar was done in SSSD not long ago and according to Luk?? (CCd), it was no pain. > > With the right Provides, "dnf install python-ipalib" (or python2-ipalib) > will do the right thing, and I thing that's enough. I don't think that's good enough, since it creates an inconsistency. > >> 4) There should be a python3-devel (and also other python3- equivalents >> of python- packages) BuildRequires when Python 3 support is enabled. > > I did miss that somehow. Thanks for checking. > I added python3-devel; the others are unnecessary because pylint is not > currently run on the Python3 version. OK, I think that will do for now. Note that many of them are required for makeapi and makeaci as well. When can we expect a Python 3 pylint patch which adds the remaining BuildRequires? -- Jan Cholasta From tbabej at redhat.com Mon Nov 30 10:55:51 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 30 Nov 2015 11:55:51 +0100 Subject: [Freeipa-devel] [PATCH 0387] custodia: Make sure container is created with first custodia In-Reply-To: <5658844D.1000808@redhat.com> References: <565875D7.5050102@redhat.com> <56587F0B.7010002@redhat.com> <5658811A.9080503@redhat.com> <5658844D.1000808@redhat.com> Message-ID: <565C2B37.3020707@redhat.com> On 11/27/2015 05:26 PM, Martin Babinsky wrote: > On 11/27/2015 05:13 PM, Tomas Babej wrote: >> >> >> On 11/27/2015 05:04 PM, Martin Babinsky wrote: >>> On 11/27/2015 04:25 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> If a first 4.3+ replica is installed in the domain, the custodia >>>> container does not exist. Make sure it is created to avoid failures >>>> during key generation. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5474 >>>> >>>> >>>> >>> >>> The patch works as advertised, but I'm not sure about the usage of >>> LDAPUpdater outside, well, updates. CC'ing local update guru for advice. >>> >> >> I'd say it's a regular pattern in the installer code, see precedences in: >> >> ipaserver/install/cainstance.py:594 >> ipaserver/install/dsinstance.py:679 >> ipaserver/install/krainstance.py:326 >> >> Tomas >> > > In that case I think it's okay. ACK. > Pushed to master: 79f32a6dc41f7058488f97c2fe7d5b087d003174 From jcholast at redhat.com Mon Nov 30 11:15:26 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Nov 2015 12:15:26 +0100 Subject: [Freeipa-devel] [PATCH] 927 topology: treat server suffix as multivalued attribute in API In-Reply-To: <56586F56.8020407@redhat.com> References: <564F34A5.60208@redhat.com> <56585FA4.3020205@redhat.com> <56586F56.8020407@redhat.com> Message-ID: <565C2FCE.7030905@redhat.com> On 27.11.2015 15:57, Petr Vobornik wrote: > On 11/27/2015 02:50 PM, Martin Babinsky wrote: >> On 11/20/2015 03:56 PM, Petr Vobornik wrote: >>> >>> >>> >> ACK >> > Pushed to master: c688954c27c219cb18aff968fc1f510afff93981 As we discussed offline, the server plugin should use topologysuffix name instead of the actual suffix DN for iparepltopomanagedsuffix. The attached patch fixes that. Also the correct plural form of "suffix" is "suffixes", not "suffices" (), I have fixed that in an additional patch. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-518-server-use-topologysuffix-name-in-iparepltopomanaged.patch Type: text/x-patch Size: 8108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-519-topology-replace-suffices-with-suffixes.patch Type: text/x-patch Size: 1408 bytes Desc: not available URL: From tbabej at redhat.com Mon Nov 30 11:25:42 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 30 Nov 2015 12:25:42 +0100 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <565C0806.5090103@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> <56547AB1.5030405@redhat.com> <56556AC2.1090302@redhat.com> <5656FC28.6000009@redhat.com> <56570AEF.7040607@redhat.com> <565C0806.5090103@redhat.com> Message-ID: <565C3236.5010703@redhat.com> On 11/30/2015 09:25 AM, Jan Cholasta wrote: > On 26.11.2015 14:36, Tomas Babej wrote: >> >> >> On 11/26/2015 01:33 PM, Jan Cholasta wrote: >>> On 25.11.2015 09:01, Jan Cholasta wrote: >>>> On 24.11.2015 15:56, Tomas Babej wrote: >>>>> >>>>> >>>>> On 11/23/2015 04:43 PM, Jan Cholasta wrote: >>>>>> 3) >>>>>> >>>>>> + host_name = Knob( >>>>>> + str, None, >>>>>> + description="fully qualified name of this host", >>>>>> + cli_name='hostname', >>>>>> + ) >>>>>> >>>>>> This knob is already defined in BaseServer, there's no need to >>>>>> redefine >>>>>> it here (just remove the "host_name = None"). >>>>>> >>>>>> If you want to change the description, change it in BaseServer. >>>>> >>>>> Yep, that was the reasoning here. Changed in BaseServer. > > You can remove the duplicate knob from Replica, since it is inherited > from BaseServer. > Yeah, this is mine brainfart. Removed. >>>>>> 5) The replica file argument conflicts with the --realm, --domain, >>>>>> --server, --admin-password and --principal options. This should be >>>>>> checked in Replica.__init__(). >>>>>> >>>>>> The --hostname option should either be conflicting as well or be >>>>>> implemented properly for legacy replica install. >>>>>> >>>>> >>>>> All of them now conflict --replica-file. >>>> >>>> Replica file is not an option but rather an argument in >>>> ipa-replica-install. >>>> >>>> I think the error message should use the same wording which is used for >>>> --forwarder vs. --no-forwarder and --reverse-zone vs. --no-reverse: >>>> "You >>>> cannot specify a --something option together with replica file". > > Nitpick: the namedtuple seems like an overkill, given it's only used in > a single place. (But I'm fine with keeping it.) > This is just to improve the readability (by a small bit). >>>> >>>>> >>>>>> >>>>>> 6) I think --admin-password should be renamed to --password and the >>>>>> description changed, since it now also allows OTP enrollment. >>>>>> >>>>> >>>>> I changed the requirements to mandate --principal when --password is >>>>> used, as we discussed. >>>> >>>> I was wrong here, sorry. >>>> >>>> ipa-replica-install assumes "admin" for principal by default, so we >>>> just >>>> need to make sure ipa-client-install is called with --principal when >>>> password is used, whether it's the provided principal or the default >>>> "admin". > > ipa-replica-install assumes "admin", but it's not the default value of > --principal, so it may be None here: > > + if installer.admin_password: > + args.extend(["--password", installer.admin_password]) > + args.extend(["--principal", installer.principal]) > > > This should be removed: > > + # Make sure --password is not used without principal, > + # that would mean OTP join for ipa-client-install > + > + password_and_principal = [self.admin_password, self.principal] > + if any(password_and_principal) and not > all(password_and_principal): > + raise RuntimeError( > + "The --password and --principal options must be used " > + "together." > + ) > Same here, fixed. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0385-5-replicainstall-Add-possiblity-to-install-client-in-o.patch Type: text/x-patch Size: 6681 bytes Desc: not available URL: From tbabej at redhat.com Mon Nov 30 11:27:15 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 30 Nov 2015 12:27:15 +0100 Subject: [Freeipa-devel] [PATCH] 924 use starttls in CSReplicationManager connection again In-Reply-To: <1448637527.3747.17.camel@redhat.com> References: <562A2A96.1080101@redhat.com> <562A4AED.8090801@redhat.com> <56585FE1.6020505@redhat.com> <1448637527.3747.17.camel@redhat.com> Message-ID: <565C3293.5070605@redhat.com> On 11/27/2015 04:18 PM, Simo Sorce wrote: > On Fri, 2015-11-27 at 14:51 +0100, Petr Vobornik wrote: >> On 10/23/2015 04:57 PM, Simo Sorce wrote: >>> On 23/10/15 08:39, Petr Vobornik wrote: >>>> not sure if the change in2606f5aecd6ac0db31abb515b691529bb7eaf14e was a >>>> mistake or done on purpose. >>>> >>>> Anyway: >>>> commit 2606f5aecd6ac0db31abb515b691529bb7eaf14e >>>> >>>> has: >>>> - realm, hostname, dirman_passwd, port, starttls=True) >>>> + realm, hostname, dirman_passwd, port) >>>> >>>> In CSReplicationManager >>>> >>>> which causes, e.g.: >>>> >>>> ipa-csreplica-manage -p Secret123 list ipa.example.com >>>> cannot connect to 'ldaps://ipa.example.com:389': TLS error >>>> -5938:Encountered end of file >>>> >>>> Attached patch reverts it. >>> >>> I am not sure it was a mistake, we have changed replication from using >>> TLS to always use LDAP+GSSAPI, so why is ipa-csreplica-manage depending >>> on ldaps anyway ? >>> >>> It may need to when dealing with very old domains where we have split >>> instances for CS and IPA, but not in anything modern. I would rather >>> change the command to cope with using LDAP+GSSAPI. >>> >>> A simple revert may break something in replica promotion, would need to >>> be tested with a full master+replica install. >> >> I had this patch applied in branch while developing Topology graph - >> promotion of several replicas worked. Replica promotion uses new >> CAReplicationManager - not CSReplicationManager so it shouldn't be >> affected. CSReplicationManager is used only in >> get_cs_replication_manager call. This call is used only in >> ipa-csreplica-manage and ipa_restore.py. >> >> Without this patch the related functionality in both >> ipa-csreplica-manage and ipa_restore.py (see >> https://fedorahosted.org/freeipa/ticket/5479#comment:2 ) doesn't work. >> >> I don't think that changing ipa-csreplica-manage is worth the effort >> given that we want to deprecate the tool. >> >> Therefore I propose to go with this patch. > > OK then, go ahead. > > Simo. > ACK, patch works fine. Pushed to master: 7b976c664d5b961d5297f235197e9124ce66d5ff From jcholast at redhat.com Mon Nov 30 11:31:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Nov 2015 12:31:37 +0100 Subject: [Freeipa-devel] [PATCH 0098-0099] domain level 1 topology checks during IPA server uninstall In-Reply-To: <56586187.5090402@redhat.com> References: <564E04BE.1020304@redhat.com> <56586187.5090402@redhat.com> Message-ID: <565C3399.5030109@redhat.com> Hi, On 27.11.2015 14:58, Martin Babinsky wrote: > On 11/19/2015 06:19 PM, Martin Babinsky wrote: >> These two patches fix the following tickets: >> >> https://fedorahosted.org/freeipa/ticket/5377 >> https://fedorahosted.org/freeipa/ticket/5409 >> >> I have added a new option '--ignore-disconnected-topology' which forces >> IPA master uninstall despite reported errors in topology. I'm not quite >> sure if we want to flood ipa-server-install with uninstall-specific >> options, maybe it is better to skip the check in unattended mode and >> just print a warning about disconnected topology and what to do about it. >> >> I would like to hear your opinions about this. >> >> >> > Attaching rebased and updated patches. Patch 0098: LGTM Patch 0099: a) This check should be done in Server.__init__() rather than install_check(): + if options.ignore_disconnected_topology: + print("'--ignore-disconnected-topology' is used only during " + "uninstallation") + sys.exit(1) b) s/--ignore-disconnected-topology/--ignore-topology-disconnect/, for consistency with other options, e.g. --no-ui-redirect. Maybe even shorten it to --ignore-topology? But we probably don't want people to use this option much, so it might be better to keep it long? c) I'm fine with uninstall options, you can remove the TODO: + # TODO: ask jcholast about uninstallation options Honza -- Jan Cholasta From pvoborni at redhat.com Mon Nov 30 11:38:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Nov 2015 12:38:26 +0100 Subject: [Freeipa-devel] [PATCH] 927 topology: treat server suffix as multivalued attribute in API In-Reply-To: <565C2FCE.7030905@redhat.com> References: <564F34A5.60208@redhat.com> <56585FA4.3020205@redhat.com> <56586F56.8020407@redhat.com> <565C2FCE.7030905@redhat.com> Message-ID: <565C3532.7050405@redhat.com> On 11/30/2015 12:15 PM, Jan Cholasta wrote: > On 27.11.2015 15:57, Petr Vobornik wrote: >> On 11/27/2015 02:50 PM, Martin Babinsky wrote: >>> On 11/20/2015 03:56 PM, Petr Vobornik wrote: >>>> >>>> >>>> >>> ACK >>> >> Pushed to master: c688954c27c219cb18aff968fc1f510afff93981 > > As we discussed offline, the server plugin should use topologysuffix > name instead of the actual suffix DN for iparepltopomanagedsuffix. The > attached patch fixes that. > Also the correct plural form of "suffix" is "suffixes", not "suffices" > (), I have fixed that in an > additional patch. > Wrt 519 - we may want to fix it on all places. See the attached wip patch (coincidentally made on Friday). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0768-change-suffices-to-suffixes.patch Type: text/x-patch Size: 11840 bytes Desc: not available URL: From pvoborni at redhat.com Mon Nov 30 11:41:33 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Nov 2015 12:41:33 +0100 Subject: [Freeipa-devel] [PATCH] 938 rename topology suffixes to "domain" and "ca" Message-ID: <565C35ED.6090701@redhat.com> see https://www.redhat.com/archives/freeipa-devel/2015-November/msg00485.html -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0938-rename-topology-suffixes-to-domain-and-ca.patch Type: text/x-patch Size: 8429 bytes Desc: not available URL: From pvoborni at redhat.com Mon Nov 30 11:45:48 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Nov 2015 12:45:48 +0100 Subject: [Freeipa-devel] [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion In-Reply-To: <56570BA8.6080002@redhat.com> References: <56535233.1020207@redhat.com> <56570BA8.6080002@redhat.com> Message-ID: <565C36EC.6010904@redhat.com> On 11/26/2015 02:39 PM, Petr Vobornik wrote: > On 11/23/2015 06:51 PM, Oleg Fayans wrote: >> Hi all, >> >> Here is a draft of the Replica Promotion test plan >> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >> >> > > == Test case: Unprivileged users are not allowed to enroll and promote > clients == > User credentials are passed there through -p $principal and -w $password > options. It is correct atm because it is required for connection check. > But end goal of replica promotion is the avoid it. See > https://fedorahosted.org/freeipa/ticket/5497 and > https://fedorahosted.org/freeipa/ticket/5498 for more information. > > == Missing test cases == > 1. ipa-replica-install works on CA-less master with with both domain levels > 2. ipa-server-install works with --setup-dns option with both domain levels > 3. ipa-server-install works with externally signed CA cert with both > domain levels > 4. ipa-replica-install with options(and their combination): --setup-ca > --setup-dns --setup-kra works with both domain levels > > Note: Not sure if #2 and #3 belongs here, but should be tested. Maybe > tests for domain level 0 already exist. One more thing: test plans covers only the domain topology suffix(currently 'realm', will be renamed'[1]) and its segments. Segments for 'ca' topology suffix needs to be tested as well, or in other words that CA replication agreements are also managed. Maybe it fits more into: http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan [1] https://www.redhat.com/archives/freeipa-devel/2015-November/msg00485.html -- Petr Vobornik From tbabej at redhat.com Mon Nov 30 12:09:19 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 30 Nov 2015 13:09:19 +0100 Subject: [Freeipa-devel] [PATCH 0388] tests: Add hostmask detection for sudo rules validating Message-ID: <565C3C6F.4040901@redhat.com> Hi, IPA sudo tests worked under the assumption that the clients that are executing the sudo commands have their IPs assigned within 255.255.255.0 hostmask. Removes this (invalid) assumption and adds a dynamic detection of the hostmask of the IPA client. https://fedorahosted.org/freeipa/ticket/5501 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0388-tests-Add-hostmask-detection-for-sudo-rules-validati.patch Type: text/x-patch Size: 2671 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 30 13:15:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 14:15:19 +0100 Subject: [Freeipa-devel] [PATCH 0350] raise time limit for ldapsearch in upgrade In-Reply-To: <565BF86E.5050409@redhat.com> References: <564C6F7E.1060803@redhat.com> <564C7529.8090909@redhat.com> <564C7A9B.6060107@redhat.com> <564C7C26.5000107@redhat.com> <564C7C74.3030607@redhat.com> <564DBBD5.6040805@redhat.com> <564DCA0E.40304@redhat.com> <564DCAFB.3050602@redhat.com> <564ED304.4020000@redhat.com> <56542AC5.4020804@redhat.com> <565BF86E.5050409@redhat.com> Message-ID: <565C4BE7.5090201@redhat.com> On 30.11.2015 08:19, Jan Cholasta wrote: > On 24.11.2015 10:15, Martin Basti wrote: >> >> >> On 20.11.2015 09:00, Jan Cholasta wrote: >>> On 19.11.2015 14:13, Jan Cholasta wrote: >>>> On 19.11.2015 14:09, Martin Babinsky wrote: >>>>> On 11/19/2015 01:08 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 18.11.2015 14:26, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 18.11.2015 14:24, Martin Kosek wrote: >>>>>>>> On 11/18/2015 02:18 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 18.11.2015 13:55, Martin Kosek wrote: >>>>>>>>>> On 11/18/2015 01:30 PM, Martin Basti wrote: >>>>>>>>>>> + DEFAULT_TIME_LIMIT = -1.0 >>>>>>>>>>> + DEFAULT_SIZE_LIMIT = 0 >>>>>>>>>> ... >>>>>>>>>>> if time_limit is None or time_limit == 0: >>>>>>>>>>> - time_limit = -1.0 >>>>>>>>>>> + if self.time_limit is not None and self.time_limit >>>>>>>>>>> != 0: >>>>>>>>>>> + time_limit = self.time_limit >>>>>>>>>>> + else: >>>>>>>>>>> + time_limit = self.DEFAULT_TIME_LIMIT >>>>>>>>>>> + >>>>>>>>>> I wonder why is the -1 default time limit a float number, I >>>>>>>>>> would >>>>>>>>>> expect that >>>>>>>>>> some trouble may emerge out of it. Maybe Rob knows? >>>>>>>>>> >>>>>>>>> Python LDAP allows to have smaller granularity than seconds >>>>>>>>> and it >>>>>>>>> internally >>>>>>>>> convert time limit values to float. >>>>>>>> Hm, ok. I was just curious since the value we expose in API is Int >>>>>>>> and the >>>>>>>> default does not use the smaller granularity, so I was thinking >>>>>>>> "Why >>>>>>>> bother?". >>>>>>>> If it is fixed in your patch, good. If not, good also, no need to >>>>>>>> bikeshed here >>>>>>>> I suppose. >>>>>>> I just keep the original values there, I do not want to touch it >>>>>>> with >>>>>>> this patch >>>>>>> >>>>>> Updated patch attached, the original one has wrong default limit for >>>>>> ldap2 >>>>>> >>>>>> >>>>> ACK >>>> >>>> Hold your horses. >>> >>> 1) The upgrade_ldapsearch_limit option is not very useful, either add >>> generic search_time_limit and search_records_limit options, or don't >>> add any options at all (which, incidentally, is exactly what the >>> ticket asks for). >>> >>> 2) The limits are not passed to the connection using __init__() >>> anywhere, so there is no need to have arguments for them. >>> >>> 3) Rather than adding layers of if statements everywhere, implement >>> the time_limit and size_limit attributes as properties. >>> >>> 4) Use config_entry.single_value when setting defaults in >>> ldap2.get_ipa_config(). >>> >>> BTW, add comments only when it's not obvious what the code does - a >>> comment saying "set defaults" above two .setdefault() calls is pretty >>> redundant. >>> >> Updated patch attached > > In ldap2.create_connection(), you should set self.time_limit only if > time_limit is not None, ditto for size limit, instead of handling None > in the properties' setters. > > You don't need to handle the limits in ldap2.find_entries() anymore, > since it is handled by LDAPClient.find_entries(), so you can remove > the related code completely from ldap2.find_entries(). > Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0350.4-Upgrade-increase-time-limit-for-upgrades.patch Type: text/x-patch Size: 7863 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Nov 30 13:16:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 30 Nov 2015 14:16:33 +0100 Subject: [Freeipa-devel] [PATCH 0364] ipa-kra-install: allow first KRA to be installed on replica In-Reply-To: <56587E92.7060008@redhat.com> References: <56587E92.7060008@redhat.com> Message-ID: <565C4C31.4070509@redhat.com> On 11/27/2015 05:02 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5460 > > I tested just master, I will test ipa-4-2 later. > patch attached. > > ACK for the master branch. -- Martin^3 Babinsky From mbasti at redhat.com Mon Nov 30 15:31:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 16:31:08 +0100 Subject: [Freeipa-devel] [PATCH 0365] Remove unused KRA code from ipa-server-install Message-ID: <565C6BBC.4050902@redhat.com> First instance of KRA should be installed only by ipa-kra-install Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0365-Remove-unused-code-in-server-installer-related-to-KR.patch Type: text/x-patch Size: 3108 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Nov 30 15:43:08 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 30 Nov 2015 16:43:08 +0100 Subject: [Freeipa-devel] [PATCH 0098-0099] domain level 1 topology checks during IPA server uninstall In-Reply-To: <565C3399.5030109@redhat.com> References: <564E04BE.1020304@redhat.com> <56586187.5090402@redhat.com> <565C3399.5030109@redhat.com> Message-ID: <565C6E8C.2090900@redhat.com> On 11/30/2015 12:31 PM, Jan Cholasta wrote: > Hi, > > On 27.11.2015 14:58, Martin Babinsky wrote: >> On 11/19/2015 06:19 PM, Martin Babinsky wrote: >>> These two patches fix the following tickets: >>> >>> https://fedorahosted.org/freeipa/ticket/5377 >>> https://fedorahosted.org/freeipa/ticket/5409 >>> >>> I have added a new option '--ignore-disconnected-topology' which forces >>> IPA master uninstall despite reported errors in topology. I'm not quite >>> sure if we want to flood ipa-server-install with uninstall-specific >>> options, maybe it is better to skip the check in unattended mode and >>> just print a warning about disconnected topology and what to do about >>> it. >>> >>> I would like to hear your opinions about this. >>> >>> >>> >> Attaching rebased and updated patches. > > Patch 0098: LGTM > > > Patch 0099: > > a) This check should be done in Server.__init__() rather than > install_check(): > > + if options.ignore_disconnected_topology: > + print("'--ignore-disconnected-topology' is used only during " > + "uninstallation") > + sys.exit(1) > > > b) s/--ignore-disconnected-topology/--ignore-topology-disconnect/, for > consistency with other options, e.g. --no-ui-redirect. > > Maybe even shorten it to --ignore-topology? But we probably don't want > people to use this option much, so it might be better to keep it long? > I would rather leave it with the long option name, it is more apparent what this switch should be around. > > c) I'm fine with uninstall options, you can remove the TODO: > > + # TODO: ask jcholast about uninstallation options > > > Honza > Attaching updated patches. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0099.2-implement-domain-level-1-specific-topology-checks-in.patch Type: text/x-patch Size: 11255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0098.1-extract-domain-level-1-topology-checking-code-from-i.patch Type: text/x-patch Size: 10435 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 30 15:46:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 16:46:13 +0100 Subject: [Freeipa-devel] [PATCH 0366] Fix missing break in ipa_krb_principals.c Message-ID: <565C6F45.1020606@redhat.com> Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0366-FIX-ipa_kdb_principals-add-missing-break-statement.patch Type: text/x-patch Size: 1067 bytes Desc: not available URL: From simo at redhat.com Mon Nov 30 15:56:00 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 10:56:00 -0500 Subject: [Freeipa-devel] [PATCH 0366] Fix missing break in ipa_krb_principals.c In-Reply-To: <565C6F45.1020606@redhat.com> References: <565C6F45.1020606@redhat.com> Message-ID: <1448898960.3747.68.camel@redhat.com> On Mon, 2015-11-30 at 16:46 +0100, Martin Basti wrote: > Patch attached ack -- Simo Sorce * Red Hat, Inc * New York From mkubik at redhat.com Mon Nov 30 16:18:30 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 30 Nov 2015 17:18:30 +0100 Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin In-Reply-To: <20151123164249.4a576706@dhcp-25-21.brq.redhat.com> References: <20151120135636.71171d5c@vor2.netbox.priv> <20151123145934.36901470@dhcp-25-21.brq.redhat.com> <20151123164249.4a576706@dhcp-25-21.brq.redhat.com> Message-ID: <565C76D6.3010406@redhat.com> On 11/23/2015 04:42 PM, Filip ?kola wrote: > Sending updated patch. > > F. > > On Mon, 23 Nov 2015 14:59:34 +0100 > Filip ?kola wrote: > >> Found couple of issues (broke some dependencies). >> >> NACK >> >> F. >> >> On Fri, 20 Nov 2015 13:56:36 +0100 >> Filip ?kola wrote: >> >>> Another one. >>> >>> F. >> > > Hi, the tests look good. Few remarks, though. 1. Please, use the shortes copyright notice in new modules. # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # 2. The tests `test_group_remove_group_from_protected_group` and `test_group_full_set_of_objectclass_not_available_post_detach` were not ported. Please, include them in the patch. Also, for less hassle, please rebase your patches on top of freeipa-mkubik-0025-3-Separated-Tracker-implementations-into-standalone-pa.patch Which changes the location of tracker implementations and prevents circular imports. Thanks. -- Milan Kubik From jcholast at redhat.com Mon Nov 30 16:24:56 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Nov 2015 17:24:56 +0100 Subject: [Freeipa-devel] [PATCH 0069] ipa-replica-install support caless install with promotion. In-Reply-To: <5657FEC2.3080503@redhat.com> References: <565710A8.1020306@redhat.com> <56571376.6020209@redhat.com> <565715BB.9020200@redhat.com> <5657FEC2.3080503@redhat.com> Message-ID: <565C7858.1030702@redhat.com> Hi, On 27.11.2015 07:57, David Kupka wrote: > On 26/11/15 15:22, David Kupka wrote: >> On 26/11/15 15:13, David Kupka wrote: >>> On 26/11/15 15:01, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/5441 >>>> >>>> >>> Replaced accidentally inserted tabs. >>> >>> >>> >> Fixed indentation I screwed up when replacing tabs :-/ 1) The deprecated --*_pkcs12 and --*_pin aliases should not be supported in ipa-replica-install. 2) This check from ipa-replica-prepare should be added to Replica.__init__() as well: # If any of the PKCS#12 options are selected, all are required. cert_file_req = (options.dirsrv_cert_files, options.http_cert_files) cert_file_opt = (options.pkinit_cert_files,) if any(cert_file_req + cert_file_opt) and not all(cert_file_req): self.option_parser.error( "--dirsrv-cert-file and --http-cert-file are required if any " "PKCS#12 options are used.") 3) This check from ipa-replica-prepare should be added below the pkcs12_info initialization block in promote_check(): if (options.http_cert_files and options.dirsrv_cert_files and http_ca_cert != dirsrv_ca_cert): raise admintool.ScriptError( "Apache Server SSL certificate and Directory Server SSL " "certificate are not signed by the same CA certificate") 4) This check should use the same message as ipa-replica-prepare: "Cannot issue certificates: a CA is not installed. Use the --http-cert-file, --dirsrv-cert-file options to provide custom certificates.": + if not options.dirsrv_cert_files: + root_logger.error("The remote master does not have a CA " + "installed, can't proceed without certs") + sys.exit(3) 5) Please use the common "You cannot specify a --option together with replica file" error message here: + if any(self.ca.dirsrv_pkcs12_file, self.ca.http_pkcs12_file, + self.ca.pkinit_pkcs12_file): + raise RuntimeError("You cannot provide certificates together " + "with replica file") 6) Please make the ca_is_enabled argument of install_replica_ds() and install_http() mandatory and fill as appropriate when called, it will make the code more readable. 7) $ git diff -U0 | pep8 --diff ./ipaserver/install/server/replicainstall.py:99:80: E501 line too long (82 > 79 characters) ./ipaserver/install/server/replicainstall.py:161:80: E501 line too long (82 > 79 characters) ./ipaserver/install/server/replicainstall.py:1289:13: E265 block comment should start with '# ' ./ipaserver/install/server/replicainstall.py:1291:17: E125 continuation line with same indent as next logical line ./ipaserver/install/server/replicainstall.py:1291:17: E128 continuation line under-indented for visual indent 8) Nitpicks: s/ca_configured/ca_is_configured/ in install_replica_ds(), for consistency. Set ca_enabled = False in the else branch rather than before the if statement in promote_check(). Put the "#pylint: disable=no-member" in Replica.__init__() in the same spot as it is in Server.__init__(). Honza -- Jan Cholasta From simo at redhat.com Mon Nov 30 16:27:31 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 11:27:31 -0500 Subject: [Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication In-Reply-To: <5656AAEB.1070806@redhat.com> References: <564DE017.4020408@redhat.com> <1447951434.5132.27.camel@redhat.com> <564F4105.1040204@redhat.com> <56557E81.1020202@redhat.com> <1448473562.17462.6.camel@redhat.com> <5656AAEB.1070806@redhat.com> Message-ID: <1448900851.3747.70.camel@redhat.com> On Thu, 2015-11-26 at 07:47 +0100, Jan Cholasta wrote: > On 25.11.2015 18:46, Simo Sorce wrote: > > On Wed, 2015-11-25 at 10:25 +0100, Jan Cholasta wrote: > >> On 20.11.2015 16:49, Jan Cholasta wrote: > >>> On 19.11.2015 17:43, Simo Sorce wrote: > >>>> 510: > >>>> - We should probably tightenup the ACI to allos host X to only add > >>>> memberPrincipal = X and no other value, also the host should not be > >>>> allowed to change the memberPrincipal attribute only the keys. > >>>> If we can't express this in ACIs we can live with the ones you propose > >>>> though. > >>> > >>> I think this can be done. > >> > >> Turns out this can be done only if member (or some other DN attribute) > >> is used instead of memberPrincipal. > >> > >> So, to reiterate: > >> > >>>>> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'? > >>>>> > >>>>> If 'member' was used instead, we would gain referential integrity and > >>>>> the ability to add ACIs based on the attribute (think > >>>>> userattr="member#USERDN"). > >>>> > >>>> To avoid referential integrity and mixup with other group objects, it > >>>> was intentional. > >> > >> Why is referential integrity a problem? > > > > Because it will remove the member if the object it references goes away, > > and I do not want an "orphaned" entry for custodia. > > But without referential integrity you get an orphaned entry too, except > with an extra dangling reference. IMHO that's even worse than "plain" > orhpaned entry, because you can't spot it just by looking at the > attribute value. > > > > >> Mixup with other group objects can be solved by using a different attribute. > > > > There is also the fact in future we may want to use this with "external" > > principals (like in IPA-IPA trusts or similar) so I didn't want to have > > to come up with bogus DNs in that case. > > IIRC Alexander was working on something like exposing external > principals in LDAP using the compat plugin, in order to allow external > users to run IPA commands. We do not want to depend on the compat tree in such a core feature. > Alternatively, it could do what groups do - use DN for internal > references and string (be it principal or something else) for external > references. Same as above. > Anyway, either memberPrincipal is replaced with a member-like attribute, > or the ACI stays as it is. I would prefer a member-like attribute, > because I feel that's the way LDAP entries should reference each other, > but I will leave the decision to you. Let's keep it as it is for now, I'll think more about it. Simo. -- Simo Sorce * Red Hat, Inc * New York From lslebodn at redhat.com Mon Nov 30 16:32:56 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 30 Nov 2015 17:32:56 +0100 Subject: [Freeipa-devel] [PATCH 0388] tests: Add hostmask detection for sudo rules validating In-Reply-To: <565C3C6F.4040901@redhat.com> References: <565C3C6F.4040901@redhat.com> Message-ID: <20151130163256.GA7759@mail.corp.redhat.com> On (30/11/15 13:09), Tomas Babej wrote: >Hi, > >IPA sudo tests worked under the assumption that the clients that >are executing the sudo commands have their IPs assigned within >255.255.255.0 hostmask. > >Removes this (invalid) assumption and adds a dynamic detection of >the hostmask of the IPA client. > >https://fedorahosted.org/freeipa/ticket/5501 >From e6f1846f0d7d17303e5b30b1643651ba739b2b6c Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Mon, 30 Nov 2015 12:53:39 +0100 >Subject: [PATCH] tests: Add hostmask detection for sudo rules validating on > hostmask > >IPA sudo tests worked under the assumption that the clients that >are executing the sudo commands have their IPs assigned within >255.255.255.0 hostmask. > >Removes this (invalid) assumption and adds a dynamic detection of >the hostmask of the IPA client. > >https://fedorahosted.org/freeipa/ticket/5501 >--- > ipatests/test_integration/test_sudo.py | 25 +++++++++++++++++++++++-- > 1 file changed, 23 insertions(+), 2 deletions(-) > >diff --git a/ipatests/test_integration/test_sudo.py b/ipatests/test_integration/test_sudo.py >index 1dd4c5d73c9fa4288af4fc2708aa3abd51407217..d97771dfa1a7fd2938a0be20a1b79814b852b03e 100644 >--- a/ipatests/test_integration/test_sudo.py >+++ b/ipatests/test_integration/test_sudo.py >@@ -17,6 +17,9 @@ > # You should have received a copy of the GNU General Public License > # along with this program. If not, see . > >+import pytest >+import re >+ > from ipatests.test_integration.base import IntegrationTest > from ipatests.test_integration.tasks import clear_sssd_cache > >@@ -269,13 +272,31 @@ class TestSudo(IntegrationTest): > '--hostgroups', 'testhostgroup']) > > def test_sudo_rule_restricted_to_one_hostmask_setup(self): >- # Add the client's /24 hostmask to the rule >+ # Add the client's hostmask to the rule > ip = self.client.ip >+ >+ # We need to detect the hostmask first >+ result = self.client.run_command(['ip', 'addr']) >+ full_ip_regex = r'(?P{0}/\d{0,1}) '.format(re.escape(ip)) >+ match = re.search(full_ip_regex, result) >+ >+ # Make a note for the next test, which needs to be skipped >+ # if hostmask detection failed >+ self.skip_hostmask_based = False >+ >+ if not match: >+ self.skip_hostmask_based = True >+ raise pytest.skip("Hostmask could not be detected") >+ >+ full_ip = match.group('full_ip') > self.master.run_command(['ipa', '-n', 'sudorule-add-host', > 'testrule', >- '--hostmask', '%s/24' % ip]) >+ '--hostmask', full_ip]) > > def test_sudo_rule_restricted_to_one_hostmask(self): >+ if self.skip_hostmask_based: >+ raise pytest.skip("Hostmask could not be detected") >+ > result1 = self.list_sudo_commands("testuser1") > assert "(ALL : ALL) NOPASSWD: ALL" in result1.stdout_text I got following errors with the patch. =================================== FAILURES =================================== ___________ TestSudo.test_sudo_rule_restricted_to_one_hostmask_setup ___________ self = def test_sudo_rule_restricted_to_one_hostmask_setup(self): # Add the client's hostmask to the rule ip = self.client.ip # We need to detect the hostmask first result = self.client.run_command(['ip', 'addr']) > full_ip_regex = r'(?P{0}/\d{0,1}) '.format(re.escape(ip)) E KeyError: '0,1' test_integration/test_sudo.py:280: KeyError ______________ TestSudo.test_sudo_rule_restricted_to_one_hostmask ______________ self = def test_sudo_rule_restricted_to_one_hostmask(self): > if self.skip_hostmask_based: E AttributeError: 'TestSudo' object has no attribute 'skip_hostmask_based' test_integration/test_sudo.py:297: AttributeError ______ TestSudo.test_setting_category_to_all_with_valid_entries_host_mask ______ self = def test_setting_category_to_all_with_valid_entries_host_mask(self): result = self.reset_rule_categories(safe_delete=False) > assert result.returncode != 0 E assert 0 != 0 E + where 0 = .returncode test_integration/test_sudo.py:305: AssertionError ______ TestSudo.test_sudo_rule_restricted_to_one_hostmask_negative_setup _______ self = def test_sudo_rule_restricted_to_one_hostmask_negative_setup(self): # Add the master's hostmask to the rule ip = self.master.ip self.master.run_command(['ipa', '-n', 'sudorule-add-host', 'testrule', > '--hostmask', '%s/32' % ip]) test_integration/test_sudo.py:319: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../pytest_multihost/host.py:222: in run_command command.wait(raiseonerr=raiseonerr) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = raiseonerr = True def wait(self, raiseonerr=True): """Wait for the remote process to exit Raises an excption if the exit code is not 0, unless raiseonerr is true. """ if self._done: return self.returncode self._end_process() self._done = True if raiseonerr and self.returncode: self.log.error('Exit code: %s', self.returncode) > raise subprocess.CalledProcessError(self.returncode, self.argv) E CalledProcessError: Command '['ipa', '-n', 'sudorule-add-host', 'testrule', '--hostmask', '10.16.184.13/32']' returned non-zero exit status 1 ../pytest_multihost/transport.py:159: CalledProcessError _________ TestSudo.test_sudo_rule_restricted_to_one_hostmask_negative __________ self = def test_sudo_rule_restricted_to_one_hostmask_negative(self): result1 = self.list_sudo_commands("testuser1") > assert result1.returncode != 0 E assert 0 != 0 E + where 0 = .returncode test_integration/test_sudo.py:323: AssertionError ==================== 5 failed, 70 passed in 679.39 seconds ===================== LS From mbasti at redhat.com Mon Nov 30 16:34:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 17:34:45 +0100 Subject: [Freeipa-devel] [PATCH 0366] Fix missing break in ipa_krb_principals.c In-Reply-To: <1448898960.3747.68.camel@redhat.com> References: <565C6F45.1020606@redhat.com> <1448898960.3747.68.camel@redhat.com> Message-ID: <565C7AA5.3010900@redhat.com> On 30.11.2015 16:56, Simo Sorce wrote: > On Mon, 2015-11-30 at 16:46 +0100, Martin Basti wrote: >> Patch attached > ack > Pushed to master: 21f7584f9f44fdc3dee0f9d038f31edd8ee1aab2 From amarecek at redhat.com Mon Nov 30 16:50:46 2015 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Mon, 30 Nov 2015 11:50:46 -0500 (EST) Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package In-Reply-To: <56586B5D.2040507@redhat.com> References: <564F31CE.5010402@redhat.com> <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> <5652DFAE.90906@redhat.com> <5658694F.3080404@redhat.com> <56586A7F.3070004@redhat.com> <56586B5D.2040507@redhat.com> Message-ID: <647877470.20906478.1448902246584.JavaMail.zimbra@redhat.com> Tested with today's master, ACK. - alich - ----- Original Message ----- > From: "Milan Kub?k" > To: freeipa-devel at redhat.com > Sent: Friday, November 27, 2015 3:40:29 PM > Subject: Re: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package > > On 11/27/2015 03:36 PM, Milan Kub?k wrote: > > > > On 11/27/2015 03:31 PM, Milan Kub?k wrote: > > > On 11/23/2015 10:43 AM, Lenka Doudova wrote: > > > NACK - there's a "typo" in ..../tracker/user_plugin.py, line 17-18: > > def get_user_dn(cn): > > return DN(('cn', cn), api.env.container_user, api.env.basedn) > > > should be > > def get_user_dn(uid): > > return DN(('uid', uid), api.env.container_user, api.env.basedn) > > > Some tests may fail because of that. > Lenka > > > On 11/20/2015 08:54 PM, Ale? Mare?ek wrote: > > > Looks good. ACK. > > ----- Original Message ----- > > > From: "Milan Kub?k" > To: "freeipa-devel" > Cc: "Filip Skola" , "Ales Marecek" > Sent: Friday, November 20, 2015 3:44:30 PM > Subject: [patch 0025] Separated Tracker implementations into standalone > package > > Fixes https://fedorahosted.org/freeipa/ticket/5467 > Patches attached. > > -- > Milan Kubik > > > > Fixed the function and moved it into different module. > Updated patches attached. > > > > Self nack, some imports missing > > -- > Milan Kubik > > > Patches updated. > > -- > Milan Kubik > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From mbasti at redhat.com Mon Nov 30 17:15:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 18:15:55 +0100 Subject: [Freeipa-devel] [PATCH 0098-0099] domain level 1 topology checks during IPA server uninstall In-Reply-To: <565C6E8C.2090900@redhat.com> References: <564E04BE.1020304@redhat.com> <56586187.5090402@redhat.com> <565C3399.5030109@redhat.com> <565C6E8C.2090900@redhat.com> Message-ID: <565C844B.7050901@redhat.com> On 30.11.2015 16:43, Martin Babinsky wrote: > On 11/30/2015 12:31 PM, Jan Cholasta wrote: >> Hi, >> >> On 27.11.2015 14:58, Martin Babinsky wrote: >>> On 11/19/2015 06:19 PM, Martin Babinsky wrote: >>>> These two patches fix the following tickets: >>>> >>>> https://fedorahosted.org/freeipa/ticket/5377 >>>> https://fedorahosted.org/freeipa/ticket/5409 >>>> >>>> I have added a new option '--ignore-disconnected-topology' which >>>> forces >>>> IPA master uninstall despite reported errors in topology. I'm not >>>> quite >>>> sure if we want to flood ipa-server-install with uninstall-specific >>>> options, maybe it is better to skip the check in unattended mode and >>>> just print a warning about disconnected topology and what to do about >>>> it. >>>> >>>> I would like to hear your opinions about this. >>>> >>>> >>>> >>> Attaching rebased and updated patches. >> >> Patch 0098: LGTM >> >> >> Patch 0099: >> >> a) This check should be done in Server.__init__() rather than >> install_check(): >> >> + if options.ignore_disconnected_topology: >> + print("'--ignore-disconnected-topology' is used only during " >> + "uninstallation") >> + sys.exit(1) >> >> >> b) s/--ignore-disconnected-topology/--ignore-topology-disconnect/, for >> consistency with other options, e.g. --no-ui-redirect. >> >> Maybe even shorten it to --ignore-topology? But we probably don't want >> people to use this option much, so it might be better to keep it long? >> > I would rather leave it with the long option name, it is more apparent > what this switch should be around. >> >> c) I'm fine with uninstall options, you can remove the TODO: >> >> + # TODO: ask jcholast about uninstallation options >> >> >> Honza >> > > Attaching updated patches. > NACK ipa-server-install --uninstall 2015-11-30T17:14:30Z DEBUG Destroyed connection context.ldap2_140081152041808 2015-11-30T17:14:30Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 91, in _handle_exception super(Continuous, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 387, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 439, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 387, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 355, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 352, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 71, in _uninstall for nothing in self._uninstaller(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1409, in main uninstall_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 265, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1140, in uninstall_check api, masters, options.ignore_disconnected_topology) AttributeError: 'uninstaller(Server)' object has no attribute 'ignore_disconnected_topology' 2015-11-30T17:14:30Z ERROR 'uninstaller(Server)' object has no attribute 'ignore_disconnected_topology' 2015-11-30T17:14:30Z INFO The ipa-server-install command was successful From mbasti at redhat.com Mon Nov 30 17:29:31 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 18:29:31 +0100 Subject: [Freeipa-devel] [PATCH 0364, 0367] ipa-kra-install: allow first KRA to be installed on replica In-Reply-To: <565C4C31.4070509@redhat.com> References: <56587E92.7060008@redhat.com> <565C4C31.4070509@redhat.com> Message-ID: <565C877B.3050405@redhat.com> On 30.11.2015 14:16, Martin Babinsky wrote: > On 11/27/2015 05:02 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5460 >> >> I tested just master, I will test ipa-4-2 later. >> patch attached. >> >> > > ACK for the master branch. > Thanks, additional patch improves error message when ipa-replica-install --setup-ca --setup-kra is executed and KRA is not installed anywhere yet. I'm working on patches for ipa-4-2 branch Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0367-Modify-error-message-to-install-first-instance-of-KR.patch Type: text/x-patch Size: 1123 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Nov 30 17:41:43 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 30 Nov 2015 18:41:43 +0100 Subject: [Freeipa-devel] [PATCH 0098-0099] domain level 1 topology checks during IPA server uninstall In-Reply-To: <565C844B.7050901@redhat.com> References: <564E04BE.1020304@redhat.com> <56586187.5090402@redhat.com> <565C3399.5030109@redhat.com> <565C6E8C.2090900@redhat.com> <565C844B.7050901@redhat.com> Message-ID: <565C8A57.2000305@redhat.com> On 11/30/2015 06:15 PM, Martin Basti wrote: > > > On 30.11.2015 16:43, Martin Babinsky wrote: >> On 11/30/2015 12:31 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 27.11.2015 14:58, Martin Babinsky wrote: >>>> On 11/19/2015 06:19 PM, Martin Babinsky wrote: >>>>> These two patches fix the following tickets: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5377 >>>>> https://fedorahosted.org/freeipa/ticket/5409 >>>>> >>>>> I have added a new option '--ignore-disconnected-topology' which >>>>> forces >>>>> IPA master uninstall despite reported errors in topology. I'm not >>>>> quite >>>>> sure if we want to flood ipa-server-install with uninstall-specific >>>>> options, maybe it is better to skip the check in unattended mode and >>>>> just print a warning about disconnected topology and what to do about >>>>> it. >>>>> >>>>> I would like to hear your opinions about this. >>>>> >>>>> >>>>> >>>> Attaching rebased and updated patches. >>> >>> Patch 0098: LGTM >>> >>> >>> Patch 0099: >>> >>> a) This check should be done in Server.__init__() rather than >>> install_check(): >>> >>> + if options.ignore_disconnected_topology: >>> + print("'--ignore-disconnected-topology' is used only during " >>> + "uninstallation") >>> + sys.exit(1) >>> >>> >>> b) s/--ignore-disconnected-topology/--ignore-topology-disconnect/, for >>> consistency with other options, e.g. --no-ui-redirect. >>> >>> Maybe even shorten it to --ignore-topology? But we probably don't want >>> people to use this option much, so it might be better to keep it long? >>> >> I would rather leave it with the long option name, it is more apparent >> what this switch should be around. >>> >>> c) I'm fine with uninstall options, you can remove the TODO: >>> >>> + # TODO: ask jcholast about uninstallation options >>> >>> >>> Honza >>> >> >> Attaching updated patches. >> > NACK > > ipa-server-install --uninstall > > 2015-11-30T17:14:30Z DEBUG Destroyed connection > context.ldap2_140081152041808 > 2015-11-30T17:14:30Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 91, in _handle_exception > super(Continuous, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 387, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 439, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 387, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 355, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 352, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 71, in _uninstall > for nothing in self._uninstaller(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 1409, in main > uninstall_check(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 265, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 1140, in uninstall_check > api, masters, options.ignore_disconnected_topology) > AttributeError: 'uninstaller(Server)' object has no attribute > 'ignore_disconnected_topology' > > 2015-11-30T17:14:30Z ERROR 'uninstaller(Server)' object has no attribute > 'ignore_disconnected_topology' > 2015-11-30T17:14:30Z INFO The ipa-server-install command was successful > Sorry I have failed horribly during option rename. Attaching patch that should actually work. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0099.3-implement-domain-level-1-specific-topology-checks-in.patch Type: text/x-patch Size: 11243 bytes Desc: not available URL: From simo at redhat.com Mon Nov 30 18:04:58 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 13:04:58 -0500 Subject: [Freeipa-devel] rename topology suffixes In-Reply-To: <5658522A.4070506@redhat.com> References: <56573012.2040803@redhat.com> <5657F2BE.4020304@redhat.com> <5658073E.3060402@redhat.com> <56580DB7.7010604@redhat.com> <56584295.4030700@redhat.com> <5658483E.1040405@redhat.com> <56584EFE.2070508@redhat.com> <5658522A.4070506@redhat.com> Message-ID: <1448906698.3747.88.camel@redhat.com> On Fri, 2015-11-27 at 13:52 +0100, Martin Babinsky wrote: > On 11/27/2015 01:39 PM, Jan Cholasta wrote: > > On 27.11.2015 13:10, Petr Vobornik wrote: > >> On 11/27/2015 12:46 PM, Petr Spacek wrote: > >>> On 27.11.2015 09:00, Jan Cholasta wrote: > >>>> On 27.11.2015 08:33, Martin Kosek wrote: > >>>>> On 11/27/2015 07:05 AM, Jan Cholasta wrote: > >>>>>> On 26.11.2015 17:15, Petr Vobornik wrote: > >>>>>>> New topology management gives names to managed suffixes: > >>>>>>> > >>>>>>> ipaca: o=ipaca > >>>>>>> realm: dc=example,dc=com > >>>>>>> > >>>>>>> We already had several offline discussions to change the names > >>>>>>> because > >>>>>>> they could be better. It would be difficult to change them after > >>>>>>> release > >>>>>>> of 4.3. > >>>>>>> > >>>>>>> New proposals: > >>>>>>> ca for o=ipaca > >>>>>>> domain for dc=example,dc=com > >>>>>>> > >>>>>>> What do you think? > >>>>>> > >>>>>> +1 > >>>>> > >>>>> ca is probably fine. Domain also, although the original realm name > >>>>> is OK > >>>>> with me too, domain has too many meanings and can be confused with DNS > >>>>> domain. > >>>> > >>>> Realm is too Kerberos-specific. The names are visible only in topology > >>>> context, so I don't think it would be confusing. When you say "the > >>>> domain > >>>> suffix", it describes the suffix pretty correctly IMHO. > >>> > >>> Here I agree with Martin that domain is too overloaded term, so I > >>> would prefer > >>> realm or so. > >>> > >>> Also, I do not think that 'Realm is too Kerberos-specific' is a valid > >>> argument > >>> because 'domain is too DNS-centric' :-) > >>> > >> > >> I guess we could find arguments for both 'domain' and 'realm'. :) I > >> don't have strong opinions on any. > >> > >> Actually, DN of the suffix consist of several 'DC' RDNs. DC is an > >> initialism of "domain component". Several components create a domain so > >> domain is correct ;) > > > > "Domain" is also used by AD and in our documentation IIRC. > > > We also have "domain levels" and not "realm levels" and IPA domain level > has very little to do with DNS. We should use the word "realm" only when dealing specifically with the Kerberos component. MOst people think of "domains" and "domain controllers", for good or bad that's the terminology people kind of standardized on. If we do not like domain I would see acceptable to use: - Ca Tree - Identity Tree Not sure that this is very accurate either and maybe too long. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Nov 30 18:13:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 19:13:04 +0100 Subject: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package In-Reply-To: <647877470.20906478.1448902246584.JavaMail.zimbra@redhat.com> References: <564F31CE.5010402@redhat.com> <2089136880.12558785.1448049270339.JavaMail.zimbra@redhat.com> <5652DFAE.90906@redhat.com> <5658694F.3080404@redhat.com> <56586A7F.3070004@redhat.com> <56586B5D.2040507@redhat.com> <647877470.20906478.1448902246584.JavaMail.zimbra@redhat.com> Message-ID: <565C91B0.2070908@redhat.com> NACK 1) With this patch I received this error in test_user_plugin.py E AssertionError: assert_deepequal: expected != got. E 0106: user_status: Query status of "tuser1" E expected = 1 E got = 2 E path = ('count',) I have just admin user on my system 2) ______________________________________________________________________________ ERROR collecting test_xmlrpc/test_stageuser_plugin.py ______________________________________________________________________________ test_xmlrpc/test_stageuser_plugin.py:28: in from ipatests.test_xmlrpc.tracker.user_plugin import UserTracker E ImportError: No module named tracker.user_plugin ______________________________________________________________________________ ERROR collecting test_xmlrpc/test_stageuser_plugin.py ______________________________________________________________________________ test_xmlrpc/test_stageuser_plugin.py:28: in from ipatests.test_xmlrpc.tracker.user_plugin import UserTracker E ImportError: No module named tracker.user_plugin 3) ________________________________________________________________________________ ERROR collecting test_xmlrpc/test_group_plugin.py ________________________________________________________________________________ test_xmlrpc/test_group_plugin.py:34: in from ipatests.test_xmlrpc.tracker.user_plugin import UserTracker E ImportError: No module named tracker.user_plugin ________________________________________________________________________________ ERROR collecting test_xmlrpc/test_group_plugin.py ________________________________________________________________________________ test_xmlrpc/test_group_plugin.py:34: in from ipatests.test_xmlrpc.tracker.user_plugin import UserTracker E ImportError: No module named tracker.user_plugin 4) ________________________________________________________________________________ ERROR collecting test_xmlrpc/test_host_plugin.py _________________________________________________________________________________ test_xmlrpc/test_host_plugin.py:42: in from ipatests.test_xmlrpc.tracker.host_plugin import HostTracker E ImportError: No module named tracker.host_plugin ________________________________________________________________________________ ERROR collecting test_xmlrpc/test_host_plugin.py _________________________________________________________________________________ test_xmlrpc/test_host_plugin.py:42: in from ipatests.test_xmlrpc.tracker.host_plugin import HostTracker E ImportError: No module named tracker.host_plugin 5) ________________________________________________________________________________ ERROR collecting test_xmlrpc/test_caacl_plugin.py ________________________________________________________________________________ test_xmlrpc/test_caacl_plugin.py:15: in from ipatests.test_xmlrpc.test_certprofile_plugin import default_profile ../_pytest/assertion/rewrite.py:171: in load_module py.builtin.exec_(co, mod.__dict__) test_xmlrpc/test_certprofile_plugin.py:17: in from ipatests.test_xmlrpc.tracker.certprofile_plugin import CertprofileTracker E ImportError: No module named tracker.certprofile_plugin ________________________________________________________________________________ ERROR collecting test_xmlrpc/test_caacl_plugin.py ________________________________________________________________________________ test_xmlrpc/test_caacl_plugin.py:15: in from ipatests.test_xmlrpc.test_certprofile_plugin import default_profile ../_pytest/assertion/rewrite.py:171: in load_module py.builtin.exec_(co, mod.__dict__) test_xmlrpc/test_certprofile_plugin.py:17: in from ipatests.test_xmlrpc.tracker.certprofile_plugin import CertprofileTracker E ImportError: No module named tracker.certprofile_plugin .... N) rpm -ql freeipa-tests | grep tracker returns nothing, IMO the tracker directory in not in RPM On 30.11.2015 17:50, Ale? Mare?ek wrote: > Tested with today's master, ACK. > - alich - > > ----- Original Message ----- >> From: "Milan Kub?k" >> To: freeipa-devel at redhat.com >> Sent: Friday, November 27, 2015 3:40:29 PM >> Subject: Re: [Freeipa-devel] [patch 0025] Separated Tracker implementations into standalone package >> >> On 11/27/2015 03:36 PM, Milan Kub?k wrote: >> >> >> >> On 11/27/2015 03:31 PM, Milan Kub?k wrote: >> >> >> On 11/23/2015 10:43 AM, Lenka Doudova wrote: >> >> >> NACK - there's a "typo" in ..../tracker/user_plugin.py, line 17-18: >> >> def get_user_dn(cn): >> >> return DN(('cn', cn), api.env.container_user, api.env.basedn) >> >> >> should be >> >> def get_user_dn(uid): >> >> return DN(('uid', uid), api.env.container_user, api.env.basedn) >> >> >> Some tests may fail because of that. >> Lenka >> >> >> On 11/20/2015 08:54 PM, Ale? Mare?ek wrote: >> >> >> Looks good. ACK. >> >> ----- Original Message ----- >> >> >> From: "Milan Kub?k" >> To: "freeipa-devel" >> Cc: "Filip Skola" , "Ales Marecek" >> Sent: Friday, November 20, 2015 3:44:30 PM >> Subject: [patch 0025] Separated Tracker implementations into standalone >> package >> >> Fixes https://fedorahosted.org/freeipa/ticket/5467 >> Patches attached. >> >> -- >> Milan Kubik >> >> >> >> Fixed the function and moved it into different module. >> Updated patches attached. >> >> >> >> Self nack, some imports missing >> >> -- >> Milan Kubik >> >> >> Patches updated. >> >> -- >> Milan Kubik >> >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From simo at redhat.com Mon Nov 30 18:17:56 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 13:17:56 -0500 Subject: [Freeipa-devel] [PATCH 0385] replicainstall: Add possiblity to install client in one In-Reply-To: <565C3236.5010703@redhat.com> References: <5652FD85.3050105@redhat.com> <5653343B.6020200@redhat.com> <56547AB1.5030405@redhat.com> <56556AC2.1090302@redhat.com> <5656FC28.6000009@redhat.com> <56570AEF.7040607@redhat.com> <565C0806.5090103@redhat.com> <565C3236.5010703@redhat.com> Message-ID: <1448907476.3747.89.camel@redhat.com> On Mon, 2015-11-30 at 12:25 +0100, Tomas Babej wrote: > + # Perform only if we have the necessary options > + if not any([installer.admin_password, installer.keytab]): > + sys.exit("IPA client is not configured on this system.\n" > + "You must use a replica file or join the system " > + "either by using by running 'ipa-client-install'. " > + "Alternatively, you may specify enrollment related options " > + "directly, see man ipa-replica-install.") > + There is a typo "either by using by " Also this seem to be run in promote_check, so you should not mention replica files, as promotion can only be run at domain level 1 where replica files cannot be used. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Nov 30 18:20:53 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 13:20:53 -0500 Subject: [Freeipa-devel] [PATCH 0364, 0367] ipa-kra-install: allow first KRA to be installed on replica In-Reply-To: <565C877B.3050405@redhat.com> References: <56587E92.7060008@redhat.com> <565C4C31.4070509@redhat.com> <565C877B.3050405@redhat.com> Message-ID: <1448907653.3747.90.camel@redhat.com> On Mon, 2015-11-30 at 18:29 +0100, Martin Basti wrote: > > On 30.11.2015 14:16, Martin Babinsky wrote: > > On 11/27/2015 05:02 PM, Martin Basti wrote: > >> https://fedorahosted.org/freeipa/ticket/5460 > >> > >> I tested just master, I will test ipa-4-2 later. > >> patch attached. > >> > >> > > > > ACK for the master branch. > > > Thanks, additional patch improves error message when ipa-replica-install > --setup-ca --setup-kra is executed and KRA is not installed anywhere yet. > > I'm working on patches for ipa-4-2 branch Question, shouldn't we just go ahead an install the first KRA ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Nov 30 18:22:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 19:22:16 +0100 Subject: [Freeipa-devel] [PATCH 0364, 0367] ipa-kra-install: allow first KRA to be installed on replica In-Reply-To: <1448907653.3747.90.camel@redhat.com> References: <56587E92.7060008@redhat.com> <565C4C31.4070509@redhat.com> <565C877B.3050405@redhat.com> <1448907653.3747.90.camel@redhat.com> Message-ID: <565C93D8.4050007@redhat.com> On 30.11.2015 19:20, Simo Sorce wrote: > On Mon, 2015-11-30 at 18:29 +0100, Martin Basti wrote: >> On 30.11.2015 14:16, Martin Babinsky wrote: >>> On 11/27/2015 05:02 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5460 >>>> >>>> I tested just master, I will test ipa-4-2 later. >>>> patch attached. >>>> >>>> >>> ACK for the master branch. >>> >> Thanks, additional patch improves error message when ipa-replica-install >> --setup-ca --setup-kra is executed and KRA is not installed anywhere yet. >> >> I'm working on patches for ipa-4-2 branch > Question, shouldn't we just go ahead an install the first KRA ? > > Simo. > On meeting today Alexander told that this we do not want. Also Honza do not want to have KRA installed by default. Martin From simo at redhat.com Mon Nov 30 18:24:34 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 13:24:34 -0500 Subject: [Freeipa-devel] [PATCH 0364, 0367] ipa-kra-install: allow first KRA to be installed on replica In-Reply-To: <565C93D8.4050007@redhat.com> References: <56587E92.7060008@redhat.com> <565C4C31.4070509@redhat.com> <565C877B.3050405@redhat.com> <1448907653.3747.90.camel@redhat.com> <565C93D8.4050007@redhat.com> Message-ID: <1448907874.3747.91.camel@redhat.com> On Mon, 2015-11-30 at 19:22 +0100, Martin Basti wrote: > > On 30.11.2015 19:20, Simo Sorce wrote: > > On Mon, 2015-11-30 at 18:29 +0100, Martin Basti wrote: > >> On 30.11.2015 14:16, Martin Babinsky wrote: > >>> On 11/27/2015 05:02 PM, Martin Basti wrote: > >>>> https://fedorahosted.org/freeipa/ticket/5460 > >>>> > >>>> I tested just master, I will test ipa-4-2 later. > >>>> patch attached. > >>>> > >>>> > >>> ACK for the master branch. > >>> > >> Thanks, additional patch improves error message when ipa-replica-install > >> --setup-ca --setup-kra is executed and KRA is not installed anywhere yet. > >> > >> I'm working on patches for ipa-4-2 branch > > Question, shouldn't we just go ahead an install the first KRA ? > > > > Simo. > > > On meeting today Alexander told that this we do not want. > Also Honza do not want to have KRA installed by default. Ok, I wasn't sure, fine by me. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Nov 30 18:27:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 19:27:02 +0100 Subject: [Freeipa-devel] [PATCH 0106] perform IPA client uninstallation as a last step of server uninstall In-Reply-To: <5658745A.3060701@redhat.com> References: <5658745A.3060701@redhat.com> Message-ID: <565C94F6.1060704@redhat.com> On 27.11.2015 16:18, Martin Babinsky wrote: > This patch fixes https://fedorahosted.org/freeipa/ticket/5410 > > > Functional ACK Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Nov 30 18:37:04 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 13:37:04 -0500 Subject: [Freeipa-devel] [PATCH 560] Allow to set allowed krb authz data type per user In-Reply-To: <1448473396.17462.4.camel@redhat.com> References: <1448406570.29102.26.camel@redhat.com> <56555E8C.5020608@redhat.com> <1448473396.17462.4.camel@redhat.com> Message-ID: <1448908624.3747.92.camel@redhat.com> On Wed, 2015-11-25 at 12:43 -0500, Simo Sorce wrote: > On Wed, 2015-11-25 at 08:09 +0100, Jan Cholasta wrote: > > On 25.11.2015 00:09, Simo Sorce wrote: > > > This patch is untested and mostly an RFC. > > > > > > I think it is all we need to allow to specify authz data types per user > > > and by setting the attribute to NONE preventing a user from getting > > > MS-PAC data in their ticket. > > > > > > Alexander you changed quite a bit the code around here so I'd like to > > > know if you think the change I made in the KDC will cause any issue with > > > the special PACs we generate for master's principals. As far as I can > > > tell it shouldn't. > > > > > > Any opinion is welcome. > > > > Before your change, the server entry was checked for AS requests, now > > only the client entry is checked for AS requests. I'm not very familiar > > with ipa-kdb, but shouldn't the server entry still be checked as a > > fallback when there is no authorization data in the client entry? > > This is partly why I CCed Alexander, the way the get function works is > that it will get policy on the entry itself and if nothing is there it > will try with the global policy, so in both cases the global policy is > sourced as fallback. > > For AS requests though you are generally asking for a TGT so the > "server" is the krbtgt entry that has no policy. It is through though > that a client *can* ask for a ticket directly via an AS request, that is > uncommon and it is unclear to me what we should do in that case if > client and server have incompatible options. > > Well this is why it is a RFC after all :) > > > The attribute is exposed in the service plugin, shouldn't it be exposed > > in the user plugin as well? > > I didn't do it on purpose yet but eventually we may want to expose it, > indeed. The reason I didn't is that we may want to use something like > CoS to populate the attribute based on group membership and I am not > sure we want to expose it per user, up top debate. > > > Nitpick: don't remove the space character here: "( uid )". > > noted. Bump, Alexander any opinion ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Nov 30 18:38:29 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 13:38:29 -0500 Subject: [Freeipa-devel] [PATCH 556-557] Add option to disable setkeytab extended operations In-Reply-To: <1448462853.29102.44.camel@redhat.com> References: <1448394152.29102.10.camel@redhat.com> <1448395038.29102.11.camel@redhat.com> <1448399848.29102.13.camel@redhat.com> <56555AC7.2000908@redhat.com> <5655BF5B.6020405@redhat.com> <1448462853.29102.44.camel@redhat.com> Message-ID: <1448908709.3747.93.camel@redhat.com> On Wed, 2015-11-25 at 09:47 -0500, Simo Sorce wrote: > On Wed, 2015-11-25 at 09:02 -0500, Rob Crittenden wrote: > > Jan Cholasta wrote: > > > On 24.11.2015 22:17, Simo Sorce wrote: > > >> On Tue, 2015-11-24 at 14:57 -0500, Simo Sorce wrote: > > >>> On Tue, 2015-11-24 at 14:42 -0500, Simo Sorce wrote: > > >>>> Since some time we use the getkeytab operation to fetch keytabs on > > >>>> newer > > >>>> clients. According to bug #232 setkeytab can be used to circumvent > > >>>> password quality controls so it needs to be slowly retired. > > >>>> > > >>>> The attached patches implement #5485 in 2 parts. > > >>>> > > >>>> The first introduces the option DisableSetKeytab which globally > > >>>> disables > > >>>> the setkeytab extended operation. This is set to false by default for > > >>>> backwards compatibility. > > >>>> > > >>>> The second introduces an option called DisableUserSetKeytab, which is > > >>>> active by default in new installs (but not in upgraded ones), and only > > >>>> disables the use of setkeytab for ipa suers, but not for > > >>>> hosts/services. > > >>>> This is because user's are the ones that may abuse the interface to > > >>>> escape password policies and users also normally do not acquire > > >>>> keytabs, > > >>>> so it is a safe bet to disable just them by default in new installs. > > >>>> > > >>>> (Testing in progress) > > >>> > > >>> Tested and working as expected. > > >> > > >> I realized that adding options to ipaConfig require to add them in the > > >> UI as well, attached patches add options in API.txt and config.py > > >> Make now complain I should change API Major or Minor, but it is not > > >> clear to me why given this are additional values and no real change or > > >> new function is introduced. What's the recommendation ? > > > > > > When does make complain? It is supposed to complain only when API.txt > > > does not match code. > > > > > > Anyway, we usually bump minor version even for backward compatible > > > changes, see e.g. commit 9549a59. > > > > > > > The point of API.txt (and the heavy client) was to save a round-trip. > > Being able to pass in an invalid option would void that rule hence > > having to update the API when new values are added. > > > > rob > > Ok added version change to the second patch (so we bump it only once > given these are basically related changes. Bump, is this ok ? -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Nov 30 18:42:02 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 30 Nov 2015 13:42:02 -0500 Subject: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names In-Reply-To: <56558064.7010600@redhat.com> References: <1448400058.29102.17.camel@redhat.com> <56558064.7010600@redhat.com> Message-ID: <1448908922.3747.94.camel@redhat.com> On Wed, 2015-11-25 at 10:33 +0100, Martin Babinsky wrote: > On 11/24/2015 10:20 PM, Simo Sorce wrote: > > This addresses #3860, giving admins the option to not require preauth > > for Hosts and services. > > > > I did not add this option by default, although it does reduce the load > > on the KDC as well as speed up TGT acquisition for service principal > > accounts that acquire TGTs. > > > > Tested and working as expected (SPNs are not returned PREAUTH_NEEDED > > error while normal users are). > > > > HTH, > > Simo. > > > > > > > Hi Simo, > > I was not able to apply the patch on current master branch: > > """ > git am > ../review/ssorce/3860/freeipa-simo-558-1-Allow-admins-to-disable-preauth-for-SPNs.patch > -3 > > Applying: Allow admins to disable preauth for SPNs. > error: invalid object 100644 a6b4d4349a9ac6de453d9ad3c679ec32add4e43b > for 'ipalib/plugins/config.py' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0001 Allow admins to disable preauth for SPNs. > """ > > It seems that I nedd to apply some of your other patches first (which one?) Sorry did not see this question earlier, it requires 556 and 557, I just bumped that thread. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Nov 30 18:42:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 19:42:23 +0100 Subject: [Freeipa-devel] [PATCH 0067] ipa-client-install: add support for Ed25519 SSH keys (RFC 7479) In-Reply-To: <5654269F.80105@redhat.com> References: <56542657.9090304@redhat.com> <5654269F.80105@redhat.com> Message-ID: <565C988F.8060709@redhat.com> On 24.11.2015 09:58, Petr Spacek wrote: > On 24.11.2015 09:56, Petr Spacek wrote: >> Hello, >> >> ipa-client-install: add support for Ed25519 SSH keys (RFC 7479) >> >> https://fedorahosted.org/freeipa/ticket/5471 >> > Once again ... > > > ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Nov 30 19:00:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 20:00:58 +0100 Subject: [Freeipa-devel] [PATCH] Removed duplicate domain name validation function In-Reply-To: <56587181.1070004@redhat.com> References: <5655DF48.4060302@redhat.com> <56586981.2010703@redhat.com> <565869D0.4060606@redhat.com> <56586D27.4030802@redhat.com> <56587181.1070004@redhat.com> Message-ID: <565C9CEA.80105@redhat.com> On 27.11.2015 16:06, Stanislav Laznicka wrote: > Please, see the modified patch attached. > > Standa > > On 11/27/2015 03:48 PM, Martin Basti wrote: >> >> >> On 27.11.2015 15:33, Petr Spacek wrote: >>> On 27.11.2015 15:32, Martin Basti wrote: >>>> >>>> On 25.11.2015 17:18, Stanislav Laznicka wrote: >>>>> There were two functions for the same purpose. Removed one. >>>>> >>>>> >>>> Hello, >>>> >>>> I would like to have "log" param of is_host_resolvable as optional >>> Is there an immediate need for the optional param? If not, I would >>> not clutter >>> the code. >>> >> So at least I would like to move log param as the last param, in case >> of need it can be modified to optional parameter. >> >> Or log can be default as root_logger, IMO we us only root_logger >> everywhere, but this need investigation. >> >> Martin > It works, but I would like to have Honza's opinion if ipalib/util.py is the right place for the new method and if we really need to use exceptions. IMO is_record_resolvable() should return only True/False and then it can be located in ipapython module From mbasti at redhat.com Mon Nov 30 19:34:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Nov 2015 20:34:16 +0100 Subject: [Freeipa-devel] [PATCH 0098-0099] domain level 1 topology checks during IPA server uninstall In-Reply-To: <565C8A57.2000305@redhat.com> References: <564E04BE.1020304@redhat.com> <56586187.5090402@redhat.com> <565C3399.5030109@redhat.com> <565C6E8C.2090900@redhat.com> <565C844B.7050901@redhat.com> <565C8A57.2000305@redhat.com> Message-ID: <565CA4B8.1010701@redhat.com> On 30.11.2015 18:41, Martin Babinsky wrote: > On 11/30/2015 06:15 PM, Martin Basti wrote: >> >> >> On 30.11.2015 16:43, Martin Babinsky wrote: >>> On 11/30/2015 12:31 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 27.11.2015 14:58, Martin Babinsky wrote: >>>>> On 11/19/2015 06:19 PM, Martin Babinsky wrote: >>>>>> These two patches fix the following tickets: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5377 >>>>>> https://fedorahosted.org/freeipa/ticket/5409 >>>>>> >>>>>> I have added a new option '--ignore-disconnected-topology' which >>>>>> forces >>>>>> IPA master uninstall despite reported errors in topology. I'm not >>>>>> quite >>>>>> sure if we want to flood ipa-server-install with uninstall-specific >>>>>> options, maybe it is better to skip the check in unattended mode and >>>>>> just print a warning about disconnected topology and what to do >>>>>> about >>>>>> it. >>>>>> >>>>>> I would like to hear your opinions about this. >>>>>> >>>>>> >>>>>> >>>>> Attaching rebased and updated patches. >>>> >>>> Patch 0098: LGTM >>>> >>>> >>>> Patch 0099: >>>> >>>> a) This check should be done in Server.__init__() rather than >>>> install_check(): >>>> >>>> + if options.ignore_disconnected_topology: >>>> + print("'--ignore-disconnected-topology' is used only during " >>>> + "uninstallation") >>>> + sys.exit(1) >>>> >>>> >>>> b) s/--ignore-disconnected-topology/--ignore-topology-disconnect/, for >>>> consistency with other options, e.g. --no-ui-redirect. >>>> >>>> Maybe even shorten it to --ignore-topology? But we probably don't want >>>> people to use this option much, so it might be better to keep it long? >>>> >>> I would rather leave it with the long option name, it is more apparent >>> what this switch should be around. >>>> >>>> c) I'm fine with uninstall options, you can remove the TODO: >>>> >>>> + # TODO: ask jcholast about uninstallation options >>>> >>>> >>>> Honza >>>> >>> >>> Attaching updated patches. >>> >> NACK >> >> ipa-server-install --uninstall >> >> 2015-11-30T17:14:30Z DEBUG Destroyed connection >> context.ldap2_140081152041808 >> 2015-11-30T17:14:30Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", >> line 91, in _handle_exception >> super(Continuous, self)._handle_exception(exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 387, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 439, in _handle_exception >> super(ComponentBase, self)._handle_exception(exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 387, in _handle_exception >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 355, in __runner >> step() >> File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", >> line 352, in >> step = lambda: next(self.__gen) >> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line 81, in run_generator_with_yield_from >> six.reraise(*exc_info) >> File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", >> line 59, in run_generator_with_yield_from >> value = gen.send(prev_value) >> File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", >> line 71, in _uninstall >> for nothing in self._uninstaller(self.parent): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", >> line 1409, in main >> uninstall_check(self) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", >> line 265, in decorated >> func(installer) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", >> line 1140, in uninstall_check >> api, masters, options.ignore_disconnected_topology) >> AttributeError: 'uninstaller(Server)' object has no attribute >> 'ignore_disconnected_topology' >> >> 2015-11-30T17:14:30Z ERROR 'uninstaller(Server)' object has no attribute >> 'ignore_disconnected_topology' >> 2015-11-30T17:14:30Z INFO The ipa-server-install command was successful >> > > Sorry I have failed horribly during option rename. Attaching patch > that should actually work. > functional ACK