From jcholast at redhat.com Fri Jul 1 03:55:35 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 1 Jul 2016 05:55:35 +0200 Subject: [Freeipa-devel] [PATCH] 0081 Add --ca option to cert-revoke and cert-remove-hold In-Reply-To: References: <20160629041103.GB4200@dhcp-40-8.bne.redhat.com> <20160629084722.GF4200@dhcp-40-8.bne.redhat.com> Message-ID: <57bb0b1b-941d-2f45-974b-2aca133050b0@redhat.com> On 29.6.2016 12:18, Jan Cholasta wrote: > On 29.6.2016 10:47, Fraser Tweedale wrote: >> On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 29.6.2016 06:11, Fraser Tweedale wrote: >>>> Dear team, >>>> >>>> The attached patch implements the --ca option for the rest of the >>>> cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999). >>> >>> 1) I don't think cert-status should be treated specially. The >>> operation to >>> check status of a certificate request is not specific to Dogtag. >>> >> I'm happy to add the option, with the caveat that because (of top of >> head) there is not (yet) a way in Dogtag to distinguish/filter >> requests by target CA, value may go unused. > > IMO that's OK, since it's a safe non-descructive operation. > >> >>> >>> 2) cert-show is called twice in cert-revoke. Can we call it just once? >>> >> I'll address this in next patchset. > > OK. ACK on the first version of the patch, since it's better than nothing. The ticket remains open, please fix the rest ASAP. Added VERSION bump and pushed to master: ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e Honza -- Jan Cholasta From jcholast at redhat.com Fri Jul 1 04:07:37 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 1 Jul 2016 06:07:37 +0200 Subject: [Freeipa-devel] [PATCH] 0072..0075 Lightweight CA renewal In-Reply-To: <20160629084131.GE4200@dhcp-40-8.bne.redhat.com> References: <20160621062416.GE4200@dhcp-40-8.bne.redhat.com> <3151c80a-656a-80f3-804d-e368ec513b25@redhat.com> <20160624064943.GP4200@dhcp-40-8.bne.redhat.com> <66f412e4-5894-53d9-9c3e-c5691da0f105@redhat.com> <20160629084131.GE4200@dhcp-40-8.bne.redhat.com> Message-ID: <069f33b7-af17-6145-2e5e-977e7af84249@redhat.com> On 29.6.2016 10:41, Fraser Tweedale wrote: > On Wed, Jun 29, 2016 at 09:30:17AM +0200, Jan Cholasta wrote: >> On 29.6.2016 08:55, Jan Cholasta wrote: >>> On 24.6.2016 08:49, Fraser Tweedale wrote: >>>> On Thu, Jun 23, 2016 at 09:51:02AM +0200, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 21.6.2016 08:24, Fraser Tweedale wrote: >>>>>> The attached patches add lightweight CA renewal. There are two >>>>>> substantive aspects: >>>>>> >>>>>> 1. The renew_ca_cert updates the serial number in the lightweight >>>>>> CA's entry in the Dogtag database. This causes CA clones to observe >>>>>> the renewal and update the certs in their own NSSDBs. >>>>>> >>>>>> 2. The ipa-certupdate command adds Certmonger tracking requests for >>>>>> lightweight CAs (on the renewal master only). >>>>>> >>>>>> Correct behaviour also depends on my patch 0069 (in-server API for >>>>>> renew_ca_cert script). >>>>> >>>>> Patch 0072-0074: LGTM >>>>> >>>>> Patch 0075: >>>>> >>>>> 1) Lightweight CA certs should be tracked by certmonger on all CA >>>>> servers, >>>>> not just on the renewal master. The behavior should be the same as >>>>> for the >>>>> main CA cert, i.e. the actual renewal is done only on the renewal >>>>> master, >>>>> other CA servers only update their NSS DBs (this is handled in >>>>> dogtag-ipa-ca-renew-agent-submit). >>>>> >>>>> This is important because CA renewal master can change at any time, and >>>>> without all CA certs being tracked on all CA servers, there is no >>>>> guarantee >>>>> the renewal would happen. >>>>> >>>>> 2) Since CA clones update their NSS DBs on their own, >>>>> dogtag-ipa-ca-renew-agent should be updated not to put them in >>>>> cn=ca_renewal,cn=ipa,cn=etc. >>>>> >>>> Thanks for the review, Honza. Updated patch 0075-2 attached. >>> >>> Thanks, ACK. >>> >>> Rebased patch 0072 and pushed to master: >>> 0078e7a9192a940104d8f6621b33d24d814c109b >>> >>> It would be nice if lightweight CAs known at replica install time were >>> tracked without having to manually run ipa-certupdate after >>> ipa-replica-install. Shall I file a ticket for this, or will you be able >>> to provide a patch before Friday? >> >> Also, the certs should be untracked on server uninstall. >> > File the ticket, and I'll try to address by Friday anyways :) > > Thanks, > Fraser > -- Jan Cholasta From ldoudova at redhat.com Fri Jul 1 04:36:28 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 1 Jul 2016 06:36:28 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> Message-ID: <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> On 06/30/2016 05:01 PM, Martin Babinsky wrote: > On 06/30/2016 03:47 PM, Lenka Doudova wrote: >> Hi, >> >> attaching patch with some basic coverage for external trust feature. Bit >> more detailed info in commit message. >> >> Since the feature requires me to run commands previously used only for >> forest root domains even for subdomains, I made some changes in >> ipatests/test_integration/tasks.py file, so that it would enable me to >> reuse existing function without copy-pasting them for one variable >> change. >> >> >> Lenka >> >> >> > > Hi Lenka, > > I have a few comments: > > 1.) > > -def establish_trust_with_ad(master, ad, extra_args=()): > +def establish_trust_with_ad(master, ad, extra_args=(), subdomain=False): > > This modification seems extremely kludgy to me. > > I would rather change the function signature to: > > -def establish_trust_with_ad(master, ad, extra_args=()): > +def establish_trust_with_ad(master, ad_domain, extra_args=()): > > and pass the domain name itself to the function instead of doing magic > inside. The same goes with `remove trust_with_ad`. You may want to fix > the calls to them in existing code so that the domain is passed > instead of the whole trust object. > > 2.) > > +def sync_time_hostname(host, srv_hostname): > + """ > + Syncs time with the remote server given by its hostname. > + Please note that this function leaves ntpd stopped. > + """ > + host.run_command(['systemctl', 'stop', 'ntpd']) > + host.run_command(['ntpdate', srv_hostname]) > + > + > > this looks like a duplicate of the function above it, why is it even > needed? > > 3.) > +class TestExternalTrustWithSubdomain(ADTrustBase): > + """ > + Test establishing external trust with subdomain > + """ > + > + @classmethod > + def install(cls, mh): > + super(ADTrustBase, cls).install(mh) > + cls.ad = cls.ad_domains[0].ads[0] > + cls.install_adtrust() > + cls.check_sid_generation() > + > + # Determine whether the subdomain AD is available > + try: > + child_ad = cls.host_by_role(cls.optional_extra_roles[0]) > + cls.ad_subdomain = > '.'.join(child_ad.hostname.split('.')[1:]) > + cls.ad_subdomain_hostname = child_ad.hostname > + except LookupError: > + cls.ad_subdomain = None > + > + cls.configure_dns_and_time() > > Please use proper OOP practices when overriding the behavior of the > base test class. > > For starters you could rewrite the install method like this: > > + @classmethod > + def install(cls, mh): > + # Determine whether the subdomain AD is available > + try: > + cls.child_ad = cls.host_by_role(cls.optional_extra_roles[0]) > + cls.ad_subdomain = > '.'.join(child_ad.hostname.split('.')[1:]) > + cls.ad_subdomain_hostname = child_ad.hostname > + except LookupError: > + raise nose.SkipTest("AFAIK this will skip the whole test > class") > + super(ADTrustBase, cls).install(mh) > > with child_ad stored as class attribute, you can override > `configure_dns_and_time`: > + def configure_dns_and_time(cls): > + tasks.configure_dns_for_trust(cls.master, cls.ad_subdomain) > # no need to re-implement the function just to get to the child > AD DC hostname now > + tasks.sync_time(cls.master, cls.child_ad.hostname) > > You can then use this class as an intermediary in the hierarchy and > inherit the other external/non-external trust test classes from it, > since most setup method in them are just copy-pasted from this one. > Hi, thanks for review, fixed patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0025.2-Tests-External-trust.patch Type: text/x-patch Size: 16957 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jul 1 04:47:36 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 1 Jul 2016 14:47:36 +1000 Subject: [Freeipa-devel] [PATCH] 0086 Add --ca option to cert-status In-Reply-To: <57bb0b1b-941d-2f45-974b-2aca133050b0@redhat.com> References: <20160629041103.GB4200@dhcp-40-8.bne.redhat.com> <20160629084722.GF4200@dhcp-40-8.bne.redhat.com> <57bb0b1b-941d-2f45-974b-2aca133050b0@redhat.com> Message-ID: <20160701044736.GG4200@dhcp-40-8.bne.redhat.com> On Fri, Jul 01, 2016 at 05:55:35AM +0200, Jan Cholasta wrote: > On 29.6.2016 12:18, Jan Cholasta wrote: > > On 29.6.2016 10:47, Fraser Tweedale wrote: > > > On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: > > > > Hi, > > > > > > > > On 29.6.2016 06:11, Fraser Tweedale wrote: > > > > > Dear team, > > > > > > > > > > The attached patch implements the --ca option for the rest of the > > > > > cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999). > > > > > > > > 1) I don't think cert-status should be treated specially. The > > > > operation to > > > > check status of a certificate request is not specific to Dogtag. > > > > > > > I'm happy to add the option, with the caveat that because (of top of > > > head) there is not (yet) a way in Dogtag to distinguish/filter > > > requests by target CA, value may go unused. > > > > IMO that's OK, since it's a safe non-descructive operation. > > > > > > > > > > > > > 2) cert-show is called twice in cert-revoke. Can we call it just once? > > > > > > > I'll address this in next patchset. > > > > OK. > > ACK on the first version of the patch, since it's better than nothing. The > ticket remains open, please fix the rest ASAP. > > Added VERSION bump and pushed to master: > ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e > > Honza > New patch 0086 attached, adding the option to cert-status command. (2) will be addressed later due to conflicts with other patches (or maybe as part of those other patches). Thanks, Fraser -------------- next part -------------- From b4d49da637035cdd8b4504b09b9790b3fc68c144 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 1 Jul 2016 14:42:37 +1000 Subject: [PATCH] Add --cn option to cert-status Add the 'cacn' option to the cert-status command. Right now there is nothing we need to (or can) do with it, but we add it anyway for future use. Fixes: https://fedorahosted.org/freeipa/ticket/5999 --- API.txt | 3 ++- VERSION | 4 ++-- ipaserver/plugins/cert.py | 14 ++++++-------- 3 files changed, 10 insertions(+), 11 deletions(-) diff --git a/API.txt b/API.txt index c01692e17dc1ed368c14e32ab7e3fc09bc4d1ffc..9f9456d2cefac9c31ff89f3812a862a80e7ad307 100644 --- a/API.txt +++ b/API.txt @@ -799,9 +799,10 @@ output: Entry('result') output: Output('summary', type=[, ]) output: PrimaryKey('value') command: cert_status/1 -args: 1,3,3 +args: 1,4,3 arg: Int('request_id') option: Flag('all', autofill=True, cli_name='all', default=False) +option: Str('cacn?', autofill=True, cli_name='ca', default=u'ipa') option: Flag('raw', autofill=True, cli_name='raw', default=False) option: Str('version?') output: Entry('result') diff --git a/VERSION b/VERSION index 23ceecc98e6ecf9adc21016508ba9feaa1454e6f..212b7d740a12a313395faf3bcdefaf09c41651f9 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=205 -# Last change: Add --ca option to cert-revoke and cert-remove-hold +IPA_API_VERSION_MINOR=206 +# Last change: Add --ca option to cert-status diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 817bdc26f1d8b53a323802079d19e367404528bd..70add0bb38a08ec030969dce6369cde85a33a5fb 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -638,17 +638,15 @@ class cert_status(Retrieve, BaseCertMethod, VirtualCommand): operation = "certificate status" - def get_options(self): - for option in super(cert_status, self).get_options(): - if option.name == 'cacn': - # Dogtag requests are uniquely identified by their - # number; there is no need to distinguish by CA. - continue - yield option - def execute(self, request_id, **kw): ca_enabled_check() self.check_access() + + # Dogtag requests are uniquely identified by their number; + # furthermore, Dogtag (as at v10.3.4) does not report the + # target CA in request data, so we cannot check. So for + # now, there is nothing we can do with the 'cacn' option. + return dict( result=self.Backend.ra.check_request_status(str(request_id)), value=pkey_to_value(request_id, kw), -- 2.5.5 From jcholast at redhat.com Fri Jul 1 04:54:11 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 1 Jul 2016 06:54:11 +0200 Subject: [Freeipa-devel] [PATCH] 0086 Add --ca option to cert-status In-Reply-To: <20160701044736.GG4200@dhcp-40-8.bne.redhat.com> References: <20160629041103.GB4200@dhcp-40-8.bne.redhat.com> <20160629084722.GF4200@dhcp-40-8.bne.redhat.com> <57bb0b1b-941d-2f45-974b-2aca133050b0@redhat.com> <20160701044736.GG4200@dhcp-40-8.bne.redhat.com> Message-ID: <0a90a203-8748-8e01-76f3-7354f6dcc2eb@redhat.com> On 1.7.2016 06:47, Fraser Tweedale wrote: > On Fri, Jul 01, 2016 at 05:55:35AM +0200, Jan Cholasta wrote: >> On 29.6.2016 12:18, Jan Cholasta wrote: >>> On 29.6.2016 10:47, Fraser Tweedale wrote: >>>> On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 29.6.2016 06:11, Fraser Tweedale wrote: >>>>>> Dear team, >>>>>> >>>>>> The attached patch implements the --ca option for the rest of the >>>>>> cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999). >>>>> >>>>> 1) I don't think cert-status should be treated specially. The >>>>> operation to >>>>> check status of a certificate request is not specific to Dogtag. >>>>> >>>> I'm happy to add the option, with the caveat that because (of top of >>>> head) there is not (yet) a way in Dogtag to distinguish/filter >>>> requests by target CA, value may go unused. >>> >>> IMO that's OK, since it's a safe non-descructive operation. >>> >>>> >>>>> >>>>> 2) cert-show is called twice in cert-revoke. Can we call it just once? >>>>> >>>> I'll address this in next patchset. >>> >>> OK. >> >> ACK on the first version of the patch, since it's better than nothing. The >> ticket remains open, please fix the rest ASAP. >> >> Added VERSION bump and pushed to master: >> ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e >> >> Honza >> > New patch 0086 attached, adding the option to cert-status command. Thanks. We could at least check if the specified CA exists, couldn't we? > > (2) will be addressed later due to conflicts with other patches (or > maybe as part of those other patches). OK. > > Thanks, > Fraser > -- Jan Cholasta From dkupka at redhat.com Fri Jul 1 05:58:31 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 1 Jul 2016 07:58:31 +0200 Subject: [Freeipa-devel] [PATCH 0108] schema: Decrease schema TTL to one hour Message-ID: https://fedorahosted.org/freeipa/ticket/4739 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0108.0-schema-Decrease-schema-TTL-to-one-hour.patch Type: text/x-patch Size: 1234 bytes Desc: not available URL: From dkupka at redhat.com Fri Jul 1 05:59:26 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 1 Jul 2016 07:59:26 +0200 Subject: [Freeipa-devel] [PATCH 0109] schema: Perform the check for schema update when, force_schema_check is True Message-ID: https://fedorahosted.org/freeipa/ticket/4739 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0109.0-schema-Perform-the-check-for-schema-update-when-forc.patch Type: text/x-patch Size: 1129 bytes Desc: not available URL: From slaznick at redhat.com Fri Jul 1 06:36:29 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 1 Jul 2016 08:36:29 +0200 Subject: [Freeipa-devel] [PATCH] 0070..0071 Fix replica installation from IPA v4.2 In-Reply-To: <20160617065950.GQ4744@dhcp-40-8.bne.redhat.com> References: <20160617065950.GQ4744@dhcp-40-8.bne.redhat.com> Message-ID: On 06/17/2016 08:59 AM, Fraser Tweedale wrote: > The attached patches fix > https://fedorahosted.org/freeipa/ticket/5963 > > Thanks Milan for reporting. > > Cheers, > Fraser > Tried this patch on 4.4 with domain level set to 0 and it does fix the issue for me so ACK for 4.4. Not sure if this is going to be backported but if so, both patches will need modifications for 4.2 and the latter patch will require modifications for 4.3 for them to apply. From ftweedal at redhat.com Fri Jul 1 06:42:05 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 1 Jul 2016 16:42:05 +1000 Subject: [Freeipa-devel] [PATCH] 0070..0071 Fix replica installation from IPA v4.2 In-Reply-To: References: <20160617065950.GQ4744@dhcp-40-8.bne.redhat.com> Message-ID: <20160701064204.GK4200@dhcp-40-8.bne.redhat.com> On Fri, Jul 01, 2016 at 08:36:29AM +0200, Stanislav Laznicka wrote: > On 06/17/2016 08:59 AM, Fraser Tweedale wrote: > > The attached patches fix > > https://fedorahosted.org/freeipa/ticket/5963 > > > > Thanks Milan for reporting. > > > > Cheers, > > Fraser > > > Tried this patch on 4.4 with domain level set to 0 and it does fix the issue > for me so ACK for 4.4. > > Not sure if this is going to be backported but if so, both patches will need > modifications for 4.2 and the latter patch will require modifications for > 4.3 for them to apply. > Thanks for testing! It is only needed for 4.4. Cheers, Fraser From mharmsen at redhat.com Fri Jul 1 06:50:47 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 1 Jul 2016 00:50:47 -0600 Subject: [Freeipa-devel] Karma Request for Dogtag 10.2.6 on Fedora 23 Message-ID: <577612C7.3080101@redhat.com> The following bug has been addressed in Fedora 23: * Bugzilla Bug #1323400 - freeipa fails to start correctly after pki-core update on upgraded system Please provide Karma for the following Fedora 23 build located in Bodhi at: * https://bodhi.fedoraproject.org/updates/FEDORA-2016-188c172b10 pki-core-10.2.6-20.fc23 Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Jul 1 06:53:14 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 08:53:14 +0200 Subject: [Freeipa-devel] [PATCH] Fix minor typo In-Reply-To: References: Message-ID: On 30.06.2016 18:56, Yuri Chornoivan wrote: > Hi, > > /ipaserver/plugins/cert.py:120: > > Verify that a certificate is owner by a specific user: > > It might be > > Verify that a certificate is owned by a specific user: > > Thanks for reviewing this possible typo fix. > > Best regards, > Yuri > > ACK Pushed to master: f5eb71f75e5e205674ed8df1e4c6324602fbe733 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Jul 1 06:57:50 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 1 Jul 2016 08:57:50 +0200 Subject: [Freeipa-devel] [PATCH] 0086 Add --ca option to cert-status In-Reply-To: <0a90a203-8748-8e01-76f3-7354f6dcc2eb@redhat.com> References: <20160629041103.GB4200@dhcp-40-8.bne.redhat.com> <20160629084722.GF4200@dhcp-40-8.bne.redhat.com> <57bb0b1b-941d-2f45-974b-2aca133050b0@redhat.com> <20160701044736.GG4200@dhcp-40-8.bne.redhat.com> <0a90a203-8748-8e01-76f3-7354f6dcc2eb@redhat.com> Message-ID: <901d3b0c-859a-995e-da03-742bcee8fa83@redhat.com> On 1.7.2016 06:54, Jan Cholasta wrote: > On 1.7.2016 06:47, Fraser Tweedale wrote: >> On Fri, Jul 01, 2016 at 05:55:35AM +0200, Jan Cholasta wrote: >>> On 29.6.2016 12:18, Jan Cholasta wrote: >>>> On 29.6.2016 10:47, Fraser Tweedale wrote: >>>>> On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 29.6.2016 06:11, Fraser Tweedale wrote: >>>>>>> Dear team, >>>>>>> >>>>>>> The attached patch implements the --ca option for the rest of the >>>>>>> cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999). >>>>>> >>>>>> 1) I don't think cert-status should be treated specially. The >>>>>> operation to >>>>>> check status of a certificate request is not specific to Dogtag. >>>>>> >>>>> I'm happy to add the option, with the caveat that because (of top of >>>>> head) there is not (yet) a way in Dogtag to distinguish/filter >>>>> requests by target CA, value may go unused. >>>> >>>> IMO that's OK, since it's a safe non-descructive operation. >>>> >>>>> >>>>>> >>>>>> 2) cert-show is called twice in cert-revoke. Can we call it just >>>>>> once? >>>>>> >>>>> I'll address this in next patchset. >>>> >>>> OK. >>> >>> ACK on the first version of the patch, since it's better than >>> nothing. The >>> ticket remains open, please fix the rest ASAP. >>> >>> Added VERSION bump and pushed to master: >>> ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e >>> >>> Honza >>> >> New patch 0086 attached, adding the option to cert-status command. > > Thanks. We could at least check if the specified CA exists, couldn't we? To speed things up, I have updated your patch with this, see the attachment. If the change looks good to you, we can push the patch. > >> >> (2) will be addressed later due to conflicts with other patches (or >> maybe as part of those other patches). > > OK. > >> >> Thanks, >> Fraser >> > > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ftweedal-0086-jcholast1-Add-cn-option-to-cert-status.patch Type: text/x-patch Size: 2816 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 1 06:55:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 08:55:31 +0200 Subject: [Freeipa-devel] [PATCH] 961 webui: prevent infinite reload for users with krbbprincipal alias set In-Reply-To: References: Message-ID: On 30.06.2016 19:54, Martin Babinsky wrote: > On 06/30/2016 07:34 PM, Petr Vobornik wrote: >> Web UI has an inbuilt mechanism to reload in case response from a server >> contains a different principal than the one loaded during Web UI >> startup. >> >> see rpc.js:381 >> >> With kerberos aliases support the loaded principal could be different >> because krbprincipalname contained multiple values. >> >> In such case krbcanonicalname should be used - it contains the same >> principal as the one which will be in future API responses. >> >> part of: https://fedorahosted.org/freeipa/ticket/5927 >> > > This patch is the WebUI counterpart to my WIP hacks to rpcserver.py > which possible to login to webui via enterprise principal (e.g. > use at email.com). > > for me ACK. > Pushed to master: 88f7154f7fcb1ca86dcbeeaca3c220ed4b88d55f From mbasti at redhat.com Fri Jul 1 06:57:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 08:57:43 +0200 Subject: [Freeipa-devel] [PATCH] 0070..0071 Fix replica installation from IPA v4.2 In-Reply-To: <20160701064204.GK4200@dhcp-40-8.bne.redhat.com> References: <20160617065950.GQ4744@dhcp-40-8.bne.redhat.com> <20160701064204.GK4200@dhcp-40-8.bne.redhat.com> Message-ID: <4d9cce5c-5c6a-9cba-a796-0a9a1e1ff728@redhat.com> On 01.07.2016 08:42, Fraser Tweedale wrote: > On Fri, Jul 01, 2016 at 08:36:29AM +0200, Stanislav Laznicka wrote: >> On 06/17/2016 08:59 AM, Fraser Tweedale wrote: >>> The attached patches fix >>> https://fedorahosted.org/freeipa/ticket/5963 >>> >>> Thanks Milan for reporting. >>> >>> Cheers, >>> Fraser >>> >> Tried this patch on 4.4 with domain level set to 0 and it does fix the issue >> for me so ACK for 4.4. >> >> Not sure if this is going to be backported but if so, both patches will need >> modifications for 4.2 and the latter patch will require modifications for >> 4.3 for them to apply. >> > Thanks for testing! > > It is only needed for 4.4. > > Cheers, > Fraser > master: * 0334693cfc56bc2788ea3b4f3cea9547c9c00340 Split CA replica installation steps for domain level 0 * 3ac3882631564cd774114e61e607fffdbd667eee Fix migration from pre-lightweight CAs master From mbasti at redhat.com Fri Jul 1 07:03:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 09:03:44 +0200 Subject: [Freeipa-devel] [PATCH] 0009 Do not log error when removing a non-existing file In-Reply-To: References: Message-ID: <10e72d18-ef99-5151-c66e-2974071c6b9e@redhat.com> On 30.06.2016 10:24, Florence Blanc-Renaud wrote: > Hi, > > this patch fixes issue 1) of the following ticket: > Uninstallation complains about missing 'ipa.conf' > > Issue 2) is not reproducible on the master, and issue 3) is handled in > a separate ticket. > > https://fedorahosted.org/freeipa/ticket/6012 > > ACK Pushed to master: d9ae9ee1b5397765ba7f184c7647bd36708ca0e8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Fri Jul 1 07:04:48 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 1 Jul 2016 09:04:48 +0200 Subject: [Freeipa-devel] [PATCH] 0067-72: webui for kerberos aliases In-Reply-To: References: Message-ID: <962d66f8-756d-49f0-dbe1-722534bf58d9@redhat.com> On 06/30/2016 05:27 PM, Petr Vobornik wrote: > On 06/30/2016 02:48 PM, Pavel Vomacka wrote: >> Hello, >> >> please review these patches. First two patches fix two minor bugs in >> custom_command_multivalued_widget. >> >> The rest of patches add webui for kerberos aliases. >> >> https://fedorahosted.org/freeipa/ticket/5927 >> > A preliminary review - I only read the code. > > Patch 0067: LGTM, > > btw same wrong interface is in on_error_add, but there it is not use fixed for on_error_add as well. > > Patch 0068: lGTM > > Patch 0069: > > 1. A nitpick, not necessarily a NACK. > krb_custom_command_multivalued_widget should be named e.g. > krb_principal_multivalued_widget. > > 2. Doc texts for the new widges are missing. This can be added later. > > > 3. `!principal_name || principal_name === '')` is the same as > `!principal_name` > > so > > var principal_name = value[0]; > > if (!principal_name || principal_name === '') { > principal_name = {}; > } > > could be simplified into > var principal_name = value[0] || {}; > > but why is an object set into that.principal_name when it is later used > as a text: `that.principal_text.text(that.principal_name);` > fixed > Patch 0070: LGTM > > Patch 0071: LGTM > > Patch 0072: LGTM if the change of krbprincipalname to krbcanonicalname > is good. > > Updated patches attached. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0067-2-Change-error-handling-in-custom_command_multivalued_.patch Type: text/x-patch Size: 1730 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0069-2-Add-widgets-for-kerberos-aliases.patch Type: text/x-patch Size: 6057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0070-2-Add-widget-for-kerberos-aliases-to-user-page.patch Type: text/x-patch Size: 1292 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0071-2-Add-widget-for-kerberos-aliases-to-hosts-page.patch Type: text/x-patch Size: 1302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0072-2-Add-widget-for-kerberos-aliases-to-service-page.patch Type: text/x-patch Size: 2740 bytes Desc: not available URL: From pspacek at redhat.com Fri Jul 1 07:05:54 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 09:05:54 +0200 Subject: [Freeipa-devel] [PATCH 0146] Fix internal errors in host-add and other commands caused by DNS resolutio In-Reply-To: <666c475c-8c59-41ef-08f7-0f0592729c4a@redhat.com> References: <666c475c-8c59-41ef-08f7-0f0592729c4a@redhat.com> Message-ID: On 30.6.2016 21:23, Petr Spacek wrote: > Hello, > > Fix internal errors in host-add and other commands caused by DNS resolution > > Previously resolver was returning CheckedIPAddress objects. This > internal server error in cases where DNS actually returned reserved IP > addresses. > > Now the resolver is returning UnsafeIPAddress objects which do syntactic > checks but do not filter IP addresses. > >>From now on we can decide if some IP address should be accepted as-is or > if it needs to be contrained to some subset of IP addresses using > CheckedIPAddress class. > > This regression was caused by changes for > https://fedorahosted.org/freeipa/ticket/5710 > > > > I've split parser and checks into separate classes. Attached script > CheckedIPAddressRefactoring.py uses python-hypothesis to compare results from > old and new implementations. It seems that all valid inputs return the very > same results. The new implementation is a bit stricter when it comes to > invalid inputs (parse_netmask=False & addr=IPNetwork instance) but as far as I > can tell this case could not happen in current IPA anyway. > > ipa-server-install, ipa-client-install, ipa-replica-install, and > ipa-ca-install on replica seem to work. DNS records for ipa-ca were properly > updated after replica installation. Also installation on server without A/AAAA > record in DNS and subsequent ipa-dns-install worked just fine. My bad, I forgot to attach cleanup patch 147 which is prerequisite for 146. (Sorry for the numbering.) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0147-Remove-unused-is_local-interface-and-defaultnet-from.patch Type: text/x-patch Size: 2022 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 1 07:07:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 09:07:06 +0200 Subject: [Freeipa-devel] [PATCH 0546-0547] use timestamps for ipareplica-conncheck.log In-Reply-To: <30d0400f-c2ac-d0c7-9df4-1cf35ce03caf@redhat.com> References: <99fed015-9ac8-7f87-284d-a5f08aa67c19@redhat.com> <0f7601a7-2a42-ed7b-e48a-f93812433646@redhat.com> <66bd71cf-27e3-abfa-ab32-c9b25b05bec4@redhat.com> <898c49ab-189d-4a9f-68af-72ed6761dcf0@redhat.com> <372907cb-6380-7df9-0ade-022a2ca5f629@redhat.com> <654d77dd-24c0-e822-ae67-13cf4d84b5e4@redhat.com> <30d0400f-c2ac-d0c7-9df4-1cf35ce03caf@redhat.com> Message-ID: <03526b35-9260-5b84-3b66-c4e81d24b805@redhat.com> On 30.06.2016 19:42, Martin Babinsky wrote: > On 06/30/2016 01:54 PM, Martin Basti wrote: >> >> >> On 30.06.2016 12:07, Petr Spacek wrote: >>> On 30.6.2016 10:21, Jan Cholasta wrote: >>>> On 30.6.2016 10:12, Petr Spacek wrote: >>>>> On 30.6.2016 10:14, Jan Cholasta wrote: >>>>>> On 30.6.2016 10:06, Petr Spacek wrote: >>>>>>> On 30.6.2016 10:02, Jan Cholasta wrote: >>>>>>>> On 30.6.2016 09:56, Petr Spacek wrote: >>>>>>>>> On 30.6.2016 09:40, Martin Basti wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5757 >>>>>>>> "The easiest solution would be to add timestamps to logs, or >>>>>>>> log to >>>>>>>> different >>>>>>>> logs from oddjob or from installer >>>>>>>> (ipareplica-conncheck.local.log and >>>>>>>> ipareplica-conncheck.remote.log)" >>>>>>>> >>>>>>>> Actually the easiest solution would be not to log into a file >>>>>>>> when executed >>>>>>>> from oddjob. >>>>>>> Well, IPA is hard enough to debug even with logs. I would not make >>>>>>> situation >>>>>>> even worse by not logging at all :-) >>>>>> The commands logs into stderr, and both stdout and stderr are sent >>>>>> back to the >>>>>> caller of the oddjob. >>>>>> >>>>>> Alternatively, it could log into a different file (say >>>>>> /var/log/ipareplica-conncheck-oddjob.log). IMO timestamps are an >>>>>> overkill to >>>>>> fix this bug. >>>>> When we are at it, a custom logger is overkill. IMHO we should log >>>>> everything >>>>> to journal and be done with it ... >>>> It's not, we want to log to at least stderr ourselves. >>>> >>>> Also, it would be even harder to implement than timestamps, and time >>>> is a >>> Sure, we do not have time: >>> => ACK for current version of the patch. >>> >>> Petr^2 Spacek >>> >>>> factor here. It would fit more into >>>> . >>>> >>>>> Petr^2 Spacek >>>>> >>>>>>>>>> Patches attached. >>>>>>>>> I would rather use timestamp format with dashes between numbers >>>>>>>>> to make it >>>>>>>>> easier to read and parse for humans. >>>>>>>>> >>>>>>>>> Compare: >>>>>>>>> >>>>>>>>> 201606270954 >>>>>>>>> 201606290954 >>>>>>>>> 201606300954 >>>>>>>>> >>>>>>>>> with >>>>>>>>> >>>>>>>>> 2016-06-27-09-54 >>>>>>>>> 2016-06-29-09-54 >>>>>>>>> 2016-06-30-09-54 >>>>> >>>> >>> >> >> New patches attaches >> >> > > Works for me, ACK. > master: * 4ce0258c235c985e07a19d291bd699720d9ef1bf Add option --no-log for ipa-replica-conncheck script * 08fcc7e25af54379eec87f4e22f8cd26db7ffbb0 Do not log to file in remote conncheck side From pspacek at redhat.com Fri Jul 1 07:08:03 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 09:08:03 +0200 Subject: [Freeipa-devel] [PATCH 0108] schema: Decrease schema TTL to one hour In-Reply-To: References: Message-ID: <4d5ffd35-dad1-be62-d239-c15f105f33a6@redhat.com> On 1.7.2016 07:58, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4739 > -- > David Kupka > > freeipa-dkupka-0108.0-schema-Decrease-schema-TTL-to-one-hour.patch > > > From 796fd4291dd17128e7bdfecf2d14ae7b151987f5 Mon Sep 17 00:00:00 2001 > From: David Kupka > Date: Fri, 1 Jul 2016 07:34:43 +0200 > Subject: [PATCH] schema: Decrease schema TTL to one hour > > Since checking schema is relatively cheap operation (one round-trip with > almost no data) we can do it offten to ensure schema will fetched by > client ASAP after it was updated on server. > > https://fedorahosted.org/freeipa/ticket/4739 > --- > ipaserver/plugins/schema.py | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/ipaserver/plugins/schema.py b/ipaserver/plugins/schema.py > index c7aa5f36c37d39a5131ca8ad915cb6e61bb748ec..a82b357899a483fd3b3dc9f7407bd26a4c03aada 100644 > --- a/ipaserver/plugins/schema.py > +++ b/ipaserver/plugins/schema.py > @@ -21,7 +21,10 @@ from ipapython.version import API_VERSION > > # Schema TTL sent to clients in response to schema call. > # Number of seconds before client should check for schema update. > -SCHEMA_TTL = 7*24*3600 # default: 7 days > +# This should be long enough to not slow down regular work or skripts > +# but also short enough to ensure schema will be retvieved soon after > +# it was updated > +SCHEMA_TTL = 3600 # default: 1 hour > > __doc__ = _(""" > API Schema > -- 2.7.4 ACK -- Petr^2 Spacek From mbasti at redhat.com Fri Jul 1 07:23:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 09:23:55 +0200 Subject: [Freeipa-devel] [PATCH 0108] schema: Decrease schema TTL to one hour In-Reply-To: <4d5ffd35-dad1-be62-d239-c15f105f33a6@redhat.com> References: <4d5ffd35-dad1-be62-d239-c15f105f33a6@redhat.com> Message-ID: <017921ea-b6cb-6efe-cd1c-e617ef3b0732@redhat.com> On 01.07.2016 09:08, Petr Spacek wrote: > On 1.7.2016 07:58, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4739 >> -- >> David Kupka >> >> freeipa-dkupka-0108.0-schema-Decrease-schema-TTL-to-one-hour.patch >> >> >> From 796fd4291dd17128e7bdfecf2d14ae7b151987f5 Mon Sep 17 00:00:00 2001 >> From: David Kupka >> Date: Fri, 1 Jul 2016 07:34:43 +0200 >> Subject: [PATCH] schema: Decrease schema TTL to one hour >> >> Since checking schema is relatively cheap operation (one round-trip with >> almost no data) we can do it offten to ensure schema will fetched by >> client ASAP after it was updated on server. >> >> https://fedorahosted.org/freeipa/ticket/4739 >> --- >> ipaserver/plugins/schema.py | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/ipaserver/plugins/schema.py b/ipaserver/plugins/schema.py >> index c7aa5f36c37d39a5131ca8ad915cb6e61bb748ec..a82b357899a483fd3b3dc9f7407bd26a4c03aada 100644 >> --- a/ipaserver/plugins/schema.py >> +++ b/ipaserver/plugins/schema.py >> @@ -21,7 +21,10 @@ from ipapython.version import API_VERSION >> >> # Schema TTL sent to clients in response to schema call. >> # Number of seconds before client should check for schema update. >> -SCHEMA_TTL = 7*24*3600 # default: 7 days >> +# This should be long enough to not slow down regular work or skripts >> +# but also short enough to ensure schema will be retvieved soon after >> +# it was updated >> +SCHEMA_TTL = 3600 # default: 1 hour >> >> __doc__ = _(""" >> API Schema >> -- 2.7.4 > ACK > Pushed to master: e5635f7ef423c7b203004a0cbf625360d351a78e From mbabinsk at redhat.com Fri Jul 1 07:25:09 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 09:25:09 +0200 Subject: [Freeipa-devel] [WIP] Kerberos principal aliases pt. 2 In-Reply-To: <043bef51-3318-2caf-46c4-aa300a501c5c@redhat.com> References: <7064fcdb-1005-20fb-d880-4749b468e241@redhat.com> <043bef51-3318-2caf-46c4-aa300a501c5c@redhat.com> Message-ID: <93ea9fe5-733c-d7b6-8290-f63844f0a66c@redhat.com> On 06/30/2016 11:17 PM, David Kupka wrote: > On 28/06/16 20:08, Martin Babinsky wrote: >> On 06/24/2016 09:52 AM, Martin Babinsky wrote: >>> Hi list, >>> >>> I am furiously working on tickets related to the proper support and API >>> for managing kerberos principal aliases for hosts, users, and >>> services[1-5]. >>> >>> To better track and comment on my progress, I have forked freeipa on git >>> and created a branch for you to test and review. The link is here: >>> >>> https://github.com/martbab/freeipa/tree/krb5-principal-aliases >>> >>> Please be aware that I may force-push into the branch without warning >>> when fixing issues we will discover during testing/review. >>> >>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>> [2] https://fedorahosted.org/freeipa/ticket/3864 >>> [3] https://fedorahosted.org/freeipa/ticket/3961 >>> [4] https://fedorahosted.org/freeipa/ticket/1365 >>> [5] https://fedorahosted.org/freeipa/ticket/5413 >>> >> >> Based on Jan's suggestions I have reworked the code substantially and >> force-pushed it into the github branch. Please review. >> > > Hello! > > I have gone through the code and tested the functionality in basic use > cases (server-install, upgrade, replica-install, adding/removing > principals, getting ticket with alias, ...). Code looks good to me and > everything* seems to work smoothly. > > condACK, if Pavel or Petr^1 (or anyone else who tried this) don't report > any issue really soon. > > *except for https://fedorahosted.org/freeipa/ticket/6017 > Thanks, David. here are the reviewed patches rebased on the most current master. If no one objects I suggest to push them. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0168-ipapython-module-for-Kerberos-principal-manipulation.patch Type: text/x-patch Size: 7482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0169-Test-suite-for-ipapython-kerberos.py.patch Type: text/x-patch Size: 4601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0170-ipalib-introduce-Principal-parameter.patch Type: text/x-patch Size: 6539 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0171-Migrate-management-framework-plugins-to-use-Principa.patch Type: text/x-patch Size: 56873 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0172-Add-ACI-for-admins-to-modify-principal-attributes.patch Type: text/x-patch Size: 1645 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0173-replace-an-ACI-relying-on-presence-of-deprecated-obj.patch Type: text/x-patch Size: 1636 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0174-Allow-for-commands-that-use-positional-parameters-to.patch Type: text/x-patch Size: 16701 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0175-Make-framework-consider-krbcanonicalname-as-service-.patch Type: text/x-patch Size: 15140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0176-Provide-API-for-management-of-host-service-and-user-.patch Type: text/x-patch Size: 35209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0177-Unify-display-of-principal-names-aliases-across-enti.patch Type: text/x-patch Size: 23062 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 1 07:27:24 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 09:27:24 +0200 Subject: [Freeipa-devel] [PATCH 0549] Translations IPA 4.4.0 Message-ID: <91a7e725-2b31-42fe-b2eb-1d6dc5041c73@redhat.com> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0549-IPA-4.4.0-Translations.patch Type: text/x-patch Size: 402788 bytes Desc: not available URL: From dkupka at redhat.com Fri Jul 1 07:32:55 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 1 Jul 2016 09:32:55 +0200 Subject: [Freeipa-devel] [WIP] Thin client In-Reply-To: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> References: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> Message-ID: On 28/04/16 14:45, Jan Cholasta wrote: > Hi, > > I have pushed my thin client WIP branch to GitHub: > . > > All commits up to "ipalib: use relative imports for cross-plugin > imports" should be good for review. The rest is subject to change > (WARNING: I will force push into this branch). > > Honza > Hello! Patches: client: add support for pre-schema servers client: do not crash when overriding remote command as method brings compatibility with old servers into thin client (making it not so thin after all :-). I've tested it against 4.2 and 4.3 servers and the important parts work. There are some minor issues (e.g. dynamic defaults not working) but they can be addressed later, ACK. -- David Kupka From mbasti at redhat.com Fri Jul 1 07:37:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 09:37:58 +0200 Subject: [Freeipa-devel] [WIP] Kerberos principal aliases pt. 2 In-Reply-To: <93ea9fe5-733c-d7b6-8290-f63844f0a66c@redhat.com> References: <7064fcdb-1005-20fb-d880-4749b468e241@redhat.com> <043bef51-3318-2caf-46c4-aa300a501c5c@redhat.com> <93ea9fe5-733c-d7b6-8290-f63844f0a66c@redhat.com> Message-ID: On 01.07.2016 09:25, Martin Babinsky wrote: > On 06/30/2016 11:17 PM, David Kupka wrote: >> On 28/06/16 20:08, Martin Babinsky wrote: >>> On 06/24/2016 09:52 AM, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> I am furiously working on tickets related to the proper support and >>>> API >>>> for managing kerberos principal aliases for hosts, users, and >>>> services[1-5]. >>>> >>>> To better track and comment on my progress, I have forked freeipa >>>> on git >>>> and created a branch for you to test and review. The link is here: >>>> >>>> https://github.com/martbab/freeipa/tree/krb5-principal-aliases >>>> >>>> Please be aware that I may force-push into the branch without warning >>>> when fixing issues we will discover during testing/review. >>>> >>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>>> [2] https://fedorahosted.org/freeipa/ticket/3864 >>>> [3] https://fedorahosted.org/freeipa/ticket/3961 >>>> [4] https://fedorahosted.org/freeipa/ticket/1365 >>>> [5] https://fedorahosted.org/freeipa/ticket/5413 >>>> >>> >>> Based on Jan's suggestions I have reworked the code substantially and >>> force-pushed it into the github branch. Please review. >>> >> >> Hello! >> >> I have gone through the code and tested the functionality in basic use >> cases (server-install, upgrade, replica-install, adding/removing >> principals, getting ticket with alias, ...). Code looks good to me and >> everything* seems to work smoothly. >> >> condACK, if Pavel or Petr^1 (or anyone else who tried this) don't report >> any issue really soon. >> >> *except for https://fedorahosted.org/freeipa/ticket/6017 >> > Thanks, David. > > here are the reviewed patches rebased on the most current master. If > no one objects I suggest to push them. > > > master: * de6abc7af2dac7994b0fff4396115320d1a9a54d ipapython module for Kerberos principal manipulation and parsing * e6fc8f84d3ad5fc4c030ad592a3d743c02393439 Test suite for `ipapython/kerberos.py` * 974eb7b5efd20ad2195b0ad578637ab31f4c1df4 ipalib: introduce Principal parameter * c2af032c0333f7e210c54369159d1d9f5e3fec74 Migrate management framework plugins to use Principal parameter * d1517482b5e9508780087ec48be63a5bb531fed9 Add ACI for admins to modify principal attributes * 7e803aa4625869ef6a8e78a09cd99270c4cc77e5 replace an ACI relying on presence of deprecated objectclass * 750a392fe22aa8ddcb21077e8c24b96d36ecf20c Allow for commands that use positional parameters to add/remove attributes * a28d312796839e3413c98ee37d34ccc892e85357 Make framework consider krbcanonicalname as service primary key * e6ff83e3610d553f6ff98e3adbfbe3c6984b2f17 Provide API for management of host, service, and user principal aliases * acf2234ebc8609a35a8f45598d5d817cbdbff121 Unify display of principal names/aliases across entities -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Fri Jul 1 07:38:04 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 1 Jul 2016 09:38:04 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> Message-ID: <6b621f74-de2e-c038-0cca-517929b99f21@redhat.com> On 30/06/16 21:34, David Kupka wrote: > On 04/05/16 17:22, Pavel Vomacka wrote: >> >> >> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>> That patch looks suspiciously short given the struggles I saw in >>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>> :-) >>>> >>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>> filling >>>> "krbPasswordExpiration" attribute at all, i.e. have password *without* >>>> expiration? Or is krbPasswordExpiration mandatory? >>> So I looked at the MIT code, and it seem like they are coping just fine >>> with a missing (ie value = 0 internally) pw_expiration attribute. >>> >>> So if we make our code cope with omitting any expiration if the >>> attribute is missing then yes, we can mark no expiration with simply >>> removing (or not setting) the krbPasswordExpiration attribute. >>> The attribute itself is optional and can be omitted. >>> >>> I think this is a good idea, and is definitely better than inventing a a >>> magic value. >>> >>> Simo. >>> >> Just a note: I tested David's patch and it actually doesn't work when >> the new password policy for ipausers group is created (priority = 0, >> which should be the highest priority). The maxlife and minlife values >> are empty. Even if I set the new password policy maxlife and minlife to >> 0 the result was that password will expire in 90 days. The patch worked >> correctly when I changed value of maxlife and minlife to 0 in >> 'global_policy'. Then the password expiration was set to 2038-01-01. >> > > Hello! > > I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop > plugins to tickle in order to have password that don't expire. Updated > patch attached. > > https://fedorahosted.org/freeipa/ticket/2795 Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0100.2-Allow-unexpiring-passwords.patch Type: text/x-patch Size: 6676 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jul 1 07:47:00 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 1 Jul 2016 09:47:00 +0200 Subject: [Freeipa-devel] [PATCH] 0067-72: webui for kerberos aliases In-Reply-To: <962d66f8-756d-49f0-dbe1-722534bf58d9@redhat.com> References: <962d66f8-756d-49f0-dbe1-722534bf58d9@redhat.com> Message-ID: <4c05c61d-27cf-a160-3d18-15c910e9c5bd@redhat.com> On 07/01/2016 09:04 AM, Pavel Vomacka wrote: > > > On 06/30/2016 05:27 PM, Petr Vobornik wrote: >> On 06/30/2016 02:48 PM, Pavel Vomacka wrote: >>> Hello, >>> >>> please review these patches. First two patches fix two minor bugs in >>> custom_command_multivalued_widget. >>> >>> The rest of patches add webui for kerberos aliases. >>> >>> https://fedorahosted.org/freeipa/ticket/5927 >>> >> A preliminary review - I only read the code. >> >> Patch 0067: LGTM, >> >> btw same wrong interface is in on_error_add, but there it is not use > fixed for on_error_add as well. >> >> Patch 0068: lGTM >> >> Patch 0069: >> >> 1. A nitpick, not necessarily a NACK. >> krb_custom_command_multivalued_widget should be named e.g. >> krb_principal_multivalued_widget. >> >> 2. Doc texts for the new widges are missing. This can be added later. >> >> >> 3. `!principal_name || principal_name === '')` is the same as >> `!principal_name` >> >> so >> >> var principal_name = value[0]; >> >> if (!principal_name || principal_name === '') { >> principal_name = {}; >> } >> >> could be simplified into >> var principal_name = value[0] || {}; >> >> but why is an object set into that.principal_name when it is later used >> as a text: `that.principal_text.text(that.principal_name);` >> > fixed >> Patch 0070: LGTM >> >> Patch 0071: LGTM >> >> Patch 0072: LGTM if the change of krbprincipalname to krbcanonicalname >> is good. >> >> > Updated patches attached. > Focusing on element was returned to patch 68 as discussed offline. ACK for all. master: * df56fd3371bd20a2ce8f5d0097e05437b7827e29 Change error handling in custom_command_multivalued_widget * 2232a5bb09b3e99d10598ab64d0bf5d8ef006df4 Set default confirmation button label to 'Remove' * 4bc2e3164fbc4fdbbd4ecd1d26001a5d4671dd94 Add widgets for kerberos aliases * 2da3090a9716bc47e9cf29329ac9bdb734376cb6 Add widget for kerberos aliases to user page * 62c4e15d16cf1b29d4a23db146c774ba01bf5935 Add widget for kerberos aliases to hosts page * 2ec59b7f232d9119d32d7a5574efba8965904ee8 Add widget for kerberos aliases to service page -- Petr Vobornik From jcholast at redhat.com Fri Jul 1 08:05:48 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 1 Jul 2016 10:05:48 +0200 Subject: [Freeipa-devel] [PATCH] 0086 Add --ca option to cert-status In-Reply-To: <901d3b0c-859a-995e-da03-742bcee8fa83@redhat.com> References: <20160629041103.GB4200@dhcp-40-8.bne.redhat.com> <20160629084722.GF4200@dhcp-40-8.bne.redhat.com> <57bb0b1b-941d-2f45-974b-2aca133050b0@redhat.com> <20160701044736.GG4200@dhcp-40-8.bne.redhat.com> <0a90a203-8748-8e01-76f3-7354f6dcc2eb@redhat.com> <901d3b0c-859a-995e-da03-742bcee8fa83@redhat.com> Message-ID: <8024f8c4-43e0-70de-3f22-8007b0784e04@redhat.com> On 1.7.2016 08:57, Jan Cholasta wrote: > On 1.7.2016 06:54, Jan Cholasta wrote: >> On 1.7.2016 06:47, Fraser Tweedale wrote: >>> On Fri, Jul 01, 2016 at 05:55:35AM +0200, Jan Cholasta wrote: >>>> On 29.6.2016 12:18, Jan Cholasta wrote: >>>>> On 29.6.2016 10:47, Fraser Tweedale wrote: >>>>>> On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 29.6.2016 06:11, Fraser Tweedale wrote: >>>>>>>> Dear team, >>>>>>>> >>>>>>>> The attached patch implements the --ca option for the rest of the >>>>>>>> cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999). >>>>>>> >>>>>>> 1) I don't think cert-status should be treated specially. The >>>>>>> operation to >>>>>>> check status of a certificate request is not specific to Dogtag. >>>>>>> >>>>>> I'm happy to add the option, with the caveat that because (of top of >>>>>> head) there is not (yet) a way in Dogtag to distinguish/filter >>>>>> requests by target CA, value may go unused. >>>>> >>>>> IMO that's OK, since it's a safe non-descructive operation. >>>>> >>>>>> >>>>>>> >>>>>>> 2) cert-show is called twice in cert-revoke. Can we call it just >>>>>>> once? >>>>>>> >>>>>> I'll address this in next patchset. >>>>> >>>>> OK. >>>> >>>> ACK on the first version of the patch, since it's better than >>>> nothing. The >>>> ticket remains open, please fix the rest ASAP. >>>> >>>> Added VERSION bump and pushed to master: >>>> ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e >>>> >>>> Honza >>>> >>> New patch 0086 attached, adding the option to cert-status command. >> >> Thanks. We could at least check if the specified CA exists, couldn't we? > > To speed things up, I have updated your patch with this, see the > attachment. > > If the change looks good to you, we can push the patch. Your original patch works for me, ACK. My change can be pushed under the one-liner rule, so pushing them combined in the modified patch. Pushed to master: 4844eaec197690e21c6cf44743df7f456d0e185d > >> >>> >>> (2) will be addressed later due to conflicts with other patches (or >>> maybe as part of those other patches). >> >> OK. >> >>> >>> Thanks, >>> Fraser >>> >> >> > > > > -- Jan Cholasta From dkupka at redhat.com Fri Jul 1 08:03:36 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 1 Jul 2016 10:03:36 +0200 Subject: [Freeipa-devel] [PATCH 0109] schema: Perform the check for schema update when, force_schema_check is True In-Reply-To: References: Message-ID: <8d2911bd-9046-f724-8408-71e117ba6fe3@redhat.com> On 01/07/16 07:59, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4739 Offline NACK from Honza, attaching updated patch. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-109.1-schema-Perform-the-check-for-schema-update-when-forc.patch Type: text/x-patch Size: 1367 bytes Desc: not available URL: From jcholast at redhat.com Fri Jul 1 08:12:56 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 1 Jul 2016 10:12:56 +0200 Subject: [Freeipa-devel] [PATCH 0109] schema: Perform the check for schema update when, force_schema_check is True In-Reply-To: <8d2911bd-9046-f724-8408-71e117ba6fe3@redhat.com> References: <8d2911bd-9046-f724-8408-71e117ba6fe3@redhat.com> Message-ID: On 1.7.2016 10:03, David Kupka wrote: > On 01/07/16 07:59, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4739 > > Offline NACK from Honza, attaching updated patch. Works for me, ACK. Pushed to master: cea1f33606e85ac83a7bda66fbef318e47412531 -- Jan Cholasta From mbasti at redhat.com Fri Jul 1 08:22:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 10:22:58 +0200 Subject: [Freeipa-devel] [PATCH] 0156 extdom: add certificate request In-Reply-To: <20160624184101.GD4873@10.4.128.1> References: <2912b62b-c68c-9800-b6b1-441c71ad89e9@redhat.com> <20160624125955.GF14566@p.Speedport_W_724V_Typ_A_05011603_00_009> <3e3a6cae-594e-5c0f-8777-42e8fcf17dee@redhat.com> <09c4491d-b5cc-be69-81d0-9b54e0248470@redhat.com> <20160624163109.GB3346@p.Speedport_W_724V_Typ_A_05011603_00_009> <20160624170025.wu5zt7s3yl2nwn5l@redhat.com> <20160624172834.GB4873@10.4.128.1> <20160624174337.alcw2u5mcxiablwt@redhat.com> <20160624175521.GC4873@10.4.128.1> <20160624180908.xojks7cmx4htyz6z@redhat.com> <20160624184101.GD4873@10.4.128.1> Message-ID: <73c273de-d2a2-4e0c-b419-b70bc15fb9db@redhat.com> On 24.06.2016 20:41, Lukas Slebodnik wrote: > On (24/06/16 21:09), Alexander Bokovoy wrote: >> On Fri, 24 Jun 2016, Lukas Slebodnik wrote: >>>>>>> ah sorry, since 1.14.0 is not release yet we use 1.13.9x to track the >>>>>>> alpha and beta releases and still have incrementing version numbers. So, >>>>>>> it might be better to use '>= 1.13.90' in the spec file instead of >>>>>>> '1.14.0'. >>>>>> +1, At this point '>= 1.13.90' should be safe. >>>>> -1 >>>>> I vote for official release. >>>>> I cannot see a reason why this patch should be pushed immediately. >>>>> 1.13.90 is just a sssd convention for alpha release and it can be confusing for >>>>> others whyt there isn't tarball for 1.13.90 >>>> It would allow git master to be built against sssd git master without >>>> additional problems. It is consistency here that I'm after. >>>> >>> It allows it even now and without this patch. >>> I'm sorry I miss a logic here. >> No, > That's not true. > > You wrote: "It would allow git master to be built" > against sssd git master" > ^^^^^^^^^^^^^^ > One more time. This patch will not change that > because you can build freeipa git master > against "sssd git master" even now. > > It's not my problem that freeipa requires git master of other project. > But it does not mean that you need to officialy requires > some weird version "1.13.90". It is really confusing. > >> it does not prevent you from running with the code that does not >> have needed support. 1.13.4 has no extdom certificate request support >> so you would need to make sure you are actually installing the correct >> SSSD packages manually while changing the version to 1.13.90 would make >> clear we demand a specific functionality. > Building freeipa and installing are two different things. > If you need to install freeipa git master then you need to use > extra copr anyway because: > A) you cannot install freeipa master in rawhide because there isn't > pki-core-10.3.3-1.fc25 > b) you cannot install freeipa master on fedora 24 due lots of missing > dependencies (including libsss_nss_idmap-1.14.0) > > If one would like to install freeipa git master rpms without copr > then he/she will not able to do it on fedora 24 without new libsss_nss_idmap > because dnf will not be able to find dependency > "libsss_nss_idmap.so.0(SSS_NSS_IDMAP_0.2.0)(64bit)" > >> It is a very small thing, of >> course, but helpful to those who have to deal with rebases/updates of >> their distribution packages and have not been following freeipa-devel@ >> list in detail. At the very least the inability to find 1.13.90 in a >> regular place would cause question being asked. >> > It's helpful but confusing. That's the reason why we should avoid using > 1.13.90. I doubt that anyone will try to use alpha version of sssd or freeipa > on other distributions (debian, ubuntu) especially if they do not work reliably > on fedora. So there's no reason for a rush. > > LS > Pushed to master: a635135ba3caa6359c38f305d7982925ef3de50b Version with dependency on 1.13.90 was pushed, we can increase it when SSSD 1.14.0 will be released -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0536.4-Bump-SSSD-version-in-requires.patch Type: text/x-patch Size: 1932 bytes Desc: not available URL: From tbordaz at redhat.com Fri Jul 1 08:26:03 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 1 Jul 2016 10:26:03 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> Message-ID: <5776291B.30301@redhat.com> Hi David, The patch looks good but being not familiar with that code, my comments may be absolutely wrong In ipadb_get_pwd_expiration, if it is not 'self' we set '*export=mod_time'. If for some reason 'mod_time==0', it has now a specific meaning 'not expiring' . Does it match the comment '* not 'self', so reset */' In ipadb_entry_to_mods, it deletes krbPasswordExpiration. But just before it adds in the mods krbPasswordExpiration=0 or krbPasswordExpiration=entry->pw_expiration Could we skip those mods if entry->pw_expiration==0 or expire_time==0 ? In ipapwd_SetPassword, ipapwd_post_modadd, same remark as above. Something that I am not sure is what is the expected relation between passwordexpirationtime and krbPasswordExpiration thanks thierry On 06/30/2016 09:34 PM, David Kupka wrote: > On 04/05/16 17:22, Pavel Vomacka wrote: >> >> >> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>> That patch looks suspiciously short given the struggles I saw in >>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>> :-) >>>> >>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>> filling >>>> "krbPasswordExpiration" attribute at all, i.e. have password *without* >>>> expiration? Or is krbPasswordExpiration mandatory? >>> So I looked at the MIT code, and it seem like they are coping just fine >>> with a missing (ie value = 0 internally) pw_expiration attribute. >>> >>> So if we make our code cope with omitting any expiration if the >>> attribute is missing then yes, we can mark no expiration with simply >>> removing (or not setting) the krbPasswordExpiration attribute. >>> The attribute itself is optional and can be omitted. >>> >>> I think this is a good idea, and is definitely better than inventing >>> a a >>> magic value. >>> >>> Simo. >>> >> Just a note: I tested David's patch and it actually doesn't work when >> the new password policy for ipausers group is created (priority = 0, >> which should be the highest priority). The maxlife and minlife values >> are empty. Even if I set the new password policy maxlife and minlife to >> 0 the result was that password will expire in 90 days. The patch worked >> correctly when I changed value of maxlife and minlife to 0 in >> 'global_policy'. Then the password expiration was set to 2038-01-01. >> > > Hello! > > I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop > plugins to tickle in order to have password that don't expire. Updated > patch attached. > > https://fedorahosted.org/freeipa/ticket/2795 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Fri Jul 1 08:36:34 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 1 Jul 2016 10:36:34 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <5776291B.30301@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> <5776291B.30301@redhat.com> Message-ID: Hi David, I did a functional review, and everything works well, so functional-ACK. But I did not do the code review. On 07/01/2016 10:26 AM, thierry bordaz wrote: > Hi David, > > The patch looks good but being not familiar with that code, my > comments may be absolutely wrong > > In ipadb_get_pwd_expiration, if it is not 'self' we set > '*export=mod_time'. > If for some reason 'mod_time==0', it has now a specific meaning 'not > expiring' . Does it match the comment '* not 'self', so reset */' > > In ipadb_entry_to_mods, it deletes krbPasswordExpiration. But just > before it adds in the mods krbPasswordExpiration=0 or > krbPasswordExpiration=entry->pw_expiration > Could we skip those mods if entry->pw_expiration==0 or expire_time==0 ? > > In ipapwd_SetPassword, ipapwd_post_modadd, same remark as above. > > Something that I am not sure is what is the expected relation between > passwordexpirationtime and krbPasswordExpiration > > thanks > thierry > > On 06/30/2016 09:34 PM, David Kupka wrote: >> On 04/05/16 17:22, Pavel Vomacka wrote: >>> >>> >>> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>>> That patch looks suspiciously short given the struggles I saw in >>>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>>> :-) >>>>> >>>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>>> filling >>>>> "krbPasswordExpiration" attribute at all, i.e. have password >>>>> *without* >>>>> expiration? Or is krbPasswordExpiration mandatory? >>>> So I looked at the MIT code, and it seem like they are coping just >>>> fine >>>> with a missing (ie value = 0 internally) pw_expiration attribute. >>>> >>>> So if we make our code cope with omitting any expiration if the >>>> attribute is missing then yes, we can mark no expiration with simply >>>> removing (or not setting) the krbPasswordExpiration attribute. >>>> The attribute itself is optional and can be omitted. >>>> >>>> I think this is a good idea, and is definitely better than >>>> inventing a a >>>> magic value. >>>> >>>> Simo. >>>> >>> Just a note: I tested David's patch and it actually doesn't work when >>> the new password policy for ipausers group is created (priority = 0, >>> which should be the highest priority). The maxlife and minlife values >>> are empty. Even if I set the new password policy maxlife and minlife to >>> 0 the result was that password will expire in 90 days. The patch worked >>> correctly when I changed value of maxlife and minlife to 0 in >>> 'global_policy'. Then the password expiration was set to 2038-01-01. >>> >> >> Hello! >> >> I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop >> plugins to tickle in order to have password that don't expire. >> Updated patch attached. >> >> https://fedorahosted.org/freeipa/ticket/2795 >> >> > -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Jul 1 08:37:35 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 10:37:35 +0200 Subject: [Freeipa-devel] [PATCH 0146] Fix internal errors in host-add and other commands caused by DNS resolutio In-Reply-To: References: <666c475c-8c59-41ef-08f7-0f0592729c4a@redhat.com> Message-ID: On 01.07.2016 09:05, Petr Spacek wrote: > On 30.6.2016 21:23, Petr Spacek wrote: >> Hello, >> >> Fix internal errors in host-add and other commands caused by DNS resolution >> >> Previously resolver was returning CheckedIPAddress objects. This >> internal server error in cases where DNS actually returned reserved IP >> addresses. >> >> Now the resolver is returning UnsafeIPAddress objects which do syntactic >> checks but do not filter IP addresses. >> >> >From now on we can decide if some IP address should be accepted as-is or >> if it needs to be contrained to some subset of IP addresses using >> CheckedIPAddress class. >> >> This regression was caused by changes for >> https://fedorahosted.org/freeipa/ticket/5710 >> >> >> >> I've split parser and checks into separate classes. Attached script >> CheckedIPAddressRefactoring.py uses python-hypothesis to compare results from >> old and new implementations. It seems that all valid inputs return the very >> same results. The new implementation is a bit stricter when it comes to >> invalid inputs (parse_netmask=False & addr=IPNetwork instance) but as far as I >> can tell this case could not happen in current IPA anyway. >> >> ipa-server-install, ipa-client-install, ipa-replica-install, and >> ipa-ca-install on replica seem to work. DNS records for ipa-ca were properly >> updated after replica installation. Also installation on server without A/AAAA >> record in DNS and subsequent ipa-dns-install worked just fine. > > My bad, I forgot to attach cleanup patch 147 which is prerequisite for 146. > (Sorry for the numbering.) > ACK master: * ce1f9ca51bd91ed66233c1bac7eb05fac9c855c7 Remove unused is_local(), interface, and defaultnet from CheckedIPAddress * 5e78b54d7c532bec0ee5a4ce3f1b6d6c94d17c51 Fix internal errors in host-add and other commands caused by DNS resolution I will review 4.3 later From pvoborni at redhat.com Fri Jul 1 08:38:57 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 1 Jul 2016 10:38:57 +0200 Subject: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names In-Reply-To: <56DF05BB.3010206@redhat.com> References: <1448400058.29102.17.camel@redhat.com> <56558064.7010600@redhat.com> <1448908922.3747.94.camel@redhat.com> <565DB5E1.8040500@redhat.com> <1449004137.9040.18.camel@redhat.com> <566193C8.9050609@redhat.com> <1457452173.8257.197.camel@redhat.com> <56DEF51B.5070808@redhat.com> <1457452819.8257.204.camel@redhat.com> <56DEFBBB.7020401@redhat.com> <1457455825.8257.205.camel@redhat.com> <56DF05BB.3010206@redhat.com> Message-ID: <7aaa0c0c-7585-2b1e-2c6a-ed8fa4e7279b@redhat.com> On 03/08/2016 06:02 PM, Martin Babinsky wrote: > On 03/08/2016 05:50 PM, Simo Sorce wrote: >> On Tue, 2016-03-08 at 17:20 +0100, Martin Babinsky wrote: >>> On 03/08/2016 05:00 PM, Simo Sorce wrote: >>>> On Tue, 2016-03-08 at 16:51 +0100, Martin Babinsky wrote: >>>>> On 03/08/2016 04:49 PM, Simo Sorce wrote: >>>>>> On Fri, 2015-12-04 at 14:23 +0100, Martin Babinsky wrote: >>>>>>> On 12/01/2015 10:08 PM, Simo Sorce wrote: >>>>>>>> On Tue, 2015-12-01 at 15:59 +0100, Martin Babinsky wrote: >>>>>>>>> On 11/30/2015 07:42 PM, Simo Sorce wrote: >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> It seems that I need something else, patch 556-2 applies >>>>>>>>> cleanly, but >>>>>>>>> patch 557-3 fails with http://fpaste.org/296230/89819431/ on >>>>>>>>> both master >>>>>>>>> and 4-2 branch. >>>>>>>>> >>>>>>>> >>>>>>>> Rebased 556,557 in their thread, and here is the rebase for 558 >>>>>>>> on top >>>>>>>> of them. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> ACK. I'm afraid that this patch and 556, 557 will require another >>>>>>> round >>>>>>> of rebase before pushing, though. >>>>>> >>>>>> Rebased on top of master (not on 556/557) per Petr's request. >>>>>> >>>>>> Simo. >>>>>> >>>>>> >>>>> >>>>> NACK, if you do API changes please increment API version in VERSION. >>>> >>>> Why wasn't this a problem in the previous ACK ? >>>> >>>> Simo. >>>> >>> >>> Probably because I missed it, sorry. >>> >> >> Fixed. >> >> Simo. >> > > Thanks, ACK. > was this pushed? -- Petr Vobornik From cheimes at redhat.com Fri Jul 1 08:42:36 2016 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 1 Jul 2016 10:42:36 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance Message-ID: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus returns OK. The ca_status() function defaults to api.env.ca_host as host. On a replica without CA ca_host is a remote host (e.g. master's FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, which might be blocked by a firewall. https://fedorahosted.org/freeipa/ticket/6016 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0031-RedHatCAService-should-wait-for-local-Dogtag-instanc.patch Type: text/x-patch Size: 1518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkupka at redhat.com Fri Jul 1 08:46:29 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 1 Jul 2016 10:46:29 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <5776291B.30301@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> <5776291B.30301@redhat.com> Message-ID: <47909847-7ff8-25b5-3a34-e04a7e2e0457@redhat.com> Hello Thierry! Thanks for looking into it. I will try to answer your questions and comments inline. On 01/07/16 10:26, thierry bordaz wrote: > Hi David, > > The patch looks good but being not familiar with that code, my comments > may be absolutely wrong > > In ipadb_get_pwd_expiration, if it is not 'self' we set '*export=mod_time'. > If for some reason 'mod_time==0', it has now a specific meaning 'not > expiring' . Does it match the comment '* not 'self', so reset */' mod_time should be timestamp of the modification operation. So mod_time == 0 should happen only when the change was performed in the very beginning of 70's. > > In ipadb_entry_to_mods, it deletes krbPasswordExpiration. But just > before it adds in the mods krbPasswordExpiration=0 or > krbPasswordExpiration=entry->pw_expiration > Could we skip those mods if entry->pw_expiration==0 or expire_time==0 ? That is exactly what I thought. But in that part of code I have no chance to check if the attribute is present in the entry or not. Also I can't catch and ignore the resulting error when deleting nonexistent attribute. Here only LDAPMod structures are filled but the execution is done in an other part of code. So I choose the easy path and always set the attribute and delete it right after if necessary. > > In ipapwd_SetPassword, ipapwd_post_modadd, same remark as above. > > Something that I am not sure is what is the expected relation between > passwordexpirationtime and krbPasswordExpiration I'm not sure either. I think we don't use passwordexpirationtime attribute. > > thanks > thierry > > On 06/30/2016 09:34 PM, David Kupka wrote: >> On 04/05/16 17:22, Pavel Vomacka wrote: >>> >>> >>> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>>> That patch looks suspiciously short given the struggles I saw in >>>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>>> :-) >>>>> >>>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>>> filling >>>>> "krbPasswordExpiration" attribute at all, i.e. have password *without* >>>>> expiration? Or is krbPasswordExpiration mandatory? >>>> So I looked at the MIT code, and it seem like they are coping just fine >>>> with a missing (ie value = 0 internally) pw_expiration attribute. >>>> >>>> So if we make our code cope with omitting any expiration if the >>>> attribute is missing then yes, we can mark no expiration with simply >>>> removing (or not setting) the krbPasswordExpiration attribute. >>>> The attribute itself is optional and can be omitted. >>>> >>>> I think this is a good idea, and is definitely better than inventing >>>> a a >>>> magic value. >>>> >>>> Simo. >>>> >>> Just a note: I tested David's patch and it actually doesn't work when >>> the new password policy for ipausers group is created (priority = 0, >>> which should be the highest priority). The maxlife and minlife values >>> are empty. Even if I set the new password policy maxlife and minlife to >>> 0 the result was that password will expire in 90 days. The patch worked >>> correctly when I changed value of maxlife and minlife to 0 in >>> 'global_policy'. Then the password expiration was set to 2038-01-01. >>> >> >> Hello! >> >> I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop >> plugins to tickle in order to have password that don't expire. Updated >> patch attached. >> >> https://fedorahosted.org/freeipa/ticket/2795 >> >> > > -- David Kupka From pspacek at redhat.com Fri Jul 1 08:48:57 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 10:48:57 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> Message-ID: <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> On 1.7.2016 10:42, Christian Heimes wrote: > RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a > HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus > returns OK. The ca_status() function defaults to api.env.ca_host as > host. > > On a replica without CA ca_host is a remote host (e.g. master's > FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, > which might be blocked by a firewall. > > https://fedorahosted.org/freeipa/ticket/6016 Interesting. How it happens that replica without CA is calling RedHatCAService? Also, why replica should be waiting for CA if it is not installed? I'm confused. -- Petr^2 Spacek From cheimes at redhat.com Fri Jul 1 08:55:00 2016 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 1 Jul 2016 10:55:00 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> Message-ID: On 2016-07-01 10:48, Petr Spacek wrote: > On 1.7.2016 10:42, Christian Heimes wrote: >> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >> returns OK. The ca_status() function defaults to api.env.ca_host as >> host. >> >> On a replica without CA ca_host is a remote host (e.g. master's >> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >> which might be blocked by a firewall. >> >> https://fedorahosted.org/freeipa/ticket/6016 > > Interesting. How it happens that replica without CA is calling RedHatCAService? > > Also, why replica should be waiting for CA if it is not installed? > > I'm confused. There is a hint in the last sentence: ipa-ca-install The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install doesn't wait for the local Dogtag to come up but connects to a remote Dogtag to check if it's up. It uses 8443 or 8080, which might be blocked. In my test setup I have both ports blocked so ipa-ca-install never succeeds. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From pspacek at redhat.com Fri Jul 1 08:59:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 10:59:02 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> Message-ID: On 1.7.2016 10:55, Christian Heimes wrote: > On 2016-07-01 10:48, Petr Spacek wrote: >> On 1.7.2016 10:42, Christian Heimes wrote: >>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>> returns OK. The ca_status() function defaults to api.env.ca_host as >>> host. >>> >>> On a replica without CA ca_host is a remote host (e.g. master's >>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>> which might be blocked by a firewall. >>> >>> https://fedorahosted.org/freeipa/ticket/6016 >> >> Interesting. How it happens that replica without CA is calling RedHatCAService? >> >> Also, why replica should be waiting for CA if it is not installed? >> >> I'm confused. > > There is a hint in the last sentence: ipa-ca-install > > The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install > doesn't wait for the local Dogtag to come up but connects to a remote > Dogtag to check if it's up. It uses 8443 or 8080, which might be > blocked. In my test setup I have both ports blocked so ipa-ca-install > never succeeds. Oh, I missed that, thanks! Isn't the root cause that ipa.env.ca_host does not get updated during ipa-ca-install? -- Petr^2 Spacek From mbabinsk at redhat.com Fri Jul 1 09:02:37 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 11:02:37 +0200 Subject: [Freeipa-devel] [PATCH] 0085 Fix upgrade when Dogtag also upgraded from 10.2 -> 10.3 In-Reply-To: <20160630111644.GR4200@dhcp-40-8.bne.redhat.com> References: <20160630111644.GR4200@dhcp-40-8.bne.redhat.com> Message-ID: <2fdb77d0-612e-5714-ac39-e9960546a49b@redhat.com> On 06/30/2016 01:16 PM, Fraser Tweedale wrote: > Hullo, > > The attached patch fixes > https://fedorahosted.org/freeipa/ticket/6011. > > Cheers, > Fraser > > > ACK -- Martin^3 Babinsky From cheimes at redhat.com Fri Jul 1 09:04:29 2016 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 1 Jul 2016 11:04:29 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> Message-ID: On 2016-07-01 10:59, Petr Spacek wrote: > On 1.7.2016 10:55, Christian Heimes wrote: >> On 2016-07-01 10:48, Petr Spacek wrote: >>> On 1.7.2016 10:42, Christian Heimes wrote: >>>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>>> returns OK. The ca_status() function defaults to api.env.ca_host as >>>> host. >>>> >>>> On a replica without CA ca_host is a remote host (e.g. master's >>>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>>> which might be blocked by a firewall. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6016 >>> >>> Interesting. How it happens that replica without CA is calling RedHatCAService? >>> >>> Also, why replica should be waiting for CA if it is not installed? >>> >>> I'm confused. >> >> There is a hint in the last sentence: ipa-ca-install >> >> The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install >> doesn't wait for the local Dogtag to come up but connects to a remote >> Dogtag to check if it's up. It uses 8443 or 8080, which might be >> blocked. In my test setup I have both ports blocked so ipa-ca-install >> never succeeds. > > Oh, I missed that, thanks! > > Isn't the root cause that ipa.env.ca_host does not get updated during > ipa-ca-install? Been there, tried it, didn't work: https://fedorahosted.org/freeipa/ticket/6016#comment:1 It just doesn't make sense that RedHatCAService should ever check a remote instance. The rest of the class is about the local systemd service. As soon as we have sd_notify https://fedorahosted.org/pki/ticket/1233 implemented, we can use systemd to wait for Dogtag. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbabinsk at redhat.com Fri Jul 1 09:07:01 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 11:07:01 +0200 Subject: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names In-Reply-To: <7aaa0c0c-7585-2b1e-2c6a-ed8fa4e7279b@redhat.com> References: <1448400058.29102.17.camel@redhat.com> <56558064.7010600@redhat.com> <1448908922.3747.94.camel@redhat.com> <565DB5E1.8040500@redhat.com> <1449004137.9040.18.camel@redhat.com> <566193C8.9050609@redhat.com> <1457452173.8257.197.camel@redhat.com> <56DEF51B.5070808@redhat.com> <1457452819.8257.204.camel@redhat.com> <56DEFBBB.7020401@redhat.com> <1457455825.8257.205.camel@redhat.com> <56DF05BB.3010206@redhat.com> <7aaa0c0c-7585-2b1e-2c6a-ed8fa4e7279b@redhat.com> Message-ID: On 07/01/2016 10:38 AM, Petr Vobornik wrote: > On 03/08/2016 06:02 PM, Martin Babinsky wrote: >> On 03/08/2016 05:50 PM, Simo Sorce wrote: >>> On Tue, 2016-03-08 at 17:20 +0100, Martin Babinsky wrote: >>>> On 03/08/2016 05:00 PM, Simo Sorce wrote: >>>>> On Tue, 2016-03-08 at 16:51 +0100, Martin Babinsky wrote: >>>>>> On 03/08/2016 04:49 PM, Simo Sorce wrote: >>>>>>> On Fri, 2015-12-04 at 14:23 +0100, Martin Babinsky wrote: >>>>>>>> On 12/01/2015 10:08 PM, Simo Sorce wrote: >>>>>>>>> On Tue, 2015-12-01 at 15:59 +0100, Martin Babinsky wrote: >>>>>>>>>> On 11/30/2015 07:42 PM, Simo Sorce wrote: >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>> It seems that I need something else, patch 556-2 applies >>>>>>>>>> cleanly, but >>>>>>>>>> patch 557-3 fails with http://fpaste.org/296230/89819431/ on >>>>>>>>>> both master >>>>>>>>>> and 4-2 branch. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Rebased 556,557 in their thread, and here is the rebase for 558 >>>>>>>>> on top >>>>>>>>> of them. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>>> >>>>>>>> >>>>>>>> ACK. I'm afraid that this patch and 556, 557 will require another >>>>>>>> round >>>>>>>> of rebase before pushing, though. >>>>>>> >>>>>>> Rebased on top of master (not on 556/557) per Petr's request. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>>> >>>>>> >>>>>> NACK, if you do API changes please increment API version in VERSION. >>>>> >>>>> Why wasn't this a problem in the previous ACK ? >>>>> >>>>> Simo. >>>>> >>>> >>>> Probably because I missed it, sorry. >>>> >>> >>> Fixed. >>> >>> Simo. >>> >> >> Thanks, ACK. >> > > was this pushed? > Yes I see 3e45c9be0aefb03751665a951f426ac59c50a551 in master. -- Martin^3 Babinsky From ldoudova at redhat.com Fri Jul 1 09:09:36 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 1 Jul 2016 11:09:36 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains Message-ID: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> Hi all, here's patch with basic test suite for support of UPN. Note: it needs to be applied on top of my patch 0025.2 (or later, if there's will be more fixes to that patch). Lenka From pvoborni at redhat.com Fri Jul 1 09:10:27 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 1 Jul 2016 11:10:27 +0200 Subject: [Freeipa-devel] [PATCH] 0085 Fix upgrade when Dogtag also upgraded from 10.2 -> 10.3 In-Reply-To: <2fdb77d0-612e-5714-ac39-e9960546a49b@redhat.com> References: <20160630111644.GR4200@dhcp-40-8.bne.redhat.com> <2fdb77d0-612e-5714-ac39-e9960546a49b@redhat.com> Message-ID: On 07/01/2016 11:02 AM, Martin Babinsky wrote: > On 06/30/2016 01:16 PM, Fraser Tweedale wrote: >> Hullo, >> >> The attached patch fixes >> https://fedorahosted.org/freeipa/ticket/6011. >> >> Cheers, >> Fraser >> >> >> > ACK > Pushed to master: 3691e39a62da5134f911f6a798f79a3a2ae0c025 -- Petr Vobornik From ldoudova at redhat.com Fri Jul 1 09:13:47 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 1 Jul 2016 11:13:47 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> Message-ID: <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> And, of course, a patch file :) On 07/01/2016 11:09 AM, Lenka Doudova wrote: > Hi all, > > here's patch with basic test suite for support of UPN. > > Note: it needs to be applied on top of my patch 0025.2 (or later, if > there's will be more fixes to that patch). > > > Lenka > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0026-Tests-Support-of-UPN-for-trusted-domains.patch Type: text/x-patch Size: 2444 bytes Desc: not available URL: From pspacek at redhat.com Fri Jul 1 09:17:18 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 11:17:18 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> Message-ID: On 1.7.2016 11:04, Christian Heimes wrote: > On 2016-07-01 10:59, Petr Spacek wrote: >> On 1.7.2016 10:55, Christian Heimes wrote: >>> On 2016-07-01 10:48, Petr Spacek wrote: >>>> On 1.7.2016 10:42, Christian Heimes wrote: >>>>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>>>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>>>> returns OK. The ca_status() function defaults to api.env.ca_host as >>>>> host. >>>>> >>>>> On a replica without CA ca_host is a remote host (e.g. master's >>>>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>>>> which might be blocked by a firewall. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6016 >>>> >>>> Interesting. How it happens that replica without CA is calling RedHatCAService? >>>> >>>> Also, why replica should be waiting for CA if it is not installed? >>>> >>>> I'm confused. >>> >>> There is a hint in the last sentence: ipa-ca-install >>> >>> The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install >>> doesn't wait for the local Dogtag to come up but connects to a remote >>> Dogtag to check if it's up. It uses 8443 or 8080, which might be >>> blocked. In my test setup I have both ports blocked so ipa-ca-install >>> never succeeds. >> >> Oh, I missed that, thanks! >> >> Isn't the root cause that ipa.env.ca_host does not get updated during >> ipa-ca-install? > > Been there, tried it, didn't work: > https://fedorahosted.org/freeipa/ticket/6016#comment:1 I understand that it does not work right now but it does not mean that it is an actual problem in api.env :-) Anyway, I'm testing your patch but I'm not sure we can get it into 4.4.0 as Petr^1 is about to push the RELEASE button any minute now. Petr^2 Spacek > It just doesn't make sense that RedHatCAService should ever check a > remote instance. The rest of the class is about the local systemd > service. As soon as we have sd_notify > https://fedorahosted.org/pki/ticket/1233 implemented, we can use systemd > to wait for Dogtag. From pvoborni at redhat.com Fri Jul 1 09:22:40 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 1 Jul 2016 11:22:40 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <47909847-7ff8-25b5-3a34-e04a7e2e0457@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> <5776291B.30301@redhat.com> <47909847-7ff8-25b5-3a34-e04a7e2e0457@redhat.com> Message-ID: <218b9b43-34b2-1dc0-d372-94cae7649045@redhat.com> On 07/01/2016 10:46 AM, David Kupka wrote: > Hello Thierry! > > Thanks for looking into it. I will try to answer your questions and > comments inline. > > On 01/07/16 10:26, thierry bordaz wrote: >> Hi David, >> >> The patch looks good but being not familiar with that code, my comments >> may be absolutely wrong >> >> In ipadb_get_pwd_expiration, if it is not 'self' we set >> '*export=mod_time'. >> If for some reason 'mod_time==0', it has now a specific meaning 'not >> expiring' . Does it match the comment '* not 'self', so reset */' > > mod_time should be timestamp of the modification operation. So mod_time > == 0 should happen only when the change was performed in the very > beginning of 70's. > >> >> In ipadb_entry_to_mods, it deletes krbPasswordExpiration. But just >> before it adds in the mods krbPasswordExpiration=0 or >> krbPasswordExpiration=entry->pw_expiration >> Could we skip those mods if entry->pw_expiration==0 or expire_time==0 ? > > That is exactly what I thought. But in that part of code I have no > chance to check if the attribute is present in the entry or not. Also I > can't catch and ignore the resulting error when deleting nonexistent > attribute. Here only LDAPMod structures are filled but the execution is > done in an other part of code. > So I choose the easy path and always set the attribute and delete it > right after if necessary. > >> >> In ipapwd_SetPassword, ipapwd_post_modadd, same remark as above. >> >> Something that I am not sure is what is the expected relation between >> passwordexpirationtime and krbPasswordExpiration > > I'm not sure either. I think we don't use passwordexpirationtime attribute. > >> >> thanks >> thierry I don't see a strict NACK here. Given pvomacka's functional ACK, I have pushed it. We can fix corner cases later. Pushed to master: d2cb9ed327ee4003598d5e45d80ab7918b89eeed >> >> On 06/30/2016 09:34 PM, David Kupka wrote: >>> On 04/05/16 17:22, Pavel Vomacka wrote: >>>> >>>> >>>> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>>>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>>>> That patch looks suspiciously short given the struggles I saw in >>>>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>>>> :-) >>>>>> >>>>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>>>> filling >>>>>> "krbPasswordExpiration" attribute at all, i.e. have password >>>>>> *without* >>>>>> expiration? Or is krbPasswordExpiration mandatory? >>>>> So I looked at the MIT code, and it seem like they are coping just >>>>> fine >>>>> with a missing (ie value = 0 internally) pw_expiration attribute. >>>>> >>>>> So if we make our code cope with omitting any expiration if the >>>>> attribute is missing then yes, we can mark no expiration with simply >>>>> removing (or not setting) the krbPasswordExpiration attribute. >>>>> The attribute itself is optional and can be omitted. >>>>> >>>>> I think this is a good idea, and is definitely better than inventing >>>>> a a >>>>> magic value. >>>>> >>>>> Simo. >>>>> >>>> Just a note: I tested David's patch and it actually doesn't work when >>>> the new password policy for ipausers group is created (priority = 0, >>>> which should be the highest priority). The maxlife and minlife values >>>> are empty. Even if I set the new password policy maxlife and minlife to >>>> 0 the result was that password will expire in 90 days. The patch worked >>>> correctly when I changed value of maxlife and minlife to 0 in >>>> 'global_policy'. Then the password expiration was set to 2038-01-01. >>>> >>> >>> Hello! >>> >>> I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop >>> plugins to tickle in order to have password that don't expire. Updated >>> patch attached. >>> >>> https://fedorahosted.org/freeipa/ticket/2795 >>> >> -- Petr Vobornik From tbordaz at redhat.com Fri Jul 1 09:22:46 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 1 Jul 2016 11:22:46 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <47909847-7ff8-25b5-3a34-e04a7e2e0457@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> <5776291B.30301@redhat.com> <47909847-7ff8-25b5-3a34-e04a7e2e0457@redhat.com> Message-ID: <57763666.1080304@redhat.com> On 07/01/2016 10:46 AM, David Kupka wrote: > Hello Thierry! > > Thanks for looking into it. I will try to answer your questions and > comments inline. > > On 01/07/16 10:26, thierry bordaz wrote: >> Hi David, >> >> The patch looks good but being not familiar with that code, my comments >> may be absolutely wrong >> >> In ipadb_get_pwd_expiration, if it is not 'self' we set >> '*export=mod_time'. >> If for some reason 'mod_time==0', it has now a specific meaning 'not >> expiring' . Does it match the comment '* not 'self', so reset */' > > mod_time should be timestamp of the modification operation. So > mod_time == 0 should happen only when the change was performed in the > very beginning of 70's. Right. My fault I did not understand that code. > >> >> In ipadb_entry_to_mods, it deletes krbPasswordExpiration. But just >> before it adds in the mods krbPasswordExpiration=0 or >> krbPasswordExpiration=entry->pw_expiration >> Could we skip those mods if entry->pw_expiration==0 or expire_time==0 ? > > That is exactly what I thought. But in that part of code I have no > chance to check if the attribute is present in the entry or not. Also > I can't catch and ignore the resulting error when deleting nonexistent > attribute. Here only LDAPMod structures are filled but the execution > is done in an other part of code. > So I choose the easy path and always set the attribute and delete it > right after if necessary. I think there is something a bit strange here. To be able to delete the attribute we first need to set it to a specific value then deleting the value we manage to delete the attribute. I did not find a routine like ipa_get_ldap_mod_delattr. With such routine I wonder if we could to something like: if (entry->pw_expiration == 0) { kerr = ipadb_get_ldap_mod_delattr(imods, "krbPasswordExpiration"); } else { kerr = ipadb_get_ldap_mod_time(imods, "krbPasswordExpiration", entry->pw_expiration, mod_op); } Instead of kerr = ipadb_get_ldap_mod_time(imods, "krbPasswordExpiration", entry->pw_expiration, mod_op); if (entry->pw_expiration == 0) { kerr = ipadb_get_ldap_mod_time(imods, "krbPasswordExpiration", entry->pw_expiration, LDAP_MOD_DELETE); } > >> >> In ipapwd_SetPassword, ipapwd_post_modadd, same remark as above. >> >> Something that I am not sure is what is the expected relation between >> passwordexpirationtime and krbPasswordExpiration > > I'm not sure either. I think we don't use passwordexpirationtime > attribute. I think they should be somehow linked, in fact it is looking it is what happen in ipapwd_write_krb_keys. But it looks it happens only when the krb keys are created. > >> >> thanks >> thierry >> >> On 06/30/2016 09:34 PM, David Kupka wrote: >>> On 04/05/16 17:22, Pavel Vomacka wrote: >>>> >>>> >>>> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>>>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>>>> That patch looks suspiciously short given the struggles I saw in >>>>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>>>> :-) >>>>>> >>>>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>>>> filling >>>>>> "krbPasswordExpiration" attribute at all, i.e. have password >>>>>> *without* >>>>>> expiration? Or is krbPasswordExpiration mandatory? >>>>> So I looked at the MIT code, and it seem like they are coping just >>>>> fine >>>>> with a missing (ie value = 0 internally) pw_expiration attribute. >>>>> >>>>> So if we make our code cope with omitting any expiration if the >>>>> attribute is missing then yes, we can mark no expiration with simply >>>>> removing (or not setting) the krbPasswordExpiration attribute. >>>>> The attribute itself is optional and can be omitted. >>>>> >>>>> I think this is a good idea, and is definitely better than inventing >>>>> a a >>>>> magic value. >>>>> >>>>> Simo. >>>>> >>>> Just a note: I tested David's patch and it actually doesn't work when >>>> the new password policy for ipausers group is created (priority = 0, >>>> which should be the highest priority). The maxlife and minlife values >>>> are empty. Even if I set the new password policy maxlife and >>>> minlife to >>>> 0 the result was that password will expire in 90 days. The patch >>>> worked >>>> correctly when I changed value of maxlife and minlife to 0 in >>>> 'global_policy'. Then the password expiration was set to 2038-01-01. >>>> >>> >>> Hello! >>> >>> I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop >>> plugins to tickle in order to have password that don't expire. Updated >>> patch attached. >>> >>> https://fedorahosted.org/freeipa/ticket/2795 >>> >>> >> >> > From mbabinsk at redhat.com Fri Jul 1 09:23:11 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 11:23:11 +0200 Subject: [Freeipa-devel] [PATCH 0549] Translations IPA 4.4.0 In-Reply-To: References: <91a7e725-2b31-42fe-b2eb-1d6dc5041c73@redhat.com> Message-ID: <10a145b5-0e16-1f1a-a0f9-a6e8cadb701c@redhat.com> On 07/01/2016 10:34 AM, Martin Basti wrote: > > > On 01.07.2016 09:27, Martin Basti wrote: >> Patch attached. >> >> >> > Updated patch ACK. -- Martin^3 Babinsky From cheimes at redhat.com Fri Jul 1 09:26:11 2016 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 1 Jul 2016 11:26:11 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> Message-ID: <8e2fe143-828c-14b8-4228-64c690e1ab99@redhat.com> On 2016-07-01 11:17, Petr Spacek wrote: > On 1.7.2016 11:04, Christian Heimes wrote: >> On 2016-07-01 10:59, Petr Spacek wrote: >>> On 1.7.2016 10:55, Christian Heimes wrote: >>>> On 2016-07-01 10:48, Petr Spacek wrote: >>>>> On 1.7.2016 10:42, Christian Heimes wrote: >>>>>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>>>>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>>>>> returns OK. The ca_status() function defaults to api.env.ca_host as >>>>>> host. >>>>>> >>>>>> On a replica without CA ca_host is a remote host (e.g. master's >>>>>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>>>>> which might be blocked by a firewall. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6016 >>>>> >>>>> Interesting. How it happens that replica without CA is calling RedHatCAService? >>>>> >>>>> Also, why replica should be waiting for CA if it is not installed? >>>>> >>>>> I'm confused. >>>> >>>> There is a hint in the last sentence: ipa-ca-install >>>> >>>> The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install >>>> doesn't wait for the local Dogtag to come up but connects to a remote >>>> Dogtag to check if it's up. It uses 8443 or 8080, which might be >>>> blocked. In my test setup I have both ports blocked so ipa-ca-install >>>> never succeeds. >>> >>> Oh, I missed that, thanks! >>> >>> Isn't the root cause that ipa.env.ca_host does not get updated during >>> ipa-ca-install? >> >> Been there, tried it, didn't work: >> https://fedorahosted.org/freeipa/ticket/6016#comment:1 > > I understand that it does not work right now but it does not mean that it is > an actual problem in api.env :-) > > Anyway, I'm testing your patch but I'm not sure we can get it into 4.4.0 as > Petr^1 is about to push the RELEASE button any minute now. Thanks Petr. I talked to Petr^1 on IRC. Since 4.2 and 4.3 are also affected, it's better not to rush this patch. It won't make it into 4.4.0. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkupka at redhat.com Fri Jul 1 09:31:55 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 1 Jul 2016 11:31:55 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <57763666.1080304@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> <5776291B.30301@redhat.com> <47909847-7ff8-25b5-3a34-e04a7e2e0457@redhat.com> <57763666.1080304@redhat.com> Message-ID: <79ab50e8-8a8b-a81e-4d2d-57ecb99f508f@redhat.com> On 01/07/16 11:22, thierry bordaz wrote: > > > On 07/01/2016 10:46 AM, David Kupka wrote: >> Hello Thierry! >> >> Thanks for looking into it. I will try to answer your questions and >> comments inline. >> >> On 01/07/16 10:26, thierry bordaz wrote: >>> Hi David, >>> >>> The patch looks good but being not familiar with that code, my comments >>> may be absolutely wrong >>> >>> In ipadb_get_pwd_expiration, if it is not 'self' we set >>> '*export=mod_time'. >>> If for some reason 'mod_time==0', it has now a specific meaning 'not >>> expiring' . Does it match the comment '* not 'self', so reset */' >> >> mod_time should be timestamp of the modification operation. So >> mod_time == 0 should happen only when the change was performed in the >> very beginning of 70's. > > Right. My fault I did not understand that code. >> >>> >>> In ipadb_entry_to_mods, it deletes krbPasswordExpiration. But just >>> before it adds in the mods krbPasswordExpiration=0 or >>> krbPasswordExpiration=entry->pw_expiration >>> Could we skip those mods if entry->pw_expiration==0 or expire_time==0 ? >> >> That is exactly what I thought. But in that part of code I have no >> chance to check if the attribute is present in the entry or not. Also >> I can't catch and ignore the resulting error when deleting nonexistent >> attribute. Here only LDAPMod structures are filled but the execution >> is done in an other part of code. >> So I choose the easy path and always set the attribute and delete it >> right after if necessary. > > I think there is something a bit strange here. > To be able to delete the attribute we first need to set it to a specific > value then deleting the value we manage to delete the attribute. > I did not find a routine like ipa_get_ldap_mod_delattr. With such > routine I wonder if we could to something like: > > if (entry->pw_expiration == 0) { > kerr = ipadb_get_ldap_mod_delattr(imods, > "krbPasswordExpiration"); > } else { > > kerr = ipadb_get_ldap_mod_time(imods, > "krbPasswordExpiration", > entry->pw_expiration, > mod_op); > } > > > Instead of > > kerr = ipadb_get_ldap_mod_time(imods, > "krbPasswordExpiration", > entry->pw_expiration, > mod_op); > if (entry->pw_expiration == 0) { > kerr = ipadb_get_ldap_mod_time(imods, > "krbPasswordExpiration", > entry->pw_expiration, LDAP_MOD_DELETE); > } > > > At some point I have added such routine and tried same approach as you do. But when the krbPasswordExpiration is not present in the entry (user already has non-expiring password) there is an error later when the mods are applied (err=16 ~ no such attribute). When I found this I decided to always LDAP_MOD_REPLACE the attribute (replace operation does not fail when the attribute is missing). And then remove it when it shouldn't be there. After that I decided to remove my _del_attr routine because I didn't want to add new unnecessary code. >> >>> >>> In ipapwd_SetPassword, ipapwd_post_modadd, same remark as above. >>> >>> Something that I am not sure is what is the expected relation between >>> passwordexpirationtime and krbPasswordExpiration >> >> I'm not sure either. I think we don't use passwordexpirationtime >> attribute. > I think they should be somehow linked, in fact it is looking it is what > happen in ipapwd_write_krb_keys. > But it looks it happens only when the krb keys are created. Probablby, I don't recall seeing passwordexpirationtime attribute used anywhere. >> >>> >>> thanks >>> thierry >>> >>> On 06/30/2016 09:34 PM, David Kupka wrote: >>>> On 04/05/16 17:22, Pavel Vomacka wrote: >>>>> >>>>> >>>>> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>>>>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>>>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>>>>> That patch looks suspiciously short given the struggles I saw in >>>>>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>>>>> :-) >>>>>>> >>>>>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>>>>> filling >>>>>>> "krbPasswordExpiration" attribute at all, i.e. have password >>>>>>> *without* >>>>>>> expiration? Or is krbPasswordExpiration mandatory? >>>>>> So I looked at the MIT code, and it seem like they are coping just >>>>>> fine >>>>>> with a missing (ie value = 0 internally) pw_expiration attribute. >>>>>> >>>>>> So if we make our code cope with omitting any expiration if the >>>>>> attribute is missing then yes, we can mark no expiration with simply >>>>>> removing (or not setting) the krbPasswordExpiration attribute. >>>>>> The attribute itself is optional and can be omitted. >>>>>> >>>>>> I think this is a good idea, and is definitely better than inventing >>>>>> a a >>>>>> magic value. >>>>>> >>>>>> Simo. >>>>>> >>>>> Just a note: I tested David's patch and it actually doesn't work when >>>>> the new password policy for ipausers group is created (priority = 0, >>>>> which should be the highest priority). The maxlife and minlife values >>>>> are empty. Even if I set the new password policy maxlife and >>>>> minlife to >>>>> 0 the result was that password will expire in 90 days. The patch >>>>> worked >>>>> correctly when I changed value of maxlife and minlife to 0 in >>>>> 'global_policy'. Then the password expiration was set to 2038-01-01. >>>>> >>>> >>>> Hello! >>>> >>>> I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop >>>> plugins to tickle in order to have password that don't expire. Updated >>>> patch attached. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2795 >>>> >>>> >>> >>> >> > -- David Kupka From pspacek at redhat.com Fri Jul 1 09:43:32 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 11:43:32 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> Message-ID: On 1.7.2016 11:17, Petr Spacek wrote: > On 1.7.2016 11:04, Christian Heimes wrote: >> On 2016-07-01 10:59, Petr Spacek wrote: >>> On 1.7.2016 10:55, Christian Heimes wrote: >>>> On 2016-07-01 10:48, Petr Spacek wrote: >>>>> On 1.7.2016 10:42, Christian Heimes wrote: >>>>>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>>>>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>>>>> returns OK. The ca_status() function defaults to api.env.ca_host as >>>>>> host. >>>>>> >>>>>> On a replica without CA ca_host is a remote host (e.g. master's >>>>>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>>>>> which might be blocked by a firewall. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6016 >>>>> >>>>> Interesting. How it happens that replica without CA is calling RedHatCAService? >>>>> >>>>> Also, why replica should be waiting for CA if it is not installed? >>>>> >>>>> I'm confused. >>>> >>>> There is a hint in the last sentence: ipa-ca-install >>>> >>>> The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install >>>> doesn't wait for the local Dogtag to come up but connects to a remote >>>> Dogtag to check if it's up. It uses 8443 or 8080, which might be >>>> blocked. In my test setup I have both ports blocked so ipa-ca-install >>>> never succeeds. >>> >>> Oh, I missed that, thanks! >>> >>> Isn't the root cause that ipa.env.ca_host does not get updated during >>> ipa-ca-install? >> >> Been there, tried it, didn't work: >> https://fedorahosted.org/freeipa/ticket/6016#comment:1 > > I understand that it does not work right now but it does not mean that it is > an actual problem in api.env :-) > > Anyway, I'm testing your patch but I'm not sure we can get it into 4.4.0 as > Petr^1 is about to push the RELEASE button any minute now. > > Petr^2 Spacek > >> It just doesn't make sense that RedHatCAService should ever check a >> remote instance. The rest of the class is about the local systemd >> service. As soon as we have sd_notify >> https://fedorahosted.org/pki/ticket/1233 implemented, we can use systemd >> to wait for Dogtag. It seems to work but ipa-client-install blows up on certificate request. # getcert list Number of certificates and requests being tracked: 1. Request ID '20160701093734': status: CA_UNREACHABLE ca-error: Server at https://vm-058-082.abc.idm.lab.eng.brq.redhat.com/ipa/xml failed request, will retry: 903 (RPC failed at server. an internal error has occurred). stuck: no key pair storage: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local IPA host',token='NSS Certificate DB',pinfile='/etc/ipa/nssdb/pwdfile.txt' certificate: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local IPA host' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes error log on the server: [Fri Jul 01 11:37:34.294677 2016] [wsgi:error] [pid 38273] ipa: INFO: [jsonserver_kerb] host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: host_mod(u'vm-046.abc.idm.lab.eng.brq.redhat.com', ipasshpubkey=(u'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtrWFHeOF6UxI/DNdlLsUUazTpol2sRqQgbZplpkB9t/HUSjUHq0OY1mwaUfxvJp/E9yDmuHZgUgzKMSAdUf2apwFm5bw3T7qSdJ0Y7hC9vG0v6kLT0EaPuQmfJ8Rt4xOyva9htKbzkxs9Kr0ujB6V4u41ZZW2oevqtGunC2+aCxkQzd42we0c47ypxnvl8gGAa76CDXenGaChPKSfeEMddnhFvjGfkSyqjD+dCxBF+IyTRDPtt6f5iF80lfv/559rsKYlHdbbgv30i5C/F2DzaB011BmcQwK1eWSGWsEWVFtQKNMdahTl2IMgvZwHcaw8TMqgqqgZ7ZZ6lMR+UA8l', u'ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHkoeGOzfQzqYOGQs2bdgL0jOBul+/eTBZ0HBM8HW3Wb5O15Fv3rt8jRp+xdSQcdG3DV5yPfjd66Fyz5hCTKS6s=', u'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH5/uXvdJ1l+uTAk0rgbjKeTBx9HRWk7w+xJLHMt/yRx'), updatedns=False, version=u'2.26'): SUCCESS [Fri Jul 01 11:37:37.961175 2016] [wsgi:error] [pid 38272] ipa: ERROR: non-public: ValueError: User name is defined only for user and enterprise principals [Fri Jul 01 11:37:37.961220 2016] [wsgi:error] [pid 38272] Traceback (most recent call last): [Fri Jul 01 11:37:37.961224 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 352, in wsgi_execute [Fri Jul 01 11:37:37.961226 2016] [wsgi:error] [pid 38272] result = self.Command[name](*args, **options) [Fri Jul 01 11:37:37.961229 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__ [Fri Jul 01 11:37:37.961259 2016] [wsgi:error] [pid 38272] return self.__do_call(*args, **options) [Fri Jul 01 11:37:37.961262 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in __do_call [Fri Jul 01 11:37:37.961265 2016] [wsgi:error] [pid 38272] ret = self.run(*args, **options) [Fri Jul 01 11:37:37.961267 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run [Fri Jul 01 11:37:37.961269 2016] [wsgi:error] [pid 38272] return self.execute(*args, **options) [Fri Jul 01 11:37:37.961271 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 456, in execute [Fri Jul 01 11:37:37.961274 2016] [wsgi:error] [pid 38272] caacl_check(principal_type, principal, ca, profile_id) [Fri Jul 01 11:37:37.961276 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 227, in caacl_check [Fri Jul 01 11:37:37.961278 2016] [wsgi:error] [pid 38272] principal, ca, profile_id): [Fri Jul 01 11:37:37.961280 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/caacl.py", line 126, in acl_evaluate [Fri Jul 01 11:37:37.961283 2016] [wsgi:error] [pid 38272] req = _acl_make_request(principal_type, principal, ca_id, profile_id) [Fri Jul 01 11:37:37.961285 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/caacl.py", line 68, in _acl_make_request [Fri Jul 01 11:37:37.961287 2016] [wsgi:error] [pid 38272] req.user.name = principal.username [Fri Jul 01 11:37:37.961289 2016] [wsgi:error] [pid 38272] File "/usr/lib/python2.7/site-packages/ipapython/kerberos.py", line 169, in username [Fri Jul 01 11:37:37.961292 2016] [wsgi:error] [pid 38272] "User name is defined only for user and enterprise principals") [Fri Jul 01 11:37:37.961294 2016] [wsgi:error] [pid 38272] ValueError: User name is defined only for user and enterprise principals [Fri Jul 01 11:37:37.961656 2016] [wsgi:error] [pid 38272] ipa: INFO: [xmlserver] host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: cert_request(u'MIIEDjCCAvYCAQAwZTEzMDEGA1UEChMqRE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NMS4wLAYDVQQDEyV2bS0wNDYuYWJjLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1zWanFx8qhfuHDgCjkQxkNBx6PoHfc+xNdb2OBcPfcfHL9HMjRGmTWN+CRZ388C+qxaExYed6WfmB/pK+b2M3fOnz1SRBPqicnCERP3G4mg02sL8cH068FShJvJECxWZxhvMiy/I0l/gRef1CJhaMJ5XGGuhZrLn3+Cv1BEgQDajBFsaZVeWTmwvROTjTht95QLUp8r9laPlGDzYnCdaWQ/R6Z1y+Mdu3I5VmxYL8TsH3NTDHjPvkDuQfPcdGkWp9V06QMp7MZeX0DEhsG2jeQc309xbe3vaPNPWClUv9OQX9xDgdlKO3E6UZKKWjXNUpqErpSFC1PiFqsMbJ36J7QIDAQABoIIBYjArBgkqhkiG9w0BCRQxHh4cAEwAbwBjAGEAbAAgAEkAUABBACAAaABvAHMAdDCCATEGCSqGSIb3DQEJDjGCASIwggEeMIHrBgNVHREBAQAEgeAwgd2gZQYKKwYBBAGCNxQCA6BXDFVob3N0L3ZtLTA0Ni5hYmMuaWRtLmxhYi5lbmcuYnJxLnJlZGhhdC5jb21ARE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NoHQGBisGAQUCAqBqMGigLBsqRE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NoTgwNqADAgEBoS8wLRsEaG9zdBsldm0tMDQ2LmFiYy5pZG0ubGFiLmVuZy5icnEucmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQQxo41ZpwB24cjTd1cxY9eKbxNkTANBgkqhkiG9w0BAQsFAAOCAQEAERsZQANNrwiDBTEa0Kpif5DB/lfRjSedZpIL/mPPRUJnKus/9hV5gyUZcUQ+c2NEwvIApBJk0TeSIU0xj+dFOsqaN8iPj05XI5axEnBOqGdkHfjxSe96eR7WHCX8JJPdy5SMcoa1T3R6+4myq2/CWceTNcfxM4DdAY5kYvaePOPb13l3YUy9yB12QhDx+BBTNfmsmVxvGkySfegJcJMacQrbIk3AAoj3BklrTSQPqESBvqSVWT/yZE2HcQ6H2aLfeChdieYFsl/gPqCbLDKQA7gdK9Pv5w2dDzMGvpNne/1MCksu9MD9Ys9KvuugOjWNHciglO/kwF4ZJbfJsRqz0Q==', principal=u'host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', add=True, version=u'2.51'): ValueError I suspect that this is a regression caused by Kerberos aliases support but I'm not going to ACK this until I can test it thoroughly. -- Petr^2 Spacek From tbordaz at redhat.com Fri Jul 1 09:45:20 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 1 Jul 2016 11:45:20 +0200 Subject: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity). In-Reply-To: <79ab50e8-8a8b-a81e-4d2d-57ecb99f508f@redhat.com> References: <1462372560.3624.62.camel@redhat.com> <7d0b9a1f-95da-142c-7fa5-f9e5fbcd1ec4@redhat.com> <1777358e-8acf-fd18-6714-f705a4a48de8@redhat.com> <5776291B.30301@redhat.com> <47909847-7ff8-25b5-3a34-e04a7e2e0457@redhat.com> <57763666.1080304@redhat.com> <79ab50e8-8a8b-a81e-4d2d-57ecb99f508f@redhat.com> Message-ID: <57763BB0.6040505@redhat.com> On 07/01/2016 11:31 AM, David Kupka wrote: > On 01/07/16 11:22, thierry bordaz wrote: >> >> >> On 07/01/2016 10:46 AM, David Kupka wrote: >>> Hello Thierry! >>> >>> Thanks for looking into it. I will try to answer your questions and >>> comments inline. >>> >>> On 01/07/16 10:26, thierry bordaz wrote: >>>> Hi David, >>>> >>>> The patch looks good but being not familiar with that code, my >>>> comments >>>> may be absolutely wrong >>>> >>>> In ipadb_get_pwd_expiration, if it is not 'self' we set >>>> '*export=mod_time'. >>>> If for some reason 'mod_time==0', it has now a specific meaning 'not >>>> expiring' . Does it match the comment '* not 'self', so reset */' >>> >>> mod_time should be timestamp of the modification operation. So >>> mod_time == 0 should happen only when the change was performed in the >>> very beginning of 70's. >> >> Right. My fault I did not understand that code. >>> >>>> >>>> In ipadb_entry_to_mods, it deletes krbPasswordExpiration. But just >>>> before it adds in the mods krbPasswordExpiration=0 or >>>> krbPasswordExpiration=entry->pw_expiration >>>> Could we skip those mods if entry->pw_expiration==0 or >>>> expire_time==0 ? >>> >>> That is exactly what I thought. But in that part of code I have no >>> chance to check if the attribute is present in the entry or not. Also >>> I can't catch and ignore the resulting error when deleting nonexistent >>> attribute. Here only LDAPMod structures are filled but the execution >>> is done in an other part of code. >>> So I choose the easy path and always set the attribute and delete it >>> right after if necessary. >> >> I think there is something a bit strange here. >> To be able to delete the attribute we first need to set it to a specific >> value then deleting the value we manage to delete the attribute. >> I did not find a routine like ipa_get_ldap_mod_delattr. With such >> routine I wonder if we could to something like: >> >> if (entry->pw_expiration == 0) { >> kerr = ipadb_get_ldap_mod_delattr(imods, >> "krbPasswordExpiration"); >> } else { >> >> kerr = ipadb_get_ldap_mod_time(imods, >> "krbPasswordExpiration", >> entry->pw_expiration, >> mod_op); >> } >> >> >> Instead of >> >> kerr = ipadb_get_ldap_mod_time(imods, >> "krbPasswordExpiration", >> entry->pw_expiration, >> mod_op); >> if (entry->pw_expiration == 0) { >> kerr = ipadb_get_ldap_mod_time(imods, >> "krbPasswordExpiration", >> entry->pw_expiration, LDAP_MOD_DELETE); >> } >> >> >> > > At some point I have added such routine and tried same approach as you > do. But when the krbPasswordExpiration is not present in the entry > (user already has non-expiring password) there is an error later when > the mods are applied (err=16 ~ no such attribute). > > When I found this I decided to always LDAP_MOD_REPLACE the attribute > (replace operation does not fail when the attribute is missing). And > then remove it when it shouldn't be there. After that I decided to > remove my _del_attr routine because I didn't want to add new > unnecessary code. Yes I agree and the code is working fine ! My concern is that ipadb_mods_new is trying to find empty mod slot. Hopefully there is no such empty slot currently. But in theory the mods can have a random order and I think it is dangerous. Adding a value to be able to delete the attribute afterward can fail if the ops are done in the opposite order. > >>> >>>> >>>> In ipapwd_SetPassword, ipapwd_post_modadd, same remark as above. >>>> >>>> Something that I am not sure is what is the expected relation between >>>> passwordexpirationtime and krbPasswordExpiration >>> >>> I'm not sure either. I think we don't use passwordexpirationtime >>> attribute. >> I think they should be somehow linked, in fact it is looking it is what >> happen in ipapwd_write_krb_keys. >> But it looks it happens only when the krb keys are created. > > Probablby, I don't recall seeing passwordexpirationtime attribute used > anywhere. > >>> >>>> >>>> thanks >>>> thierry >>>> >>>> On 06/30/2016 09:34 PM, David Kupka wrote: >>>>> On 04/05/16 17:22, Pavel Vomacka wrote: >>>>>> >>>>>> >>>>>> On 05/04/2016 04:36 PM, Simo Sorce wrote: >>>>>>> On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote: >>>>>>>> On 05/02/2016 02:28 PM, David Kupka wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>>>>>> That patch looks suspiciously short given the struggles I saw in >>>>>>>> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html >>>>>>>> >>>>>>>> :-) >>>>>>>> >>>>>>>> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid >>>>>>>> filling >>>>>>>> "krbPasswordExpiration" attribute at all, i.e. have password >>>>>>>> *without* >>>>>>>> expiration? Or is krbPasswordExpiration mandatory? >>>>>>> So I looked at the MIT code, and it seem like they are coping just >>>>>>> fine >>>>>>> with a missing (ie value = 0 internally) pw_expiration attribute. >>>>>>> >>>>>>> So if we make our code cope with omitting any expiration if the >>>>>>> attribute is missing then yes, we can mark no expiration with >>>>>>> simply >>>>>>> removing (or not setting) the krbPasswordExpiration attribute. >>>>>>> The attribute itself is optional and can be omitted. >>>>>>> >>>>>>> I think this is a good idea, and is definitely better than >>>>>>> inventing >>>>>>> a a >>>>>>> magic value. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> Just a note: I tested David's patch and it actually doesn't work >>>>>> when >>>>>> the new password policy for ipausers group is created (priority = 0, >>>>>> which should be the highest priority). The maxlife and minlife >>>>>> values >>>>>> are empty. Even if I set the new password policy maxlife and >>>>>> minlife to >>>>>> 0 the result was that password will expire in 90 days. The patch >>>>>> worked >>>>>> correctly when I changed value of maxlife and minlife to 0 in >>>>>> 'global_policy'. Then the password expiration was set to 2038-01-01. >>>>>> >>>>> >>>>> Hello! >>>>> >>>>> I hope I've finally find all the places in ipa-kdb and ipa-pwd-extop >>>>> plugins to tickle in order to have password that don't expire. >>>>> Updated >>>>> patch attached. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2795 >>>>> >>>>> >>>> >>>> >>> >> > > From pspacek at redhat.com Fri Jul 1 09:57:49 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 11:57:49 +0200 Subject: [Freeipa-devel] [PATCH 0148] client-install: log exceptions from certmonger.request_cer Message-ID: <0a0abe42-5e64-419c-bcc6-6006c6f59a30@redhat.com> Hello, client-install: log exceptions from certmonger.request_cert -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0148-client-install-log-exceptions-from-certmonger.reques.patch Type: text/x-patch Size: 1236 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Jul 1 09:58:52 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 11:58:52 +0200 Subject: [Freeipa-devel] [PATCH 0178] Fix incorrect check for principal type when evaluating CA ACLs Message-ID: Fixing first regression caused by principal alias work. Thanks Petr Spacek for finding it. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0178-Fix-incorrect-check-for-principal-type-when-evaluati.patch Type: text/x-patch Size: 1141 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jul 1 10:01:18 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 1 Jul 2016 12:01:18 +0200 Subject: [Freeipa-devel] FreeIPA 4.4.0 tagged Message-ID: <86759086-16c9-7350-9501-f557fefd8f93@redhat.com> FreeIPA 4.4.0 was tagged. Release notes will follow soon. * http://www.freeipa.org/page/Downloads#Latest_Release_-_FreeIPA_4.4.0 * http://freeipa.org/downloads/src/freeipa-4.4.0.tar.gz SHA1: 441ef8cb2b0ac103723d03b0478da641d697e104 MD5: 078697b25e02361fca37d00a1144130d -- Petr Vobornik From lslebodn at redhat.com Fri Jul 1 10:23:47 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 1 Jul 2016 12:23:47 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> Message-ID: <20160701102346.GR9283@10.4.128.1> On (01/07/16 11:13), Lenka Doudova wrote: >And, of course, a patch file :) > > >On 07/01/2016 11:09 AM, Lenka Doudova wrote: >> Hi all, >> >> here's patch with basic test suite for support of UPN. >> >> Note: it needs to be applied on top of my patch 0025.2 (or later, if >> there's will be more fixes to that patch). >> >> >> Lenka >> > >From 5c8cb8727322371b7246f6d939b38ac1cbd61e4c Mon Sep 17 00:00:00 2001 >From: Lenka Doudova >Date: Fri, 1 Jul 2016 11:00:57 +0200 >Subject: [PATCH] Tests: Support of UPN for trusted domains > >Basic set of tests to verify support of UPN functionality. > >Test cases: >- establish trust >- verify the trust recognizes UPN >- verify AD user with UPN can be resolved >- verify AD user with UPN can authenticate >- remove trust > >https://fedorahosted.org/freeipa/ticket/5354 >--- > ipatests/test_integration/test_trust.py | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > >diff --git a/ipatests/test_integration/test_trust.py b/ipatests/test_integration/test_trust.py >index d662e80727b6eab3df93166d35ddbaea6a0f6f7a..e8fdc6ba68fb6275a0d7920c76ca434ed830ed84 100644 >--- a/ipatests/test_integration/test_trust.py >+++ b/ipatests/test_integration/test_trust.py >@@ -388,3 +388,35 @@ class TestExternalTrustWithRootDomain(ADTrustBase): > > tasks.remove_trust_with_ad(self.master, self.ad_domain) > tasks.clear_sssd_cache(self.master) >+ >+ >+class TestTrustWithUPN(ADTrustBase): >+ """ >+ Test support of UPN for trusted domains >+ """ >+ def test_upn_in_nonposix_trust(self): >+ """ Check that UPN is listed as trust attribute """ >+ result = self.master.run_command(['ipa', 'trust-show', self.ad_domain, >+ '--all', '--raw']) >+ >+ assert "ipantadditionalsuffixes: UPNsuffix.com" in result.stdout_text >+ >+ def test_upn_user_resolution_in_nonposix_trust(self): >+ """ Check that user with UPN can be resolved """ >+ upnuser = 'upnuser at UPNsuffix.com' >+ result = self.master.run_command(['getent', 'passwd', upnuser]) Is there a special reason for not using pwd.getpwnam() ? LS From pspacek at redhat.com Fri Jul 1 11:08:25 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 13:08:25 +0200 Subject: [Freeipa-devel] [PATCH 0178] Fix incorrect check for principal type when evaluating CA ACLs In-Reply-To: References: Message-ID: <0e303825-51d1-e838-4f4a-ab68f146d23e@redhat.com> On 1.7.2016 11:58, Martin Babinsky wrote: > Fixing first regression caused by principal alias work. > > Thanks Petr Spacek for finding it. ACK, please add ticket number before push: https://fedorahosted.org/freeipa/ticket/3864 -- Petr^2 Spacek From abokovoy at redhat.com Fri Jul 1 11:08:43 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 1 Jul 2016 14:08:43 +0300 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <20160701102346.GR9283@10.4.128.1> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> <20160701102346.GR9283@10.4.128.1> Message-ID: <20160701110843.dwmmbwxaaogwf3t7@redhat.com> On Fri, 01 Jul 2016, Lukas Slebodnik wrote: >On (01/07/16 11:13), Lenka Doudova wrote: >>And, of course, a patch file :) >> >> >>On 07/01/2016 11:09 AM, Lenka Doudova wrote: >>> Hi all, >>> >>> here's patch with basic test suite for support of UPN. >>> >>> Note: it needs to be applied on top of my patch 0025.2 (or later, if >>> there's will be more fixes to that patch). >>> >>> >>> Lenka >>> >> > >>From 5c8cb8727322371b7246f6d939b38ac1cbd61e4c Mon Sep 17 00:00:00 2001 >>From: Lenka Doudova >>Date: Fri, 1 Jul 2016 11:00:57 +0200 >>Subject: [PATCH] Tests: Support of UPN for trusted domains >> >>Basic set of tests to verify support of UPN functionality. >> >>Test cases: >>- establish trust >>- verify the trust recognizes UPN >>- verify AD user with UPN can be resolved >>- verify AD user with UPN can authenticate >>- remove trust >> >>https://fedorahosted.org/freeipa/ticket/5354 >>--- >> ipatests/test_integration/test_trust.py | 32 ++++++++++++++++++++++++++++++++ >> 1 file changed, 32 insertions(+) >> >>diff --git a/ipatests/test_integration/test_trust.py b/ipatests/test_integration/test_trust.py >>index d662e80727b6eab3df93166d35ddbaea6a0f6f7a..e8fdc6ba68fb6275a0d7920c76ca434ed830ed84 100644 >>--- a/ipatests/test_integration/test_trust.py >>+++ b/ipatests/test_integration/test_trust.py >>@@ -388,3 +388,35 @@ class TestExternalTrustWithRootDomain(ADTrustBase): >> >> tasks.remove_trust_with_ad(self.master, self.ad_domain) >> tasks.clear_sssd_cache(self.master) >>+ >>+ >>+class TestTrustWithUPN(ADTrustBase): >>+ """ >>+ Test support of UPN for trusted domains >>+ """ >>+ def test_upn_in_nonposix_trust(self): >>+ """ Check that UPN is listed as trust attribute """ >>+ result = self.master.run_command(['ipa', 'trust-show', self.ad_domain, >>+ '--all', '--raw']) >>+ >>+ assert "ipantadditionalsuffixes: UPNsuffix.com" in result.stdout_text >>+ >>+ def test_upn_user_resolution_in_nonposix_trust(self): >>+ """ Check that user with UPN can be resolved """ >>+ upnuser = 'upnuser at UPNsuffix.com' >>+ result = self.master.run_command(['getent', 'passwd', upnuser]) >Is there a special reason for not using pwd.getpwnam() ? Technically -- yes. In case there was a change in the system configuration (/etc/nsswitch.conf), then these changes wouldn't be reflected in the application that is already using NSSWITCH interface. However, in this particular case no change to config files is expected so pwd.getpwnam() can be used. -- / Alexander Bokovoy From jcholast at redhat.com Fri Jul 1 11:16:53 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 1 Jul 2016 13:16:53 +0200 Subject: [Freeipa-devel] [PATCH 0178] Fix incorrect check for principal type when evaluating CA ACLs In-Reply-To: <0e303825-51d1-e838-4f4a-ab68f146d23e@redhat.com> References: <0e303825-51d1-e838-4f4a-ab68f146d23e@redhat.com> Message-ID: On 1.7.2016 13:08, Petr Spacek wrote: > On 1.7.2016 11:58, Martin Babinsky wrote: >> Fixing first regression caused by principal alias work. >> >> Thanks Petr Spacek for finding it. > > ACK, please add ticket number before push: > https://fedorahosted.org/freeipa/ticket/3864 > Pushed to master: 0ade41abbad324d8c54449f3b1024a7651dc259d -- Jan Cholasta From pspacek at redhat.com Fri Jul 1 11:25:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 13:25:02 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> Message-ID: <9751cf00-78b4-0dfd-4c70-7a04cb930215@redhat.com> On 1.7.2016 11:43, Petr Spacek wrote: > On 1.7.2016 11:17, Petr Spacek wrote: >> On 1.7.2016 11:04, Christian Heimes wrote: >>> On 2016-07-01 10:59, Petr Spacek wrote: >>>> On 1.7.2016 10:55, Christian Heimes wrote: >>>>> On 2016-07-01 10:48, Petr Spacek wrote: >>>>>> On 1.7.2016 10:42, Christian Heimes wrote: >>>>>>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>>>>>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>>>>>> returns OK. The ca_status() function defaults to api.env.ca_host as >>>>>>> host. >>>>>>> >>>>>>> On a replica without CA ca_host is a remote host (e.g. master's >>>>>>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>>>>>> which might be blocked by a firewall. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6016 >>>>>> >>>>>> Interesting. How it happens that replica without CA is calling RedHatCAService? >>>>>> >>>>>> Also, why replica should be waiting for CA if it is not installed? >>>>>> >>>>>> I'm confused. >>>>> >>>>> There is a hint in the last sentence: ipa-ca-install >>>>> >>>>> The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install >>>>> doesn't wait for the local Dogtag to come up but connects to a remote >>>>> Dogtag to check if it's up. It uses 8443 or 8080, which might be >>>>> blocked. In my test setup I have both ports blocked so ipa-ca-install >>>>> never succeeds. >>>> >>>> Oh, I missed that, thanks! >>>> >>>> Isn't the root cause that ipa.env.ca_host does not get updated during >>>> ipa-ca-install? >>> >>> Been there, tried it, didn't work: >>> https://fedorahosted.org/freeipa/ticket/6016#comment:1 >> >> I understand that it does not work right now but it does not mean that it is >> an actual problem in api.env :-) >> >> Anyway, I'm testing your patch but I'm not sure we can get it into 4.4.0 as >> Petr^1 is about to push the RELEASE button any minute now. >> >> Petr^2 Spacek >> >>> It just doesn't make sense that RedHatCAService should ever check a >>> remote instance. The rest of the class is about the local systemd >>> service. As soon as we have sd_notify >>> https://fedorahosted.org/pki/ticket/1233 implemented, we can use systemd >>> to wait for Dogtag. > > It seems to work but ipa-client-install blows up on certificate request. > > # getcert list > Number of certificates and requests being tracked: 1. > Request ID '20160701093734': > status: CA_UNREACHABLE > ca-error: Server at > https://vm-058-082.abc.idm.lab.eng.brq.redhat.com/ipa/xml failed request, will > retry: 903 (RPC failed at server. an internal error has occurred). > stuck: no > key pair storage: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local > IPA host',token='NSS Certificate DB',pinfile='/etc/ipa/nssdb/pwdfile.txt' > certificate: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local IPA > host' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > error log on the server: > > [Fri Jul 01 11:37:34.294677 2016] [wsgi:error] [pid 38273] ipa: INFO: > [jsonserver_kerb] > host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: > host_mod(u'vm-046.abc.idm.lab.eng.brq.redhat.com', ipasshpubkey=(u'ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQCtrWFHeOF6UxI/DNdlLsUUazTpol2sRqQgbZplpkB9t/HUSjUHq0OY1mwaUfxvJp/E9yDmuHZgUgzKMSAdUf2apwFm5bw3T7qSdJ0Y7hC9vG0v6kLT0EaPuQmfJ8Rt4xOyva9htKbzkxs9Kr0ujB6V4u41ZZW2oevqtGunC2+aCxkQzd42we0c47ypxnvl8gGAa76CDXenGaChPKSfeEMddnhFvjGfkSyqjD+dCxBF+IyTRDPtt6f5iF80lfv/559rsKYlHdbbgv30i5C/F2DzaB011BmcQwK1eWSGWsEWVFtQKNMdahTl2IMgvZwHcaw8TMqgqqgZ7ZZ6lMR+UA8l', > u'ecdsa-sha2-nistp256 > AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHkoeGOzfQzqYOGQs2bdgL0jOBul+/eTBZ0HBM8HW3Wb5O15Fv3rt8jRp+xdSQcdG3DV5yPfjd66Fyz5hCTKS6s=', > u'ssh-ed25519 > AAAAC3NzaC1lZDI1NTE5AAAAIH5/uXvdJ1l+uTAk0rgbjKeTBx9HRWk7w+xJLHMt/yRx'), > updatedns=False, version=u'2.26'): SUCCESS > [Fri Jul 01 11:37:37.961175 2016] [wsgi:error] [pid 38272] ipa: ERROR: > non-public: ValueError: User name is defined only for user and enterprise > principals > [Fri Jul 01 11:37:37.961220 2016] [wsgi:error] [pid 38272] Traceback (most > recent call last): > [Fri Jul 01 11:37:37.961224 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 352, in > wsgi_execute > [Fri Jul 01 11:37:37.961226 2016] [wsgi:error] [pid 38272] result = > self.Command[name](*args, **options) > [Fri Jul 01 11:37:37.961229 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__ > [Fri Jul 01 11:37:37.961259 2016] [wsgi:error] [pid 38272] return > self.__do_call(*args, **options) > [Fri Jul 01 11:37:37.961262 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in __do_call > [Fri Jul 01 11:37:37.961265 2016] [wsgi:error] [pid 38272] ret = > self.run(*args, **options) > [Fri Jul 01 11:37:37.961267 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run > [Fri Jul 01 11:37:37.961269 2016] [wsgi:error] [pid 38272] return > self.execute(*args, **options) > [Fri Jul 01 11:37:37.961271 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 456, in execute > [Fri Jul 01 11:37:37.961274 2016] [wsgi:error] [pid 38272] > caacl_check(principal_type, principal, ca, profile_id) > [Fri Jul 01 11:37:37.961276 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 227, in > caacl_check > [Fri Jul 01 11:37:37.961278 2016] [wsgi:error] [pid 38272] principal, ca, > profile_id): > [Fri Jul 01 11:37:37.961280 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/caacl.py", line 126, in > acl_evaluate > [Fri Jul 01 11:37:37.961283 2016] [wsgi:error] [pid 38272] req = > _acl_make_request(principal_type, principal, ca_id, profile_id) > [Fri Jul 01 11:37:37.961285 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/caacl.py", line 68, in > _acl_make_request > [Fri Jul 01 11:37:37.961287 2016] [wsgi:error] [pid 38272] req.user.name = > principal.username > [Fri Jul 01 11:37:37.961289 2016] [wsgi:error] [pid 38272] File > "/usr/lib/python2.7/site-packages/ipapython/kerberos.py", line 169, in username > [Fri Jul 01 11:37:37.961292 2016] [wsgi:error] [pid 38272] "User name is > defined only for user and enterprise principals") > [Fri Jul 01 11:37:37.961294 2016] [wsgi:error] [pid 38272] ValueError: User > name is defined only for user and enterprise principals > [Fri Jul 01 11:37:37.961656 2016] [wsgi:error] [pid 38272] ipa: INFO: > [xmlserver] > host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: > cert_request(u'MIIEDjCCAvYCAQAwZTEzMDEGA1UEChMqRE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NMS4wLAYDVQQDEyV2bS0wNDYuYWJjLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1zWanFx8qhfuHDgCjkQxkNBx6PoHfc+xNdb2OBcPfcfHL9HMjRGmTWN+CRZ388C+qxaExYed6WfmB/pK+b2M3fOnz1SRBPqicnCERP3G4mg02sL8cH068FShJvJECxWZxhvMiy/I0l/gRef1CJhaMJ5XGGuhZrLn3+Cv1BEgQDajBFsaZVeWTmwvROTjTht95QLUp8r9laPlGDzYnCdaWQ/R6Z1y+Mdu3I5VmxYL8TsH3NTDHjPvkDuQfPcdGkWp9V06QMp7MZeX0DEhsG2jeQc309xbe3vaPNPWClUv9OQX9xDgdlKO3E6UZKKWjXNUpqErpSFC1PiFqsMbJ36J7QIDAQABoIIBYjArBgkqhkiG9w0BCRQxHh4cAEwAbwBjAGEAbAAgAEkAUABBACAAaABvAHMAdDCCATEGCSqGSIb3DQEJDjGCASIwggEeMIHrBgNVHREBAQAEgeAwgd2gZQYKKwYBBAGCNxQCA6BXDFVob3N0L3ZtLTA0Ni5hYmMuaWRtLmxhYi5lbmcuYnJxLnJlZGhhdC5jb21ARE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NoHQGBisGAQUCAqBqMGigLBsqRE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NoTgwNqADAgEBoS8wLRsEaG9zdBsldm0tMDQ2LmFiYy5pZG0ubGFiLmVuZy5icnEucmVkaGF0LmNvbTAMBgNVHRMBAf8EAj! > AAMCAGA1UdDgEBAAQWBBQQxo41ZpwB24cjTd1cxY9eKbxNkTANBgkqhkiG9w0BAQsFAAOCAQEAERsZQANNrwiDBTEa0Kpif5DB/lfRjSedZpIL/mPPRUJnKus/9hV5gyUZcUQ+c2NEwvIApBJk0TeSIU0xj+dFOsqaN8iPj05XI5axEnBOqGdkHfjxSe96eR7WHCX8JJPdy5SMcoa1T3R6+4myq2/CWceTNcfxM4DdAY5kYvaePOPb13l3YUy9yB12QhDx+BBTNfmsmVxvGkySfegJcJMacQrbIk3AAoj3BklrTSQPqESBvqSVWT/yZE2HcQ6H2aLfeChdieYFsl/gPqCbLDKQA7gdK9Pv5w2dDzMGvpNne/1MCksu9MD9Ys9KvuugOjWNHciglO/kwF4ZJbfJsRqz0Q==', > principal=u'host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', > add=True, version=u'2.51'): ValueError > > > I suspect that this is a regression caused by Kerberos aliases support but I'm > not going to ACK this until I can test it thoroughly. Okay, after '[PATCH 0178] Fix incorrect check for principal type when evaluating CA ACLs' it works. ACK. -- Petr^2 Spacek From pspacek at redhat.com Fri Jul 1 11:26:42 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 13:26:42 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Create server certs with DNS altname In-Reply-To: <20160120040409.GN31821@dhcp-40-8.bne.redhat.com> References: <20151207052611.GG23644@dhcp-40-8.bne.redhat.com> <5665813B.90406@redhat.com> <20151207224639.GL23644@dhcp-40-8.bne.redhat.com> <56660D1D.6000109@redhat.com> <20151208090638.GQ23644@dhcp-40-8.bne.redhat.com> <20160120040409.GN31821@dhcp-40-8.bne.redhat.com> Message-ID: On 20.1.2016 05:04, Fraser Tweedale wrote: > On Tue, Dec 08, 2015 at 07:06:39PM +1000, Fraser Tweedale wrote: >> On Mon, Dec 07, 2015 at 05:50:05PM -0500, Rob Crittenden wrote: >>> Fraser Tweedale wrote: >>>> On Mon, Dec 07, 2015 at 01:53:15PM +0100, Martin Kosek wrote: >>>>> On 12/07/2015 06:26 AM, Fraser Tweedale wrote: >>>>>> The attached patch fixes >>>>>> https://fedorahosted.org/freeipa/ticket/4970. >>>>>> >>>>>> Note that the problem is addressed by adding the appropriate request >>>>>> extension to the CSR; the fix does not involve changing the default >>>>>> profile behaviour, which is complicated (see ticket for details). >>>>> >>>>> Thanks for the patch! This is something we should really fix, I already get >>>>> warnings in my Python scripts when I hit sites protected by such HTTPS cert: >>>>> >>>>> /usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:264: >>>>> SubjectAltNameWarning: Certificate for projects.engineering.redhat.com has no >>>>> `subjectAltName`, falling back to check for a `commonName` for now. This >>>>> feature is being removed by major browsers and deprecated by RFC 2818. (See >>>>> https://github.com/shazow/urllib3/issues/497 for details.) >>>>> >>>>> Should we split ticket 4970, for the FreeIPA server part and then for cert >>>>> profile part? As it looks like the FreeIPA server will be fixed even in FreeIPA >>>>> 4.3.x and the other part later. >>>>> >>>>> How difficult do you see the general FreeIPA Certificate Profile part of this >>>>> request? Is it a too big task to handle in 4.4 time frame? >>>>> >>>> I will split the ticket and would suggest 4.4 Backlog - it might be >>>> doable but is a lower priority than e.g. Sub-CAs. >>> >>> If you are going to defer the profile part then you should probably >>> update the client to also include a SAN if --request-cert is provided. >>> >>> rob >>> >> Yes, good idea. Updated patch attached. >> >> Cheers, >> Fraser > > Bump, with rebased patch. Hi, this seems to work for Apache on IPA server & client cert. ACK. Interestingly enough I found out that Dogtag cert used on port 8443 does not have any SAN. Is it in scope of this ticket? -- Petr^2 Spacek From mbasti at redhat.com Fri Jul 1 11:29:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 13:29:57 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <20160701110843.dwmmbwxaaogwf3t7@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> <20160701102346.GR9283@10.4.128.1> <20160701110843.dwmmbwxaaogwf3t7@redhat.com> Message-ID: <2e4d1655-d817-0403-ff2d-20fecca80ffa@redhat.com> On 01.07.2016 13:08, Alexander Bokovoy wrote: > On Fri, 01 Jul 2016, Lukas Slebodnik wrote: >> On (01/07/16 11:13), Lenka Doudova wrote: >>> And, of course, a patch file :) >>> >>> >>> On 07/01/2016 11:09 AM, Lenka Doudova wrote: >>>> Hi all, >>>> >>>> here's patch with basic test suite for support of UPN. >>>> >>>> Note: it needs to be applied on top of my patch 0025.2 (or later, if >>>> there's will be more fixes to that patch). >>>> >>>> >>>> Lenka >>>> >>> >> >>> From 5c8cb8727322371b7246f6d939b38ac1cbd61e4c Mon Sep 17 00:00:00 2001 >>> From: Lenka Doudova >>> Date: Fri, 1 Jul 2016 11:00:57 +0200 >>> Subject: [PATCH] Tests: Support of UPN for trusted domains >>> >>> Basic set of tests to verify support of UPN functionality. >>> >>> Test cases: >>> - establish trust >>> - verify the trust recognizes UPN >>> - verify AD user with UPN can be resolved >>> - verify AD user with UPN can authenticate >>> - remove trust >>> >>> https://fedorahosted.org/freeipa/ticket/5354 >>> --- >>> ipatests/test_integration/test_trust.py | 32 >>> ++++++++++++++++++++++++++++++++ >>> 1 file changed, 32 insertions(+) >>> >>> diff --git a/ipatests/test_integration/test_trust.py >>> b/ipatests/test_integration/test_trust.py >>> index >>> d662e80727b6eab3df93166d35ddbaea6a0f6f7a..e8fdc6ba68fb6275a0d7920c76ca434ed830ed84 >>> 100644 >>> --- a/ipatests/test_integration/test_trust.py >>> +++ b/ipatests/test_integration/test_trust.py >>> @@ -388,3 +388,35 @@ class >>> TestExternalTrustWithRootDomain(ADTrustBase): >>> >>> tasks.remove_trust_with_ad(self.master, self.ad_domain) >>> tasks.clear_sssd_cache(self.master) >>> + >>> + >>> +class TestTrustWithUPN(ADTrustBase): >>> + """ >>> + Test support of UPN for trusted domains >>> + """ >>> + def test_upn_in_nonposix_trust(self): >>> + """ Check that UPN is listed as trust attribute """ >>> + result = self.master.run_command(['ipa', 'trust-show', >>> self.ad_domain, >>> + '--all', '--raw']) >>> + >>> + assert "ipantadditionalsuffixes: UPNsuffix.com" in >>> result.stdout_text >>> + >>> + def test_upn_user_resolution_in_nonposix_trust(self): >>> + """ Check that user with UPN can be resolved """ >>> + upnuser = 'upnuser at UPNsuffix.com' >>> + result = self.master.run_command(['getent', 'passwd', >>> upnuser]) >> Is there a special reason for not using pwd.getpwnam() ? > Technically -- yes. In case there was a change in the system > configuration (/etc/nsswitch.conf), then these changes wouldn't be > reflected in the application that is already using NSSWITCH interface. > > However, in this particular case no change to config files is expected > so pwd.getpwnam() can be used. Please note that the commands are executed remotely in CI tests, pwd.getpwnam() provides only local data. Martin^2 From mbasti at redhat.com Fri Jul 1 11:34:12 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 13:34:12 +0200 Subject: [Freeipa-devel] [PATCH 0148] client-install: log exceptions from certmonger.request_cer In-Reply-To: <0a0abe42-5e64-419c-bcc6-6006c6f59a30@redhat.com> References: <0a0abe42-5e64-419c-bcc6-6006c6f59a30@redhat.com> Message-ID: On 01.07.2016 11:57, Petr Spacek wrote: > Hello, > > client-install: log exceptions from certmonger.request_cert > > > ACK Pushed to master: dc5b2eaa772fda5673b222bc9107cf5b85c1295d -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Jul 1 11:42:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 13:42:00 +0200 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: References: Message-ID: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> On 29.06.2016 20:46, Ben Lipton wrote: > The attached patch silences some annoying messages I've been getting > when upgrading the freeipa-client package on F24: > """ > WARNING: 'UseLogin yes' is not supported in Fedora and may cause > several problems. > Could not load host key: /etc/ssh/ssh_host_dsa_key > """ > > Since the script causing the message only looks at the return code > from sshd to determine the right options to use, I thought it might be > ok to discard the output. What do you think? > > Ben > > Hello, I don't like to hiding errors/warnings. Can you determine and solve the root cause? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri Jul 1 12:30:31 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 1 Jul 2016 22:30:31 +1000 Subject: [Freeipa-devel] [PATCH] 0086 Add --ca option to cert-status In-Reply-To: <8024f8c4-43e0-70de-3f22-8007b0784e04@redhat.com> References: <20160629041103.GB4200@dhcp-40-8.bne.redhat.com> <20160629084722.GF4200@dhcp-40-8.bne.redhat.com> <57bb0b1b-941d-2f45-974b-2aca133050b0@redhat.com> <20160701044736.GG4200@dhcp-40-8.bne.redhat.com> <0a90a203-8748-8e01-76f3-7354f6dcc2eb@redhat.com> <901d3b0c-859a-995e-da03-742bcee8fa83@redhat.com> <8024f8c4-43e0-70de-3f22-8007b0784e04@redhat.com> Message-ID: <20160701123031.GO4200@dhcp-40-8.bne.redhat.com> On Fri, Jul 01, 2016 at 10:05:48AM +0200, Jan Cholasta wrote: > On 1.7.2016 08:57, Jan Cholasta wrote: > > On 1.7.2016 06:54, Jan Cholasta wrote: > > > On 1.7.2016 06:47, Fraser Tweedale wrote: > > > > On Fri, Jul 01, 2016 at 05:55:35AM +0200, Jan Cholasta wrote: > > > > > On 29.6.2016 12:18, Jan Cholasta wrote: > > > > > > On 29.6.2016 10:47, Fraser Tweedale wrote: > > > > > > > On Wed, Jun 29, 2016 at 10:04:05AM +0200, Jan Cholasta wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 29.6.2016 06:11, Fraser Tweedale wrote: > > > > > > > > > Dear team, > > > > > > > > > > > > > > > > > > The attached patch implements the --ca option for the rest of the > > > > > > > > > cert-blah commands (https://fedorahosted.org/freeipa/ticket/5999). > > > > > > > > > > > > > > > > 1) I don't think cert-status should be treated specially. The > > > > > > > > operation to > > > > > > > > check status of a certificate request is not specific to Dogtag. > > > > > > > > > > > > > > > I'm happy to add the option, with the caveat that because (of top of > > > > > > > head) there is not (yet) a way in Dogtag to distinguish/filter > > > > > > > requests by target CA, value may go unused. > > > > > > > > > > > > IMO that's OK, since it's a safe non-descructive operation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) cert-show is called twice in cert-revoke. Can we call it just > > > > > > > > once? > > > > > > > > > > > > > > > I'll address this in next patchset. > > > > > > > > > > > > OK. > > > > > > > > > > ACK on the first version of the patch, since it's better than > > > > > nothing. The > > > > > ticket remains open, please fix the rest ASAP. > > > > > > > > > > Added VERSION bump and pushed to master: > > > > > ffb1f5b1f24f0de30529d50f8c8dfb9a896c149e > > > > > > > > > > Honza > > > > > > > > > New patch 0086 attached, adding the option to cert-status command. > > > > > > Thanks. We could at least check if the specified CA exists, couldn't we? > > > > To speed things up, I have updated your patch with this, see the > > attachment. > > > > If the change looks good to you, we can push the patch. > > Your original patch works for me, ACK. My change can be pushed under the > one-liner rule, so pushing them combined in the modified patch. > > Pushed to master: 4844eaec197690e21c6cf44743df7f456d0e185d > Jan, thanks for pushing that along. My WIP was much the same, but I got bitten by stale API schema on client side and it did not know about the --ca option. I revisited it tonight, but by then you had pushed the commit :) Cheers, Fraser From ofayans at redhat.com Fri Jul 1 12:38:01 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 1 Jul 2016 14:38:01 +0200 Subject: [Freeipa-devel] [Test][patch-0052] Test for incorrect client domain In-Reply-To: References: <57738D26.50404@redhat.com> <57751347.50908@redhat.com> Message-ID: <57766429.4090901@redhat.com> Hi Martin. Now I have this client installation thing sorted out. The test works as expected On 06/30/2016 02:57 PM, Martin Basti wrote: > > > On 30.06.2016 14:40, Oleg Fayans wrote: >> Hi Martin, >> >> Attached is a new version of the patch with two test cases separated. >> >> On 06/29/2016 12:23 PM, Martin Basti wrote: >>> >>> On 29.06.2016 10:56, Oleg Fayans wrote: >>>> >>> Hello, >>> >>> + assert_error(result, >>> + "Failed to verify that %s is an IPA Server" % >>> + self.master.hostname) >>> >>> >>> I would expect this error there: >>> >>> "Cannot promote this client to a replica. Local domain '{local}' does >>> not match IPA domain '{ipadomain}'. " >> Right, that's what this ticket is about: >> https://fedorahosted.org/freeipa/ticket/6006 >> >> Once these changes are implemented, we can update this test > > Wat? > > You get exactly the right message from ipa-replica-install, tested, > reviewed by several people. >> >>> You should not use random REALM, in this case you don't test domains but >>> realms. You can leave the test with incorrect realm there, but as >>> separated testcase >> Oh, ok. But it does not seem possible to setup client providing only >> --realm without --domain: installer would not do it. >> > > Try to read again: "should not use *random* REALM". Nothing prevents you > to use, --realm=TEST.REALM --domain=random-blah-domain >> >>> Martin^2 >>> >>> >> >> > > NACK > > + domain_name = 'exxample.test' > + realm_name = domain_name.upper() > > you still use random realm name, and you still don't test > ipa-replica-install, that ticket has nothing related to domain in > ipa-client-install, it is related to replica promotion > > Martin^2 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0052.2-Test-for-incorrect-client-domain.patch Type: text/x-patch Size: 3440 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Jul 1 12:38:09 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 14:38:09 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> Message-ID: On 07/01/2016 06:36 AM, Lenka Doudova wrote: > > > On 06/30/2016 05:01 PM, Martin Babinsky wrote: >> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>> Hi, >>> >>> attaching patch with some basic coverage for external trust feature. Bit >>> more detailed info in commit message. >>> >>> Since the feature requires me to run commands previously used only for >>> forest root domains even for subdomains, I made some changes in >>> ipatests/test_integration/tasks.py file, so that it would enable me to >>> reuse existing function without copy-pasting them for one variable >>> change. >>> >>> >>> Lenka >>> >>> >>> >> >> Hi Lenka, >> >> I have a few comments: >> >> 1.) >> >> -def establish_trust_with_ad(master, ad, extra_args=()): >> +def establish_trust_with_ad(master, ad, extra_args=(), subdomain=False): >> >> This modification seems extremely kludgy to me. >> >> I would rather change the function signature to: >> >> -def establish_trust_with_ad(master, ad, extra_args=()): >> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >> >> and pass the domain name itself to the function instead of doing magic >> inside. The same goes with `remove trust_with_ad`. You may want to fix >> the calls to them in existing code so that the domain is passed >> instead of the whole trust object. >> >> 2.) >> >> +def sync_time_hostname(host, srv_hostname): >> + """ >> + Syncs time with the remote server given by its hostname. >> + Please note that this function leaves ntpd stopped. >> + """ >> + host.run_command(['systemctl', 'stop', 'ntpd']) >> + host.run_command(['ntpdate', srv_hostname]) >> + >> + >> >> this looks like a duplicate of the function above it, why is it even >> needed? >> >> 3.) >> +class TestExternalTrustWithSubdomain(ADTrustBase): >> + """ >> + Test establishing external trust with subdomain >> + """ >> + >> + @classmethod >> + def install(cls, mh): >> + super(ADTrustBase, cls).install(mh) >> + cls.ad = cls.ad_domains[0].ads[0] >> + cls.install_adtrust() >> + cls.check_sid_generation() >> + >> + # Determine whether the subdomain AD is available >> + try: >> + child_ad = cls.host_by_role(cls.optional_extra_roles[0]) >> + cls.ad_subdomain = >> '.'.join(child_ad.hostname.split('.')[1:]) >> + cls.ad_subdomain_hostname = child_ad.hostname >> + except LookupError: >> + cls.ad_subdomain = None >> + >> + cls.configure_dns_and_time() >> >> Please use proper OOP practices when overriding the behavior of the >> base test class. >> >> For starters you could rewrite the install method like this: >> >> + @classmethod >> + def install(cls, mh): >> + # Determine whether the subdomain AD is available >> + try: >> + cls.child_ad = cls.host_by_role(cls.optional_extra_roles[0]) >> + cls.ad_subdomain = >> '.'.join(child_ad.hostname.split('.')[1:]) >> + cls.ad_subdomain_hostname = child_ad.hostname >> + except LookupError: >> + raise nose.SkipTest("AFAIK this will skip the whole test >> class") >> + super(ADTrustBase, cls).install(mh) >> >> with child_ad stored as class attribute, you can override >> `configure_dns_and_time`: >> + def configure_dns_and_time(cls): >> + tasks.configure_dns_for_trust(cls.master, cls.ad_subdomain) >> # no need to re-implement the function just to get to the child >> AD DC hostname now >> + tasks.sync_time(cls.master, cls.child_ad.hostname) >> >> You can then use this class as an intermediary in the hierarchy and >> inherit the other external/non-external trust test classes from it, >> since most setup method in them are just copy-pasted from this one. >> > Hi, > thanks for review, fixed patch attached. > > Lenka Hi Lenka, I am still not happy about the patch underutilizing the potential for a proper inheritance hierarchy and instead relying on a staggering amounts of copy-pasting for implementation. I am attaching a quick untested patch illustrating how the implementation should look like. Also you have some leftovers from previous revision, please fix them: Pylint is running, please wait ... ************* Module ipatests.test_integration.test_trust ipatests/test_integration/test_trust.py:236: [E1101(no-member), TestExternalTrustWithSubdomain.configure_dns_and_time] Module 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) ipatests/test_integration/test_trust.py:243: [E1123(unexpected-keyword-arg), TestExternalTrustWithSubdomain.test_establish_trust] Unexpected keyword argument 'subdomain' in function call) ipatests/test_integration/test_trust.py:279: [E1123(unexpected-keyword-arg), TestExternalTrustWithSubdomain.test_remove_nonposix_trust] Unexpected keyword argument 'subdomain' in function call) ipatests/test_integration/test_trust.py:330: [E1101(no-member), TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) Makefile:137: recipe for target 'lint' failed make: *** [lint] Error 1 sending incremental file list (this is before I started meddling with it) -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-desired-test-class-hierarchy.patch Type: text/x-patch Size: 7903 bytes Desc: not available URL: From mkubik at redhat.com Fri Jul 1 12:42:24 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 1 Jul 2016 14:42:24 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> Message-ID: <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> On 06/16/2016 03:23 PM, Lenka Doudova wrote: > Hi, > > attached are tests for authentication indicators. Please note: > > 1. newly created service tracker is not exactly complete, list of > unimplemented methods is in doc. These methods can be filled in when > existing declarative tests are refactored. > > 2. patch 0015 depends on 0014, so it should not be pushed without it. > > > Lenka > > > patch 0014: In the update method, what happens when the updated attributes contain addattr? It is not clear to me. Is it necessary? patch 0015: host1 and service2 do not tell anything about the purpose of the fixture. Please assign more descriptive names to them. Why do the fixtures have 'function' scope? Does the service entry exist during the second and third test case? patch 0016: Per offline discussion, admin user has no special privileges here, LGTM. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Jul 1 12:48:20 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 1 Jul 2016 14:48:20 +0200 Subject: [Freeipa-devel] [PATCH 0548] Fix replica install with CA In-Reply-To: References: <240c23fc-4c58-6af4-70df-0cfd650bbf84@redhat.com> Message-ID: On 30.6.2016 18:05, Martin Basti wrote: > > > On 30.06.2016 13:20, Martin Basti wrote: >> >> >> On 30.06.2016 13:18, Petr Spacek wrote: >>> On 30.6.2016 13:04, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5966 >>>> >>>> This only for master branch, ipa-4-3 fix will be different (soon) >>>> >>>> Patch attached >>> ACK >>> >> Pushed to master: a155f692e7ad7807a5ea28250d1e72b3e821991e >> > > And 4.3 patch attached. ACK -- Petr^2 Spacek From mbabinsk at redhat.com Fri Jul 1 13:04:42 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 15:04:42 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> Message-ID: <84d6fa1f-265c-9408-3ecd-65c640da1793@redhat.com> On 07/01/2016 11:13 AM, Lenka Doudova wrote: > And, of course, a patch file :) > > > On 07/01/2016 11:09 AM, Lenka Doudova wrote: >> Hi all, >> >> here's patch with basic test suite for support of UPN. >> >> Note: it needs to be applied on top of my patch 0025.2 (or later, if >> there's will be more fixes to that patch). >> >> >> Lenka >> > > > Hi Lenka, test data such as usernames, etc. should be stored either in separate resource files or at least as class attributes like this: diff --git a/ipatests/test_integration/test_trust.py b/ipatests/test_integration/test_trust.py index e8fdc6b..86ba7cc 100644 --- a/ipatests/test_integration/test_trust.py +++ b/ipatests/test_integration/test_trust.py @@ -394,28 +394,33 @@ class TestTrustWithUPN(ADTrustBase): """ Test support of UPN for trusted domains """ + upn_suffix = 'UPNsuffix.com' + upn_username = 'upnuser' + upn_princ = '{}@{}'.format(upn_username, upn_suffix) + upn_password = 'Secret123456' + def test_upn_in_nonposix_trust(self): """ Check that UPN is listed as trust attribute """ result = self.master.run_command(['ipa', 'trust-show', self.ad_domain, '--all', '--raw']) - assert "ipantadditionalsuffixes: UPNsuffix.com" in result.stdout_text + assert ("ipantadditionalsuffixes: {}".format(self.upn_suffix) in + result.stdout_text) def test_upn_user_resolution_in_nonposix_trust(self): """ Check that user with UPN can be resolved """ - upnuser = 'upnuser at UPNsuffix.com' - result = self.master.run_command(['getent', 'passwd', upnuser]) + result = self.master.run_command(['getent', 'passwd', self.upn_princ]) # result will contain AD domain, not UPN - upnuser_regex = "^upnuser@{0}:\*:(\d+):(\d+):UPN User:/:$".format( - self.ad_domain) + upnuser_regex = "^{}@{}:\*:(\d+):(\d+):UPN User:/:$".format( + self.upn_username, self.ad_domain) assert re.search(upnuser_regex, result.stdout_text) def test_upn_user_authentication(self): """ Check that AD user with UPN can authenticate in IPA """ self.master.run_command(['systemctl', 'restart', 'krb5kdc']) - self.master.run_command(['kinit', '-C', '-E', 'upnuser at UPNsuffix.com'], - stdin_text='Secret123456') + self.master.run_command(['kinit', '-C', '-E', self.upn_princ], + stdin_text=self.upn_password) otherwise LGTM. -- Martin^3 Babinsky From mbasti at redhat.com Fri Jul 1 13:38:38 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 15:38:38 +0200 Subject: [Freeipa-devel] [PATCH 0146] Fix internal errors in host-add and other commands caused by DNS resolutio In-Reply-To: References: <666c475c-8c59-41ef-08f7-0f0592729c4a@redhat.com> Message-ID: On 01.07.2016 10:37, Martin Basti wrote: > > > On 01.07.2016 09:05, Petr Spacek wrote: >> On 30.6.2016 21:23, Petr Spacek wrote: >>> Hello, >>> >>> Fix internal errors in host-add and other commands caused by DNS >>> resolution >>> >>> Previously resolver was returning CheckedIPAddress objects. This >>> internal server error in cases where DNS actually returned reserved IP >>> addresses. >>> >>> Now the resolver is returning UnsafeIPAddress objects which do >>> syntactic >>> checks but do not filter IP addresses. >>> >>> >From now on we can decide if some IP address should be accepted >>> as-is or >>> if it needs to be contrained to some subset of IP addresses using >>> CheckedIPAddress class. >>> >>> This regression was caused by changes for >>> https://fedorahosted.org/freeipa/ticket/5710 >>> >>> >>> >>> I've split parser and checks into separate classes. Attached script >>> CheckedIPAddressRefactoring.py uses python-hypothesis to compare >>> results from >>> old and new implementations. It seems that all valid inputs return >>> the very >>> same results. The new implementation is a bit stricter when it comes to >>> invalid inputs (parse_netmask=False & addr=IPNetwork instance) but >>> as far as I >>> can tell this case could not happen in current IPA anyway. >>> >>> ipa-server-install, ipa-client-install, ipa-replica-install, and >>> ipa-ca-install on replica seem to work. DNS records for ipa-ca were >>> properly >>> updated after replica installation. Also installation on server >>> without A/AAAA >>> record in DNS and subsequent ipa-dns-install worked just fine. >> >> My bad, I forgot to attach cleanup patch 147 which is prerequisite >> for 146. >> (Sorry for the numbering.) >> > ACK > > master: > * ce1f9ca51bd91ed66233c1bac7eb05fac9c855c7 Remove unused is_local(), > interface, and defaultnet from CheckedIPAddress > * 5e78b54d7c532bec0ee5a4ce3f1b6d6c94d17c51 Fix internal errors in > host-add and other commands caused by DNS resolution > > I will review 4.3 later > ACK ipa-4-3: * 0db277eb224b92319aede319999d1840db781c10 Remove unused is_local(), interface, and defaultnet from CheckedIPAddress * b8d5881ba93b00653ba42c61369f19ca27fb7a64 Fix internal errors in host-add and other commands caused by DNS resolution From frenaud at redhat.com Fri Jul 1 13:51:02 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Fri, 1 Jul 2016 15:51:02 +0200 Subject: [Freeipa-devel] [PATCH] pylint fixes In-Reply-To: <6b1ff078-f1dd-c5d3-607b-2e2e84b9d878@redhat.com> References: <495588b7-9e02-942d-81fd-01e852f07e6c@redhat.com> <623d1af4-7e4c-63ce-d6d3-3874a6ef87cd@redhat.com> <9fb20d03-4559-8ad2-1e95-4c1da386ae06@redhat.com> <7bf2dcab-0a71-abc6-2062-aa291fd82278@redhat.com> <6b1ff078-f1dd-c5d3-607b-2e2e84b9d878@redhat.com> Message-ID: <32f24f39-4f11-f10b-667a-f0cb279e4639@redhat.com> On 06/21/2016 01:51 PM, Martin Basti wrote: > > > On 21.06.2016 08:38, Florence Blanc-Renaud wrote: >> On 06/20/2016 07:08 PM, Martin Basti wrote: >>> >>> >>> On 20.06.2016 19:06, Martin Basti wrote: >>>> >>>> >>>> >>>> On 20.06.2016 12:00, Florence Blanc-Renaud wrote: >>>>> On 06/09/2016 05:10 PM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> I've received a bunch of pylint fixes produced by upstream >>>>>> contributor who is >>>>>> not subscribed to the list so I'm resending them here. >>>>>> >>>>>> All credit goes to B?rta Jan <55042barta at sstebrno.eu>. >>>>>> >>>>>> Flo, if you have time for it I think that it could be a good >>>>>> exercise which >>>>>> will lead you to various dark corners in IPA :-) >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Date: Fri, 3 Jun 2016 14:57:16 +0200 >>>>>> From: B?rta Jan <55042barta at sstebrno.eu> >>>>>> To: pspacek at redhat.com >>>>> ___- In the patch >>>>> 0002-pylint-fix-simplifiable-if-statement-warnings.patch:_ >>>>> >>>>> diff --git a/ipatests/test_integration/tasks.py >>>>> b/ipatests/test_integration/tasks.py >>>>> index aebd907..ca2e10f 100644 >>>>> --- a/ipatests/test_integration/tasks.py >>>>> +++ b/ipatests/test_integration/tasks.py >>>>> @@ -149,11 +149,7 @@ def host_service_active(host, service): >>>>> res = host.run_command(['systemctl', 'is-active', '--quiet', >>>>> service], >>>>> raiseonerr=False) >>>>> >>>>> - if res.returncode == 0: >>>>> - return True >>>>> - else: >>>>> - return False >>>>> - >>>>> + return res.returncode >>>>> >>>>> should be instead: return res.returncode *== 0* (otherwise the return >>>>> type is an int and not a boolean). >>>>> >>>>> In the same file: >>>>> @@ -295,11 +291,7 @@ def >>>>> master_authoritative_for_client_domain(master, client): >>>>> zone = ".".join(client.hostname.split('.')[1:]) >>>>> result = master.run_command(["ipa", "dnszone-show", zone], >>>>> raiseonerr=False) >>>>> - if result.returncode == 0: >>>>> - return True >>>>> - else: >>>>> - return False >>>>> - >>>>> + result.returncode == 0 >>>>> >>>>> should be instead: *return* result.returncode == 0 (otherwise there >>>>> is no return statement) >>>>> >>>>> diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py >>>>> index 197814c..36b6ba5 100644 >>>>> --- a/ipaserver/plugins/dogtag.py >>>>> +++ b/ipaserver/plugins/dogtag.py >>>>> @@ -1689,12 +1689,7 @@ class ra(rabase.rabase): >>>>> # Return command result >>>>> cmd_result = {} >>>>> >>>>> - if parse_result.get('revoked') == 'yes': >>>>> - cmd_result['revoked'] = True >>>>> - else: >>>>> - cmd_result['revoked'] = False >>>>> - >>>>> - return cmd_result >>>>> + cmd_result['revoked'] = parse_result.get('revoked') >>>>> >>>>> Should be instead: cmd_result['revoked'] = >>>>> parse_result.get('revoked') *== 'yes'* (otherwise the type is a >>>>> string and not a boolean) >>>>> >>>>> _- in the patch 00__04-pylint-fix-unneeded-not.patch_ >>>>> >>>>> @@ -632,7 +632,7 @@ class host_add(LDAPCreate): >>>>> options['ip_address'], >>>>> check_forward=True, >>>>> check_reverse=check_reverse) >>>>> - if not options.get('force', False) and not 'ip_address' in >>>>> options: >>>>> + if options.get('force', False) and 'ip_address' not in >>>>> options: >>>>> >>>>> Should be instead: if *not* options.get('force', False) and >>>>> 'ip_address' not in options: >>>>> because of operators precedence >>>>> >>>>> I will review patches 0005 to 0010 later today. >>>>> Flo. >>>>> >>>>> >>>> >>>> How about patches 1, and 3? Because patches are independent, we can >>>> separately ACK them and push them. >>>> >>>> Martin^2 >>>> >>>> >>> >>> Sorry, I just noticed that there is no patch 1 :) >>> >>> >> Patch 0003 is OK, ACK for this one. >> Flo. >> > Patch 0003: Pushed to master: 94909d21dbf033cbe34089782c430ec25b9ad0bc > Hi, please find my comments on the remaining patches. - Patch 0005 must be rebased because of changes in ipatests/test_integration/tasks.py the patch can also modify pylintrc (remove pointless-statement) - Patch 0006: no need to rename the items in "for e in ...", renaming the Exception as exc should be enough - Patch 0007: pylintrc should remove old-style-class instead of bad-classmethod-argument - Patch 0008: this one should remove bad-classmethod-argument in pylintrc - Patch 0009: ok - Patch 0010: In the __bind method(self, obj_type), cls variable is already used thus replacing self with cls can be done only if cls is also renamed into something else. Flo. From mkubik at redhat.com Fri Jul 1 13:57:29 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 1 Jul 2016 15:57:29 +0200 Subject: [Freeipa-devel] [patch 0038-0040] Sub CA test patches In-Reply-To: References: <072dcce1-3a76-9f26-62d7-a70e403239af@redhat.com> <20160624014203.GO4200@dhcp-40-8.bne.redhat.com> <0e08d68d-cc4e-3f8c-de7f-be8d21ee91f7@redhat.com> <20160627005734.GR4200@dhcp-40-8.bne.redhat.com> Message-ID: On 06/27/2016 01:31 PM, Milan Kub?k wrote: > On 06/27/2016 02:57 AM, Fraser Tweedale wrote: >> On Fri, Jun 24, 2016 at 12:08:24PM +0200, Milan Kub?k wrote: >>> On 06/24/2016 03:42 AM, Fraser Tweedale wrote: >>>> On Tue, Jun 21, 2016 at 05:01:35PM +0200, Milan Kub?k wrote: >>>>> Hi Fraser and list, >>>>> >>>>> I have made changes to the test plan on the wiki [1] according to the >>>>> information in "[Testplan review] Sub CAs" thread. >>>>> >>>>> I also implemented the tests in the test plan: >>>>> >>>>> patch 0038 - CATracker and CA CRUD test >>>>> patch 0039 - extension to CA ACL test >>>>> patch 0040 - functional test with ACLs and certificate profile, >>>>> reusing my >>>>> previous S/MIME based tests. This patch also tests for the >>>>> cert-request >>>>> behavior when profile ID or CA cn are ommited. >>>>> >>>>> The tests ATM do not verify the Issuer name in the certificate >>>>> itself, just >>>>> from the ipa entry of the certificate. >>>>> >>>> The approach you are using:: >>>> >>>> assert cert_info['result']['issuer'] == >>>> smime_signing_ca.ipasubjectdn >>>> >>>> is not quite as you describe (these are virtual attributes, not >>>> attributes of an actual entry); but the approach is valid. >>> The issue then is in the wording? The other approach I could have >>> used here >>> is to retrieve the two certificates and compare the fields manually. >>> Are these virtual attributes created from the certificate itself? >>> >> That's correct. >> >>>>> Fraser, could you please verify my reasoning behind the test cases >>>>> for >>>>> cert-request in the patch 40? >>>>> >>>> The tests look OK. With the default CA / default profiles, is there >>>> appropriate isolation between test cases to ensure that if, e.g. >>>> some other test case adds/modifies CA ACLs such that these >>>> expected-to-fail tests now pass, that this does not affect the >>>> TestCertSignMIMEwithSubCA test case? >>>> >>>> Thanks, >>>> Fraser >>> The ACL, SMIME CA and S/MIME profile lifetime is constrained by the >>> class >>> scope >>> enforced by pytest. >>> The two test cases depend on the fact documented in the designs and >>> that is >>> what >>> cert-request fallbacks to when CA or profile ID are not provided. >>> Unless something changes caIPAserviceCert profile or affiliated ACL, >>> then >>> the test cases >>> are safe. >>> >> If you have thought about possible interference from other tests, I >> am happy. >> >> Note another problematic scenario: what if a different (preceding) >> test adds a CA ACL that would allow the requests that you expect to >> fail? Just something to think about :) >> >> Thanks, >> Fraser > Then the failure would be problem of the preceding test and we would > need to fix it. We are dealing with test side effects > in other parts of the execution already... > > The test is constructed in a way that isolates it (to a certain > degree) by the mechanisms available > in pytest. Of course I cannot make the test future-proof or guarantee > that a bug in some other test > will not affect the execution of other tests as they all run against > one IPA instance. > I do not think, however, that potential misbehaving test case that > will interfere > should prevent us from implementing this and similar test cases. > > If you have some specific issue that is in the patch, I'm happy to fix > them. >>> I will try to think more about corner cases here. >>>>> [1]: http://www.freeipa.org/page/V4/Sub-CAs/Test_Plan >>>>> >>>>> Cheers >>>>> >>>>> -- >>>>> Milan Kubik >>>>> >>> Attaching rebased patches and removing the expected fail from one of >>> the >>> tests as ticket 5981 has fix posted. >>> >>> -- >>> Milan Kubik >>> > > Hi Fraser, can we continue with the review, please? -- Milan Kubik From mbasti at redhat.com Fri Jul 1 14:09:51 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 16:09:51 +0200 Subject: [Freeipa-devel] [Test][patch-0052] Test for incorrect client domain In-Reply-To: <57766429.4090901@redhat.com> References: <57738D26.50404@redhat.com> <57751347.50908@redhat.com> <57766429.4090901@redhat.com> Message-ID: <669d6d7f-bc76-d0d7-0ccf-39fd404b995e@redhat.com> On 01.07.2016 14:38, Oleg Fayans wrote: > Hi Martin. Now I have this client installation thing sorted out. The > test works as expected > > On 06/30/2016 02:57 PM, Martin Basti wrote: >> >> On 30.06.2016 14:40, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Attached is a new version of the patch with two test cases separated. >>> >>> On 06/29/2016 12:23 PM, Martin Basti wrote: >>>> On 29.06.2016 10:56, Oleg Fayans wrote: >>>> Hello, >>>> >>>> + assert_error(result, >>>> + "Failed to verify that %s is an IPA Server" % >>>> + self.master.hostname) >>>> >>>> >>>> I would expect this error there: >>>> >>>> "Cannot promote this client to a replica. Local domain '{local}' does >>>> not match IPA domain '{ipadomain}'. " >>> Right, that's what this ticket is about: >>> https://fedorahosted.org/freeipa/ticket/6006 >>> >>> Once these changes are implemented, we can update this test >> Wat? >> >> You get exactly the right message from ipa-replica-install, tested, >> reviewed by several people. >>>> You should not use random REALM, in this case you don't test domains but >>>> realms. You can leave the test with incorrect realm there, but as >>>> separated testcase >>> Oh, ok. But it does not seem possible to setup client providing only >>> --realm without --domain: installer would not do it. >>> >> Try to read again: "should not use *random* REALM". Nothing prevents you >> to use, --realm=TEST.REALM --domain=random-blah-domain >>>> Martin^2 >>>> >>>> >>> >> NACK >> >> + domain_name = 'exxample.test' >> + realm_name = domain_name.upper() >> >> you still use random realm name, and you still don't test >> ipa-replica-install, that ticket has nothing related to domain in >> ipa-client-install, it is related to replica promotion >> >> Martin^2 I have a few comments: 1) This is unused and should not be there + realm_name = domain_name.upper() 2) teardown_method shouldn't be more robust, what happens if client uninstall raises an error? 3) in both tests + '-w', self.master.config.dirman_password, -w means admin password (ipa-client-install --help), so you should use admin not directory manager password 4) + result = client.run_command(['ipa-client-install', '-U', '--domain', + self.master.domain.realm, '-w', did you mean: '--domain', self.master.domain.name.upper() From ldoudova at redhat.com Fri Jul 1 14:15:58 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 1 Jul 2016 16:15:58 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> Message-ID: On 07/01/2016 02:38 PM, Martin Babinsky wrote: > On 07/01/2016 06:36 AM, Lenka Doudova wrote: >> >> >> On 06/30/2016 05:01 PM, Martin Babinsky wrote: >>> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>>> Hi, >>>> >>>> attaching patch with some basic coverage for external trust >>>> feature. Bit >>>> more detailed info in commit message. >>>> >>>> Since the feature requires me to run commands previously used only for >>>> forest root domains even for subdomains, I made some changes in >>>> ipatests/test_integration/tasks.py file, so that it would enable me to >>>> reuse existing function without copy-pasting them for one variable >>>> change. >>>> >>>> >>>> Lenka >>>> >>>> >>>> >>> >>> Hi Lenka, >>> >>> I have a few comments: >>> >>> 1.) >>> >>> -def establish_trust_with_ad(master, ad, extra_args=()): >>> +def establish_trust_with_ad(master, ad, extra_args=(), >>> subdomain=False): >>> >>> This modification seems extremely kludgy to me. >>> >>> I would rather change the function signature to: >>> >>> -def establish_trust_with_ad(master, ad, extra_args=()): >>> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >>> >>> and pass the domain name itself to the function instead of doing magic >>> inside. The same goes with `remove trust_with_ad`. You may want to fix >>> the calls to them in existing code so that the domain is passed >>> instead of the whole trust object. >>> >>> 2.) >>> >>> +def sync_time_hostname(host, srv_hostname): >>> + """ >>> + Syncs time with the remote server given by its hostname. >>> + Please note that this function leaves ntpd stopped. >>> + """ >>> + host.run_command(['systemctl', 'stop', 'ntpd']) >>> + host.run_command(['ntpdate', srv_hostname]) >>> + >>> + >>> >>> this looks like a duplicate of the function above it, why is it even >>> needed? >>> >>> 3.) >>> +class TestExternalTrustWithSubdomain(ADTrustBase): >>> + """ >>> + Test establishing external trust with subdomain >>> + """ >>> + >>> + @classmethod >>> + def install(cls, mh): >>> + super(ADTrustBase, cls).install(mh) >>> + cls.ad = cls.ad_domains[0].ads[0] >>> + cls.install_adtrust() >>> + cls.check_sid_generation() >>> + >>> + # Determine whether the subdomain AD is available >>> + try: >>> + child_ad = cls.host_by_role(cls.optional_extra_roles[0]) >>> + cls.ad_subdomain = >>> '.'.join(child_ad.hostname.split('.')[1:]) >>> + cls.ad_subdomain_hostname = child_ad.hostname >>> + except LookupError: >>> + cls.ad_subdomain = None >>> + >>> + cls.configure_dns_and_time() >>> >>> Please use proper OOP practices when overriding the behavior of the >>> base test class. >>> >>> For starters you could rewrite the install method like this: >>> >>> + @classmethod >>> + def install(cls, mh): >>> + # Determine whether the subdomain AD is available >>> + try: >>> + cls.child_ad = >>> cls.host_by_role(cls.optional_extra_roles[0]) >>> + cls.ad_subdomain = >>> '.'.join(child_ad.hostname.split('.')[1:]) >>> + cls.ad_subdomain_hostname = child_ad.hostname >>> + except LookupError: >>> + raise nose.SkipTest("AFAIK this will skip the whole test >>> class") >>> + super(ADTrustBase, cls).install(mh) >>> >>> with child_ad stored as class attribute, you can override >>> `configure_dns_and_time`: >>> + def configure_dns_and_time(cls): >>> + tasks.configure_dns_for_trust(cls.master, cls.ad_subdomain) >>> # no need to re-implement the function just to get to the child >>> AD DC hostname now >>> + tasks.sync_time(cls.master, cls.child_ad.hostname) >>> >>> You can then use this class as an intermediary in the hierarchy and >>> inherit the other external/non-external trust test classes from it, >>> since most setup method in them are just copy-pasted from this one. >>> >> Hi, >> thanks for review, fixed patch attached. >> >> Lenka > > Hi Lenka, > > I am still not happy about the patch underutilizing the potential for > a proper inheritance hierarchy and instead relying on a staggering > amounts of copy-pasting for implementation. > > I am attaching a quick untested patch illustrating how the > implementation should look like. > > Also you have some leftovers from previous revision, please fix them: > > Pylint is running, please wait ... > ************* Module ipatests.test_integration.test_trust > ipatests/test_integration/test_trust.py:236: [E1101(no-member), > TestExternalTrustWithSubdomain.configure_dns_and_time] Module > 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) > ipatests/test_integration/test_trust.py:243: > [E1123(unexpected-keyword-arg), > TestExternalTrustWithSubdomain.test_establish_trust] Unexpected > keyword argument 'subdomain' in function call) > ipatests/test_integration/test_trust.py:279: > [E1123(unexpected-keyword-arg), > TestExternalTrustWithSubdomain.test_remove_nonposix_trust] Unexpected > keyword argument 'subdomain' in function call) > ipatests/test_integration/test_trust.py:330: [E1101(no-member), > TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module > 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) > Makefile:137: recipe for target 'lint' failed > make: *** [lint] Error 1 > sending incremental file list > > (this is before I started meddling with it) > > Thank you very much for the example, fixed patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0025.3-Tests-External-trust.patch Type: text/x-patch Size: 15476 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 1 14:27:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 16:27:57 +0200 Subject: [Freeipa-devel] [PATCH 0146] Fix internal errors in host-add and other commands caused by DNS resolutio In-Reply-To: References: <666c475c-8c59-41ef-08f7-0f0592729c4a@redhat.com> Message-ID: <9684f013-42f7-6f89-67a8-6e176c111f05@redhat.com> On 01.07.2016 10:37, Martin Basti wrote: > > > On 01.07.2016 09:05, Petr Spacek wrote: >> On 30.6.2016 21:23, Petr Spacek wrote: >>> Hello, >>> >>> Fix internal errors in host-add and other commands caused by DNS >>> resolution >>> >>> Previously resolver was returning CheckedIPAddress objects. This >>> internal server error in cases where DNS actually returned reserved IP >>> addresses. >>> >>> Now the resolver is returning UnsafeIPAddress objects which do >>> syntactic >>> checks but do not filter IP addresses. >>> >>> >From now on we can decide if some IP address should be accepted >>> as-is or >>> if it needs to be contrained to some subset of IP addresses using >>> CheckedIPAddress class. >>> >>> This regression was caused by changes for >>> https://fedorahosted.org/freeipa/ticket/5710 >>> >>> >>> >>> I've split parser and checks into separate classes. Attached script >>> CheckedIPAddressRefactoring.py uses python-hypothesis to compare >>> results from >>> old and new implementations. It seems that all valid inputs return >>> the very >>> same results. The new implementation is a bit stricter when it comes to >>> invalid inputs (parse_netmask=False & addr=IPNetwork instance) but >>> as far as I >>> can tell this case could not happen in current IPA anyway. >>> >>> ipa-server-install, ipa-client-install, ipa-replica-install, and >>> ipa-ca-install on replica seem to work. DNS records for ipa-ca were >>> properly >>> updated after replica installation. Also installation on server >>> without A/AAAA >>> record in DNS and subsequent ipa-dns-install worked just fine. >> >> My bad, I forgot to attach cleanup patch 147 which is prerequisite >> for 146. >> (Sorry for the numbering.) >> > ACK > > master: > * ce1f9ca51bd91ed66233c1bac7eb05fac9c855c7 Remove unused is_local(), > interface, and defaultnet from CheckedIPAddress > * 5e78b54d7c532bec0ee5a4ce3f1b6d6c94d17c51 Fix internal errors in > host-add and other commands caused by DNS resolution > > I will review 4.3 later > ACK ipa-4-3: * 0db277eb224b92319aede319999d1840db781c10 Remove unused is_local(), interface, and defaultnet from CheckedIPAddress * b8d5881ba93b00653ba42c61369f19ca27fb7a64 Fix internal errors in host-add and other commands caused by DNS resolution From mbasti at redhat.com Fri Jul 1 14:28:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 16:28:36 +0200 Subject: [Freeipa-devel] [PATCH 0548] Fix replica install with CA In-Reply-To: References: <240c23fc-4c58-6af4-70df-0cfd650bbf84@redhat.com> Message-ID: <2f19b334-ecec-adc2-c45d-0b5d15de0677@redhat.com> On 01.07.2016 14:48, Petr Spacek wrote: > On 30.6.2016 18:05, Martin Basti wrote: >> >> On 30.06.2016 13:20, Martin Basti wrote: >>> >>> On 30.06.2016 13:18, Petr Spacek wrote: >>>> On 30.6.2016 13:04, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5966 >>>>> >>>>> This only for master branch, ipa-4-3 fix will be different (soon) >>>>> >>>>> Patch attached >>>> ACK >>>> >>> Pushed to master: a155f692e7ad7807a5ea28250d1e72b3e821991e >>> >> And 4.3 patch attached. > ACK > Pushed to ipa-4-3: 4edd39fb05dfd92924fc7f0c37fee3d269edf298 From ldoudova at redhat.com Fri Jul 1 14:45:48 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 1 Jul 2016 16:45:48 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <84d6fa1f-265c-9408-3ecd-65c640da1793@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> <84d6fa1f-265c-9408-3ecd-65c640da1793@redhat.com> Message-ID: On 07/01/2016 03:04 PM, Martin Babinsky wrote: > On 07/01/2016 11:13 AM, Lenka Doudova wrote: >> And, of course, a patch file :) >> >> >> On 07/01/2016 11:09 AM, Lenka Doudova wrote: >>> Hi all, >>> >>> here's patch with basic test suite for support of UPN. >>> >>> Note: it needs to be applied on top of my patch 0025.2 (or later, if >>> there's will be more fixes to that patch). >>> >>> >>> Lenka >>> >> >> >> > > Hi Lenka, > > test data such as usernames, etc. should be stored either in separate > resource files or at least as class attributes like this: > > diff --git a/ipatests/test_integration/test_trust.py > b/ipatests/test_integration/test_trust.py > index e8fdc6b..86ba7cc 100644 > --- a/ipatests/test_integration/test_trust.py > +++ b/ipatests/test_integration/test_trust.py > @@ -394,28 +394,33 @@ class TestTrustWithUPN(ADTrustBase): > """ > Test support of UPN for trusted domains > """ > + upn_suffix = 'UPNsuffix.com' > + upn_username = 'upnuser' > + upn_princ = '{}@{}'.format(upn_username, upn_suffix) > + upn_password = 'Secret123456' > + > def test_upn_in_nonposix_trust(self): > """ Check that UPN is listed as trust attribute """ > result = self.master.run_command(['ipa', 'trust-show', > self.ad_domain, > '--all', '--raw']) > > - assert "ipantadditionalsuffixes: UPNsuffix.com" in > result.stdout_text > + assert ("ipantadditionalsuffixes: {}".format(self.upn_suffix) in > + result.stdout_text) > > def test_upn_user_resolution_in_nonposix_trust(self): > """ Check that user with UPN can be resolved """ > - upnuser = 'upnuser at UPNsuffix.com' > - result = self.master.run_command(['getent', 'passwd', upnuser]) > + result = self.master.run_command(['getent', 'passwd', > self.upn_princ]) > > # result will contain AD domain, not UPN > - upnuser_regex = "^upnuser@{0}:\*:(\d+):(\d+):UPN > User:/:$".format( > - self.ad_domain) > + upnuser_regex = "^{}@{}:\*:(\d+):(\d+):UPN User:/:$".format( > + self.upn_username, self.ad_domain) > assert re.search(upnuser_regex, result.stdout_text) > > def test_upn_user_authentication(self): > """ Check that AD user with UPN can authenticate in IPA """ > self.master.run_command(['systemctl', 'restart', 'krb5kdc']) > - self.master.run_command(['kinit', '-C', '-E', > 'upnuser at UPNsuffix.com'], > - stdin_text='Secret123456') > + self.master.run_command(['kinit', '-C', '-E', self.upn_princ], > + stdin_text=self.upn_password) > > otherwise LGTM. > Thanks for review, fixed patch attached. Few notes: 1. mbabinsky's suggestion to store testdata as class attributes or separate resource file: I decided to use the class attribute approach. The separate resource file is a nice idea, which I have already put on my "to do" list - there's a lot of hardcoded stuff in the trust tests, even in the original ones (before my patches), so when there's time I'll work on a way how to dynamically provide this data as test configuration 2. previous discussion about getent vs. pwd.getpwnam(): I'll leave the getent command, since according to mbasti the alternative would not work in CI. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0026.2-Tests-Support-of-UPN-for-trusted-domains.patch Type: text/x-patch Size: 2750 bytes Desc: not available URL: From ofayans at redhat.com Fri Jul 1 14:55:21 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 1 Jul 2016 16:55:21 +0200 Subject: [Freeipa-devel] [Test][patch-0052] Test for incorrect client domain In-Reply-To: <669d6d7f-bc76-d0d7-0ccf-39fd404b995e@redhat.com> References: <57738D26.50404@redhat.com> <57751347.50908@redhat.com> <57766429.4090901@redhat.com> <669d6d7f-bc76-d0d7-0ccf-39fd404b995e@redhat.com> Message-ID: <57768459.7060906@redhat.com> Hi Martin, Thanks for the review. The updated patch is attached On 07/01/2016 04:09 PM, Martin Basti wrote: > > > On 01.07.2016 14:38, Oleg Fayans wrote: >> Hi Martin. Now I have this client installation thing sorted out. The >> test works as expected >> >> On 06/30/2016 02:57 PM, Martin Basti wrote: >>> >>> On 30.06.2016 14:40, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Attached is a new version of the patch with two test cases separated. >>>> >>>> On 06/29/2016 12:23 PM, Martin Basti wrote: >>>>> On 29.06.2016 10:56, Oleg Fayans wrote: >>>>> Hello, >>>>> >>>>> + assert_error(result, >>>>> + "Failed to verify that %s is an IPA Server" % >>>>> + self.master.hostname) >>>>> >>>>> >>>>> I would expect this error there: >>>>> >>>>> "Cannot promote this client to a replica. Local domain '{local}' does >>>>> not match IPA domain '{ipadomain}'. " >>>> Right, that's what this ticket is about: >>>> https://fedorahosted.org/freeipa/ticket/6006 >>>> >>>> Once these changes are implemented, we can update this test >>> Wat? >>> >>> You get exactly the right message from ipa-replica-install, tested, >>> reviewed by several people. >>>>> You should not use random REALM, in this case you don't test >>>>> domains but >>>>> realms. You can leave the test with incorrect realm there, but as >>>>> separated testcase >>>> Oh, ok. But it does not seem possible to setup client providing only >>>> --realm without --domain: installer would not do it. >>>> >>> Try to read again: "should not use *random* REALM". Nothing prevents you >>> to use, --realm=TEST.REALM --domain=random-blah-domain >>>>> Martin^2 >>>>> >>>>> >>>> >>> NACK >>> >>> + domain_name = 'exxample.test' >>> + realm_name = domain_name.upper() >>> >>> you still use random realm name, and you still don't test >>> ipa-replica-install, that ticket has nothing related to domain in >>> ipa-client-install, it is related to replica promotion >>> >>> Martin^2 > > I have a few comments: > > 1) > This is unused and should not be there > + realm_name = domain_name.upper() Done > > 2) > teardown_method > shouldn't be more robust, what happens if client uninstall raises an error? Agree. Done > > 3) in both tests > + '-w', self.master.config.dirman_password, > > -w means admin password (ipa-client-install --help), so you should use > admin not directory manager password Fixed > > 4) > + result = client.run_command(['ipa-client-install', '-U', > '--domain', > + self.master.domain.realm, '-w', > > did you mean: '--domain', self.master.domain.name.upper() Yes. Fixed. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0052.3-Test-for-incorrect-client-domain.patch Type: text/x-patch Size: 3547 bytes Desc: not available URL: From ldoudova at redhat.com Fri Jul 1 15:13:27 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 1 Jul 2016 17:13:27 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> Message-ID: <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> On 07/01/2016 02:42 PM, Milan Kub?k wrote: > On 06/16/2016 03:23 PM, Lenka Doudova wrote: >> Hi, >> >> attached are tests for authentication indicators. Please note: >> >> 1. newly created service tracker is not exactly complete, list of >> unimplemented methods is in doc. These methods can be filled in when >> existing declarative tests are refactored. >> >> 2. patch 0015 depends on 0014, so it should not be pushed without it. >> >> >> Lenka >> >> >> > > patch 0014: > > In the update method, what happens when the updated attributes contain > addattr? It is not clear to me. Is it necessary? > Example: ipa service-mod SRV --addattr="authind=radius" Result: The way the tracker works, this adds /u'addattr="authind=radius"'/ to the list of expected results (result of /self.attrs.update(updates)/. Of course nothing like that appears anywhere, so in case there's the /--addattr/ option, it's necessary to ensure it won't get to the /self.attrs/ atribute. > patch 0015: > > host1 and service2 do not tell anything about the purpose of the > fixture. Please assign more descriptive names to them. > Why do the fixtures have 'function' scope? Does the service entry > exist during the second and third test case? > Renamed. > > patch 0016: > > Per offline discussion, admin user has no special privileges here, LGTM. > > -- > Milan Kubik Thanks for review, fixed patches (14.2 and 15.2) attached. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0014.2-Tests-Tracker-class-for-services.patch Type: text/x-patch Size: 7240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0015.2-Tests-Authentication-indicators-xmlrpc-tests.patch Type: text/x-patch Size: 2946 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 1 16:16:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Jul 2016 18:16:39 +0200 Subject: [Freeipa-devel] [Test][patch-0052] Test for incorrect client domain In-Reply-To: <57768459.7060906@redhat.com> References: <57738D26.50404@redhat.com> <57751347.50908@redhat.com> <57766429.4090901@redhat.com> <669d6d7f-bc76-d0d7-0ccf-39fd404b995e@redhat.com> <57768459.7060906@redhat.com> Message-ID: On 01.07.2016 16:55, Oleg Fayans wrote: > Hi Martin, > > Thanks for the review. The updated patch is attached > > On 07/01/2016 04:09 PM, Martin Basti wrote: >> >> On 01.07.2016 14:38, Oleg Fayans wrote: >>> Hi Martin. Now I have this client installation thing sorted out. The >>> test works as expected >>> >>> On 06/30/2016 02:57 PM, Martin Basti wrote: >>>> On 30.06.2016 14:40, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Attached is a new version of the patch with two test cases separated. >>>>> >>>>> On 06/29/2016 12:23 PM, Martin Basti wrote: >>>>>> On 29.06.2016 10:56, Oleg Fayans wrote: >>>>>> Hello, >>>>>> >>>>>> + assert_error(result, >>>>>> + "Failed to verify that %s is an IPA Server" % >>>>>> + self.master.hostname) >>>>>> >>>>>> >>>>>> I would expect this error there: >>>>>> >>>>>> "Cannot promote this client to a replica. Local domain '{local}' does >>>>>> not match IPA domain '{ipadomain}'. " >>>>> Right, that's what this ticket is about: >>>>> https://fedorahosted.org/freeipa/ticket/6006 >>>>> >>>>> Once these changes are implemented, we can update this test >>>> Wat? >>>> >>>> You get exactly the right message from ipa-replica-install, tested, >>>> reviewed by several people. >>>>>> You should not use random REALM, in this case you don't test >>>>>> domains but >>>>>> realms. You can leave the test with incorrect realm there, but as >>>>>> separated testcase >>>>> Oh, ok. But it does not seem possible to setup client providing only >>>>> --realm without --domain: installer would not do it. >>>>> >>>> Try to read again: "should not use *random* REALM". Nothing prevents you >>>> to use, --realm=TEST.REALM --domain=random-blah-domain >>>>>> Martin^2 >>>>>> >>>>>> >>>> NACK >>>> >>>> + domain_name = 'exxample.test' >>>> + realm_name = domain_name.upper() >>>> >>>> you still use random realm name, and you still don't test >>>> ipa-replica-install, that ticket has nothing related to domain in >>>> ipa-client-install, it is related to replica promotion >>>> >>>> Martin^2 >> I have a few comments: >> >> 1) >> This is unused and should not be there >> + realm_name = domain_name.upper() > Done >> 2) >> teardown_method >> shouldn't be more robust, what happens if client uninstall raises an error? > Agree. Done > >> 3) in both tests >> + '-w', self.master.config.dirman_password, >> >> -w means admin password (ipa-client-install --help), so you should use >> admin not directory manager password > Fixed > >> 4) >> + result = client.run_command(['ipa-client-install', '-U', >> '--domain', >> + self.master.domain.realm, '-w', >> >> did you mean: '--domain', self.master.domain.name.upper() > Yes. Fixed. > ACK master: f784532d4ed6f25cf8ba12f83a7c322515434855 ipa-4-3: 844364bd2770b267c6e913de75b7caa926489c75 From mbabinsk at redhat.com Fri Jul 1 16:18:58 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Jul 2016 18:18:58 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation Message-ID: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> Quick hacky fix for https://fedorahosted.org/freeipa/ticket/6028 Admittedly a more systematic solution exists. We may discuss it further in this thread (such as add options to modrdn plugin to append to multivalue attributes). If time is the issue, we may use this fix instead and revert it later when more robust solution is implemented. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: .freeipa-mbabinsk-0179-Preserve-user-principal-aliases-during-rename-operat.patch.swp Type: application/octet-stream Size: 16384 bytes Desc: not available URL: From ftweedal at redhat.com Mon Jul 4 03:10:36 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 4 Jul 2016 13:10:36 +1000 Subject: [Freeipa-devel] [PATCH] 0087 uninstall: untrack lightweight CA certs Message-ID: <20160704031036.GP4200@dhcp-40-8.bne.redhat.com> The attached patch fixes https://fedorahosted.org/freeipa/ticket/6020 Thanks, Fraser -------------- next part -------------- From 15cca8e108c6d47a647cbc1dc647dcecbf334b9d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 4 Jul 2016 13:05:28 +1000 Subject: [PATCH] uninstall: untrack lightweight CA certs Fixes: https://fedorahosted.org/freeipa/ticket/6020 --- ipaserver/install/cainstance.py | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 5e3e8c7f9a1845b82d23de589f804aa065387b38..070498fe8a394802ea55f848a268e2b6563ec472 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1127,6 +1127,12 @@ class CAInstance(DogtagInstance): """ super(CAInstance, self).stop_tracking_certificates(False) + # stop tracking lightweight CA signing certs + for request_id in certmonger.get_requests_for_dir(self.nss_db): + nickname = certmonger.get_request_value(request_id, 'key-nickname') + if nickname.startswith('caSigningCert cert-pki-ca '): + certmonger.stop_tracking(self.nss_db, nickname=nickname) + try: certmonger.stop_tracking(paths.HTTPD_ALIAS_DIR, nickname='ipaCert') except RuntimeError as e: -- 2.5.5 From ftweedal at redhat.com Mon Jul 4 06:57:46 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 4 Jul 2016 16:57:46 +1000 Subject: [Freeipa-devel] [patch 0038-0040] Sub CA test patches In-Reply-To: References: <072dcce1-3a76-9f26-62d7-a70e403239af@redhat.com> <20160624014203.GO4200@dhcp-40-8.bne.redhat.com> <0e08d68d-cc4e-3f8c-de7f-be8d21ee91f7@redhat.com> <20160627005734.GR4200@dhcp-40-8.bne.redhat.com> Message-ID: <20160704065746.GU4200@dhcp-40-8.bne.redhat.com> On Fri, Jul 01, 2016 at 03:57:29PM +0200, Milan Kub?k wrote: > On 06/27/2016 01:31 PM, Milan Kub?k wrote: > > On 06/27/2016 02:57 AM, Fraser Tweedale wrote: > > > On Fri, Jun 24, 2016 at 12:08:24PM +0200, Milan Kub?k wrote: > > > > On 06/24/2016 03:42 AM, Fraser Tweedale wrote: > > > > > On Tue, Jun 21, 2016 at 05:01:35PM +0200, Milan Kub?k wrote: > > > > > > Hi Fraser and list, > > > > > > > > > > > > I have made changes to the test plan on the wiki [1] according to the > > > > > > information in "[Testplan review] Sub CAs" thread. > > > > > > > > > > > > I also implemented the tests in the test plan: > > > > > > > > > > > > patch 0038 - CATracker and CA CRUD test > > > > > > patch 0039 - extension to CA ACL test > > > > > > patch 0040 - functional test with ACLs and certificate > > > > > > profile, reusing my > > > > > > previous S/MIME based tests. This patch also tests for > > > > > > the cert-request > > > > > > behavior when profile ID or CA cn are ommited. > > > > > > > > > > > > The tests ATM do not verify the Issuer name in the > > > > > > certificate itself, just > > > > > > from the ipa entry of the certificate. > > > > > > > > > > > The approach you are using:: > > > > > > > > > > assert cert_info['result']['issuer'] == > > > > > smime_signing_ca.ipasubjectdn > > > > > > > > > > is not quite as you describe (these are virtual attributes, not > > > > > attributes of an actual entry); but the approach is valid. > > > > The issue then is in the wording? The other approach I could > > > > have used here > > > > is to retrieve the two certificates and compare the fields manually. > > > > Are these virtual attributes created from the certificate itself? > > > > > > > That's correct. > > > > > > > > > Fraser, could you please verify my reasoning behind the > > > > > > test cases for > > > > > > cert-request in the patch 40? > > > > > > > > > > > The tests look OK. With the default CA / default profiles, is there > > > > > appropriate isolation between test cases to ensure that if, e.g. > > > > > some other test case adds/modifies CA ACLs such that these > > > > > expected-to-fail tests now pass, that this does not affect the > > > > > TestCertSignMIMEwithSubCA test case? > > > > > > > > > > Thanks, > > > > > Fraser > > > > The ACL, SMIME CA and S/MIME profile lifetime is constrained by > > > > the class > > > > scope > > > > enforced by pytest. > > > > The two test cases depend on the fact documented in the designs > > > > and that is > > > > what > > > > cert-request fallbacks to when CA or profile ID are not provided. > > > > Unless something changes caIPAserviceCert profile or affiliated > > > > ACL, then > > > > the test cases > > > > are safe. > > > > > > > If you have thought about possible interference from other tests, I > > > am happy. > > > > > > Note another problematic scenario: what if a different (preceding) > > > test adds a CA ACL that would allow the requests that you expect to > > > fail? Just something to think about :) > > > > > > Thanks, > > > Fraser > > Then the failure would be problem of the preceding test and we would > > need to fix it. We are dealing with test side effects > > in other parts of the execution already... > > > > The test is constructed in a way that isolates it (to a certain degree) > > by the mechanisms available > > in pytest. Of course I cannot make the test future-proof or guarantee > > that a bug in some other test > > will not affect the execution of other tests as they all run against one > > IPA instance. > > I do not think, however, that potential misbehaving test case that will > > interfere > > should prevent us from implementing this and similar test cases. > > > > If you have some specific issue that is in the patch, I'm happy to fix > > them. > > > > I will try to think more about corner cases here. > > > > > > [1]: http://www.freeipa.org/page/V4/Sub-CAs/Test_Plan > > > > > > > > > > > > Cheers > > > > > > > > > > > > -- > > > > > > Milan Kubik > > > > > > > > > > Attaching rebased patches and removing the expected fail from > > > > one of the > > > > tests as ticket 5981 has fix posted. > > > > > > > > -- > > > > Milan Kubik > > > > > > > > > > Hi Fraser, > > can we continue with the review, please? > Hi Milan, Yes, we can :) Two issues, outlined below. 1) Running the tests, I get error in test_create_subca_with_subject_conflict cleanup:: ____________ ERROR at teardown of TestCAbasicCRUD.test_create_subca_with_subject_conflict _____________ def cleanup(): created = self.exists try: del_command() E NotFound: crud-subca-2: Certificate Authority not found I do not know testing framework very well but it looks like track_create() sets 'self.exists = True' before the create command throws the (expected) DuplicateEntry error. (These are called from create() in the tracker 'base' class). Later, cleanup() catches a NotFound but re-throws it because it believes the entry should have existed. 2) the usercert.conf.tmpl does not like a subject base with spaces in it, i.e. if 'openssl req' config template gets formatted like: [ dn ] commonName = "alice" o=IPA.LOCAL 201606201330 then 'openssl req' fails with nasty error like: 140644791924600:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:108: 140644791924600:error:0B083077:x509 certificate routines:X509_NAME_ENTRY_create_by_txt:invalid field name:x509name.c:295:name=o and CalledProcessError gets raised and the test fails. Simplest solution is to simply remove the '{ipacertbase}' from the template, because AFAIK it is not needed and parsing and formatting the certbase (which could have multiple AVAs) is more complex than the test calls for, IMO. Thanks, Fraser From ftweedal at redhat.com Mon Jul 4 07:06:16 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 4 Jul 2016 17:06:16 +1000 Subject: [Freeipa-devel] [freeipa] #6002: Default CA can be used without an ACL In-Reply-To: <055.a874b9e24d14ff50c7966339031dfb11@fedorahosted.org> References: <040.c455dd24c0d77033bb69ad9540d2e83b@fedorahosted.org> <055.a874b9e24d14ff50c7966339031dfb11@fedorahosted.org> Message-ID: <20160704070616.GA10771@dhcp-40-8.bne.redhat.com> On Tue, Jun 28, 2016 at 01:47:23PM -0000, freeipa wrote: > #6002: Default CA can be used without an ACL > > Comment (by ftweedal): > > This is expected behaviour; if a CA ACL does not reference any CAs, > and does not have cacat=all, then it is assumed to refer to the > default CA. This is for backwards compatibility with existing > CA ACLs, which do not reference any CAs but did (and still do) > allow access to IPA CA. > > Leaving open for discussion about whether to break compatibility > for a more consistent behaviour. > Didn't get any feedback in the ticket yet so raising on list for visibility. If people agree with current behaviour I can add a clarification to caacl plugin help text and close out this ticket. Thanks, Fraser From mbabinsk at redhat.com Mon Jul 4 08:18:56 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 4 Jul 2016 10:18:56 +0200 Subject: [Freeipa-devel] [PATCH] 0087 uninstall: untrack lightweight CA certs In-Reply-To: <20160704031036.GP4200@dhcp-40-8.bne.redhat.com> References: <20160704031036.GP4200@dhcp-40-8.bne.redhat.com> Message-ID: <89f902e3-6552-0bfe-7d85-b7d7423679ed@redhat.com> On 07/04/2016 05:10 AM, Fraser Tweedale wrote: > The attached patch fixes > https://fedorahosted.org/freeipa/ticket/6020 > > Thanks, > Fraser > > > ACK. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Jul 4 10:54:53 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 4 Jul 2016 12:54:53 +0200 Subject: [Freeipa-devel] [PATCH 0180] allow multiple dashes in the components of server hostname Message-ID: <38e18ae9-f2d9-60f0-1c97-1951652f94fd@redhat.com> The PKI bug preventing use of multiple dashes in hostnames [1] was already fixed. We may now relax our own syntax constraints. https://fedorahosted.org/freeipa/ticket/4710 [1] https://fedorahosted.org/pki/ticket/1260 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0180-allow-multiple-dashes-in-the-components-of-server-ho.patch Type: text/x-patch Size: 2028 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Jul 4 11:36:50 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 4 Jul 2016 13:36:50 +0200 Subject: [Freeipa-devel] [PATCH 0181] ipa-nis-manage: Use server API to retrieve plugin status Message-ID: <81d6e74c-e1e4-26d8-0c89-70457ef4e5cd@redhat.com> https://fedorahosted.org/freeipa/ticket/6027 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0181-ipa-nis-manage-Use-server-API-to-retrieve-plugin-sta.patch Type: text/x-patch Size: 881 bytes Desc: not available URL: From yurchor at ukr.net Mon Jul 4 18:30:44 2016 From: yurchor at ukr.net (Yuri Chornoivan) Date: Mon, 04 Jul 2016 21:30:44 +0300 Subject: [Freeipa-devel] [PATCH] Fix minor typos Message-ID: Hi, A fresh portion of typo fixes. Thanks in advance for reviewing. Best regards, Yuri -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-minor-typos.patch Type: application/octet-stream Size: 9423 bytes Desc: not available URL: From ofayans at redhat.com Mon Jul 4 20:50:58 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 4 Jul 2016 22:50:58 +0200 Subject: [Freeipa-devel] [Test][patch-0053] Forced-client-reenrollment test fixed. Message-ID: <577ACC32.3030201@redhat.com> 2 out of 7 tests currently fail due to a known issue [1], others pass. [1] https://fedorahosted.org/freeipa/ticket/6029 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0053-Updated-forced_client_reenrollment-test.patch Type: text/x-patch Size: 8102 bytes Desc: not available URL: From frenaud at redhat.com Tue Jul 5 12:38:19 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Tue, 5 Jul 2016 14:38:19 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup Message-ID: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> Hi, the output of ipa selinuxusermap-add-hostgroup and selinuxusermap-add-user does not display any more the host/host group or user/group that could not be added. This patch fixes this regression by adding the labels host/hostgroup/user/group to the list of _failed_member_output_params of the class ClientMethod. https://fedorahosted.org/freeipa/ticket/6026 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0010-Show-full-error-message-for-selinuxusermap-add-hostg.patch Type: text/x-patch Size: 1527 bytes Desc: not available URL: From mharmsen at redhat.com Tue Jul 5 14:58:58 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 5 Jul 2016 08:58:58 -0600 Subject: [Freeipa-devel] Karma Request for Dogtag 10.3.3-3 on Fedora 24 Message-ID: <577BCB32.9070205@redhat.com> The following candidate build of Dogtag 10.3.3-3 for Fedora 24 consists of the following: * pki-core-10.3.3-3.fc24 Please provide Karma for this build in Bodhi located at: * https://bodhi.fedoraproject.org/updates/FEDORA-2016-af639eaba8 pki-core-10.3.3-3.fc24 Additionally, the following build has been provided for Fedora 25 (rawhide): * pki-core-10.3.3-3.fc25 Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Tue Jul 5 16:21:26 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 5 Jul 2016 18:21:26 +0200 Subject: [Freeipa-devel] [PATCH] Fix minor typos In-Reply-To: References: Message-ID: <77d5128e-fdbe-1a7f-ff3e-b4c653239644@redhat.com> On 07/04/2016 08:30 PM, Yuri Chornoivan wrote: > Hi, > > A fresh portion of typo fixes. > > Thanks in advance for reviewing. > > Best regards, > Yuri > > Hi Yuri, thanks for your patch! The patch introduces new pep8/pep257 complaints that you can detect using "git diff HEAD~$NUMBER_OF_PATCHES -U0 | pep8 --diff" (mainly due to line length). The code was not be compliant before your patch but it is a good practice to fix the existing issue if you modify the same line. You can find more information regarding coding style in the wiki page Contribute/Code [1] Apart from this, I have the following comment: - DOM\name is one of the Active Directory formats used to specify a domain and a name. Your fix should rather escape the \ so that it is kept inside the docstring. Otherwise, it looks good to me. Thanks again! [1] http://www.freeipa.org/page/Contribute/Code#Code_quality Flo. From lslebodn at redhat.com Tue Jul 5 20:34:24 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 5 Jul 2016 22:34:24 +0200 Subject: [Freeipa-devel] [PATCH] Fix minor typos In-Reply-To: <77d5128e-fdbe-1a7f-ff3e-b4c653239644@redhat.com> References: <77d5128e-fdbe-1a7f-ff3e-b4c653239644@redhat.com> Message-ID: <20160705203423.GE25346@10.4.128.1> On (05/07/16 18:21), Florence Blanc-Renaud wrote: >On 07/04/2016 08:30 PM, Yuri Chornoivan wrote: >> Hi, >> >> A fresh portion of typo fixes. >> >> Thanks in advance for reviewing. >> >> Best regards, >> Yuri >> >> >Hi Yuri, > >thanks for your patch! > >The patch introduces new pep8/pep257 complaints that you can detect using >"git diff HEAD~$NUMBER_OF_PATCHES -U0 | pep8 --diff" (mainly due to line >length). >The code was not be compliant before your patch but it is a good practice to >fix the existing issue if you modify the same line. > >You can find more information regarding coding style in the wiki page >Contribute/Code [1] > >Apart from this, I have the following comment: >- DOM\name is one of the Active Directory formats used to specify a domain >and a name. Your fix should rather escape the \ so that it is kept inside the >docstring. > Maybe it would be better to user user(username) instead of name e.g. 'DOM\username', or 'username at domain' LS From flo at redhat.com Wed Jul 6 09:18:45 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 6 Jul 2016 11:18:45 +0200 Subject: [Freeipa-devel] [PATCH 0181] ipa-nis-manage: Use server API to retrieve plugin status In-Reply-To: <81d6e74c-e1e4-26d8-0c89-70457ef4e5cd@redhat.com> References: <81d6e74c-e1e4-26d8-0c89-70457ef4e5cd@redhat.com> Message-ID: On 07/04/2016 01:36 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/6027 > > > Hi Martin, I tested your patch and it correctly fixes the issue. Ack, Flo. From flo at redhat.com Wed Jul 6 09:22:47 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 6 Jul 2016 11:22:47 +0200 Subject: [Freeipa-devel] [PATCH] Fix minor typos In-Reply-To: <20160705203423.GE25346@10.4.128.1> References: <77d5128e-fdbe-1a7f-ff3e-b4c653239644@redhat.com> <20160705203423.GE25346@10.4.128.1> Message-ID: <56eec26f-6ca6-8373-bdee-f8e8674aa21c@redhat.com> On 07/05/2016 10:34 PM, Lukas Slebodnik wrote: > On (05/07/16 18:21), Florence Blanc-Renaud wrote: >> On 07/04/2016 08:30 PM, Yuri Chornoivan wrote: >>> Hi, >>> >>> A fresh portion of typo fixes. >>> >>> Thanks in advance for reviewing. >>> >>> Best regards, >>> Yuri >>> >>> >> Hi Yuri, >> >> thanks for your patch! >> >> The patch introduces new pep8/pep257 complaints that you can detect using >> "git diff HEAD~$NUMBER_OF_PATCHES -U0 | pep8 --diff" (mainly due to line >> length). >> The code was not be compliant before your patch but it is a good practice to >> fix the existing issue if you modify the same line. >> >> You can find more information regarding coding style in the wiki page >> Contribute/Code [1] >> >> Apart from this, I have the following comment: >> - DOM\name is one of the Active Directory formats used to specify a domain >> and a name. Your fix should rather escape the \ so that it is kept inside the >> docstring. >> > Maybe it would be better to user user(username) instead of name > e.g. 'DOM\username', or 'username at domain' > > LS > A group can also be passed instead of a user, I think that's why the doc mentions "name" instead of "username". Flo From abokovoy at redhat.com Wed Jul 6 09:44:22 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 6 Jul 2016 12:44:22 +0300 Subject: [Freeipa-devel] [PATCH] Fix minor typos In-Reply-To: <56eec26f-6ca6-8373-bdee-f8e8674aa21c@redhat.com> References: <77d5128e-fdbe-1a7f-ff3e-b4c653239644@redhat.com> <20160705203423.GE25346@10.4.128.1> <56eec26f-6ca6-8373-bdee-f8e8674aa21c@redhat.com> Message-ID: <20160706094422.uuvkh4nlsswewayj@redhat.com> On Wed, 06 Jul 2016, Florence Blanc-Renaud wrote: >On 07/05/2016 10:34 PM, Lukas Slebodnik wrote: >>On (05/07/16 18:21), Florence Blanc-Renaud wrote: >>>On 07/04/2016 08:30 PM, Yuri Chornoivan wrote: >>>>Hi, >>>> >>>>A fresh portion of typo fixes. >>>> >>>>Thanks in advance for reviewing. >>>> >>>>Best regards, >>>>Yuri >>>> >>>> >>>Hi Yuri, >>> >>>thanks for your patch! >>> >>>The patch introduces new pep8/pep257 complaints that you can detect using >>>"git diff HEAD~$NUMBER_OF_PATCHES -U0 | pep8 --diff" (mainly due to line >>>length). >>>The code was not be compliant before your patch but it is a good practice to >>>fix the existing issue if you modify the same line. >>> >>>You can find more information regarding coding style in the wiki page >>>Contribute/Code [1] >>> >>>Apart from this, I have the following comment: >>>- DOM\name is one of the Active Directory formats used to specify a domain >>>and a name. Your fix should rather escape the \ so that it is kept inside the >>>docstring. >>> >>Maybe it would be better to user user(username) instead of name >>e.g. 'DOM\username', or 'username at domain' >> >>LS >> >A group can also be passed instead of a user, I think that's why the >doc mentions "name" instead of "username". Yes. Anything that can be expressed as SID can be passed there -- you can pass a SID directly too. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Jul 6 15:22:22 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 6 Jul 2016 18:22:22 +0300 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> Message-ID: <20160706152222.4znlybol7y5c35gg@redhat.com> On Fri, 01 Jul 2016, Martin Babinsky wrote: >Quick hacky fix for https://fedorahosted.org/freeipa/ticket/6028 > >Admittedly a more systematic solution exists. We may discuss it >further in this thread (such as add options to modrdn plugin to append >to multivalue attributes). If time is the issue, we may use this fix >instead and revert it later when more robust solution is implemented. There is no patch, only a .swp file attached. -- / Alexander Bokovoy From blipton at redhat.com Wed Jul 6 16:13:22 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 6 Jul 2016 12:13:22 -0400 Subject: [Freeipa-devel] [WIP] Automatic CSR generation - first steps In-Reply-To: <7b971146-6d1b-5a4e-c230-97de8e962842@redhat.com> References: <0f176317-3fd1-f0c8-88a7-a593be092e19@redhat.com> <7b971146-6d1b-5a4e-c230-97de8e962842@redhat.com> Message-ID: I have added a few new features to the code, including: - A new certificate profile for user certs - Import and export of included mapping rules when certificate profiles are imported/exported The updated patches are at https://github.com/LiptonB/freeipa/pull/2/commits. I look forward to hearing your thoughts, either in the pull request or here on the mailing list. Thanks, Ben On 06/27/2016 01:44 PM, Ben Lipton wrote: > > My email client is playing tricks on me - > https://github.com/LiptonB/freeipa/pull/2 is the correct link. > > > On 06/27/2016 01:14 PM, Ben Lipton wrote: >> Hi, >> >> I have implemented the core functionality of the automatic CSR >> generation design >> (http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation). >> The code (which should be considered a work in progress) is available >> at https://github.com/LiptonB/freeipa/pull/2, please take a look and >> let me know what you think! >> >> First, a demo, then some notes: >> >> [root at ipavm ~]# ipa cert-get-requestdata --principal >> host/hostname.ipadom.example.com --format openssl >> Debug output: [req] >> prompt = no >> distinguished_name = sec0 >> req_extensions = exts >> >> [sec0] >> CN=hostname.ipadom.example.com >> O=IPADOM.EXAMPLE.COM >> >> [sec1] >> DNS=hostname.ipadom.example.com >> >> [exts] >> subjectAltName=@sec1 >> >> >> [root at ipavm ~]# ipa cert-get-requestdata --principal >> host/hostname.ipadom.example.com --format certutil >> Debug output: certutil -R -s >> CN=hostname.ipadom.example.com,O=IPADOM.EXAMPLE.COM --extSAN >> dns:hostname.ipadom.example.com >> >> >> Notes: >> - This is implemented using the four-level schema >> (http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A). >> I'm very interested in comments on improving the schema or the way I >> interact with it in the code. >> - Only includes rules for one profile at the moment, and it's >> probably not one you'd use (it weirdly puts the FQDN in both Subject >> and SubjectAltName). Think of it as an example to show that >> extensions are supported. >> - Right now, transformation rules are implemented in python. >> Migrating them to a scheme where rules are text-based and can be >> added at runtime is a future goal. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Jul 6 17:01:50 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 6 Jul 2016 19:01:50 +0200 Subject: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals Message-ID: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> Hi, although enterprise principals for trusted domains now are working as expected they do not work for the local domain: # kinit -E admin at IPA.DEVEL kinit: Client 'admin\@IPA.DEVEL at IPA.DEVEL' not found in Kerberos database while getting initial credentials Attached patch handles this case. It is not that nice because of the duplication of ipadb_fetch_principals() and ipadb_find_principal(). But I think there was a reason I do not remember why we didn't check for enterprise principals before checking the local database. If there is no such reason it might make sense to check for enterprise principals before doing the lookup. Please let me know if I should change the patch accordingly or if the current version is ok, bye, Sumit -------------- next part -------------- From a1ca7928148a58a1ac61f6d418750200866a4a63 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 6 Jul 2016 17:29:37 +0200 Subject: [PATCH] kdb: check for local realm in enterprise principals --- daemons/ipa-kdb/ipa_kdb_principals.c | 52 +++++++++++++++++++++++++++--------- 1 file changed, 40 insertions(+), 12 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 6cdfa909452a4b55912b2a5a74648abd2053482a..5b80909475565d6bb4fa8cba67629094daf51eb3 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -1198,30 +1198,58 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, /* skip '@' and use part after '@' as an enterprise realm for comparison */ realm++; - kerr = ipadb_is_princ_from_trusted_realm(kcontext, - realm, - upn->length - (realm - upn->data), - &trusted_realm); - if (kerr == 0) { - kentry = calloc(1, sizeof(krb5_db_entry)); - if (!kentry) { + /* check for our realm */ + if (strncasecmp(ipactx->realm, realm, + upn->length - (realm - upn->data)) == 0) { + /* it looks like it is ok to use malloc'ed strings as principal */ + krb5_free_unparsed_name(kcontext, principal); + principal = strndup((const char *) upn->data, upn->length); + if (principal == NULL) { kerr = ENOMEM; goto done; } - kerr = krb5_parse_name(kcontext, principal, - &kentry->princ); + + ldap_msgfree(res); + res = NULL; + kerr = ipadb_fetch_principals(ipactx, flags, principal, &res); if (kerr != 0) { goto done; } - kerr = krb5_set_principal_realm(kcontext, kentry->princ, trusted_realm); + kerr = ipadb_find_principal(kcontext, flags, res, &principal, + &lentry); if (kerr != 0) { goto done; } - *entry = kentry; + } else { + + kerr = ipadb_is_princ_from_trusted_realm(kcontext, + realm, + upn->length - (realm - upn->data), + &trusted_realm); + if (kerr == 0) { + kentry = calloc(1, sizeof(krb5_db_entry)); + if (!kentry) { + kerr = ENOMEM; + goto done; + } + kerr = krb5_parse_name(kcontext, principal, + &kentry->princ); + if (kerr != 0) { + goto done; + } + + kerr = krb5_set_principal_realm(kcontext, kentry->princ, trusted_realm); + if (kerr != 0) { + goto done; + } + *entry = kentry; + } + goto done; } + } else { + goto done; } - goto done; } kerr = ipadb_parse_ldap_entry(kcontext, principal, lentry, entry, &pol); -- 2.4.11 From jhrozek at redhat.com Wed Jul 6 17:11:19 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 6 Jul 2016 19:11:19 +0200 Subject: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals In-Reply-To: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20160706171119.GP3921@hendrix> On Wed, Jul 06, 2016 at 07:01:50PM +0200, Sumit Bose wrote: > Hi, > > although enterprise principals for trusted domains now are working as > expected they do not work for the local domain: > > # kinit -E admin at IPA.DEVEL > kinit: Client 'admin\@IPA.DEVEL at IPA.DEVEL' not found in Kerberos database while getting initial credentials > > Attached patch handles this case. It is not that nice because of the > duplication of ipadb_fetch_principals() and ipadb_find_principal(). But > I think there was a reason I do not remember why we didn't check for > enterprise principals before checking the local database. If there is no > such reason it might make sense to check for enterprise principals > before doing the lookup. Please let me know if I should change the patch > accordingly or if the current version is ok, > > bye, > Sumit > The patch fixes IPA logins for me, so functional ACK, but I'm not sure I know enough about the code to actually review the code.. From ofayans at redhat.com Thu Jul 7 06:09:39 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 7 Jul 2016 08:09:39 +0200 Subject: [Freeipa-devel] [Test][patch-0053] Forced-client-reenrollment test fixed. In-Reply-To: <577ACC32.3030201@redhat.com> References: <577ACC32.3030201@redhat.com> Message-ID: <577DF223.5010302@redhat.com> Updated version of the patch is attached with the failing tests marked as xfailed (let's make the jenkins green). On 07/04/2016 10:50 PM, Oleg Fayans wrote: > 2 out of 7 tests currently fail due to a known issue [1], others pass. > > [1] https://fedorahosted.org/freeipa/ticket/6029 > > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0053.1-Updated-forced_client_reenrollment-test.patch Type: text/x-patch Size: 8728 bytes Desc: not available URL: From akasurde at redhat.com Thu Jul 7 08:58:37 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 7 Jul 2016 14:28:37 +0530 Subject: [Freeipa-devel] [PATCH 0017] Added fix for correct IPA backup file name Message-ID: <28e5999e-9dc8-f59d-28a6-1db882199880@redhat.com> Hi All, Please review the patch. Fixes : https://fedorahosted.org/freeipa/ticket/6031 -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0017-Added-fix-for-correct-IPA-backup-file-name.patch Type: text/x-patch Size: 1743 bytes Desc: not available URL: From sbose at redhat.com Thu Jul 7 09:13:57 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 7 Jul 2016 11:13:57 +0200 Subject: [Freeipa-devel] [Testplan] Support of UPN for trusted domains In-Reply-To: <20160527082424.sr4wkzmcq4nwzpmg@redhat.com> References: <1a3667cb-e670-72da-f03f-f5b04133babe@redhat.com> <20160527081309.GI6640@p.Speedport_W_724V_Typ_A_05011603_00_009> <20160527082424.sr4wkzmcq4nwzpmg@redhat.com> Message-ID: <20160707091357.GD2919@p.Speedport_W_724V_Typ_A_05011603_00_009> On Fri, May 27, 2016 at 11:24:24AM +0300, Alexander Bokovoy wrote: > On Fri, 27 May 2016, Sumit Bose wrote: > > On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote: > > > Hi all, > > > > > > > > > here [1] is a draft of test plan for V4 RFE Support of UPN for trusted > > > domains. > > > > > > Please review this and let me know if there's something missing or wrong. > > > > Hi Lenka, > > > > thank you for the test plan. > > > > About the TBD, Alexander and I agreed to store the alternative domain > > suffixes read from AD in a new attribute in the LDAP object of the > > forest root of the trusted domain. > > > > About the kinit tests. Please note that it is expected that the -E > > option of kinit must be used when alternative suffixes are used. > > > > I'm not sure if SSSD tests are in the scope here as well. If they are I > > would suggest to add authentication tests with SSSD where e.g. the name > > with an alternative domain suffix is used as login name. This in general > > already works with SSSD but is disabled by default for IPA because of > > the missing server-side support so far. Since SSSD must be able to work > > with old and new IPA server https://fedorahosted.org/sssd/ticket/3018 > > was created so that SSSD can detect at runtime if the server supports > > this or not. > Right, I think we should make sure SSSD is tested against IPA UPN > support because otherwise we might get regressions. Hi Lenka, I would like to ask you to add test where 'kinit -E' is used with an IPA user as well to avoid regression, because currently 'kinit -E ipauser at IPA.DOMAIN' does not work. Please note that the full principal must be used with kinit in this case because when just using kinit -E ipauser kinit is smart enough to see that it makes no sense to add the default_realm twice and internally just does 'kinit ipauser at IPA.DOMAIN'. If you think this test is better suited in a different test plan please let me know, then I'll ask there. bye, Sumit > > > -- > / Alexander Bokovoy From flo at redhat.com Thu Jul 7 10:00:58 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 7 Jul 2016 12:00:58 +0200 Subject: [Freeipa-devel] [PATCH 0017] Added fix for correct IPA backup file name In-Reply-To: <28e5999e-9dc8-f59d-28a6-1db882199880@redhat.com> References: <28e5999e-9dc8-f59d-28a6-1db882199880@redhat.com> Message-ID: <0d70dfbb-db6a-5df4-858b-1181404ef147@redhat.com> On 07/07/2016 10:58 AM, Abhijeet Kasurde wrote: > Hi All, > > Please review the patch. > > Fixes : https://fedorahosted.org/freeipa/ticket/6031 > > -- > Thanks, > Abhijeet Kasurde > > IRC: akasurde > http://akasurde.github.io > > > Hi Abhijeet, thanks for your patch. I have a comment though: if the filename is modified in ipa-backup, then it should also be changed in ipa-restore, to make sure that the backup can be restored. It may be a good idea to define the file name as a constant and use this constant everywhere. As far as I can see, the tool ipa-restore checks that the backup version and ipa-restore version are consistent, meaning that both tools should use the same filename and that it will not break backward compatibility, but other team members can confirm. Flo. From shetze at redhat.com Thu Jul 7 04:58:55 2016 From: shetze at redhat.com (Sebastian Hetze) Date: Thu, 7 Jul 2016 06:58:55 +0200 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install Message-ID: <577DE18F.4050103@redhat.com> Hi * attached you find a patch that adds new options --subject_cn and --subject_mail to ipa-server-install that make the CA cert subject CN customizable. This patch has been tested by a customer in a PoC. However, i assume additional testing in different environments is required. It would be greatly appreciated if this patch would find its way into the product very soon. Beste Gr??e / Best regards Sebastian Hetze -- Senior Solution Architect Red Hat GmbH. Niederlassung Berlin Am Treptower Park 75 12435 Berlin Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: add-subject-cn-and-mail-to-external-CA-config.patch Type: text/x-patch Size: 35834 bytes Desc: not available URL: From akasurde at redhat.com Thu Jul 7 10:40:21 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 7 Jul 2016 16:10:21 +0530 Subject: [Freeipa-devel] [PATCH 0017] Added fix for correct IPA backup file name In-Reply-To: <0d70dfbb-db6a-5df4-858b-1181404ef147@redhat.com> References: <28e5999e-9dc8-f59d-28a6-1db882199880@redhat.com> <0d70dfbb-db6a-5df4-858b-1181404ef147@redhat.com> Message-ID: Hi Florence, On 07/07/2016 03:30 PM, Florence Blanc-Renaud wrote: > On 07/07/2016 10:58 AM, Abhijeet Kasurde wrote: >> Hi All, >> >> Please review the patch. >> >> Fixes : https://fedorahosted.org/freeipa/ticket/6031 >> >> -- >> Thanks, >> Abhijeet Kasurde >> >> IRC: akasurde >> http://akasurde.github.io >> >> >> > Hi Abhijeet, > > thanks for your patch. I have a comment though: if the filename is > modified in ipa-backup, then it should also be changed in ipa-restore, > to make sure that the backup can be restored. It may be a good idea to > define the file name as a constant and use this constant everywhere. > I will change ipa-restore as well. > As far as I can see, the tool ipa-restore checks that the backup > version and ipa-restore version are consistent, meaning that both > tools should use the same filename and that it will not break backward > compatibility, but other team members can confirm. > I will wait for other team members to comment on this. > Flo. > Thanks for your comments. -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Jul 7 11:16:04 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 7 Jul 2016 13:16:04 +0200 Subject: [Freeipa-devel] Dogtag 10.3.4 in Fedora 24? Message-ID: <0eab09f7-8d95-6651-1c8d-1412c08842eb@redhat.com> Hello, IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for Fedora any time soon? Or should I update my scripts to automatically enable COPR @freeipa/freeipa-master in my testing VMs? Thanks. Petr^2 Spacek > commit 45daffa22fcc6c481a8302f1947a5e0ded0b3eb8 > CommitDate: Tue Jun 28 19:15:35 2016 +0200 > > Set default OCSP URI on install and upgrade > > Dogtag has been updated to support a default OCSP URI when the > profile includes AuthInfoAccess with URI method but does not specify > the URI (instead of constructing one based on Dogtag's hostname and > port). > > Add the pkispawn config to ensure that the OCSP URI is set before > issuing CA and system certificates, and add the config to existing > CA instances on upgrade. > > Fixes: https://fedorahosted.org/freeipa/ticket/5956 > Reviewed-By: Martin Basti > --- > freeipa.spec.in | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/freeipa.spec.in b/freeipa.spec.in > index c86fc31..a4d3c06 100644 > --- a/freeipa.spec.in > +++ b/freeipa.spec.in > @@ -94,7 +94,7 @@ BuildRequires: libunistring-devel > BuildRequires: python-lesscpy > BuildRequires: python-yubico >= 1.2.3 > BuildRequires: openssl-devel > -BuildRequires: pki-base >= 10.3.3 > +BuildRequires: pki-base >= 10.3.4 From pvoborni at redhat.com Thu Jul 7 11:23:21 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 7 Jul 2016 13:23:21 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> Message-ID: On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: > Hi, > > the output of ipa selinuxusermap-add-hostgroup and > selinuxusermap-add-user does not display any more the host/host group or > user/group that could not be added. This patch fixes this regression by > adding the labels host/hostgroup/user/group to the list of > _failed_member_output_params of the class ClientMethod. > > > https://fedorahosted.org/freeipa/ticket/6026 > I've a feeling that this issue is more general and multiple commands regressed. Would be good to check other member options, e.g. also in user plugin. -- Petr Vobornik From pvoborni at redhat.com Thu Jul 7 11:31:03 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 7 Jul 2016 13:31:03 +0200 Subject: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals In-Reply-To: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <829a14a3-8547-d349-587b-d60d8003f93f@redhat.com> On 07/06/2016 07:01 PM, Sumit Bose wrote: > Hi, > > although enterprise principals for trusted domains now are working as > expected they do not work for the local domain: > > # kinit -E admin at IPA.DEVEL > kinit: Client 'admin\@IPA.DEVEL at IPA.DEVEL' not found in Kerberos database while getting initial credentials > > Attached patch handles this case. It is not that nice because of the > duplication of ipadb_fetch_principals() and ipadb_find_principal(). But > I think there was a reason I do not remember why we didn't check for > enterprise principals before checking the local database. If there is no > such reason it might make sense to check for enterprise principals > before doing the lookup. Please let me know if I should change the patch > accordingly or if the current version is ok, > > bye, > Sumit > Hi Sumit, thanks for the patch. This patch should have a ticket. It will help downstream planning. -- Petr Vobornik From sbose at redhat.com Thu Jul 7 11:52:42 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 7 Jul 2016 13:52:42 +0200 Subject: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals In-Reply-To: <829a14a3-8547-d349-587b-d60d8003f93f@redhat.com> References: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> <829a14a3-8547-d349-587b-d60d8003f93f@redhat.com> Message-ID: <20160707115242.GG2919@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Jul 07, 2016 at 01:31:03PM +0200, Petr Vobornik wrote: > On 07/06/2016 07:01 PM, Sumit Bose wrote: > > Hi, > > > > although enterprise principals for trusted domains now are working as > > expected they do not work for the local domain: > > > > # kinit -E admin at IPA.DEVEL > > kinit: Client 'admin\@IPA.DEVEL at IPA.DEVEL' not found in Kerberos database while getting initial credentials > > > > Attached patch handles this case. It is not that nice because of the > > duplication of ipadb_fetch_principals() and ipadb_find_principal(). But > > I think there was a reason I do not remember why we didn't check for > > enterprise principals before checking the local database. If there is no > > such reason it might make sense to check for enterprise principals > > before doing the lookup. Please let me know if I should change the patch > > accordingly or if the current version is ok, > > > > bye, > > Sumit > > > > Hi Sumit, > > thanks for the patch. This patch should have a ticket. It will help > downstream planning. sure, I created https://fedorahosted.org/freeipa/ticket/6036. Please clone it to suitable downstream tickets. Please note that we didn't released a patch for SSSD to enable enterprise principals automatically if the IPA server (should) support them because of this issues. Since 4.4.0 is already released I think we have to wait on the SSSD side until a new FreeIPA version with a fix is released. bye, Sumit > > -- > Petr Vobornik From pspacek at redhat.com Thu Jul 7 12:40:45 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 7 Jul 2016 14:40:45 +0200 Subject: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals In-Reply-To: <20160707115242.GG2919@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> <829a14a3-8547-d349-587b-d60d8003f93f@redhat.com> <20160707115242.GG2919@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: On 7.7.2016 13:52, Sumit Bose wrote: > On Thu, Jul 07, 2016 at 01:31:03PM +0200, Petr Vobornik wrote: >> On 07/06/2016 07:01 PM, Sumit Bose wrote: >>> Hi, >>> >>> although enterprise principals for trusted domains now are working as >>> expected they do not work for the local domain: >>> >>> # kinit -E admin at IPA.DEVEL >>> kinit: Client 'admin\@IPA.DEVEL at IPA.DEVEL' not found in Kerberos database while getting initial credentials >>> >>> Attached patch handles this case. It is not that nice because of the >>> duplication of ipadb_fetch_principals() and ipadb_find_principal(). But >>> I think there was a reason I do not remember why we didn't check for >>> enterprise principals before checking the local database. If there is no >>> such reason it might make sense to check for enterprise principals >>> before doing the lookup. Please let me know if I should change the patch >>> accordingly or if the current version is ok, I can't see the reason why we should not allow enterprise principals ... Personally I like rule of thumb 'design is not documented -> change it as you see fit & document it this time'. Petr^2 Spacek >>> >>> bye, >>> Sumit >>> >> >> Hi Sumit, >> >> thanks for the patch. This patch should have a ticket. It will help >> downstream planning. > > sure, I created https://fedorahosted.org/freeipa/ticket/6036. Please > clone it to suitable downstream tickets. > > Please note that we didn't released a patch for SSSD to enable enterprise > principals automatically if the IPA server (should) support them because > of this issues. Since 4.4.0 is already released I think we have to wait > on the SSSD side until a new FreeIPA version with a fix is released. From mbasti at redhat.com Thu Jul 7 12:54:12 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 7 Jul 2016 14:54:12 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: <9751cf00-78b4-0dfd-4c70-7a04cb930215@redhat.com> References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> <9751cf00-78b4-0dfd-4c70-7a04cb930215@redhat.com> Message-ID: <5e7f167e-b5d3-fd5a-1ec0-599df9ce0b31@redhat.com> On 01.07.2016 13:25, Petr Spacek wrote: > On 1.7.2016 11:43, Petr Spacek wrote: >> On 1.7.2016 11:17, Petr Spacek wrote: >>> On 1.7.2016 11:04, Christian Heimes wrote: >>>> On 2016-07-01 10:59, Petr Spacek wrote: >>>>> On 1.7.2016 10:55, Christian Heimes wrote: >>>>>> On 2016-07-01 10:48, Petr Spacek wrote: >>>>>>> On 1.7.2016 10:42, Christian Heimes wrote: >>>>>>>> RedHatCAService.wait_until_running() uses dogtag.ca_status() to make a >>>>>>>> HTTP(s) request to Dogtag in order to check if /ca/admin/ca/getStatus >>>>>>>> returns OK. The ca_status() function defaults to api.env.ca_host as >>>>>>>> host. >>>>>>>> >>>>>>>> On a replica without CA ca_host is a remote host (e.g. master's >>>>>>>> FQDN). ipa-ca-install waits for master:8080 instead of replica:8080, >>>>>>>> which might be blocked by a firewall. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/6016 >>>>>>> Interesting. How it happens that replica without CA is calling RedHatCAService? >>>>>>> >>>>>>> Also, why replica should be waiting for CA if it is not installed? >>>>>>> >>>>>>> I'm confused. >>>>>> There is a hint in the last sentence: ipa-ca-install >>>>>> >>>>>> The patch fixes ipa-ca-install on replicas. Right now ipa-ca-install >>>>>> doesn't wait for the local Dogtag to come up but connects to a remote >>>>>> Dogtag to check if it's up. It uses 8443 or 8080, which might be >>>>>> blocked. In my test setup I have both ports blocked so ipa-ca-install >>>>>> never succeeds. >>>>> Oh, I missed that, thanks! >>>>> >>>>> Isn't the root cause that ipa.env.ca_host does not get updated during >>>>> ipa-ca-install? >>>> Been there, tried it, didn't work: >>>> https://fedorahosted.org/freeipa/ticket/6016#comment:1 >>> I understand that it does not work right now but it does not mean that it is >>> an actual problem in api.env :-) >>> >>> Anyway, I'm testing your patch but I'm not sure we can get it into 4.4.0 as >>> Petr^1 is about to push the RELEASE button any minute now. >>> >>> Petr^2 Spacek >>> >>>> It just doesn't make sense that RedHatCAService should ever check a >>>> remote instance. The rest of the class is about the local systemd >>>> service. As soon as we have sd_notify >>>> https://fedorahosted.org/pki/ticket/1233 implemented, we can use systemd >>>> to wait for Dogtag. >> It seems to work but ipa-client-install blows up on certificate request. >> >> # getcert list >> Number of certificates and requests being tracked: 1. >> Request ID '20160701093734': >> status: CA_UNREACHABLE >> ca-error: Server at >> https://vm-058-082.abc.idm.lab.eng.brq.redhat.com/ipa/xml failed request, will >> retry: 903 (RPC failed at server. an internal error has occurred). >> stuck: no >> key pair storage: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local >> IPA host',token='NSS Certificate DB',pinfile='/etc/ipa/nssdb/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local IPA >> host' >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> error log on the server: >> >> [Fri Jul 01 11:37:34.294677 2016] [wsgi:error] [pid 38273] ipa: INFO: >> [jsonserver_kerb] >> host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >> host_mod(u'vm-046.abc.idm.lab.eng.brq.redhat.com', ipasshpubkey=(u'ssh-rsa >> AAAAB3NzaC1yc2EAAAADAQABAAABAQCtrWFHeOF6UxI/DNdlLsUUazTpol2sRqQgbZplpkB9t/HUSjUHq0OY1mwaUfxvJp/E9yDmuHZgUgzKMSAdUf2apwFm5bw3T7qSdJ0Y7hC9vG0v6kLT0EaPuQmfJ8Rt4xOyva9htKbzkxs9Kr0ujB6V4u41ZZW2oevqtGunC2+aCxkQzd42we0c47ypxnvl8gGAa76CDXenGaChPKSfeEMddnhFvjGfkSyqjD+dCxBF+IyTRDPtt6f5iF80lfv/559rsKYlHdbbgv30i5C/F2DzaB011BmcQwK1eWSGWsEWVFtQKNMdahTl2IMgvZwHcaw8TMqgqqgZ7ZZ6lMR+UA8l', >> u'ecdsa-sha2-nistp256 >> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHkoeGOzfQzqYOGQs2bdgL0jOBul+/eTBZ0HBM8HW3Wb5O15Fv3rt8jRp+xdSQcdG3DV5yPfjd66Fyz5hCTKS6s=', >> u'ssh-ed25519 >> AAAAC3NzaC1lZDI1NTE5AAAAIH5/uXvdJ1l+uTAk0rgbjKeTBx9HRWk7w+xJLHMt/yRx'), >> updatedns=False, version=u'2.26'): SUCCESS >> [Fri Jul 01 11:37:37.961175 2016] [wsgi:error] [pid 38272] ipa: ERROR: >> non-public: ValueError: User name is defined only for user and enterprise >> principals >> [Fri Jul 01 11:37:37.961220 2016] [wsgi:error] [pid 38272] Traceback (most >> recent call last): >> [Fri Jul 01 11:37:37.961224 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 352, in >> wsgi_execute >> [Fri Jul 01 11:37:37.961226 2016] [wsgi:error] [pid 38272] result = >> self.Command[name](*args, **options) >> [Fri Jul 01 11:37:37.961229 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__ >> [Fri Jul 01 11:37:37.961259 2016] [wsgi:error] [pid 38272] return >> self.__do_call(*args, **options) >> [Fri Jul 01 11:37:37.961262 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in __do_call >> [Fri Jul 01 11:37:37.961265 2016] [wsgi:error] [pid 38272] ret = >> self.run(*args, **options) >> [Fri Jul 01 11:37:37.961267 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run >> [Fri Jul 01 11:37:37.961269 2016] [wsgi:error] [pid 38272] return >> self.execute(*args, **options) >> [Fri Jul 01 11:37:37.961271 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 456, in execute >> [Fri Jul 01 11:37:37.961274 2016] [wsgi:error] [pid 38272] >> caacl_check(principal_type, principal, ca, profile_id) >> [Fri Jul 01 11:37:37.961276 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 227, in >> caacl_check >> [Fri Jul 01 11:37:37.961278 2016] [wsgi:error] [pid 38272] principal, ca, >> profile_id): >> [Fri Jul 01 11:37:37.961280 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/caacl.py", line 126, in >> acl_evaluate >> [Fri Jul 01 11:37:37.961283 2016] [wsgi:error] [pid 38272] req = >> _acl_make_request(principal_type, principal, ca_id, profile_id) >> [Fri Jul 01 11:37:37.961285 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/caacl.py", line 68, in >> _acl_make_request >> [Fri Jul 01 11:37:37.961287 2016] [wsgi:error] [pid 38272] req.user.name = >> principal.username >> [Fri Jul 01 11:37:37.961289 2016] [wsgi:error] [pid 38272] File >> "/usr/lib/python2.7/site-packages/ipapython/kerberos.py", line 169, in username >> [Fri Jul 01 11:37:37.961292 2016] [wsgi:error] [pid 38272] "User name is >> defined only for user and enterprise principals") >> [Fri Jul 01 11:37:37.961294 2016] [wsgi:error] [pid 38272] ValueError: User >> name is defined only for user and enterprise principals >> [Fri Jul 01 11:37:37.961656 2016] [wsgi:error] [pid 38272] ipa: INFO: >> [xmlserver] >> host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >> cert_request(u'MIIEDjCCAvYCAQAwZTEzMDEGA1UEChMqRE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NMS4wLAYDVQQDEyV2bS0wNDYuYWJjLmlkbS5sYWIuZW5nLmJycS5yZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1zWanFx8qhfuHDgCjkQxkNBx6PoHfc+xNdb2OBcPfcfHL9HMjRGmTWN+CRZ388C+qxaExYed6WfmB/pK+b2M3fOnz1SRBPqicnCERP3G4mg02sL8cH068FShJvJECxWZxhvMiy/I0l/gRef1CJhaMJ5XGGuhZrLn3+Cv1BEgQDajBFsaZVeWTmwvROTjTht95QLUp8r9laPlGDzYnCdaWQ/R6Z1y+Mdu3I5VmxYL8TsH3NTDHjPvkDuQfPcdGkWp9V06QMp7MZeX0DEhsG2jeQc309xbe3vaPNPWClUv9OQX9xDgdlKO3E6UZKKWjXNUpqErpSFC1PiFqsMbJ36J7QIDAQABoIIBYjArBgkqhkiG9w0BCRQxHh4cAEwAbwBjAGEAbAAgAEkAUABBACAAaABvAHMAdDCCATEGCSqGSIb3DQEJDjGCASIwggEeMIHrBgNVHREBAQAEgeAwgd2gZQYKKwYBBAGCNxQCA6BXDFVob3N0L3ZtLTA0Ni5hYmMuaWRtLmxhYi5lbmcuYnJxLnJlZGhhdC5jb21ARE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NoHQGBisGAQUCAqBqMGigLBsqRE9NLTA1OC0wODIuQUJDLklETS5MQUIuRU5HLkJSUS5SRURIQVQuQ09NoTgwNqADAgEBoS8wLRsEaG9zdBsldm0tMDQ2LmFiYy5pZG0ubGFiLmVuZy5icnEucmVkaGF0LmNvbTAMBgNVHRMBAf8E! > Aj! >> AAMCAGA1UdDgEBAAQWBBQQxo41ZpwB24cjTd1cxY9eKbxNkTANBgkqhkiG9w0BAQsFAAOCAQEAERsZQANNrwiDBTEa0Kpif5DB/lfRjSedZpIL/mPPRUJnKus/9hV5gyUZcUQ+c2NEwvIApBJk0TeSIU0xj+dFOsqaN8iPj05XI5axEnBOqGdkHfjxSe96eR7WHCX8JJPdy5SMcoa1T3R6+4myq2/CWceTNcfxM4DdAY5kYvaePOPb13l3YUy9yB12QhDx+BBTNfmsmVxvGkySfegJcJMacQrbIk3AAoj3BklrTSQPqESBvqSVWT/yZE2HcQ6H2aLfeChdieYFsl/gPqCbLDKQA7gdK9Pv5w2dDzMGvpNne/1MCksu9MD9Ys9KvuugOjWNHciglO/kwF4ZJbfJsRqz0Q==', >> principal=u'host/vm-046.abc.idm.lab.eng.brq.redhat.com at DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >> add=True, version=u'2.51'): ValueError >> >> >> I suspect that this is a regression caused by Kerberos aliases support but I'm >> not going to ACK this until I can test it thoroughly. > Okay, after '[PATCH 0178] Fix incorrect check for principal type when > evaluating CA ACLs' it works. ACK. > Patch needs changes in ipa-4-3 branch From rcritten at redhat.com Thu Jul 7 13:06:18 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 7 Jul 2016 09:06:18 -0400 Subject: [Freeipa-devel] [PATCH 0017] Added fix for correct IPA backup file name In-Reply-To: References: <28e5999e-9dc8-f59d-28a6-1db882199880@redhat.com> <0d70dfbb-db6a-5df4-858b-1181404ef147@redhat.com> Message-ID: <577E53CA.5040205@redhat.com> Abhijeet Kasurde wrote: > Hi Florence, > > > On 07/07/2016 03:30 PM, Florence Blanc-Renaud wrote: >> On 07/07/2016 10:58 AM, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> Please review the patch. >>> >>> Fixes : https://fedorahosted.org/freeipa/ticket/6031 >>> >>> -- >>> Thanks, >>> Abhijeet Kasurde >>> >>> IRC: akasurde >>> http://akasurde.github.io >>> >>> >>> >> Hi Abhijeet, >> >> thanks for your patch. I have a comment though: if the filename is >> modified in ipa-backup, then it should also be changed in ipa-restore, >> to make sure that the backup can be restored. It may be a good idea to >> define the file name as a constant and use this constant everywhere. >> > I will change ipa-restore as well. >> As far as I can see, the tool ipa-restore checks that the backup >> version and ipa-restore version are consistent, meaning that both >> tools should use the same filename and that it will not break backward >> compatibility, but other team members can confirm. >> > I will wait for other team members to comment on this. ipa-restore will probably need to look for both the ipa-full.tar and ipa-full.tar.gz because the version check is optional. rob From rcritten at redhat.com Thu Jul 7 13:16:12 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 7 Jul 2016 09:16:12 -0400 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <577DE18F.4050103@redhat.com> References: <577DE18F.4050103@redhat.com> Message-ID: <577E561C.3070208@redhat.com> Sebastian Hetze wrote: > Hi * > > attached you find a patch that adds new options --subject_cn and > --subject_mail to ipa-server-install that make the CA cert subject CN > customizable. > > This patch has been tested by a customer in a PoC. > However, i assume additional testing in different environments is required. > > It would be greatly appreciated if this patch would find its way into > the product very soon. I don't see the advantage of passing around the subject_rdn along with the base. Why not pre-combine them into a DN? Similarly, I think I'd drop storing the subject base and RDN and just store just the DN. I don't think there would be any backwards compat issues as this would only apply to new installs. I think this would explode the number of options as users request additional attributes for the subject (OU, C, etc). Might be better to make the user pass in a full DN if they want to manage the CA subject. I don't know if any validation would be required for dogtag (e.g. is there a minimum set of components needed?) rob From pspacek at redhat.com Thu Jul 7 13:18:33 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 7 Jul 2016 15:18:33 +0200 Subject: [Freeipa-devel] IPA clients in AD DNS domain & Kerberos referrals Message-ID: Hello, this is probably a silly idea ... I wonder if there is some way to use Kerberos referrals on AD side in a way which would return cross-realm referral to IPA realm. Maybe it could be used in Frankenstein setup where IPA client belongs to a DNS domain managed by AD ... I do not know, just throwing out the idea. -- Petr^2 Spacek From abokovoy at redhat.com Thu Jul 7 13:32:26 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 7 Jul 2016 16:32:26 +0300 Subject: [Freeipa-devel] IPA clients in AD DNS domain & Kerberos referrals In-Reply-To: References: Message-ID: <20160707133226.andiuqxtii52g7pc@redhat.com> On Thu, 07 Jul 2016, Petr Spacek wrote: >Hello, > >this is probably a silly idea ... > >I wonder if there is some way to use Kerberos referrals on AD side in a way >which would return cross-realm referral to IPA realm. > >Maybe it could be used in Frankenstein setup where IPA client belongs to a DNS >domain managed by AD ... I do not know, just throwing out the idea. Yes, throw it out completely. :) For each trust Active Directory has a name suffix routing table. This table contains list of fully qualified domain names (TLNs) that belong to the trusted domain/forest's namespace or excluded from it. For those TLNs which belong to the trusted domain/forest namespace, Kerberos cross-realm TGT is issued to the client together with the referral. For those TLNs which are excluded from the namespace belonging to the trusted domain/forest namespace, no Kerberos cross-realm TGT is issued and no referral is given. If any of the TLNs from the trusted domain/forest conflicts with the Active Directory's own table or from any other trusted domain/forest, the trust is frozen and the conflict is marked as such. The whole forest trust is non-operational then. So there is only one possible solution: add exclusion TLNs for every host that belongs to IPA but is in AD DNS namespace to the AD own table. I talked to Microsoft people while at IOLab event and we verified that this is not a solution. The routing table is a single list and is consulted every single TGT request. This makes a solution of TLN exclusion entries a highly inefficient and affecting performance of all AD DCs for any requests. -- / Alexander Bokovoy From mkubik at redhat.com Thu Jul 7 13:46:52 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 7 Jul 2016 15:46:52 +0200 Subject: [Freeipa-devel] [patch 0038-0040] Sub CA test patches In-Reply-To: <20160704065746.GU4200@dhcp-40-8.bne.redhat.com> References: <072dcce1-3a76-9f26-62d7-a70e403239af@redhat.com> <20160624014203.GO4200@dhcp-40-8.bne.redhat.com> <0e08d68d-cc4e-3f8c-de7f-be8d21ee91f7@redhat.com> <20160627005734.GR4200@dhcp-40-8.bne.redhat.com> <20160704065746.GU4200@dhcp-40-8.bne.redhat.com> Message-ID: On 07/04/2016 08:57 AM, Fraser Tweedale wrote: > Hi Milan, > > Yes, we can :) Two issues, outlined below. > > > 1) > Running the tests, I get error in > test_create_subca_with_subject_conflict cleanup:: > > ____________ ERROR at teardown of TestCAbasicCRUD.test_create_subca_with_subject_conflict _____________ > > def cleanup(): > created = self.exists > try: > del_command() > > > E NotFound: crud-subca-2: Certificate Authority not found > > > I do not know testing framework very well but it looks like > track_create() sets 'self.exists = True' before the create command > throws the (expected) DuplicateEntry error. (These are called from > create() in the tracker 'base' class). Later, cleanup() catches a > NotFound but re-throws it because it believes the entry should have > existed. > > > 2) > the usercert.conf.tmpl does not like a subject base with spaces in > it, i.e. if 'openssl req' config template gets formatted like: > > [ dn ] > commonName = "alice" > o=IPA.LOCAL 201606201330 > > then 'openssl req' fails with nasty error like: > > 140644791924600:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:108: > 140644791924600:error:0B083077:x509 certificate routines:X509_NAME_ENTRY_create_by_txt:invalid field name:x509name.c:295:name=o > > and CalledProcessError gets raised and the test fails. > > Simplest solution is to simply remove the '{ipacertbase}' from the > template, because AFAIK it is not needed and parsing and formatting > the certbase (which could have multiple AVAs) is more complex than > the test calls for, IMO. > > > Thanks, > Fraser Hi, thanks. I must have missed the first issue after I removed the expected fail marker. I have fixed it now. As for the usercert template, this code is older than the issues at hand. I do not remember why exactly I used that option in the openssl config. I have removed that in a new patch. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0038-2-ipatests-Tracker-implementation-for-Sub-CA-feature.patch Type: text/x-patch Size: 11842 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0039-2-ipatests-Extend-CAACL-suite-to-cover-Sub-CA-members.patch Type: text/x-patch Size: 6442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0040-2-ipatests-Test-Sub-CA-with-CAACL-and-certificate-prof.patch Type: text/x-patch Size: 6341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0041-ipatests-remove-ipacertbase-option-from-test-CSR-con.patch Type: text/x-patch Size: 1919 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jul 7 14:04:57 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 7 Jul 2016 16:04:57 +0200 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <577E561C.3070208@redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> Message-ID: <708de570-5fe4-52a5-9395-ff017b8c9142@redhat.com> On 07/07/2016 03:16 PM, Rob Crittenden wrote: > Sebastian Hetze wrote: >> Hi * >> >> attached you find a patch that adds new options --subject_cn and >> --subject_mail to ipa-server-install that make the CA cert subject CN >> customizable. >> >> This patch has been tested by a customer in a PoC. >> However, i assume additional testing in different environments is >> required. >> >> It would be greatly appreciated if this patch would find its way into >> the product very soon. > > I don't see the advantage of passing around the subject_rdn along with > the base. Why not pre-combine them into a DN? > > Similarly, I think I'd drop storing the subject base and RDN and just > store just the DN. I don't think there would be any backwards compat > issues as this would only apply to new installs. > > I think this would explode the number of options as users request > additional attributes for the subject (OU, C, etc). Might be better to > make the user pass in a full DN if they want to manage the CA subject. I > don't know if any validation would be required for dogtag (e.g. is there > a minimum set of components needed?) +1, IMO using e.g., --subject="e=mail,cn=Something,O=REALM.NAME" is better. But IPA should validate it properly to disallow anything not usable by dogtag. Adding Fraser for the dogtag part. > > rob > -- Petr Vobornik From shetze at redhat.com Thu Jul 7 14:10:51 2016 From: shetze at redhat.com (Sebastian Hetze) Date: Thu, 7 Jul 2016 16:10:51 +0200 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <577E561C.3070208@redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> Message-ID: <577E62EB.4010706@redhat.com> On 07/07/2016 03:16 PM, Rob Crittenden wrote: > Sebastian Hetze wrote: >> Hi * >> >> attached you find a patch that adds new options --subject_cn and >> --subject_mail to ipa-server-install that make the CA cert subject CN >> customizable. >> >> This patch has been tested by a customer in a PoC. >> However, i assume additional testing in different environments is >> required. >> >> It would be greatly appreciated if this patch would find its way into >> the product very soon. > > I don't see the advantage of passing around the subject_rdn along with > the base. Why not pre-combine them into a DN? Think of the subject_rdn as given name for the CA cert and the subject_base as family name for all subsequent service certs that IPA automatically generates and signs. While the given names for the generated service certs may stay hard coded, only the given name for the CA cert needs to be customizable as requested in the RFE. Look into the source and you will see that subject_base is used all over the place and subject_rdn (as replacement for the hard coded "CN=Certificate Authority") only related to the CA cert. They need to be kept separate. > > > Similarly, I think I'd drop storing the subject base and RDN and just > store just the DN. I don't think there would be any backwards compat > issues as this would only apply to new installs. > > I think this would explode the number of options as users request > additional attributes for the subject (OU, C, etc). Might be better to > make the user pass in a full DN if they want to manage the CA subject. > I don't know if any validation would be required for dogtag (e.g. is > there a minimum set of components needed?) CN is mandatory and only emailAddress is a commonly used option for the "given name" subject_rdn. OU, C and alike belong to the subject_base. > > rob Beste Gr??e / Best regards Sebastian Hetze -- Senior Solution Architect Red Hat GmbH. Niederlassung Berlin Am Treptower Park 75 12435 Berlin Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com From flo at redhat.com Thu Jul 7 14:40:22 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 7 Jul 2016 16:40:22 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> Message-ID: <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> On 07/07/2016 01:23 PM, Petr Vobornik wrote: > On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >> Hi, >> >> the output of ipa selinuxusermap-add-hostgroup and >> selinuxusermap-add-user does not display any more the host/host group or >> user/group that could not be added. This patch fixes this regression by >> adding the labels host/hostgroup/user/group to the list of >> _failed_member_output_params of the class ClientMethod. >> >> >> https://fedorahosted.org/freeipa/ticket/6026 >> > > I've a feeling that this issue is more general and multiple commands > regressed. Would be good to check other member options, e.g. also in > user plugin. > Hi Petr, you are right, a lot of other commands regressed. So far I checked only user and sudocmd but it is likely to be a long task. Are there regression tests that could help me make sure that the fix is exhaustive? Flo From blipton at redhat.com Thu Jul 7 15:19:52 2016 From: blipton at redhat.com (Ben Lipton) Date: Thu, 7 Jul 2016 11:19:52 -0400 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> Message-ID: Thanks for the review! Comments below. On 07/01/2016 07:42 AM, Martin Basti wrote: > > > > On 29.06.2016 20:46, Ben Lipton wrote: >> The attached patch silences some annoying messages I've been getting >> when upgrading the freeipa-client package on F24: >> """ >> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >> several problems. This will be fixed by openssh-7.2p2-9.fc24 (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably shouldn't worry about it. >> Could not load host key: /etc/ssh/ssh_host_dsa_key This is because by default sshd looks for all of /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but Fedora doesn't generate a DSA key by default. >> """ >> >> Since the script causing the message only looks at the return code >> from sshd to determine the right options to use, I thought it might >> be ok to discard the output. What do you think? >> >> Ben >> >> > > Hello, I don't like to hiding errors/warnings. Can you determine and > solve the root cause? I definitely agree with this in principle, but in this case the purpose of this code is to try different, potentially wrong, parameters to sshd until it finds a combination that it accepts. It seems like in some environments this would produce error messages that aren't actionable and don't indicate any problem for package function, which is why I didn't think these messages were necessarily worth preserving. On the other hand, if the code makes the wrong decision about sshd version we might be interested in error logs that show why. Can we log this to a file instead of the console, maybe? If you'd prefer just addressing the root cause, a patch that prevents the missing host key error is attached, but it won't stop the error messages showing up when openssh is an older version. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0002-Use-existing-HostKey-config-to-test-sshd.patch Type: text/x-patch Size: 2607 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jul 8 03:42:48 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 8 Jul 2016 13:42:48 +1000 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <577E62EB.4010706@redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> <577E62EB.4010706@redhat.com> Message-ID: <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> On Thu, Jul 07, 2016 at 04:10:51PM +0200, Sebastian Hetze wrote: > > > On 07/07/2016 03:16 PM, Rob Crittenden wrote: > > Sebastian Hetze wrote: > >> Hi * > >> > >> attached you find a patch that adds new options --subject_cn and > >> --subject_mail to ipa-server-install that make the CA cert subject CN > >> customizable. > >> > >> This patch has been tested by a customer in a PoC. > >> However, i assume additional testing in different environments is > >> required. > >> > >> It would be greatly appreciated if this patch would find its way into > >> the product very soon. > > > > I don't see the advantage of passing around the subject_rdn along with > > the base. Why not pre-combine them into a DN? > Think of the subject_rdn as given name for the CA cert and the > subject_base as family name for all subsequent service certs that IPA > automatically generates and signs. While the given names for the > generated service certs may stay hard coded, only the given name for the > CA cert needs to be customizable as requested in the RFE. > Look into the source and you will see that subject_base is used all over > the place and subject_rdn (as replacement for the hard coded > "CN=Certificate Authority") only related to the CA cert. They need to be > kept separate. > In your patch, subject_rdn is used in few places where it is passed around. I agree with Rob; in the handful of places where the full DN is formed (currently by prepending "CN=Certificate Authority"), we should pass in the full DN. > > > > > > Similarly, I think I'd drop storing the subject base and RDN and just > > store just the DN. I don't think there would be any backwards compat > > issues as this would only apply to new installs. > > > > I think this would explode the number of options as users request > > additional attributes for the subject (OU, C, etc). Might be better to > > make the user pass in a full DN if they want to manage the CA subject. > > I don't know if any validation would be required for dogtag (e.g. is > > there a minimum set of components needed?) > CN is mandatory and only emailAddress is a commonly used option for the > "given name" subject_rdn. OU, C and alike belong to the subject_base. > Let us not add new arguments. We should enhance --subject instead. Existing behaviour: - ``--subject`` gives subject base. If not given, defaults to "O=$REALM". - "CN=Certificate Authority" prepended to subject base to form full subject DN. - Dogtag requires that the CA Subject DN starts with CN. My proposal for augmented behaviour: - If ``--subject`` not given, existing behaviour retained. - If ``--subject`` supplied: 1. Extract O, OU, C, L, ST and DC components from argument (order preserved) to form the subject base. If argument contains none of these attributes, subject base is defaulted to "O=$REALM" (per current behaviour) and appended to the CA Subject DN. 2. If argument contains CN but it is not the "most specific" RDN, move it to the front (to satisfy requirement of Dogtag profile). 3. If argument does not contain CN, prepend "CN=Certificate Authortiy" per existing behaviour. 4. Apart from (1), (2) and (3), CA Subject DN stays otherwise unchanged, therefore Email Address (E) is supported. Sebastian, would this scheme meet your customer's requirements? I also note, in your patch, that you define method DsInstance.find_subject_rdn() but it is not used. What is the purpose of this method? Thank you for providing this patch and pushing forward on this RFE. If you are happy with my above proposal I'm happy to take ownership and get this over this line. Cheers, Fraser > > > > rob > > Beste Gr??e / Best regards > Sebastian Hetze > -- > Senior Solution Architect > Red Hat GmbH. Niederlassung Berlin > Am Treptower Park 75 12435 Berlin > Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 > Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com > > -- > 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 ftweedal at redhat.com Fri Jul 8 04:06:42 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 8 Jul 2016 14:06:42 +1000 Subject: [Freeipa-devel] [patch 0038-0040] Sub CA test patches In-Reply-To: References: <072dcce1-3a76-9f26-62d7-a70e403239af@redhat.com> <20160624014203.GO4200@dhcp-40-8.bne.redhat.com> <0e08d68d-cc4e-3f8c-de7f-be8d21ee91f7@redhat.com> <20160627005734.GR4200@dhcp-40-8.bne.redhat.com> <20160704065746.GU4200@dhcp-40-8.bne.redhat.com> Message-ID: <20160708040642.GJ10771@dhcp-40-8.bne.redhat.com> On Thu, Jul 07, 2016 at 03:46:52PM +0200, Milan Kub?k wrote: > On 07/04/2016 08:57 AM, Fraser Tweedale wrote: > > Hi Milan, > > > > Yes, we can :) Two issues, outlined below. > > > > > > 1) > > Running the tests, I get error in > > test_create_subca_with_subject_conflict cleanup:: > > > > ____________ ERROR at teardown of TestCAbasicCRUD.test_create_subca_with_subject_conflict _____________ > > > > def cleanup(): > > created = self.exists > > try: > > del_command() > > > > > > E NotFound: crud-subca-2: Certificate Authority not found > > > > > > I do not know testing framework very well but it looks like > > track_create() sets 'self.exists = True' before the create command > > throws the (expected) DuplicateEntry error. (These are called from > > create() in the tracker 'base' class). Later, cleanup() catches a > > NotFound but re-throws it because it believes the entry should have > > existed. > > > > > > 2) > > the usercert.conf.tmpl does not like a subject base with spaces in > > it, i.e. if 'openssl req' config template gets formatted like: > > > > [ dn ] > > commonName = "alice" > > o=IPA.LOCAL 201606201330 > > > > then 'openssl req' fails with nasty error like: > > > > 140644791924600:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:108: > > 140644791924600:error:0B083077:x509 certificate routines:X509_NAME_ENTRY_create_by_txt:invalid field name:x509name.c:295:name=o > > > > and CalledProcessError gets raised and the test fails. > > > > Simplest solution is to simply remove the '{ipacertbase}' from the > > template, because AFAIK it is not needed and parsing and formatting > > the certbase (which could have multiple AVAs) is more complex than > > the test calls for, IMO. > > > > > > Thanks, > > Fraser > Hi, thanks. > > I must have missed the first issue after I removed the expected fail marker. > I have fixed it now. > > As for the usercert template, this code is older than the issues at hand. I > do not remember why exactly I used that > option in the openssl config. I have removed that in a new patch. > Thanks Milan, All working for me now. ACK on all four patches. Cheers, Fraser From ftweedal at redhat.com Fri Jul 8 04:52:45 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 8 Jul 2016 14:52:45 +1000 Subject: [Freeipa-devel] [PATCH] spec: require Dogtag >= 10.3.3-3 In-Reply-To: <0eab09f7-8d95-6651-1c8d-1412c08842eb@redhat.com> References: <0eab09f7-8d95-6651-1c8d-1412c08842eb@redhat.com> Message-ID: <20160708045245.GL10771@dhcp-40-8.bne.redhat.com> On Thu, Jul 07, 2016 at 01:16:04PM +0200, Petr Spacek wrote: > Hello, > > IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for > Fedora any time soon? > > Or should I update my scripts to automatically enable > COPR @freeipa/freeipa-master > in my testing VMs? > > Thanks. > Petr^2 Spacek > Hi Petr, The required features were released for Fedora as 10.3.3-3. Attached patch retracts the min required version accordingly. Thanks, Fraser -------------- next part -------------- From f6fd4c9c7838e841e1a3728d7e9afbe5f081927d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 8 Jul 2016 14:47:06 +1000 Subject: [PATCH] spec: require Dogtag >= 10.3.3-3 Required features that were expected to be released in Dogtag 10.3.4 have instead been released for Fedora in 10.3.3-3. Retract the minimum required version. https://fedorahosted.org/freeipa/ticket/5956 --- freeipa.spec.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index ff27a32eebcc640cdbc8895f47732f06a90c4a1b..135e9c980011c6c2730c6c29a3c22098e48270d5 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -94,7 +94,7 @@ BuildRequires: libunistring-devel BuildRequires: python-lesscpy BuildRequires: python-yubico >= 1.2.3 BuildRequires: openssl-devel -BuildRequires: pki-base >= 10.3.4 +BuildRequires: pki-base >= 10.3.3-3 BuildRequires: python-pytest-multihost >= 0.5 BuildRequires: python-pytest-sourceorder BuildRequires: python-kdcproxy >= 0.3 @@ -155,8 +155,8 @@ Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base >= %{selinux_policy_version} Requires: slapi-nis >= 0.56.0 -Requires: pki-ca >= 10.3.4 -Requires: pki-kra >= 10.3.4 +Requires: pki-ca >= 10.3.3-3 +Requires: pki-kra >= 10.3.3-3 Requires(preun): python systemd-units Requires(postun): python systemd-units Requires: zip -- 2.5.5 From shetze at redhat.com Fri Jul 8 10:57:13 2016 From: shetze at redhat.com (Sebastian Hetze) Date: Fri, 8 Jul 2016 12:57:13 +0200 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> <577E62EB.4010706@redhat.com> <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> Message-ID: <577F8709.5060307@redhat.com> On 07/08/2016 05:42 AM, Fraser Tweedale wrote: > On Thu, Jul 07, 2016 at 04:10:51PM +0200, Sebastian Hetze wrote: >> >> On 07/07/2016 03:16 PM, Rob Crittenden wrote: >>> Sebastian Hetze wrote: >>>> Hi * >>>> >>>> attached you find a patch that adds new options --subject_cn and >>>> --subject_mail to ipa-server-install that make the CA cert subject CN >>>> customizable. >>>> >>>> This patch has been tested by a customer in a PoC. >>>> However, i assume additional testing in different environments is >>>> required. >>>> >>>> It would be greatly appreciated if this patch would find its way into >>>> the product very soon. >>> I don't see the advantage of passing around the subject_rdn along with >>> the base. Why not pre-combine them into a DN? >> Think of the subject_rdn as given name for the CA cert and the >> subject_base as family name for all subsequent service certs that IPA >> automatically generates and signs. While the given names for the >> generated service certs may stay hard coded, only the given name for the >> CA cert needs to be customizable as requested in the RFE. >> Look into the source and you will see that subject_base is used all over >> the place and subject_rdn (as replacement for the hard coded >> "CN=Certificate Authority") only related to the CA cert. They need to be >> kept separate. >> > In your patch, subject_rdn is used in few places where it is passed > around. I agree with Rob; in the handful of places where the full > DN is formed (currently by prepending "CN=Certificate Authority"), > we should pass in the full DN. I understand you have two objections: first the "passing around" of the subject_rdn and second the additional command line options. The "passing around" is required unless you decompose the "subject_base" wherever it is used today. The name subject_base is chosen for a reason, it is just the base of the subject DN. It is used all over the place, not only for the CA cert. So yes, it would be possible to rename subject_base to cacert_subject and decompose the DN on every occurance of subject_base in the code. subject_rdn,subject_base = decompose_cacert_subject(cacert_subject) Is this really an improvement to passing the parameter only to those places where it is required? I dont think so. If passing around an additional parameter is a problem, I would rather prefer to pass subject{_base,_ca_rdn,_audit_rdn,_ra_rdn} as a dictionary instead of a string and possibly allow other certificate subjects to be customized if this is required by a customer some time in the future. But this again would require to change the code everywhere where subject_base is currently used. The current RFE (and my customer) only requests the CA cert subject to be customizable. > >>> >>> Similarly, I think I'd drop storing the subject base and RDN and just >>> store just the DN. I don't think there would be any backwards compat >>> issues as this would only apply to new installs. >>> >>> I think this would explode the number of options as users request >>> additional attributes for the subject (OU, C, etc). Might be better to >>> make the user pass in a full DN if they want to manage the CA subject. >>> I don't know if any validation would be required for dogtag (e.g. is >>> there a minimum set of components needed?) >> CN is mandatory and only emailAddress is a commonly used option for the >> "given name" subject_rdn. OU, C and alike belong to the subject_base. >> > Let us not add new arguments. We should enhance --subject instead. > > Existing behaviour: > > - ``--subject`` gives subject base. If not given, defaults to > "O=$REALM". > > - "CN=Certificate Authority" prepended to subject base to form > full subject DN. > > - Dogtag requires that the CA Subject DN starts with CN. > > My proposal for augmented behaviour: > > - If ``--subject`` not given, existing behaviour retained. > > - If ``--subject`` supplied: > > 1. Extract O, OU, C, L, ST and DC components from argument > (order preserved) to form the subject base. If argument > contains none of these attributes, subject base is defaulted > to "O=$REALM" (per current behaviour) and appended to the CA > Subject DN. Actually, when using an external_ca you may rather want the subject to be forced into the canonical order. The AD PKI does this when signing the ipa.csr. That is: you need to pass the subject in canonical order in the first place to receive a signed cacert from AD that matches the requests subject. I don't suggest such an behaviour, but you should not assume the order of attributes in the base DN has no meaning just because dogtag ignores it. > > 2. If argument contains CN but it is not the "most specific" > RDN, move it to the front (to satisfy requirement of Dogtag > profile). It is quite common to have the emailAddress as additional attribute in the subject and if it exists it is always the most specific, followed by the CN. The patch I am proposing works apparently with freeipa. So what is this requirement you mention? > > 3. If argument does not contain CN, prepend "CN=Certificate > Authortiy" per existing behaviour. > > 4. Apart from (1), (2) and (3), CA Subject DN stays otherwise > unchanged, therefore Email Address (E) is supported. As I said, the AD PKI does re-order the attributes. While you may argue that it should not do that, this is reality for all of our customers using that product. And the whole purpose of this RFE and my proposed patch is to enable our customers to work with freeipa in an highly regulated environment with specific requirements regarding the subject of a CA cert, regardless what superodinate PKI the customer uses. > > Sebastian, would this scheme meet your customer's requirements? With your proposal, a subject would look like this: Subject: CN=Custom CA Name,E=caadmin at example.com,OU=Example IT,O=Example Corp,L=City,ST=State,C=US I will check with my customer if this can possibly be signed by the AD PKI, and if that works what the ordering looks like after signing. Just to indicate how weird that ordering is, observe how OpenSSL will display that subject: Subject: C=US,ST=State,L=City,O=Example Corp,OU=Example IT/emailAddress=caadmin at example.com,CN=Custom CA Name instead of the usual Subject: C=US,ST=State,L=City,O=Example Corp,OU=Example IT,CN=Custom CA Name/emailAddress=caadmin at example.com Unless there is a strong feedback from other users/customers supporting that unconventional ordering, I am against such an implementation. > > I also note, in your patch, that you define method > DsInstance.find_subject_rdn() but it is not used. What is the > purpose of this method? There is a method DsInstance.find_subject_base. The find_subject_rdn has exactly the same purpose. While I did get along without using it so far, I expect it to be required somewhere down the line the very same way find_subject_base is used today. If your testing finds the patch works perfect in all possible occasions, this new method should be removed. > > Thank you for providing this patch and pushing forward on this RFE. > If you are happy with my above proposal I'm happy to take ownership > and get this over this line. > > Cheers, > Fraser > >>> rob >> Beste Gr??e / Best regards >> Sebastian Hetze >> -- >> Senior Solution Architect >> Red Hat GmbH. Niederlassung Berlin >> Am Treptower Park 75 12435 Berlin >> Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 >> Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com >> >> -- >> 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 Beste Gr??e / Best regards Sebastian Hetze -- Senior Solution Architect Red Hat GmbH. Niederlassung Berlin Am Treptower Park 75 12435 Berlin Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com From pspacek at redhat.com Fri Jul 8 11:18:23 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 8 Jul 2016 13:18:23 +0200 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> <577E62EB.4010706@redhat.com> <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> Message-ID: <623db5fe-03af-c5d2-c48c-58ca6b2584ce@redhat.com> On 8.7.2016 05:42, Fraser Tweedale wrote: > > 2. If argument contains CN but it is not the "most specific" > RDN, move it to the front (to satisfy requirement of Dogtag > profile). I wonder if we can relax the requirement in Dogtag so no reordering is needed. After all, DN is just a name, isn't it? Why Dogtag requires particular field in DN? -- Petr^2 Spacek From mbasti at redhat.com Fri Jul 8 11:52:51 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 8 Jul 2016 13:52:51 +0200 Subject: [Freeipa-devel] [PATCH 0550] host-find: do not show SSH keys by default Message-ID: <83cd1331-5499-19c5-e1af-ccfb7b3056bc@redhat.com> Reproducible only with 2+ hosts, patch attached. https://fedorahosted.org/freeipa/ticket/6043 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0550-host-find-do-not-show-SSH-key-by-default.patch Type: text/x-patch Size: 1103 bytes Desc: not available URL: From shetze at redhat.com Fri Jul 8 11:54:33 2016 From: shetze at redhat.com (Sebastian Hetze) Date: Fri, 8 Jul 2016 13:54:33 +0200 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <577F8709.5060307@redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> <577E62EB.4010706@redhat.com> <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> <577F8709.5060307@redhat.com> Message-ID: <577F9479.9070503@redhat.com> On 07/08/2016 12:57 PM, Sebastian Hetze wrote: > > > With your proposal, a subject would look like this: > Subject: CN=Custom CA Name,E=caadmin at example.com,OU=Example IT,O=Example > Corp,L=City,ST=State,C=US > > I will check with my customer if this can possibly be signed by the AD > PKI, and if that works what the ordering looks like after signing. As I expected, the AD PKI brings the whole subject line into canonical order, resulting in that subject: Subject: E=caadmin at example.com,CN=Custom CA Name,OU=Example IT,O=Example Corp,L=City,ST=State,C=US Since the ipa-server-install requires the subject of the signed cert to match exactly the subject from the CSR, we need to construct the subject line exactly as I do in my proposed patch. And, as I said, the patch works with freeipa-4.2.0 as shipped with RHEL-7.2 Beste Gr??e / Best regards Sebastian Hetze -- Senior Solution Architect Red Hat GmbH. Niederlassung Berlin Am Treptower Park 75 12435 Berlin Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com From mbasti at redhat.com Fri Jul 8 12:01:51 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 8 Jul 2016 14:01:51 +0200 Subject: [Freeipa-devel] CI DNS locations: basic test for SRV records Message-ID: <3522a067-8d58-28cb-d09b-02928a811128@redhat.com> See commit message for details. Patch attached. This test does not cover: * NTP service records * ipa-ca A/AAAA records * ADTrust records Should I open tickets to cover cases above? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0551-CI-DNS-locations.patch Type: text/x-patch Size: 16288 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 8 12:10:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 8 Jul 2016 14:10:07 +0200 Subject: [Freeipa-devel] [Test][patch-0053] Forced-client-reenrollment test fixed. In-Reply-To: <577DF223.5010302@redhat.com> References: <577ACC32.3030201@redhat.com> <577DF223.5010302@redhat.com> Message-ID: On 07.07.2016 08:09, Oleg Fayans wrote: > Updated version of the patch is attached with the failing tests marked > as xfailed (let's make the jenkins green). > > On 07/04/2016 10:50 PM, Oleg Fayans wrote: >> 2 out of 7 tests currently fail due to a known issue [1], others pass. >> >> [1] https://fedorahosted.org/freeipa/ticket/6029 >> >> >> >> > > > This is wrong: 1) you are not getting SSHFP records, just SSH public key (with your changes) 2) you are using host-find without any arguments, so it will returns SSH key for all hosts, the code before was getting SSHFP only for one host. Would be better to use host-show? 3) you actually found a bug, because host-find and host-show should print only SSH fingerprints not SSH keys https://fedorahosted.org/freeipa/ticket/6042 https://fedorahosted.org/freeipa/ticket/6043 4) don't call it SSHFP records in code, because it is not DNS related, probably you want to get SSH fingerprints instead of SSH keys 5) It may contain multiple SSH keys, you always return only the first (the original code returns all values) def get_sshfp_record(self): - sshfp_record = '' - client_host = self.clients[0].hostname.split('.')[0] - result = self.master.run_command( - ['ipa', 'dnsrecord-show', self.master.domain.name, client_host] + ['ipa', 'host-find'] ) - - lines = result.stdout_text.splitlines() - for line in lines: - if 'SSHFP record:' in line: - sshfp_record = line.replace('SSHFP record:', '').strip() - - assert sshfp_record, 'SSHFP record not found' - - sshfp_record = set(sshfp_record.split(', ')) - self.log.debug("SSHFP record for host %s: %s", client_host, str(sshfp_record)) - - return sshfp_record + records = result.stdout_text.split('\n\n') + sshkey_re = re.compile('.+SSH public key: ssh-\w+ (\S+?),.+') + for hostrecord in records: + if self.clients[0].hostname in hostrecord: + sshfps = sshkey_re.findall(hostrecord) + assert sshfps, 'SSHFP record not found' + sshfp = sshfps[0] + return sshfp -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Jul 8 12:18:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 8 Jul 2016 14:18:04 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <577113B2.1080904@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> Message-ID: <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> On 27.06.2016 13:53, Oleg Fayans wrote: > Hi guys, > > Is there a chance the patches NN 0047.1 and 0048.1 get reviewed before > 4.4 release? They cover a good part of the Managed Topology 4.4 feature. > > On 06/17/2016 11:18 AM, Oleg Fayans wrote: >> One more test was added to the patch-0048 >> >> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>> Fixed a bug in the previous patch, automated 2 more testcases from >>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>> >>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>> >>>> >>> >>> >> >> IIUC, this will turn off the machine completely, how is cleanup done then. AFAIK our tests cannot turn on machine again and run cleanup, so you will not be able to run more tests on the same topology without manual cleanup and manual start. + replica = self.replicas[0] + replica.run_command(['poweroff']) IMO would be better to just call 'ipactl stop' instead of 'poweroff' Martin^2 From mkubik at redhat.com Fri Jul 8 12:24:41 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 8 Jul 2016 14:24:41 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> Message-ID: <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> On 07/01/2016 05:13 PM, Lenka Doudova wrote: > > > > On 07/01/2016 02:42 PM, Milan Kub?k wrote: >> On 06/16/2016 03:23 PM, Lenka Doudova wrote: >>> Hi, >>> >>> attached are tests for authentication indicators. Please note: >>> >>> 1. newly created service tracker is not exactly complete, list of >>> unimplemented methods is in doc. These methods can be filled in when >>> existing declarative tests are refactored. >>> >>> 2. patch 0015 depends on 0014, so it should not be pushed without it. >>> >>> >>> Lenka >>> >>> >>> >> >> patch 0014: >> >> In the update method, what happens when the updated attributes >> contain addattr? It is not clear to me. Is it necessary? >> > Example: > ipa service-mod SRV --addattr="authind=radius" > > Result: > The way the tracker works, this adds /u'addattr="authind=radius"'/ > to the list of expected results (result of > /self.attrs.update(updates)/. Of course nothing like that appears > anywhere, so in case there's the /--addattr/ option, it's necessary to > ensure it won't get to the /self.attrs/ atribute. > >> patch 0015: >> >> host1 and service2 do not tell anything about the purpose of the >> fixture. Please assign more descriptive names to them. >> Why do the fixtures have 'function' scope? Does the service entry >> exist during the second and third test case? >> > Renamed. >> >> patch 0016: >> >> Per offline discussion, admin user has no special privileges here, LGTM. >> >> -- >> Milan Kubik > > Thanks for review, fixed patches (14.2 and 15.2) attached. > Lenka NACK, the update method of ServiceTracker creates the entry if it doesn't exist. Why? I know the base class has this problem also [1], though. Given this will be addressed, the fixtures in the xmlrpc test will fail since the fixture scope is wrong - function instead of class. [1]: https://fedorahosted.org/freeipa/ticket/6045 -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Jul 8 13:23:12 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 8 Jul 2016 15:23:12 +0200 Subject: [Freeipa-devel] CA-less installs: passive certmonger - watch-and-warn mode Message-ID: Hi, our docs https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca claim this: "The certmonger service is not used to track certificates. Therefore, it does not warn you of impending certificate expiration." Is this correct? Can we at least configure certmonger to passively track the certificates and throw warning about impending expiration into logs? -- Petr^2 Spacek From rcritten at redhat.com Fri Jul 8 13:31:45 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 8 Jul 2016 09:31:45 -0400 Subject: [Freeipa-devel] CA-less installs: passive certmonger - watch-and-warn mode In-Reply-To: References: Message-ID: <577FAB41.7030909@redhat.com> Petr Spacek wrote: > Hi, > > our docs > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca > > claim this: > "The certmonger service is not used to track certificates. Therefore, it does > not warn you of impending certificate expiration." > > Is this correct? > > Can we at least configure certmonger to passively track the certificates and > throw warning about impending expiration into logs? > Throw a warning where? Register an e-mail address as part of the tracking perhaps? It would probably be fairly easy to write a "CA" that sends an e-mail. The trick, and this has always tripped us up, is having an MTA configured. rob From pspacek at redhat.com Fri Jul 8 13:37:17 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 8 Jul 2016 15:37:17 +0200 Subject: [Freeipa-devel] CA-less installs: passive certmonger - watch-and-warn mode In-Reply-To: <577FAB41.7030909@redhat.com> References: <577FAB41.7030909@redhat.com> Message-ID: <2e9575f4-a599-1bb7-045d-ff2e589720b8@redhat.com> On 8.7.2016 15:31, Rob Crittenden wrote: > Petr Spacek wrote: >> Hi, >> >> our docs >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca >> >> >> claim this: >> "The certmonger service is not used to track certificates. Therefore, it does >> not warn you of impending certificate expiration." >> >> Is this correct? >> >> Can we at least configure certmonger to passively track the certificates and >> throw warning about impending expiration into logs? >> > > Throw a warning where? Register an e-mail address as part of the tracking > perhaps? > > It would probably be fairly easy to write a "CA" that sends an e-mail. The > trick, and this has always tripped us up, is having an MTA configured. I would start with logs, as I wrote in the original message. This will naturally evolve into something else when we finally get user-configurable hooks. In any case, having certmonger configured to track the certs is prerequisite for all cases... -- Petr^2 Spacek From ofayans at redhat.com Fri Jul 8 13:41:11 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 8 Jul 2016 15:41:11 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> Message-ID: <577FAD77.7080504@redhat.com> Hi Martin, Thanks for the review! On 07/08/2016 02:18 PM, Martin Basti wrote: > > > On 27.06.2016 13:53, Oleg Fayans wrote: >> Hi guys, >> >> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed before >> 4.4 release? They cover a good part of the Managed Topology 4.4 feature. >> >> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>> One more test was added to the patch-0048 >>> >>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>> Fixed a bug in the previous patch, automated 2 more testcases from >>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>> >>>> >>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>> >>>>> >>>> >>>> >>> >>> > IIUC, this will turn off the machine completely, how is cleanup done > then. AFAIK our tests cannot turn on machine again and run cleanup, so > you will not be able to run more tests on the same topology without > manual cleanup and manual start. > > + replica = self.replicas[0] > + replica.run_command(['poweroff']) > > IMO would be better to just call 'ipactl stop' instead of 'poweroff' Agreed! Fixed. > > Martin^2 > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0048.2-Automated-ipa-replica-manage-del-tests.patch Type: text/x-patch Size: 4775 bytes Desc: not available URL: From rcritten at redhat.com Fri Jul 8 13:59:12 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 8 Jul 2016 09:59:12 -0400 Subject: [Freeipa-devel] CA-less installs: passive certmonger - watch-and-warn mode In-Reply-To: <2e9575f4-a599-1bb7-045d-ff2e589720b8@redhat.com> References: <577FAB41.7030909@redhat.com> <2e9575f4-a599-1bb7-045d-ff2e589720b8@redhat.com> Message-ID: <577FB1B0.7090509@redhat.com> Petr Spacek wrote: > On 8.7.2016 15:31, Rob Crittenden wrote: >> Petr Spacek wrote: >>> Hi, >>> >>> our docs >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca >>> >>> >>> claim this: >>> "The certmonger service is not used to track certificates. Therefore, it does >>> not warn you of impending certificate expiration." >>> >>> Is this correct? >>> >>> Can we at least configure certmonger to passively track the certificates and >>> throw warning about impending expiration into logs? >>> >> >> Throw a warning where? Register an e-mail address as part of the tracking >> perhaps? >> >> It would probably be fairly easy to write a "CA" that sends an e-mail. The >> trick, and this has always tripped us up, is having an MTA configured. > > I would start with logs, as I wrote in the original message. This will > naturally evolve into something else when we finally get user-configurable hooks. > > In any case, having certmonger configured to track the certs is prerequisite > for all cases... "Logs" is not very specific, do you mean syslog/journal? Feel free to open an RFE against certmonger with your proposal. I suspect that anything logged will just get lost in most cases. rob From mbasti at redhat.com Fri Jul 8 14:31:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 8 Jul 2016 16:31:34 +0200 Subject: [Freeipa-devel] [PATCH 0552] Vault: enable client side plugins CLI Message-ID: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> Patch attached. https://fedorahosted.org/freeipa/ticket/6035 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0552-Enable-vault-commands-on-client.patch Type: text/x-patch Size: 1960 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 8 14:34:22 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 8 Jul 2016 16:34:22 +0200 Subject: [Freeipa-devel] [PATCH 0552] Vault: enable client side plugins CLI In-Reply-To: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> References: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> Message-ID: <6bba2664-ad15-f6eb-ea64-017d88e55020@redhat.com> On 08.07.2016 16:31, Martin Basti wrote: > Patch attached. > https://fedorahosted.org/freeipa/ticket/6035 > > Please not this ticket during review https://fedorahosted.org/freeipa/ticket/6047 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Jul 8 14:36:45 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 8 Jul 2016 17:36:45 +0300 Subject: [Freeipa-devel] [PATCH 0552] Vault: enable client side plugins CLI In-Reply-To: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> References: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> Message-ID: <20160708143645.6wrqqapbknr4ac2j@redhat.com> On Fri, 08 Jul 2016, Martin Basti wrote: >Patch attached. >https://fedorahosted.org/freeipa/ticket/6035 >From 2c97c316c1db49daeda15c709f082ee083a741ad Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Fri, 8 Jul 2016 15:53:25 +0200 >Subject: [PATCH] Enable vault-* commands on client > >Client plugins fot vault commands were disabled by NO_CLI=True, >inherited from vault_add_interal, that is always NO_CLI=True. >Introduced by this commit 8278da6967dbe425b4e0c6cf37dc1c53052525b2 > >Removed NO_CLI=True from client side plugins for vault. > >https://fedorahosted.org/freeipa/ticket/6035 ACK. I haven't tested it but the change is obvious. -- / Alexander Bokovoy From shetze at redhat.com Sat Jul 9 09:38:01 2016 From: shetze at redhat.com (Sebastian Hetze) Date: Sat, 9 Jul 2016 11:38:01 +0200 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <577DE18F.4050103@redhat.com> References: <577DE18F.4050103@redhat.com> Message-ID: <5780C5F9.3040109@redhat.com> Hi *, from the discussion so far, I realize that I've made the false assumption that the actual requirements and business cases related to the pre exisiting RFE #828866 are well understood. To clarify the requirements, here is the core of a new RFE document that is on its way via the current customer case: 3. What is the nature and description of the request? Currently, the subject for a IPA generated CA cert is built of two components, a subject base DN (subject_base) and a static common name: 'CN=Certificate Authority'. While the subject_base is customizable via a command line option to ipa-server-install, the common name is hard coded into the installer. It is required to have the common name component of the subject DN customizable. In addition, it is required to allow an additional and optional emailAddress component prepended to the subject DN as most significant component. 4. Why does the customer need this? (List the business requirements here) The customer needs to integrate IPA into an existing chain of trust. The IPA generated CA certificate needs to be signed by an superordinate PKI. To allow the IPA CA CSR to be signed by the superordinate PKI, it needs to meet certain criteria, including a particular customer specific common name and an additional emailAddress to clearly identify the subordinate CA. The current hard coded common name does not meet the requirements and therefor makes the integration of IPA into the existing PKI impossible. This in turn leaves the Linux/Unix IT operations dependent from the superordinate PKI even in cases, where creation of service certs could perfectly be delegated to this Linux/Unix IT Ops in accordance to existing compliance rules and operational processes. 5. How would the customer like to achieve this? (List the functional requirements here) The customer would like to get options to customize the common name and add an email address to the CA cert subject upon creation with ipa-server-install --external-ca. 6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. The new feature (option) must result in a CA cert CSR with subject line like /usr/lib64/nss/unsupported-tools/pp -t cr -a -i /root/ipa.csr|grep Subject: Subject: E=caadmin at example.com,CN=Custom CA Name,OU=Example IT,O=Example Corp,L=City,ST=State,C=US or openssl req -text -noout -in /root/ipa.csr |grep Subject: Subject: C=US,ST=State,L=City,O=Example Corp,OU=Example IT,CN=Custom CA Name/emailAddress=caadmin at example.com This IPA CA CSR must be signable by an Active Directory PKI and that signed certificate must be usable to proceed with the IPA server installation. In particular, IPA must be able to provide and accept the canonical order of subject attributes with emailAddress as most significant attribute, like shown in the example above. 7. Is there already an existing RFE upstream or in Red Hat bugzilla? #828866 [RFE] enhance --subject option for ipa-server-install 8. Does the customer have any specific timeline dependencies? Within the next three months. On 07/07/2016 06:58 AM, Sebastian Hetze wrote: > Hi * > > attached you find a patch that adds new options --subject_cn and > --subject_mail to ipa-server-install that make the CA cert subject CN > customizable. > > This patch has been tested by a customer in a PoC. > However, i assume additional testing in different environments is required. > > It would be greatly appreciated if this patch would find its way into > the product very soon. > > Beste Gr??e / Best regards > Sebastian Hetze Beste Gr??e / Best regards Sebastian Hetze -- Senior Solution Architect Red Hat GmbH. Niederlassung Berlin Am Treptower Park 75 12435 Berlin Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com From blipton at redhat.com Sat Jul 9 12:46:35 2016 From: blipton at redhat.com (Ben Lipton) Date: Sat, 9 Jul 2016 08:46:35 -0400 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> Message-ID: On 07/07/2016 11:19 AM, Ben Lipton wrote: > > Thanks for the review! Comments below. > > > On 07/01/2016 07:42 AM, Martin Basti wrote: >> >> >> >> On 29.06.2016 20:46, Ben Lipton wrote: >>> The attached patch silences some annoying messages I've been getting >>> when upgrading the freeipa-client package on F24: >>> """ >>> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>> several problems. > This will be fixed by openssh-7.2p2-9.fc24 > (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably > shouldn't worry about it. >>> Could not load host key: /etc/ssh/ssh_host_dsa_key > This is because by default sshd looks for all of > /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, > /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but > Fedora doesn't generate a DSA key by default. >>> """ >>> >>> Since the script causing the message only looks at the return code >>> from sshd to determine the right options to use, I thought it might >>> be ok to discard the output. What do you think? >>> >>> Ben >>> >>> >> >> Hello, I don't like to hiding errors/warnings. Can you determine and >> solve the root cause? > > I definitely agree with this in principle, but in this case the > purpose of this code is to try different, potentially wrong, > parameters to sshd until it finds a combination that it accepts. It > seems like in some environments this would produce error messages that > aren't actionable and don't indicate any problem for package function, > which is why I didn't think these messages were necessarily worth > preserving. > > On the other hand, if the code makes the wrong decision about sshd > version we might be interested in error logs that show why. Can we log > this to a file instead of the console, maybe? > > If you'd prefer just addressing the root cause, a patch that prevents > the missing host key error is attached, but it won't stop the error > messages showing up when openssh is an older version. > > Thanks, > Ben > > Whoops, realized that my patch created a tempfile and didn't delete it. Updated. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0002-2-Use-existing-HostKey-config-to-test-sshd.patch Type: text/x-patch Size: 2798 bytes Desc: not available URL: From ftweedal at redhat.com Sun Jul 10 23:37:29 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 11 Jul 2016 09:37:29 +1000 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <623db5fe-03af-c5d2-c48c-58ca6b2584ce@redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> <577E62EB.4010706@redhat.com> <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> <623db5fe-03af-c5d2-c48c-58ca6b2584ce@redhat.com> Message-ID: <20160710233729.GN10771@dhcp-40-8.bne.redhat.com> On Fri, Jul 08, 2016 at 01:18:23PM +0200, Petr Spacek wrote: > On 8.7.2016 05:42, Fraser Tweedale wrote: > > > > 2. If argument contains CN but it is not the "most specific" > > RDN, move it to the front (to satisfy requirement of Dogtag > > profile). > > I wonder if we can relax the requirement in Dogtag so no reordering is needed. > After all, DN is just a name, isn't it? Why Dogtag requires particular field > in DN? > Cc pki-devel at . The subject name constraint in the caCAcert profile is: policyset.caCertSet.1.constraint.params.pattern=CN=.* What do you think? Can we relax or remove this constraint - or if not, why is it required? Thanks, Fraser From ftweedal at redhat.com Mon Jul 11 00:22:52 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 11 Jul 2016 10:22:52 +1000 Subject: [Freeipa-devel] Proposed patch to resolve #828866 [RFE] enhance --subject option for ipa-server-install In-Reply-To: <577F9479.9070503@redhat.com> References: <577DE18F.4050103@redhat.com> <577E561C.3070208@redhat.com> <577E62EB.4010706@redhat.com> <20160708034248.GH10771@dhcp-40-8.bne.redhat.com> <577F8709.5060307@redhat.com> <577F9479.9070503@redhat.com> Message-ID: <20160711002252.GO10771@dhcp-40-8.bne.redhat.com> On Fri, Jul 08, 2016 at 01:54:33PM +0200, Sebastian Hetze wrote: > On 07/08/2016 12:57 PM, Sebastian Hetze wrote: > > > > > > With your proposal, a subject would look like this: > > Subject: CN=Custom CA Name,E=caadmin at example.com,OU=Example IT,O=Example > > Corp,L=City,ST=State,C=US > > I was not proposing that the DN contain all those components; merely that particular components, if present, would be extract to form the subject base. In the case of --external-ca, the argument to --subject would be used as-is in the CSR. > > I will check with my customer if this can possibly be signed by the AD > > PKI, and if that works what the ordering looks like after signing. > As I expected, the AD PKI brings the whole subject line into canonical > order, resulting in that subject: > > Subject: E=caadmin at example.com,CN=Custom CA Name,OU=Example IT,O=Example > Corp,L=City,ST=State,C=US > > Since the ipa-server-install requires the subject of the signed cert to > match exactly the subject from the CSR, we need to construct the subject > line exactly as I do in my proposed patch. > > And, as I said, the patch works with freeipa-4.2.0 as shipped with RHEL-7.2 > It may work fine, but I feel it is not the best approach to add new arguments extra arguments. Your preliminary work and knowledge of the case are valuable. I will implement the single --subject argument approach and we can check that it meets the requirements. Thanks, Fraser > > Beste Gr??e / Best regards > Sebastian Hetze > -- > Senior Solution Architect > Red Hat GmbH. Niederlassung Berlin > Am Treptower Park 75 12435 Berlin > Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205 > Fax: +49 30 678 1798-111 . E-Mail: she at redhat.com > From mbabinsk at redhat.com Mon Jul 11 06:57:03 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 11 Jul 2016 08:57:03 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <20160706152222.4znlybol7y5c35gg@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> Message-ID: <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> On 07/06/2016 05:22 PM, Alexander Bokovoy wrote: > On Fri, 01 Jul 2016, Martin Babinsky wrote: >> Quick hacky fix for https://fedorahosted.org/freeipa/ticket/6028 >> >> Admittedly a more systematic solution exists. We may discuss it >> further in this thread (such as add options to modrdn plugin to append >> to multivalue attributes). If time is the issue, we may use this fix >> instead and revert it later when more robust solution is implemented. > There is no patch, only a .swp file attached. > Sorry, patch attached. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0179-Preserve-user-principal-aliases-during-rename-operat.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: From ldoudova at redhat.com Mon Jul 11 07:44:46 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 11 Jul 2016 09:44:46 +0200 Subject: [Freeipa-devel] [Testplan] Support of UPN for trusted domains In-Reply-To: <20160707091357.GD2919@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1a3667cb-e670-72da-f03f-f5b04133babe@redhat.com> <20160527081309.GI6640@p.Speedport_W_724V_Typ_A_05011603_00_009> <20160527082424.sr4wkzmcq4nwzpmg@redhat.com> <20160707091357.GD2919@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <7a19419c-9918-d3ed-fd1c-f4d2b779f53a@redhat.com> On 07/07/2016 11:13 AM, Sumit Bose wrote: > On Fri, May 27, 2016 at 11:24:24AM +0300, Alexander Bokovoy wrote: >> On Fri, 27 May 2016, Sumit Bose wrote: >>> On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote: >>>> Hi all, >>>> >>>> >>>> here [1] is a draft of test plan for V4 RFE Support of UPN for trusted >>>> domains. >>>> >>>> Please review this and let me know if there's something missing or wrong. >>> Hi Lenka, >>> >>> thank you for the test plan. >>> >>> About the TBD, Alexander and I agreed to store the alternative domain >>> suffixes read from AD in a new attribute in the LDAP object of the >>> forest root of the trusted domain. >>> >>> About the kinit tests. Please note that it is expected that the -E >>> option of kinit must be used when alternative suffixes are used. >>> >>> I'm not sure if SSSD tests are in the scope here as well. If they are I >>> would suggest to add authentication tests with SSSD where e.g. the name >>> with an alternative domain suffix is used as login name. This in general >>> already works with SSSD but is disabled by default for IPA because of >>> the missing server-side support so far. Since SSSD must be able to work >>> with old and new IPA server https://fedorahosted.org/sssd/ticket/3018 >>> was created so that SSSD can detect at runtime if the server supports >>> this or not. >> Right, I think we should make sure SSSD is tested against IPA UPN >> support because otherwise we might get regressions. > Hi Lenka, > > I would like to ask you to add test where 'kinit -E' is used with an IPA > user as well to avoid regression, because currently 'kinit -E > ipauser at IPA.DOMAIN' does not work. > > Please note that the full principal must be used with kinit in this case > because when just using > > kinit -E ipauser > > kinit is smart enough to see that it makes no sense to add the > default_realm twice and internally just does 'kinit ipauser at IPA.DOMAIN'. > > If you think this test is better suited in a different test plan please > let me know, then I'll ask there. > > bye, > Sumit Hi Sumit, this test should be covered in basic trust test suite, but I think it's not in the code of the test (I was busy with providing coverage for new features and didn't manage to go through old coverage). I'll check this and update ASAP. Thanks for catching it! Lenka >> >> -- >> / Alexander Bokovoy From frenaud at redhat.com Thu Jul 7 14:39:43 2016 From: frenaud at redhat.com (Florence Blanc-Renaud) Date: Thu, 7 Jul 2016 16:39:43 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> Message-ID: <5c7f791d-f1fc-7f77-dd19-76afa73c886b@redhat.com> On 07/07/2016 01:23 PM, Petr Vobornik wrote: > On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >> Hi, >> >> the output of ipa selinuxusermap-add-hostgroup and >> selinuxusermap-add-user does not display any more the host/host group or >> user/group that could not be added. This patch fixes this regression by >> adding the labels host/hostgroup/user/group to the list of >> _failed_member_output_params of the class ClientMethod. >> >> >> https://fedorahosted.org/freeipa/ticket/6026 >> > > I've a feeling that this issue is more general and multiple commands > regressed. Would be good to check other member options, e.g. also in > user plugin. > Hi Petr, you are right, a lot of other commands regressed. So far I checked only user and sudocmd but it is likely to be a long task. Are there regression tests that could help me make sure that the fix is exhaustive? Flo From flo at redhat.com Mon Jul 11 07:52:57 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Mon, 11 Jul 2016 09:52:57 +0200 Subject: [Freeipa-devel] [PATCH] 0011 server uninstall fails to remove krb principals Message-ID: Hi, please find a patch for the 3rd issue of ticket 6012. https://fedorahosted.org/freeipa/ticket/6012 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0011-server-uninstall-fails-to-remove-krb-principals.patch Type: text/x-patch Size: 2023 bytes Desc: not available URL: From sbose at redhat.com Mon Jul 11 07:56:29 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 11 Jul 2016 09:56:29 +0200 Subject: [Freeipa-devel] [Testplan] Support of UPN for trusted domains In-Reply-To: <7a19419c-9918-d3ed-fd1c-f4d2b779f53a@redhat.com> References: <1a3667cb-e670-72da-f03f-f5b04133babe@redhat.com> <20160527081309.GI6640@p.Speedport_W_724V_Typ_A_05011603_00_009> <20160527082424.sr4wkzmcq4nwzpmg@redhat.com> <20160707091357.GD2919@p.Speedport_W_724V_Typ_A_05011603_00_009> <7a19419c-9918-d3ed-fd1c-f4d2b779f53a@redhat.com> Message-ID: <20160711075629.GX2919@p.Speedport_W_724V_Typ_A_05011603_00_009> On Mon, Jul 11, 2016 at 09:44:46AM +0200, Lenka Doudova wrote: > > > On 07/07/2016 11:13 AM, Sumit Bose wrote: > > On Fri, May 27, 2016 at 11:24:24AM +0300, Alexander Bokovoy wrote: > > > On Fri, 27 May 2016, Sumit Bose wrote: > > > > On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote: > > > > > Hi all, > > > > > > > > > > > > > > > here [1] is a draft of test plan for V4 RFE Support of UPN for trusted > > > > > domains. > > > > > > > > > > Please review this and let me know if there's something missing or wrong. > > > > Hi Lenka, > > > > > > > > thank you for the test plan. > > > > > > > > About the TBD, Alexander and I agreed to store the alternative domain > > > > suffixes read from AD in a new attribute in the LDAP object of the > > > > forest root of the trusted domain. > > > > > > > > About the kinit tests. Please note that it is expected that the -E > > > > option of kinit must be used when alternative suffixes are used. > > > > > > > > I'm not sure if SSSD tests are in the scope here as well. If they are I > > > > would suggest to add authentication tests with SSSD where e.g. the name > > > > with an alternative domain suffix is used as login name. This in general > > > > already works with SSSD but is disabled by default for IPA because of > > > > the missing server-side support so far. Since SSSD must be able to work > > > > with old and new IPA server https://fedorahosted.org/sssd/ticket/3018 > > > > was created so that SSSD can detect at runtime if the server supports > > > > this or not. > > > Right, I think we should make sure SSSD is tested against IPA UPN > > > support because otherwise we might get regressions. > > Hi Lenka, > > > > I would like to ask you to add test where 'kinit -E' is used with an IPA > > user as well to avoid regression, because currently 'kinit -E > > ipauser at IPA.DOMAIN' does not work. > > > > Please note that the full principal must be used with kinit in this case > > because when just using > > > > kinit -E ipauser > > > > kinit is smart enough to see that it makes no sense to add the > > default_realm twice and internally just does 'kinit ipauser at IPA.DOMAIN'. > > > > If you think this test is better suited in a different test plan please > > let me know, then I'll ask there. > > > > bye, > > Sumit > Hi Sumit, > > this test should be covered in basic trust test suite, but I think it's not > in the code of the test (I was busy with providing coverage for new features > and didn't manage to go through old coverage). I'll check this and update > ASAP. > > Thanks for catching it! Thank you for taking care of it. bye, Sumit > Lenka > > > > > > > -- > > > / Alexander Bokovoy > From mbabinsk at redhat.com Mon Jul 11 08:50:21 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 11 Jul 2016 10:50:21 +0200 Subject: [Freeipa-devel] [PATCH 0182] ipa-compat-manage: use server API to retrieve plugin statu Message-ID: <3b52c33a-c943-d1c6-b718-06a796261ba5@redhat.com> Fixes regression reported in https://fedorahosted.org/freeipa/ticket/6033 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0182-ipa-compat-manage-use-server-API-to-retrieve-plugin-.patch Type: text/x-patch Size: 927 bytes Desc: not available URL: From slaznick at redhat.com Mon Jul 11 10:40:43 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Mon, 11 Jul 2016 12:40:43 +0200 Subject: [Freeipa-devel] [PATCH 0056] removed unused parameter from migrate-ds Message-ID: <5391b4ff-4ee3-92f6-f553-69fbbb9990b6@redhat.com> https://fedorahosted.org/freeipa/ticket/6034 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0056-Removed-unused-method-parameter-from-migrate-ds.patch Type: text/x-patch Size: 1133 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jul 11 11:04:42 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Jul 2016 14:04:42 +0300 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> Message-ID: <20160711110442.noea3ryuuqxngfyq@redhat.com> On Mon, 11 Jul 2016, Martin Babinsky wrote: >From 7742cab5aebb26b3a82baac379be01120c95c400 Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Fri, 1 Jul 2016 18:09:04 +0200 >Subject: [PATCH] Preserve user principal aliases during rename operation > >When a MODRDN is performed on the user entry, the MODRDN plugin resets both >krbPrincipalName and krbCanonicalName to the value constructed from uid. In >doing so, hovewer, any principal aliases added to the krbPrincipalName are >wiped clean. In this patch old aliases are fetched before the MODRDN operation >takes place and inserted back after it is performed. > >This also preserves previous user logins which can be used further for >authentication as aliases. > >https://fedorahosted.org/freeipa/ticket/6028 >--- > ipaserver/plugins/baseuser.py | 49 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > >diff --git a/ipaserver/plugins/baseuser.py b/ipaserver/plugins/baseuser.py >index 0052e718afe639bcc1c0a698ded39ea8407a0551..1d07284181e9db84609642cd61837fd8c23778af 100644 >--- a/ipaserver/plugins/baseuser.py >+++ b/ipaserver/plugins/baseuser.py >@@ -498,6 +498,53 @@ class baseuser_mod(LDAPUpdate): > len = int(config.get('ipamaxusernamelength')[0]) > ) > ) >+ >+ def preserve_krbprincipalname_pre(self, ldap, entry_attrs, *keys, **options): >+ """ >+ preserve user principal aliases during rename operation. This is the >+ pre-callback part of this. Another method called during post-callback >+ shall insert the principals back >+ """ >+ if options.get('rename') is None: >+ return >+ >+ try: >+ old_entry = ldap.get_entry( >+ entry_attrs.dn, attrs_list=( >+ 'krbprincipalname', 'krbcanonicalname')) >+ >+ if 'krbcanonicalname' not in old_entry: >+ return >+ except errors.NotFound: >+ self.obj.handle_not_found(*keys) >+ >+ self.context.krbprincipalname = old_entry.get( >+ 'krbprincipalname', []) >+ self.log.critical( >+ "krbprincipalname pre: {}".format(self.context.krbprincipalname)) >+ >+ def preserve_krbprincipalname_post(self, ldap, entry_attrs, **options): >+ """ >+ Insert the preserved aliases back to the user entry during rename >+ operation >+ """ >+ if options.get('rename') is None or not hasattr( >+ self.context, 'krbprincipalname'): >+ return >+ >+ self.log.critical( >+ "krbprincipalname post: {}".format(self.context.krbprincipalname)) >+ new_aliases = entry_attrs.get('krbprincipalname', []) >+ >+ new_aliases.extend(self.context.krbprincipalname) >+ entry_attrs['krbprincipalname'] = new_aliases >+ effective_rights = entry_attrs.pop('attributelevelrights', []) >+ >+ ldap.update_entry(entry_attrs) >+ >+ if effective_rights: >+ entry_attrs['attributelevelrights'] = effective_rights Why do you need to mess with effective rights here? Can you describe what happens on update that you need to drop them in the entry_attrs? >+ > def check_mail(self, entry_attrs): > if 'mail' in entry_attrs: > entry_attrs['mail'] = self.obj.normalize_and_validate_email(entry_attrs['mail']) >@@ -557,9 +604,11 @@ class baseuser_mod(LDAPUpdate): > > self.check_objectclass(ldap, dn, entry_attrs) > self.obj.convert_usercertificate_pre(entry_attrs) >+ self.preserve_krbprincipalname_pre(ldap, entry_attrs, *keys, **options) > > def post_common_callback(self, ldap, dn, entry_attrs, *keys, **options): > assert isinstance(dn, DN) >+ self.preserve_krbprincipalname_post(ldap, entry_attrs, **options) > if options.get('random', False): > try: > entry_attrs['randompassword'] = unicode(getattr(context, 'randompassword')) >-- >2.5.5 > -- / Alexander Bokovoy From slaznick at redhat.com Mon Jul 11 11:23:39 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Mon, 11 Jul 2016 13:23:39 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install Message-ID: https://fedorahosted.org/freeipa/ticket/6046 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0057-Don-t-show-force-ntpd-option-in-replica-install.patch Type: text/x-patch Size: 1749 bytes Desc: not available URL: From ldoudova at redhat.com Mon Jul 11 11:34:36 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 11 Jul 2016 13:34:36 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> Message-ID: On 07/08/2016 02:24 PM, Milan Kub?k wrote: > On 07/01/2016 05:13 PM, Lenka Doudova wrote: >> >> >> >> On 07/01/2016 02:42 PM, Milan Kub?k wrote: >>> On 06/16/2016 03:23 PM, Lenka Doudova wrote: >>>> Hi, >>>> >>>> attached are tests for authentication indicators. Please note: >>>> >>>> 1. newly created service tracker is not exactly complete, list of >>>> unimplemented methods is in doc. These methods can be filled in >>>> when existing declarative tests are refactored. >>>> >>>> 2. patch 0015 depends on 0014, so it should not be pushed without it. >>>> >>>> >>>> Lenka >>>> >>>> >>>> >>> >>> patch 0014: >>> >>> In the update method, what happens when the updated attributes >>> contain addattr? It is not clear to me. Is it necessary? >>> >> Example: >> ipa service-mod SRV --addattr="authind=radius" >> >> Result: >> The way the tracker works, this adds >> /u'addattr="authind=radius"'/ to the list of expected results (result >> of /self.attrs.update(updates)/. Of course nothing like that appears >> anywhere, so in case there's the /--addattr/ option, it's necessary >> to ensure it won't get to the /self.attrs/ atribute. >> >>> patch 0015: >>> >>> host1 and service2 do not tell anything about the purpose of the >>> fixture. Please assign more descriptive names to them. >>> Why do the fixtures have 'function' scope? Does the service entry >>> exist during the second and third test case? >>> >> Renamed. >>> >>> patch 0016: >>> >>> Per offline discussion, admin user has no special privileges here, LGTM. >>> >>> -- >>> Milan Kubik >> >> Thanks for review, fixed patches (14.2 and 15.2) attached. >> Lenka > > NACK, > > the update method of ServiceTracker creates the entry if it doesn't > exist. Why? I know the base class has this problem also [1], though. > Given this will be addressed, the fixtures in the xmlrpc test will > fail since the fixture scope is wrong - function instead of class. > > [1]: https://fedorahosted.org/freeipa/ticket/6045 > > -- > Milan Kubik Hi, fixed patch attached. I chose to leave the scope as it was (in case one test breaks and entry is not even created, the other tests can still be successful), but I removed the creation command from ServiceTracker update method and called it directly in the tests, so there shouldn't be hidden actions. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0014.3-Tests-Tracker-class-for-services.patch Type: text/x-patch Size: 7221 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0015.3-Tests-Authentication-indicators-xmlrpc-tests.patch Type: text/x-patch Size: 3052 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Jul 11 12:18:38 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 11 Jul 2016 14:18:38 +0200 Subject: [Freeipa-devel] [PATCH 0183] ipa-advise: correct handling of plugin namespace iteration Message-ID: <610683a7-079b-cd36-c28c-e4b0b4415aad@redhat.com> https://fedorahosted.org/freeipa/ticket/6044 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0183-ipa-advise-correct-handling-of-plugin-namespace-iter.patch Type: text/x-patch Size: 1581 bytes Desc: not available URL: From slaznick at redhat.com Mon Jul 11 12:30:23 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Mon, 11 Jul 2016 14:30:23 +0200 Subject: [Freeipa-devel] [PATCH 0183] ipa-advise: correct handling of plugin namespace iteration In-Reply-To: <610683a7-079b-cd36-c28c-e4b0b4415aad@redhat.com> References: <610683a7-079b-cd36-c28c-e4b0b4415aad@redhat.com> Message-ID: <95f99b2f-2de5-2c73-34ac-7baa99aad572@redhat.com> On 07/11/2016 02:18 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/6044 > > > ACK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Mon Jul 11 13:51:32 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 11 Jul 2016 15:51:32 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <20160711110442.noea3ryuuqxngfyq@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> Message-ID: <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> On 07/11/2016 01:04 PM, Alexander Bokovoy wrote: > On Mon, 11 Jul 2016, Martin Babinsky wrote: >> From 7742cab5aebb26b3a82baac379be01120c95c400 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Fri, 1 Jul 2016 18:09:04 +0200 >> Subject: [PATCH] Preserve user principal aliases during rename operation >> >> When a MODRDN is performed on the user entry, the MODRDN plugin resets >> both >> krbPrincipalName and krbCanonicalName to the value constructed from >> uid. In >> doing so, hovewer, any principal aliases added to the krbPrincipalName >> are >> wiped clean. In this patch old aliases are fetched before the MODRDN >> operation >> takes place and inserted back after it is performed. >> >> This also preserves previous user logins which can be used further for >> authentication as aliases. >> >> https://fedorahosted.org/freeipa/ticket/6028 >> --- >> ipaserver/plugins/baseuser.py | 49 >> +++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 49 insertions(+) >> >> diff --git a/ipaserver/plugins/baseuser.py >> b/ipaserver/plugins/baseuser.py >> index >> 0052e718afe639bcc1c0a698ded39ea8407a0551..1d07284181e9db84609642cd61837fd8c23778af >> 100644 >> --- a/ipaserver/plugins/baseuser.py >> +++ b/ipaserver/plugins/baseuser.py >> @@ -498,6 +498,53 @@ class baseuser_mod(LDAPUpdate): >> len = >> int(config.get('ipamaxusernamelength')[0]) >> ) >> ) >> + >> + def preserve_krbprincipalname_pre(self, ldap, entry_attrs, *keys, >> **options): >> + """ >> + preserve user principal aliases during rename operation. This >> is the >> + pre-callback part of this. Another method called during >> post-callback >> + shall insert the principals back >> + """ >> + if options.get('rename') is None: >> + return >> + >> + try: >> + old_entry = ldap.get_entry( >> + entry_attrs.dn, attrs_list=( >> + 'krbprincipalname', 'krbcanonicalname')) >> + >> + if 'krbcanonicalname' not in old_entry: >> + return >> + except errors.NotFound: >> + self.obj.handle_not_found(*keys) >> + >> + self.context.krbprincipalname = old_entry.get( >> + 'krbprincipalname', []) >> + self.log.critical( >> + "krbprincipalname pre: >> {}".format(self.context.krbprincipalname)) >> + >> + def preserve_krbprincipalname_post(self, ldap, entry_attrs, >> **options): >> + """ >> + Insert the preserved aliases back to the user entry during >> rename >> + operation >> + """ >> + if options.get('rename') is None or not hasattr( >> + self.context, 'krbprincipalname'): >> + return >> + >> + self.log.critical( >> + "krbprincipalname post: >> {}".format(self.context.krbprincipalname)) >> + new_aliases = entry_attrs.get('krbprincipalname', []) >> + >> + new_aliases.extend(self.context.krbprincipalname) >> + entry_attrs['krbprincipalname'] = new_aliases >> + effective_rights = entry_attrs.pop('attributelevelrights', []) >> + >> + ldap.update_entry(entry_attrs) >> + >> + if effective_rights: >> + entry_attrs['attributelevelrights'] = effective_rights > Why do you need to mess with effective rights here? > > Can you describe what happens on update that you need to drop them in > the entry_attrs? > >> + >> def check_mail(self, entry_attrs): >> if 'mail' in entry_attrs: >> entry_attrs['mail'] = >> self.obj.normalize_and_validate_email(entry_attrs['mail']) >> @@ -557,9 +604,11 @@ class baseuser_mod(LDAPUpdate): >> >> self.check_objectclass(ldap, dn, entry_attrs) >> self.obj.convert_usercertificate_pre(entry_attrs) >> + self.preserve_krbprincipalname_pre(ldap, entry_attrs, *keys, >> **options) >> >> def post_common_callback(self, ldap, dn, entry_attrs, *keys, >> **options): >> assert isinstance(dn, DN) >> + self.preserve_krbprincipalname_post(ldap, entry_attrs, >> **options) >> if options.get('random', False): >> try: >> entry_attrs['randompassword'] = >> unicode(getattr(context, 'randompassword')) >> -- >> 2.5.5 >> > > Shame on me for not using API written by myself for adding principal aliases back to the user! Shame! I have rewritten the `preserve_krbprincipalname_post` to use 'user_add_principal' to inject the missing aliases back to the entry, hence no other obscure shenanigans are needed other than plugging the new values to the displayed result. Also the code should be robust enough to handle renaming the user and back and keep all his aliases while changing canonical name to correct value. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0179.1-Preserve-user-principal-aliases-during-rename-operat.patch Type: text/x-patch Size: 3681 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jul 11 14:27:45 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 11 Jul 2016 16:27:45 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: References: Message-ID: On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/6046 > > > Isn't the bug about something else? The issue was that ipa-replica-install doesn't have --force-ntpd option. It is an option of ipa-client-install which is run from replica installer. The unattended mode is unrelated. -- Petr Vobornik From mbabinsk at redhat.com Mon Jul 11 15:15:13 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 11 Jul 2016 17:15:13 +0200 Subject: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals In-Reply-To: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <767a064c-cee9-db62-e260-ab86266c802a@redhat.com> On 07/06/2016 07:01 PM, Sumit Bose wrote: > Hi, > > although enterprise principals for trusted domains now are working as > expected they do not work for the local domain: > > # kinit -E admin at IPA.DEVEL > kinit: Client 'admin\@IPA.DEVEL at IPA.DEVEL' not found in Kerberos database while getting initial credentials > > Attached patch handles this case. It is not that nice because of the > duplication of ipadb_fetch_principals() and ipadb_find_principal(). But > I think there was a reason I do not remember why we didn't check for > enterprise principals before checking the local database. If there is no > such reason it might make sense to check for enterprise principals > before doing the lookup. Please let me know if I should change the patch > accordingly or if the current version is ok, > > bye, > Sumit > > > Code looks ok to me and the patch fixes the issue, so ACK. -- Martin^3 Babinsky From pvomacka at redhat.com Mon Jul 11 16:33:49 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Mon, 11 Jul 2016 18:33:49 +0200 Subject: [Freeipa-devel] [PATCH] webui test: bunch of patches which fix webui patches Message-ID: <91f807de-949c-bac2-8028-35e57a929081@redhat.com> Hello, please review these patches. First four of them fixes patches and the last one fixes small bug in WebUI which causes that some tests fail. https://fedorahosted.org/freeipa/ticket/6050 https://fedorahosted.org/freeipa/ticket/6052 https://fedorahosted.org/freeipa/ticket/6053 https://fedorahosted.org/freeipa/ticket/6054 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0073-Close-host-adder-dialog-before-showing-4304-dialog.patch Type: text/x-patch Size: 1011 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0075-Fix-test_navigation-tests.patch Type: text/x-patch Size: 1747 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0076-Fix-test-which-checks-removing-of-user.patch Type: text/x-patch Size: 1031 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0077-Set-default-delete-action-name-to-delete.patch Type: text/x-patch Size: 1432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0074-Remove-navigation-using-breadcrumb-menus.patch Type: text/x-patch Size: 1433 bytes Desc: not available URL: From ftweedal at redhat.com Tue Jul 12 05:17:00 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 12 Jul 2016 15:17:00 +1000 Subject: [Freeipa-devel] [PATCH] 0089 caacl: expand plugin documentation Message-ID: <20160712051700.GT10771@dhcp-40-8.bne.redhat.com> Attached patch is a doc change, addressing https://fedorahosted.org/freeipa/ticket/6002. Thanks, Fraser -------------- next part -------------- From 19c5fc60391d37c9d0500feb5d5d5a6628bc4d27 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 12 Jul 2016 15:11:11 +1000 Subject: [PATCH] caacl: expand plugin documentation Expand the 'caacl' plugin documentation to explain some common confusions including the fact that CA ACLs apply to the target subject principal (not necessarily the principal requesting the cert), and the fact that CA-less CA ACL implies the 'ipa' CA. Fixes: https://fedorahosted.org/freeipa/ticket/6002 --- ipaserver/plugins/caacl.py | 34 ++++++++++++++++++++++++++++------ 1 file changed, 28 insertions(+), 6 deletions(-) diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py index 9a60f7e27809c4f41b160647efafde94dbe90bf0..d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a 100644 --- a/ipaserver/plugins/caacl.py +++ b/ipaserver/plugins/caacl.py @@ -23,14 +23,36 @@ if six.PY3: __doc__ = _(""" Manage CA ACL rules. -This plugin is used to define rules governing which principals are -permitted to have certificates issued using a given certificate -profile. +This plugin is used to define rules governing which CAs and profiles +may be used to issue certificates to particular principals or groups +of principals. -PROFILE ID SYNTAX: +SUBJECT PRINCIPAL SCOPE: -A Profile ID is a string without spaces or punctuation starting with a letter -and followed by a sequence of letters, digits or underscore ("_"). +For a certificate request to be allowed, the principal(s) that are +the subject of a certificate request (not necessarily the principal +actually requesting the certificate) must be included in the scope +of a CA ACL that also includes the target CA and profile. + +Users can be included by name, group or the "all users" category. +Hosts can be included by name, hostgroup or the "all hosts" +category. Services can be included by service name or the "all +services" category. CA ACLs may be associated with a single type of +principal, or multiple types. + +CERTIFICATE AUTHORITY SCOPE: + +A CA ACL can be associated with one or more CAs by name, or by the +"all CAs" category. For compatibility reasons, a CA ACL with no CA +association implies an association with the 'ipa' CA (and only this +CA). + +PROFILE SCOPE: + +A CA ACL can be associated with one or more profiles by Profile ID. +The Profile ID is a string without spaces or punctuation starting +with a letter and followed by a sequence of letters, digits or +underscore ("_"). EXAMPLES: -- 2.5.5 From slaznick at redhat.com Tue Jul 12 06:44:57 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 12 Jul 2016 08:44:57 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: References: Message-ID: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> On 07/11/2016 04:27 PM, Petr Vobornik wrote: > On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >> https://fedorahosted.org/freeipa/ticket/6046 >> >> >> > Isn't the bug about something else? > > The issue was that ipa-replica-install doesn't have --force-ntpd option. > It is an option of ipa-client-install which is run from replica installer. > > The unattended mode is unrelated. My understanding is that the bug says that '--force-ntpd' option should not be shown when ipa-client-install is run during replica installation. During replica installation, the ipa-client-install script is run with the '--unattended' flag in the 'ensure_enrolled()' function. Being a separate script, there's not many options on how to pass the information not to show the message to ipa-client-install. Using the already used flag to get rid of the message seemed easiest to me. Introducing a new 'hidden' flag (like '--from-replica'), on the other hand, seems a bit harsh. From abokovoy at redhat.com Tue Jul 12 06:45:52 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 Jul 2016 09:45:52 +0300 Subject: [Freeipa-devel] [PATCH] 0089 caacl: expand plugin documentation In-Reply-To: <20160712051700.GT10771@dhcp-40-8.bne.redhat.com> References: <20160712051700.GT10771@dhcp-40-8.bne.redhat.com> Message-ID: <20160712064552.azywmrlvmd2vstrb@redhat.com> On Tue, 12 Jul 2016, Fraser Tweedale wrote: >Attached patch is a doc change, addressing >https://fedorahosted.org/freeipa/ticket/6002. > >Thanks, >Fraser >From 19c5fc60391d37c9d0500feb5d5d5a6628bc4d27 Mon Sep 17 00:00:00 2001 >From: Fraser Tweedale >Date: Tue, 12 Jul 2016 15:11:11 +1000 >Subject: [PATCH] caacl: expand plugin documentation > >Expand the 'caacl' plugin documentation to explain some common >confusions including the fact that CA ACLs apply to the target >subject principal (not necessarily the principal requesting the >cert), and the fact that CA-less CA ACL implies the 'ipa' CA. > >Fixes: https://fedorahosted.org/freeipa/ticket/6002 >--- > ipaserver/plugins/caacl.py | 34 ++++++++++++++++++++++++++++------ > 1 file changed, 28 insertions(+), 6 deletions(-) > >diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py >index 9a60f7e27809c4f41b160647efafde94dbe90bf0..d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a 100644 >--- a/ipaserver/plugins/caacl.py >+++ b/ipaserver/plugins/caacl.py >@@ -23,14 +23,36 @@ if six.PY3: > __doc__ = _(""" > Manage CA ACL rules. > >-This plugin is used to define rules governing which principals are >-permitted to have certificates issued using a given certificate >-profile. >+This plugin is used to define rules governing which CAs and profiles >+may be used to issue certificates to particular principals or groups >+of principals. > >-PROFILE ID SYNTAX: >+SUBJECT PRINCIPAL SCOPE: > >-A Profile ID is a string without spaces or punctuation starting with a letter >-and followed by a sequence of letters, digits or underscore ("_"). >+For a certificate request to be allowed, the principal(s) that are >+the subject of a certificate request (not necessarily the principal >+actually requesting the certificate) must be included in the scope >+of a CA ACL that also includes the target CA and profile. >+ >+Users can be included by name, group or the "all users" category. >+Hosts can be included by name, hostgroup or the "all hosts" >+category. Services can be included by service name or the "all >+services" category. CA ACLs may be associated with a single type of >+principal, or multiple types. >+ >+CERTIFICATE AUTHORITY SCOPE: >+ >+A CA ACL can be associated with one or more CAs by name, or by the >+"all CAs" category. For compatibility reasons, a CA ACL with no CA >+association implies an association with the 'ipa' CA (and only this >+CA). >+ >+PROFILE SCOPE: >+ >+A CA ACL can be associated with one or more profiles by Profile ID. >+The Profile ID is a string without spaces or punctuation starting >+with a letter and followed by a sequence of letters, digits or >+underscore ("_"). > > EXAMPLES: > ACK. Reads well. -- / Alexander Bokovoy From slaznick at redhat.com Tue Jul 12 08:02:34 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 12 Jul 2016 10:02:34 +0200 Subject: [Freeipa-devel] [PATCH 0182] ipa-compat-manage: use server API to retrieve plugin statu In-Reply-To: <3b52c33a-c943-d1c6-b718-06a796261ba5@redhat.com> References: <3b52c33a-c943-d1c6-b718-06a796261ba5@redhat.com> Message-ID: On 07/11/2016 10:50 AM, Martin Babinsky wrote: > Fixes regression reported in https://fedorahosted.org/freeipa/ticket/6033 > > > Hello, The ticket is rather cryptic as it has ipa-compat-manage in header but describes error in ipa-nis-manage. Both scripts suffer with the very same error, could you fix the latter as well? Thanks, Standa -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Tue Jul 12 08:22:02 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 12 Jul 2016 10:22:02 +0200 Subject: [Freeipa-devel] [PATCH 0182] ipa-compat-manage: use server API to retrieve plugin statu In-Reply-To: References: <3b52c33a-c943-d1c6-b718-06a796261ba5@redhat.com> Message-ID: <2d2cfc74-7e30-ec2d-3f0c-f94d91a8c89b@redhat.com> On 07/12/2016 10:02 AM, Stanislav Laznicka wrote: > On 07/11/2016 10:50 AM, Martin Babinsky wrote: >> Fixes regression reported in >> https://fedorahosted.org/freeipa/ticket/6033 >> > Hello, > > The ticket is rather cryptic as it has ipa-compat-manage in header but > describes error in ipa-nis-manage. Both scripts suffer with the very > same error, could you fix the latter as well? > > Thanks, > Standa Never mind, found the ipa-nis-manage patch posted earlier in the mailing list ACKed although it probably hasn't been pushed yet. ACK. From pvoborni at redhat.com Tue Jul 12 08:52:27 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Jul 2016 10:52:27 +0200 Subject: [Freeipa-devel] [PATCH] 0087 uninstall: untrack lightweight CA certs In-Reply-To: <89f902e3-6552-0bfe-7d85-b7d7423679ed@redhat.com> References: <20160704031036.GP4200@dhcp-40-8.bne.redhat.com> <89f902e3-6552-0bfe-7d85-b7d7423679ed@redhat.com> Message-ID: On 07/04/2016 10:18 AM, Martin Babinsky wrote: > On 07/04/2016 05:10 AM, Fraser Tweedale wrote: >> The attached patch fixes >> https://fedorahosted.org/freeipa/ticket/6020 >> >> Thanks, >> Fraser >> >> >> > ACK. > master: * 88841a561922fd9a57f3c473833f2ff26c8061ec uninstall: untrack lightweight CA certs -- Petr Vobornik From pvoborni at redhat.com Tue Jul 12 08:53:31 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Jul 2016 10:53:31 +0200 Subject: [Freeipa-devel] [PATCH 0181] ipa-nis-manage: Use server API to retrieve plugin status In-Reply-To: References: <81d6e74c-e1e4-26d8-0c89-70457ef4e5cd@redhat.com> Message-ID: <97ec72a1-c6b9-20a3-7892-719f588dd989@redhat.com> On 07/06/2016 11:18 AM, Florence Blanc-Renaud wrote: > On 07/04/2016 01:36 PM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6027 >> >> >> > Hi Martin, > > I tested your patch and it correctly fixes the issue. > Ack, > > Flo. > master: * c5cc79f1ad2ef1eb81ad3d9cea2882a7ae1825b2 ipa-nis-manage: Use server API to retrieve plugin status -- Petr Vobornik From pvoborni at redhat.com Tue Jul 12 08:56:24 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Jul 2016 10:56:24 +0200 Subject: [Freeipa-devel] [patch 0038-0040] Sub CA test patches In-Reply-To: <20160708040642.GJ10771@dhcp-40-8.bne.redhat.com> References: <072dcce1-3a76-9f26-62d7-a70e403239af@redhat.com> <20160624014203.GO4200@dhcp-40-8.bne.redhat.com> <0e08d68d-cc4e-3f8c-de7f-be8d21ee91f7@redhat.com> <20160627005734.GR4200@dhcp-40-8.bne.redhat.com> <20160704065746.GU4200@dhcp-40-8.bne.redhat.com> <20160708040642.GJ10771@dhcp-40-8.bne.redhat.com> Message-ID: <03e7d3dc-1308-8895-5877-0b42513ae49b@redhat.com> On 07/08/2016 06:06 AM, Fraser Tweedale wrote: > On Thu, Jul 07, 2016 at 03:46:52PM +0200, Milan Kub?k wrote: >> On 07/04/2016 08:57 AM, Fraser Tweedale wrote: >>> Hi Milan, >> > Thanks Milan, > > All working for me now. ACK on all four patches. > > Cheers, > Fraser > master: * ea9b15f435c6327c6f642e3e8093796229d94598 ipatests: Tracker implementation for Sub CA feature * 5b37aaad7718bd0214053fd2e758ba7dc332e21d ipatests: Extend CAACL suite to cover Sub CA members * d88a12f1f59640bb6593169aa4c7ea204af18cee ipatests: Test Sub CA with CAACL and certificate profile * 0277a89825cf0d8d1099f537d9eb4ab1020751d2 ipatests: remove ipacertbase option from test CSR configuration -- Petr Vobornik From pvoborni at redhat.com Tue Jul 12 09:00:28 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Jul 2016 11:00:28 +0200 Subject: [Freeipa-devel] [PATCH 0182] ipa-compat-manage: use server API to retrieve plugin statu In-Reply-To: <2d2cfc74-7e30-ec2d-3f0c-f94d91a8c89b@redhat.com> References: <3b52c33a-c943-d1c6-b718-06a796261ba5@redhat.com> <2d2cfc74-7e30-ec2d-3f0c-f94d91a8c89b@redhat.com> Message-ID: <3497a34a-2ee8-ebb1-f195-e1ba4e78f496@redhat.com> On 07/12/2016 10:22 AM, Stanislav Laznicka wrote: > On 07/12/2016 10:02 AM, Stanislav Laznicka wrote: >> On 07/11/2016 10:50 AM, Martin Babinsky wrote: >>> Fixes regression reported in >>> https://fedorahosted.org/freeipa/ticket/6033 >>> >> Hello, >> >> The ticket is rather cryptic as it has ipa-compat-manage in header but >> describes error in ipa-nis-manage. Both scripts suffer with the very >> same error, could you fix the latter as well? >> >> Thanks, >> Standa > > Never mind, found the ipa-nis-manage patch posted earlier in the mailing > list ACKed although it probably hasn't been pushed yet. > > ACK. > master: * a5efeb449bba47dd430a7b8ffa594ace189252f4 ipa-compat-manage: use server API to retrieve plugin status -- Petr Vobornik From pvoborni at redhat.com Tue Jul 12 09:03:17 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Jul 2016 11:03:17 +0200 Subject: [Freeipa-devel] [PATCH 0183] ipa-advise: correct handling of plugin namespace iteration In-Reply-To: <95f99b2f-2de5-2c73-34ac-7baa99aad572@redhat.com> References: <610683a7-079b-cd36-c28c-e4b0b4415aad@redhat.com> <95f99b2f-2de5-2c73-34ac-7baa99aad572@redhat.com> Message-ID: <706b43da-f594-ed26-9064-1a0071e6684c@redhat.com> On 07/11/2016 02:30 PM, Stanislav Laznicka wrote: > On 07/11/2016 02:18 PM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6044 >> >> >> > ACK. > > > master: * c1d8629b7490f443eededf0c0d0472d8285f85e8 ipa-advise: correct handling of plugin namespace iteration -- Petr Vobornik From pvoborni at redhat.com Tue Jul 12 10:27:01 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Jul 2016 12:27:01 +0200 Subject: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals In-Reply-To: <767a064c-cee9-db62-e260-ab86266c802a@redhat.com> References: <20160706170150.GE30099@p.Speedport_W_724V_Typ_A_05011603_00_009> <767a064c-cee9-db62-e260-ab86266c802a@redhat.com> Message-ID: On 07/11/2016 05:15 PM, Martin Babinsky wrote: > On 07/06/2016 07:01 PM, Sumit Bose wrote: >> Hi, >> >> although enterprise principals for trusted domains now are working as >> expected they do not work for the local domain: >> >> # kinit -E admin at IPA.DEVEL >> kinit: Client 'admin\@IPA.DEVEL at IPA.DEVEL' not found in Kerberos >> database while getting initial credentials >> >> Attached patch handles this case. It is not that nice because of the >> duplication of ipadb_fetch_principals() and ipadb_find_principal(). But >> I think there was a reason I do not remember why we didn't check for >> enterprise principals before checking the local database. If there is no >> such reason it might make sense to check for enterprise principals >> before doing the lookup. Please let me know if I should change the patch >> accordingly or if the current version is ok, >> >> bye, >> Sumit >> >> >> > Code looks ok to me and the patch fixes the issue, so ACK. > master: * 6d6da6b281173737bd31ba4845af11a097846c05 kdb: check for local realm in enterprise principals -- Petr Vobornik From slaznick at redhat.com Tue Jul 12 10:33:04 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 12 Jul 2016 12:33:04 +0200 Subject: [Freeipa-devel] [PATCH 0550] host-find: do not show SSH keys by default In-Reply-To: <83cd1331-5499-19c5-e1af-ccfb7b3056bc@redhat.com> References: <83cd1331-5499-19c5-e1af-ccfb7b3056bc@redhat.com> Message-ID: On 07/08/2016 01:52 PM, Martin Basti wrote: > Reproducible only with 2+ hosts, patch attached. > > https://fedorahosted.org/freeipa/ticket/6043 > > ACK. From mbabinsk at redhat.com Tue Jul 12 10:35:59 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Jul 2016 12:35:59 +0200 Subject: [Freeipa-devel] [PATCH 0056] removed unused parameter from migrate-ds In-Reply-To: <5391b4ff-4ee3-92f6-f553-69fbbb9990b6@redhat.com> References: <5391b4ff-4ee3-92f6-f553-69fbbb9990b6@redhat.com> Message-ID: <96656614-bcdc-b458-0776-ea600262654e@redhat.com> On 07/11/2016 12:40 PM, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/6034 > > > ACK -- Martin^3 Babinsky From pspacek at redhat.com Tue Jul 12 10:54:47 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Jul 2016 12:54:47 +0200 Subject: [Freeipa-devel] [PATCH 0149] help: Add dnsserver commands to help topic 'dns' Message-ID: <8ba68b2a-af2f-ff4c-9621-05d207d71cdb@redhat.com> Hello, help: Add dnsserver commands to help topic 'dns' https://bugzilla.redhat.com/show_bug.cgi?id=1353888 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0149-help-Add-dnsserver-commands-to-help-topic-dns.patch Type: text/x-patch Size: 749 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jul 12 11:05:29 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 Jul 2016 14:05:29 +0300 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> Message-ID: <20160712110529.nrrkhnkdnndjvwax@redhat.com> On Mon, 11 Jul 2016, Martin Babinsky wrote: >From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Fri, 1 Jul 2016 18:09:04 +0200 >Subject: [PATCH] Preserve user principal aliases during rename operation > >When a MODRDN is performed on the user entry, the MODRDN plugin resets both >krbPrincipalName and krbCanonicalName to the value constructed from uid. In >doing so, hovewer, any principal aliases added to the krbPrincipalName are >wiped clean. In this patch old aliases are fetched before the MODRDN operation >takes place and inserted back after it is performed. > >This also preserves previous user logins which can be used further for >authentication as aliases. > >https://fedorahosted.org/freeipa/ticket/6028 >--- > ipaserver/plugins/baseuser.py | 46 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > >diff --git a/ipaserver/plugins/baseuser.py b/ipaserver/plugins/baseuser.py >index 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815ffb2452692a7edb342f6ac3 100644 >--- a/ipaserver/plugins/baseuser.py >+++ b/ipaserver/plugins/baseuser.py >@@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): > len = int(config.get('ipamaxusernamelength')[0]) > ) > ) >+ >+ def preserve_krbprincipalname_pre(self, ldap, entry_attrs, *keys, **options): >+ """ >+ preserve user principal aliases during rename operation. This is the >+ pre-callback part of this. Another method called during post-callback >+ shall insert the principals back >+ """ >+ if options.get('rename', None) is None: >+ return >+ >+ try: >+ old_entry = ldap.get_entry( >+ entry_attrs.dn, attrs_list=( >+ 'krbprincipalname', 'krbcanonicalname')) >+ >+ if 'krbcanonicalname' not in old_entry: >+ return >+ except errors.NotFound: >+ self.obj.handle_not_found(*keys) >+ >+ self.context.krbprincipalname = old_entry.get( >+ 'krbprincipalname', []) >+ >+ def preserve_krbprincipalname_post(self, ldap, entry_attrs, **options): >+ """ >+ Insert the preserved aliases back to the user entry during rename >+ operation >+ """ >+ if options.get('rename', None) is None or not hasattr( >+ self.context, 'krbprincipalname'): >+ return >+ >+ obj_pkey = self.obj.get_primary_key_from_dn(entry_attrs.dn) >+ canonical_name = entry_attrs['krbcanonicalname'][0] >+ >+ principals_to_add = tuple(p for p in self.context.krbprincipalname if >+ p != canonical_name) >+ >+ if principals_to_add: >+ result = self.api.Command.user_add_principal( >+ obj_pkey, principals_to_add)['result'] >+ >+ entry_attrs['krbprincipalname'] = result.get('krbprincipalname', []) >+ > def check_mail(self, entry_attrs): > if 'mail' in entry_attrs: > entry_attrs['mail'] = self.obj.normalize_and_validate_email(entry_attrs['mail']) >@@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): > > self.check_objectclass(ldap, dn, entry_attrs) > self.obj.convert_usercertificate_pre(entry_attrs) >+ self.preserve_krbprincipalname_pre(ldap, entry_attrs, *keys, **options) > > def post_common_callback(self, ldap, dn, entry_attrs, *keys, **options): > assert isinstance(dn, DN) >+ self.preserve_krbprincipalname_post(ldap, entry_attrs, **options) > if options.get('random', False): > try: > entry_attrs['randompassword'] = unicode(getattr(context, 'randompassword')) >-- >2.5.5 > The approach looks good. For the record, we also support aliases for hosts and service kerberos principals but we don't support rename options for them, so there is no need to add similar logic there. -- / Alexander Bokovoy From mbabinsk at redhat.com Tue Jul 12 12:00:47 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Jul 2016 14:00:47 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <20160712110529.nrrkhnkdnndjvwax@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> Message-ID: <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: > On Mon, 11 Jul 2016, Martin Babinsky wrote: >> From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Fri, 1 Jul 2016 18:09:04 +0200 >> Subject: [PATCH] Preserve user principal aliases during rename operation >> >> When a MODRDN is performed on the user entry, the MODRDN plugin resets >> both >> krbPrincipalName and krbCanonicalName to the value constructed from >> uid. In >> doing so, hovewer, any principal aliases added to the krbPrincipalName >> are >> wiped clean. In this patch old aliases are fetched before the MODRDN >> operation >> takes place and inserted back after it is performed. >> >> This also preserves previous user logins which can be used further for >> authentication as aliases. >> >> https://fedorahosted.org/freeipa/ticket/6028 >> --- >> ipaserver/plugins/baseuser.py | 46 >> +++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 46 insertions(+) >> >> diff --git a/ipaserver/plugins/baseuser.py >> b/ipaserver/plugins/baseuser.py >> index >> 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815ffb2452692a7edb342f6ac3 >> 100644 >> --- a/ipaserver/plugins/baseuser.py >> +++ b/ipaserver/plugins/baseuser.py >> @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): >> len = >> int(config.get('ipamaxusernamelength')[0]) >> ) >> ) >> + >> + def preserve_krbprincipalname_pre(self, ldap, entry_attrs, *keys, >> **options): >> + """ >> + preserve user principal aliases during rename operation. This >> is the >> + pre-callback part of this. Another method called during >> post-callback >> + shall insert the principals back >> + """ >> + if options.get('rename', None) is None: >> + return >> + >> + try: >> + old_entry = ldap.get_entry( >> + entry_attrs.dn, attrs_list=( >> + 'krbprincipalname', 'krbcanonicalname')) >> + >> + if 'krbcanonicalname' not in old_entry: >> + return >> + except errors.NotFound: >> + self.obj.handle_not_found(*keys) >> + >> + self.context.krbprincipalname = old_entry.get( >> + 'krbprincipalname', []) >> + >> + def preserve_krbprincipalname_post(self, ldap, entry_attrs, >> **options): >> + """ >> + Insert the preserved aliases back to the user entry during >> rename >> + operation >> + """ >> + if options.get('rename', None) is None or not hasattr( >> + self.context, 'krbprincipalname'): >> + return >> + >> + obj_pkey = self.obj.get_primary_key_from_dn(entry_attrs.dn) >> + canonical_name = entry_attrs['krbcanonicalname'][0] >> + >> + principals_to_add = tuple(p for p in >> self.context.krbprincipalname if >> + p != canonical_name) >> + >> + if principals_to_add: >> + result = self.api.Command.user_add_principal( >> + obj_pkey, principals_to_add)['result'] >> + >> + entry_attrs['krbprincipalname'] = >> result.get('krbprincipalname', []) >> + >> def check_mail(self, entry_attrs): >> if 'mail' in entry_attrs: >> entry_attrs['mail'] = >> self.obj.normalize_and_validate_email(entry_attrs['mail']) >> @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): >> >> self.check_objectclass(ldap, dn, entry_attrs) >> self.obj.convert_usercertificate_pre(entry_attrs) >> + self.preserve_krbprincipalname_pre(ldap, entry_attrs, *keys, >> **options) >> >> def post_common_callback(self, ldap, dn, entry_attrs, *keys, >> **options): >> assert isinstance(dn, DN) >> + self.preserve_krbprincipalname_post(ldap, entry_attrs, >> **options) >> if options.get('random', False): >> try: >> entry_attrs['randompassword'] = >> unicode(getattr(context, 'randompassword')) >> -- >> 2.5.5 >> > The approach looks good. > > For the record, we also support aliases for hosts and service kerberos > principals but we don't support rename options for them, so there is no > need to add similar logic there. > > That's right, I have updated the corresponding section of the design page [1] for future reference. [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Management_framework -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Jul 12 12:06:32 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Jul 2016 14:06:32 +0200 Subject: [Freeipa-devel] [PATCH 0552] Vault: enable client side plugins CLI In-Reply-To: <20160708143645.6wrqqapbknr4ac2j@redhat.com> References: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> <20160708143645.6wrqqapbknr4ac2j@redhat.com> Message-ID: <409d00eb-9dd5-0e96-f66c-b7745fc9b88d@redhat.com> On 07/08/2016 04:36 PM, Alexander Bokovoy wrote: > On Fri, 08 Jul 2016, Martin Basti wrote: >> Patch attached. >> https://fedorahosted.org/freeipa/ticket/6035 > >> From 2c97c316c1db49daeda15c709f082ee083a741ad Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Fri, 8 Jul 2016 15:53:25 +0200 >> Subject: [PATCH] Enable vault-* commands on client >> >> Client plugins fot vault commands were disabled by NO_CLI=True, >> inherited from vault_add_interal, that is always NO_CLI=True. >> Introduced by this commit 8278da6967dbe425b4e0c6cf37dc1c53052525b2 >> >> Removed NO_CLI=True from client side plugins for vault. >> >> https://fedorahosted.org/freeipa/ticket/6035 > ACK. > > I haven't tested it but the change is obvious. > And it works as expected, so ACK also from me. -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Jul 12 12:10:10 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Jul 2016 14:10:10 +0200 Subject: [Freeipa-devel] [PATCH 0184] vault-add: set the default vault type on the client side if none was given Message-ID: <02cfb321-9f4e-6c79-795e-3d7c9ce64d06@redhat.com> Quick fix for https://fedorahosted.org/freeipa/ticket/6047 Note that it depends on mbasti's patch 552 (already acked) otherwise client-side vault commands would not be even visible in CLI. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0184-vault-add-set-the-default-vault-type-on-the-client-s.patch Type: text/x-patch Size: 1421 bytes Desc: not available URL: From pspacek at redhat.com Tue Jul 12 13:10:29 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Jul 2016 15:10:29 +0200 Subject: [Freeipa-devel] [PATCH] spec: require Dogtag >= 10.3.3-3 In-Reply-To: <20160708045245.GL10771@dhcp-40-8.bne.redhat.com> References: <0eab09f7-8d95-6651-1c8d-1412c08842eb@redhat.com> <20160708045245.GL10771@dhcp-40-8.bne.redhat.com> Message-ID: <9e11a6bd-3026-42ba-0cd8-03a1ec2b3175@redhat.com> On 8.7.2016 06:52, Fraser Tweedale wrote: > On Thu, Jul 07, 2016 at 01:16:04PM +0200, Petr Spacek wrote: >> Hello, >> >> IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for >> Fedora any time soon? >> >> Or should I update my scripts to automatically enable >> COPR @freeipa/freeipa-master >> in my testing VMs? >> >> Thanks. >> Petr^2 Spacek >> > Hi Petr, > > The required features were released for Fedora as 10.3.3-3. > Attached patch retracts the min required version accordingly. ACK -- Petr^2 Spacek From mbabinsk at redhat.com Tue Jul 12 13:46:56 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Jul 2016 15:46:56 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> Message-ID: <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> On 07/12/2016 02:00 PM, Martin Babinsky wrote: > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: >> On Mon, 11 Jul 2016, Martin Babinsky wrote: >>> From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 00:00:00 2001 >>> From: Martin Babinsky >>> Date: Fri, 1 Jul 2016 18:09:04 +0200 >>> Subject: [PATCH] Preserve user principal aliases during rename operation >>> >>> When a MODRDN is performed on the user entry, the MODRDN plugin resets >>> both >>> krbPrincipalName and krbCanonicalName to the value constructed from >>> uid. In >>> doing so, hovewer, any principal aliases added to the krbPrincipalName >>> are >>> wiped clean. In this patch old aliases are fetched before the MODRDN >>> operation >>> takes place and inserted back after it is performed. >>> >>> This also preserves previous user logins which can be used further for >>> authentication as aliases. >>> >>> https://fedorahosted.org/freeipa/ticket/6028 >>> --- >>> ipaserver/plugins/baseuser.py | 46 >>> +++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 46 insertions(+) >>> >>> diff --git a/ipaserver/plugins/baseuser.py >>> b/ipaserver/plugins/baseuser.py >>> index >>> 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815ffb2452692a7edb342f6ac3 >>> >>> 100644 >>> --- a/ipaserver/plugins/baseuser.py >>> +++ b/ipaserver/plugins/baseuser.py >>> @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): >>> len = >>> int(config.get('ipamaxusernamelength')[0]) >>> ) >>> ) >>> + >>> + def preserve_krbprincipalname_pre(self, ldap, entry_attrs, *keys, >>> **options): >>> + """ >>> + preserve user principal aliases during rename operation. This >>> is the >>> + pre-callback part of this. Another method called during >>> post-callback >>> + shall insert the principals back >>> + """ >>> + if options.get('rename', None) is None: >>> + return >>> + >>> + try: >>> + old_entry = ldap.get_entry( >>> + entry_attrs.dn, attrs_list=( >>> + 'krbprincipalname', 'krbcanonicalname')) >>> + >>> + if 'krbcanonicalname' not in old_entry: >>> + return >>> + except errors.NotFound: >>> + self.obj.handle_not_found(*keys) >>> + >>> + self.context.krbprincipalname = old_entry.get( >>> + 'krbprincipalname', []) >>> + >>> + def preserve_krbprincipalname_post(self, ldap, entry_attrs, >>> **options): >>> + """ >>> + Insert the preserved aliases back to the user entry during >>> rename >>> + operation >>> + """ >>> + if options.get('rename', None) is None or not hasattr( >>> + self.context, 'krbprincipalname'): >>> + return >>> + >>> + obj_pkey = self.obj.get_primary_key_from_dn(entry_attrs.dn) >>> + canonical_name = entry_attrs['krbcanonicalname'][0] >>> + >>> + principals_to_add = tuple(p for p in >>> self.context.krbprincipalname if >>> + p != canonical_name) >>> + >>> + if principals_to_add: >>> + result = self.api.Command.user_add_principal( >>> + obj_pkey, principals_to_add)['result'] >>> + >>> + entry_attrs['krbprincipalname'] = >>> result.get('krbprincipalname', []) >>> + >>> def check_mail(self, entry_attrs): >>> if 'mail' in entry_attrs: >>> entry_attrs['mail'] = >>> self.obj.normalize_and_validate_email(entry_attrs['mail']) >>> @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): >>> >>> self.check_objectclass(ldap, dn, entry_attrs) >>> self.obj.convert_usercertificate_pre(entry_attrs) >>> + self.preserve_krbprincipalname_pre(ldap, entry_attrs, *keys, >>> **options) >>> >>> def post_common_callback(self, ldap, dn, entry_attrs, *keys, >>> **options): >>> assert isinstance(dn, DN) >>> + self.preserve_krbprincipalname_post(ldap, entry_attrs, >>> **options) >>> if options.get('random', False): >>> try: >>> entry_attrs['randompassword'] = >>> unicode(getattr(context, 'randompassword')) >>> -- >>> 2.5.5 >>> >> The approach looks good. >> >> For the record, we also support aliases for hosts and service kerberos >> principals but we don't support rename options for them, so there is no >> need to add similar logic there. >> >> > > That's right, I have updated the corresponding section of the design > page [1] for future reference. > > [1] > http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Management_framework > > Adding Simo to the loop since he is not convinced that this is the right behavior. As I see it, it seems to not be a security issue but more of a different expectations about the perceived correct behavior in this particular situation. I can see the use case in keeping the old aliases, e.g. keeping the old credentials after legal name change, but I can also see the available space for user principal names piling up and cluttering quickly in large organizations. -- Martin^3 Babinsky From slaznick at redhat.com Tue Jul 12 13:53:13 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 12 Jul 2016 15:53:13 +0200 Subject: [Freeipa-devel] [PATCH 0184] vault-add: set the default vault type on the client side if none was given In-Reply-To: <02cfb321-9f4e-6c79-795e-3d7c9ce64d06@redhat.com> References: <02cfb321-9f4e-6c79-795e-3d7c9ce64d06@redhat.com> Message-ID: <686e40a5-9172-1c3f-f44c-98c4963c555d@redhat.com> On 07/12/2016 02:10 PM, Martin Babinsky wrote: > Quick fix for https://fedorahosted.org/freeipa/ticket/6047 > > Note that it depends on mbasti's patch 552 (already acked) otherwise > client-side vault commands would not be even visible in CLI. > > ACK. From pvoborni at redhat.com Tue Jul 12 14:03:36 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 12 Jul 2016 16:03:36 +0200 Subject: [Freeipa-devel] [PATCH 0552] Vault: enable client side plugins CLI In-Reply-To: <409d00eb-9dd5-0e96-f66c-b7745fc9b88d@redhat.com> References: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> <20160708143645.6wrqqapbknr4ac2j@redhat.com> <409d00eb-9dd5-0e96-f66c-b7745fc9b88d@redhat.com> Message-ID: On 07/12/2016 02:06 PM, Martin Babinsky wrote: > On 07/08/2016 04:36 PM, Alexander Bokovoy wrote: >> On Fri, 08 Jul 2016, Martin Basti wrote: >>> Patch attached. >>> https://fedorahosted.org/freeipa/ticket/6035 >> >>> From 2c97c316c1db49daeda15c709f082ee083a741ad Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Fri, 8 Jul 2016 15:53:25 +0200 >>> Subject: [PATCH] Enable vault-* commands on client >>> >>> Client plugins fot vault commands were disabled by NO_CLI=True, >>> inherited from vault_add_interal, that is always NO_CLI=True. >>> Introduced by this commit 8278da6967dbe425b4e0c6cf37dc1c53052525b2 >>> >>> Removed NO_CLI=True from client side plugins for vault. >>> >>> https://fedorahosted.org/freeipa/ticket/6035 >> ACK. >> >> I haven't tested it but the change is obvious. >> > > And it works as expected, so ACK also from me. > master: * 9feeaca9fb552229638ce98086aa75905a45b48d Enable vault-* commands on client -- Petr Vobornik From simo at redhat.com Tue Jul 12 14:19:16 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 12 Jul 2016 10:19:16 -0400 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> Message-ID: <1468333156.15769.10.camel@redhat.com> On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: > On 07/12/2016 02:00 PM, Martin Babinsky wrote: > > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: > > > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote: > > > > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 > > > > 00:00:00 2001 > > > > From: Martin Babinsky > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200 > > > > Subject: [PATCH] Preserve user principal aliases during rename > > > > operation > > > > > > > > When a MODRDN is performed on the user entry, the MODRDN plugin > > > > resets > > > > both > > > > krbPrincipalName and krbCanonicalName to the value constructed > > > > from > > > > uid. In > > > > doing so, hovewer, any principal aliases added to the > > > > krbPrincipalName > > > > are > > > > wiped clean. In this patch old aliases are fetched before the > > > > MODRDN > > > > operation > > > > takes place and inserted back after it is performed. > > > > > > > > This also preserves previous user logins which can be used > > > > further for > > > > authentication as aliases. > > > > > > > > https://fedorahosted.org/freeipa/ticket/6028 > > > > --- > > > > ipaserver/plugins/baseuser.py | 46 > > > > +++++++++++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 46 insertions(+) > > > > > > > > diff --git a/ipaserver/plugins/baseuser.py > > > > b/ipaserver/plugins/baseuser.py > > > > index > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815ffb2 > > > > 452692a7edb342f6ac3 > > > > > > > > 100644 > > > > --- a/ipaserver/plugins/baseuser.py > > > > +++ b/ipaserver/plugins/baseuser.py > > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): > > > > ????????????????????????????len = > > > > int(config.get('ipamaxusernamelength')[0]) > > > > ????????????????????????) > > > > ????????????????????) > > > > + > > > > +????def preserve_krbprincipalname_pre(self, ldap, entry_attrs, > > > > *keys, > > > > **options): > > > > +????????""" > > > > +????????preserve user principal aliases during rename > > > > operation. This > > > > is the > > > > +????????pre-callback part of this. Another method called > > > > during > > > > post-callback > > > > +????????shall insert the principals back > > > > +????????""" > > > > +????????if options.get('rename', None) is None: > > > > +????????????return > > > > + > > > > +????????try: > > > > +????????????old_entry = ldap.get_entry( > > > > +????????????????entry_attrs.dn, attrs_list=( > > > > +????????????????????'krbprincipalname', 'krbcanonicalname')) > > > > + > > > > +????????????if 'krbcanonicalname' not in old_entry: > > > > +????????????????return > > > > +????????except errors.NotFound: > > > > +????????????self.obj.handle_not_found(*keys) > > > > + > > > > +????????self.context.krbprincipalname = old_entry.get( > > > > +????????????'krbprincipalname', []) > > > > + > > > > +????def preserve_krbprincipalname_post(self, ldap, > > > > entry_attrs, > > > > **options): > > > > +????????""" > > > > +????????Insert the preserved aliases back to the user entry > > > > during > > > > rename > > > > +????????operation > > > > +????????""" > > > > +????????if options.get('rename', None) is None or not hasattr( > > > > +????????????????self.context, 'krbprincipalname'): > > > > +????????????return > > > > + > > > > +????????obj_pkey = > > > > self.obj.get_primary_key_from_dn(entry_attrs.dn) > > > > +????????canonical_name = entry_attrs['krbcanonicalname'][0] > > > > + > > > > +????????principals_to_add = tuple(p for p in > > > > self.context.krbprincipalname if > > > > +??????????????????????????????????p != canonical_name) > > > > + > > > > +????????if principals_to_add: > > > > +????????????result = self.api.Command.user_add_principal( > > > > +????????????????obj_pkey, principals_to_add)['result'] > > > > + > > > > +????????????entry_attrs['krbprincipalname'] = > > > > result.get('krbprincipalname', []) > > > > + > > > > ????def check_mail(self, entry_attrs): > > > > ????????if 'mail' in entry_attrs: > > > > ????????????entry_attrs['mail'] = > > > > self.obj.normalize_and_validate_email(entry_attrs['mail']) > > > > @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): > > > > > > > > ????????self.check_objectclass(ldap, dn, entry_attrs) > > > > ????????self.obj.convert_usercertificate_pre(entry_attrs) > > > > +????????self.preserve_krbprincipalname_pre(ldap, entry_attrs, > > > > *keys, > > > > **options) > > > > > > > > ????def post_common_callback(self, ldap, dn, entry_attrs, > > > > *keys, > > > > **options): > > > > ????????assert isinstance(dn, DN) > > > > +????????self.preserve_krbprincipalname_post(ldap, entry_attrs, > > > > **options) > > > > ????????if options.get('random', False): > > > > ????????????try: > > > > ????????????????entry_attrs['randompassword'] = > > > > unicode(getattr(context, 'randompassword')) > > > > -- > > > > 2.5.5 > > > > > > > The approach looks good. > > > > > > For the record, we also support aliases for hosts and service > > > kerberos > > > principals but we don't support rename options for them, so there > > > is no > > > need to add similar logic there. > > > > > > > > That's right, I have updated the corresponding section of the > > design > > page [1] for future reference. > > > > [1] > > http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Managemen > > t_framework > > > > > Adding Simo to the loop since he is not convinced that this is the > right? > behavior. As I see it, it seems to not be a security issue but more > of a? > different expectations about the perceived correct behavior in this? > particular situation. > > I can see the use case in keeping the old aliases, e.g. keeping the > old? > credentials after legal name change, but I can also see the > available? > space for user principal names piling up and cluttering quickly in > large? > organizations. after some thinking I think it is ok to keep by default and then drop as it avoid races if you do really want to keep the aliases. However the CLI/UI should probably offer a button/switch to allow to drop all aliases on rename, what it would do would be to modify the entry after the rename and drop the aliases. I am a bit uncertain what to do by default with the "original name". I can see it going both ways on whether to keep it by default or not. Simo. From cheimes at redhat.com Tue Jul 12 14:41:46 2016 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 12 Jul 2016 16:41:46 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: <5e7f167e-b5d3-fd5a-1ec0-599df9ce0b31@redhat.com> References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> <9751cf00-78b4-0dfd-4c70-7a04cb930215@redhat.com> <5e7f167e-b5d3-fd5a-1ec0-599df9ce0b31@redhat.com> Message-ID: <9d374af6-c688-849b-0889-d6fb82ed379b@redhat.com> On 2016-07-07 14:54, Martin Basti wrote: > Patch needs changes in ipa-4-3 branch My patch? Do you want me to submit a patch for 4.3 branch? Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From cheimes at redhat.com Tue Jul 12 14:45:11 2016 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 12 Jul 2016 16:45:11 +0200 Subject: [Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys Message-ID: Custodia's server.keys file contain the private RSA keys for encrypting and signing Custodia messages. The file was created with permission 644 and is only secured by permission 700 of the directory /etc/ipa/custodia. The installer and upgrader ensure that the file has 600. The server.keys file and all keys are now removed when during uninstallation of a server, too. https://bugzilla.redhat.com/show_bug.cgi?id=1353936 https://fedorahosted.org/freeipa/ticket/6015 https://fedorahosted.org/freeipa/ticket/6056 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0032-2-Secure-permission-and-cleanup-Custodia-server.keys.patch Type: text/x-patch Size: 7730 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From linuxguru.co at gmail.com Tue Jul 12 19:12:04 2016 From: linuxguru.co at gmail.com (Devin Acosta) Date: Tue, 12 Jul 2016 12:12:04 -0700 Subject: [Freeipa-devel] FreeIPA (Add Replica fails on GSSAPI) Message-ID: I am trying to add a 4th replica to my FreeIPA installation. I am running the latest CentOS 7.2 (full updates) and i have tried multiple times and fails every time in same location. When it fails I remove the replication agreements and try again and keeps failing in same location. [root at ipa03-aws centos]# ipa-replica-install replica-info-ipa03-aws.rsinc.local.gpg WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipa01-aws.rsinc.local': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at RSINC.LOCAL password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipa03-aws.rsinc.local': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv). Estimated time: 1 minute [1/38]: creating directory server user [2/38]: creating directory server instance [3/38]: adding default schema [4/38]: enabling memberof plugin [5/38]: enabling winsync plugin [6/38]: configuring replication version plugin [7/38]: enabling IPA enrollment plugin [8/38]: enabling ldapi [9/38]: configuring uniqueness plugin [10/38]: configuring uuid plugin [11/38]: configuring modrdn plugin [12/38]: configuring DNS plugin [13/38]: enabling entryUSN plugin [14/38]: configuring lockout plugin [15/38]: creating indices [16/38]: enabling referential integrity plugin [17/38]: configuring ssl for ds instance [18/38]: configuring certmap.conf [19/38]: configure autobind for root [20/38]: configure new location for managed entries [21/38]: configure dirsrv ccache [22/38]: enable SASL mapping fallback [23/38]: restarting directory server [24/38]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 4 seconds elapsed Update succeeded [25/38]: updating schema [26/38]: setting Auto Member configuration [27/38]: enabling S4U2Proxy delegation [28/38]: importing CA certificates from LDAP [29/38]: initializing group membership [30/38]: adding master entry [31/38]: initializing domain level [32/38]: configuring Posix uid/gid generation [33/38]: adding replication acis [34/38]: enabling compatibility plugin [35/38]: activating sidgen plugin [36/38]: activating extdom plugin [37/38]: tuning directory server [38/38]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds [1/8]: adding sasl mappings to the directory [2/8]: configuring KDC [3/8]: creating a keytab for the directory [4/8]: creating a keytab for the machine [5/8]: adding the password extension to the directory [6/8]: enable GSSAPI for replication [error] RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Can't acquire busy replica Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Can't acquire busy replica Please see attached file for the full log file. Any help would be appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 2016-07-12T18:50:11Z DEBUG Logging to /var/log/ipareplica-install.log 2016-07-12T18:50:11Z DEBUG ipa-replica-install was invoked with arguments ['replica-info-ipa03-aws.rsinc.local.gpg'] and options: {'no_dns_sshfp': None, 'skip_schema_check': None, 'no_ntp': None, 'setup_kra': None, 'ip_addresses': None, 'mkhomedir': None, 'setup_ca': None, 'no_pkinit': None, 'verbose': False, 'no_forwarders': None, 'ssh_trust_dns': None, 'setup_dns': None, 'no_reverse': None, 'reverse_zones': None, 'unattended': False, 'no_host_dns': None, 'no_sshd': None, 'no_ui_redirect': None, 'forwarders': None, 'skip_conncheck': None, 'no_ssh': None, 'quiet': False, 'no_dnssec_validation': None, 'log_file': None} 2016-07-12T18:50:11Z DEBUG IPA version 4.2.0-15.0.1.el7.centos.17 2016-07-12T18:50:11Z DEBUG Starting external process 2016-07-12T18:50:11Z DEBUG args='/usr/sbin/selinuxenabled' 2016-07-12T18:50:11Z DEBUG Process finished, return code=0 2016-07-12T18:50:11Z DEBUG stdout= 2016-07-12T18:50:11Z DEBUG stderr= 2016-07-12T18:50:11Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' 2016-07-12T18:50:11Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:50:11Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:50:11Z DEBUG Starting external process 2016-07-12T18:50:11Z DEBUG args='/usr/sbin/httpd' '-t' '-D' 'DUMP_VHOSTS' 2016-07-12T18:50:11Z DEBUG Process finished, return code=0 2016-07-12T18:50:11Z DEBUG stdout=VirtualHost configuration: *:8443 ipa03-aws.rsinc.local (/etc/httpd/conf.d/nss.conf:83) 2016-07-12T18:50:11Z DEBUG stderr= 2016-07-12T18:50:11Z DEBUG Starting external process 2016-07-12T18:50:11Z DEBUG args='/bin/systemctl' 'is-enabled' 'chronyd.service' 2016-07-12T18:50:11Z DEBUG Process finished, return code=0 2016-07-12T18:50:11Z DEBUG stdout=enabled 2016-07-12T18:50:11Z DEBUG stderr= 2016-07-12T18:50:14Z DEBUG Starting external process 2016-07-12T18:50:14Z DEBUG args='/usr/bin/gpg-agent' '--batch' '--homedir' '/tmp/tmp34bUDTipa/ipa-MkvnMP/.gnupg' '--daemon' '/usr/bin/gpg' '--batch' '--homedir' '/tmp/tmp34bUDTipa/ipa-MkvnMP/.gnupg' '--passphrase-fd' '0' '--yes' '--no-tty' '-o' '/tmp/tmp34bUDTipa/files.tar' '-d' 'replica-info-ipa03-aws.rsinc.local.gpg' 2016-07-12T18:50:14Z DEBUG Process finished, return code=0 2016-07-12T18:50:14Z DEBUG Starting external process 2016-07-12T18:50:14Z DEBUG args='tar' 'xf' '/tmp/tmp34bUDTipa/files.tar' '-C' '/tmp/tmp34bUDTipa' 2016-07-12T18:50:14Z DEBUG Process finished, return code=0 2016-07-12T18:50:14Z DEBUG stdout= 2016-07-12T18:50:14Z DEBUG stderr= 2016-07-12T18:50:14Z DEBUG Installing replica file with version 40200 (0 means no version in prepared file). 2016-07-12T18:50:14Z DEBUG Check if ipa03-aws.rsinc.local is a primary hostname for localhost 2016-07-12T18:50:14Z DEBUG Primary hostname for localhost: ipa03-aws.rsinc.local 2016-07-12T18:50:14Z DEBUG Search DNS for ipa03-aws.rsinc.local 2016-07-12T18:50:14Z DEBUG Check if ipa03-aws.rsinc.local is not a CNAME 2016-07-12T18:50:15Z DEBUG Check reverse address of 10.40.0.242 2016-07-12T18:50:15Z DEBUG Found reverse name: ipa03-aws.rsinc.local 2016-07-12T18:50:15Z DEBUG importing all plugin modules in ipalib.plugins... 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.aci 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.automember 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.automount 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.baseldap 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.baseuser 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.batch 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.caacl 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.cert 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.certprofile 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.config 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.delegation 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.dns 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.domainlevel 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.group 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.hbacrule 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.hbacsvc 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.hbacsvcgroup 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.hbactest 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.host 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.hostgroup 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.idrange 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.idviews 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.internal 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.kerberos 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.krbtpolicy 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.migration 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.misc 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.netgroup 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.otpconfig 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.otptoken 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.otptoken_yubikey 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.passwd 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.permission 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.ping 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.pkinit 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.privilege 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.pwpolicy 2016-07-12T18:50:15Z DEBUG Starting external process 2016-07-12T18:50:15Z DEBUG args='klist' '-V' 2016-07-12T18:50:15Z DEBUG Process finished, return code=0 2016-07-12T18:50:15Z DEBUG stdout=Kerberos 5 version 1.13.2 2016-07-12T18:50:15Z DEBUG stderr= 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.radiusproxy 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.realmdomains 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.role 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.rpcclient 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.selfservice 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.selinuxusermap 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.server 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.service 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.servicedelegation 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.session 2016-07-12T18:50:15Z WARNING session memcached servers not running 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.stageuser 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.sudocmd 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.sudocmdgroup 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.sudorule 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.topology 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.trust 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.user 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.vault 2016-07-12T18:50:15Z DEBUG importing plugin module ipalib.plugins.virtual 2016-07-12T18:50:15Z DEBUG importing all plugin modules in ipaserver.plugins... 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.plugins.dogtag 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.plugins.join 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.plugins.ldap2 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.plugins.rabase 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.plugins.xmlserver 2016-07-12T18:50:15Z DEBUG importing all plugin modules in ipaserver.install.plugins... 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.adtrust 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.ca_renewal_master 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.dns 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.fix_replica_agreements 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.rename_managed 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_idranges 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_managed_permissions 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_nis 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_pacs 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_passsync 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_referint 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_services 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.update_uniqueness 2016-07-12T18:50:15Z DEBUG importing plugin module ipaserver.install.plugins.upload_cacrt 2016-07-12T18:50:15Z DEBUG SessionAuthManager.register: name=jsonserver_session_59557136 2016-07-12T18:50:15Z DEBUG SessionAuthManager.register: name=xmlserver_session_59559568 2016-07-12T18:50:15Z DEBUG Mounting ipaserver.rpcserver.jsonserver_kerb() at '/json' 2016-07-12T18:50:15Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:15Z DEBUG Mounting ipaserver.rpcserver.xmlserver_session() at '/session/xml' 2016-07-12T18:50:15Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:15Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:15Z DEBUG Mounting ipaserver.rpcserver.sync_token() at '/session/sync_token' 2016-07-12T18:50:15Z DEBUG Mounting ipaserver.rpcserver.xmlserver() at '/xml' 2016-07-12T18:50:15Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:15Z DEBUG Mounting ipaserver.rpcserver.jsonserver_session() at '/session/json' 2016-07-12T18:50:15Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:15Z DEBUG Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' 2016-07-12T18:50:15Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:16Z DEBUG Mounting ipaserver.rpcserver.login_password() at '/session/login_password' 2016-07-12T18:50:16Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:16Z DEBUG Mounting ipaserver.rpcserver.change_password() at '/session/change_password' 2016-07-12T18:50:16Z DEBUG Check if ipa01-aws.rsinc.local is a primary hostname for localhost 2016-07-12T18:50:16Z DEBUG Primary hostname for localhost: ipa01-aws.rsinc.local 2016-07-12T18:50:16Z DEBUG Search DNS for ipa01-aws.rsinc.local 2016-07-12T18:50:21Z DEBUG Check if ipa01-aws.rsinc.local is not a CNAME 2016-07-12T18:50:21Z DEBUG Check reverse address of 10.10.0.88 2016-07-12T18:50:21Z DEBUG Found reverse name: ipa01-aws.rsinc.local 2016-07-12T18:50:21Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-N' '-f' '/tmp/tmprj5lWPipa/pwdfile.txt' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout= 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/pk12util' '-d' '/tmp/tmprj5lWPipa' '-i' '/tmp/tmp34bUDTipa/realm_info/dscert.p12' '-k' '/tmp/tmprj5lWPipa/pwdfile.txt' '-v' '-w' '/dev/stdin' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout=pk12util: PKCS12 IMPORT SUCCESSFUL 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-L' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u RSINC.LOCAL IPA CA ,, 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-A' '-n' 'CA 1' '-t' ',,' '-a' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout= 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-O' '-n' 'Server-Cert' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout="RSINC.LOCAL IPA CA" [CN=Certificate Authority,O=RSINC.LOCAL] "Server-Cert" [CN=ipa03-aws.rsinc.local,O=RSINC.LOCAL] 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-M' '-n' 'RSINC.LOCAL IPA CA' '-t' 'CT,C,C' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout= 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-O' '-n' 'Server-Cert' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout="RSINC.LOCAL IPA CA" [CN=Certificate Authority,O=RSINC.LOCAL] "Server-Cert" [CN=ipa03-aws.rsinc.local,O=RSINC.LOCAL] 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-L' '-n' 'RSINC.LOCAL IPA CA' '-a' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout=-----BEGIN CERTIFICATE----- MIIDkTCCAnmgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtSU0lO Qy5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDMx MTE2NDMxNVoXDTM2MDMxMTE2NDMxNVowNjEUMBIGA1UECgwLUlNJTkMuTE9DQUwx HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMeuq3fFabQUU4lMQmLEQmN4ryu3bp6ekaBc/+4txdYg AYiSUvZOChcS+6l0XWl/d1u5txR5BIKdADCvO9rcIglQbvn1y6scjbmMqzd4xtCE IN28t1ywPQlWIAGSLw2VDuZ/lmKxmyG00RMxKRvZYuWe/pHZqiza9Rywyt+hjxDK GjghSMGujqYiGXuDviR79q+g7WFQP+8e3D59NmGa8N9iGHaVOBYiNBJIS9raDWmY LvpHY5cBUYrhBGsIIia3l+V2a+9RPXceF7dN5b3xVae5BK2r39ohFtzZw6b1StVS QLeuAexrabVUZEEltzcSUyZo1pZqfsOfyOA5LUWsIsUCAwEAAaOBqTCBpjAfBgNV HSMEGDAWgBS7H+9FH63CaSCM3WK2HMFJFSqzUjAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUux/vRR+twmkgjN1ithzBSRUqs1IwQwYI KwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhMDEtYXdzLnJzaW5j LmxvY2FsOjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAIuAZ1+x3we31MvO ZRB3fg3F8JVALb8iZ8EMSktNIlW71A6UwlwMwJi/1yGBuTAp6GwgZTKETBJ40hqx 1G7DSXaViXmIf8ERRvM/0LEba+Skokt9N+F+kQeOE340/YEMvUR/uiGaaEurA3dm WsoJ0z/X401qHLH7XIyTKubI+TK6unVFwO+p6OUb/n+/ZTBPY5CluwsH67qHxAFf WBsn6fd+2kl10LC6Z/drQ+yPbApn8wo0k1Pvht2w01nFji9z3C6zsk7JG+EJ0l8W LqXaFqEeRJlG+aPmadqEYDWBE8A05+5euoc8z/zLJXZLWSMs4PpKwcuWlWZ+84gV N2jzdNA= -----END CERTIFICATE----- 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmprj5lWPipa' '-L' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u RSINC.LOCAL IPA CA CT,C,C 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-N' '-f' '/tmp/tmpX8lR1Xipa/pwdfile.txt' 2016-07-12T18:50:21Z DEBUG Process finished, return code=0 2016-07-12T18:50:21Z DEBUG stdout= 2016-07-12T18:50:21Z DEBUG stderr= 2016-07-12T18:50:21Z DEBUG Starting external process 2016-07-12T18:50:21Z DEBUG args='/usr/bin/pk12util' '-d' '/tmp/tmpX8lR1Xipa' '-i' '/tmp/tmp34bUDTipa/realm_info/httpcert.p12' '-k' '/tmp/tmpX8lR1Xipa/pwdfile.txt' '-v' '-w' '/dev/stdin' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout=pk12util: PKCS12 IMPORT SUCCESSFUL 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG Starting external process 2016-07-12T18:50:22Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-L' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u RSINC.LOCAL IPA CA ,, 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG Starting external process 2016-07-12T18:50:22Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-A' '-n' 'CA 1' '-t' ',,' '-a' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout= 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG Starting external process 2016-07-12T18:50:22Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-O' '-n' 'Server-Cert' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout="RSINC.LOCAL IPA CA" [CN=Certificate Authority,O=RSINC.LOCAL] "Server-Cert" [CN=ipa03-aws.rsinc.local,O=RSINC.LOCAL] 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG Starting external process 2016-07-12T18:50:22Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-M' '-n' 'RSINC.LOCAL IPA CA' '-t' 'CT,C,C' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout= 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG Starting external process 2016-07-12T18:50:22Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-O' '-n' 'Server-Cert' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout="RSINC.LOCAL IPA CA" [CN=Certificate Authority,O=RSINC.LOCAL] "Server-Cert" [CN=ipa03-aws.rsinc.local,O=RSINC.LOCAL] 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG Starting external process 2016-07-12T18:50:22Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-L' '-n' 'RSINC.LOCAL IPA CA' '-a' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout=-----BEGIN CERTIFICATE----- MIIDkTCCAnmgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtSU0lO Qy5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDMx MTE2NDMxNVoXDTM2MDMxMTE2NDMxNVowNjEUMBIGA1UECgwLUlNJTkMuTE9DQUwx HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMeuq3fFabQUU4lMQmLEQmN4ryu3bp6ekaBc/+4txdYg AYiSUvZOChcS+6l0XWl/d1u5txR5BIKdADCvO9rcIglQbvn1y6scjbmMqzd4xtCE IN28t1ywPQlWIAGSLw2VDuZ/lmKxmyG00RMxKRvZYuWe/pHZqiza9Rywyt+hjxDK GjghSMGujqYiGXuDviR79q+g7WFQP+8e3D59NmGa8N9iGHaVOBYiNBJIS9raDWmY LvpHY5cBUYrhBGsIIia3l+V2a+9RPXceF7dN5b3xVae5BK2r39ohFtzZw6b1StVS QLeuAexrabVUZEEltzcSUyZo1pZqfsOfyOA5LUWsIsUCAwEAAaOBqTCBpjAfBgNV HSMEGDAWgBS7H+9FH63CaSCM3WK2HMFJFSqzUjAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUux/vRR+twmkgjN1ithzBSRUqs1IwQwYI KwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhMDEtYXdzLnJzaW5j LmxvY2FsOjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAIuAZ1+x3we31MvO ZRB3fg3F8JVALb8iZ8EMSktNIlW71A6UwlwMwJi/1yGBuTAp6GwgZTKETBJ40hqx 1G7DSXaViXmIf8ERRvM/0LEba+Skokt9N+F+kQeOE340/YEMvUR/uiGaaEurA3dm WsoJ0z/X401qHLH7XIyTKubI+TK6unVFwO+p6OUb/n+/ZTBPY5CluwsH67qHxAFf WBsn6fd+2kl10LC6Z/drQ+yPbApn8wo0k1Pvht2w01nFji9z3C6zsk7JG+EJ0l8W LqXaFqEeRJlG+aPmadqEYDWBE8A05+5euoc8z/zLJXZLWSMs4PpKwcuWlWZ+84gV N2jzdNA= -----END CERTIFICATE----- 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG Starting external process 2016-07-12T18:50:22Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpX8lR1Xipa' '-L' 2016-07-12T18:50:22Z DEBUG Process finished, return code=0 2016-07-12T18:50:22Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u RSINC.LOCAL IPA CA CT,C,C 2016-07-12T18:50:22Z DEBUG stderr= 2016-07-12T18:50:22Z DEBUG importing all plugin modules in ipalib.plugins... 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.aci 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.automember 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.automount 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.baseldap 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.baseuser 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.batch 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.caacl 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.cert 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.certprofile 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.config 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.delegation 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.dns 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.domainlevel 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.group 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.hbacrule 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.hbacsvc 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.hbacsvcgroup 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.hbactest 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.host 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.hostgroup 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.idrange 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.idviews 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.internal 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.kerberos 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.krbtpolicy 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.migration 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.misc 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.netgroup 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.otpconfig 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.otptoken 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.otptoken_yubikey 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.passwd 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.permission 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.ping 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.pkinit 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.privilege 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.pwpolicy 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.radiusproxy 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.realmdomains 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.role 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.rpcclient 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.selfservice 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.selinuxusermap 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.server 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.service 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.servicedelegation 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.session 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.stageuser 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.sudocmd 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.sudocmdgroup 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.sudorule 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.topology 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.trust 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.user 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.vault 2016-07-12T18:50:22Z DEBUG importing plugin module ipalib.plugins.virtual 2016-07-12T18:50:22Z DEBUG importing all plugin modules in ipaserver.plugins... 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.plugins.dogtag 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.plugins.join 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.plugins.ldap2 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.plugins.rabase 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.plugins.xmlserver 2016-07-12T18:50:22Z DEBUG importing all plugin modules in ipaserver.install.plugins... 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.adtrust 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.ca_renewal_master 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.dns 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.fix_replica_agreements 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.rename_managed 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_idranges 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_managed_permissions 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_nis 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_pacs 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_passsync 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_referint 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_services 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.update_uniqueness 2016-07-12T18:50:22Z DEBUG importing plugin module ipaserver.install.plugins.upload_cacrt 2016-07-12T18:50:22Z DEBUG SessionAuthManager.register: name=jsonserver_session_90330320 2016-07-12T18:50:22Z DEBUG SessionAuthManager.register: name=xmlserver_session_90332176 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.jsonserver_kerb() at '/json' 2016-07-12T18:50:22Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.xmlserver_session() at '/session/xml' 2016-07-12T18:50:22Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:22Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.sync_token() at '/session/sync_token' 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.xmlserver() at '/xml' 2016-07-12T18:50:22Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.jsonserver_session() at '/session/json' 2016-07-12T18:50:22Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' 2016-07-12T18:50:22Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.login_password() at '/session/login_password' 2016-07-12T18:50:22Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:50:22Z DEBUG Mounting ipaserver.rpcserver.change_password() at '/session/change_password' 2016-07-12T18:50:24Z DEBUG Created connection context.ldap2_90329936 2016-07-12T18:50:25Z DEBUG raw: domainlevel_get(version=u'2.156') 2016-07-12T18:50:25Z DEBUG domainlevel_get(version=u'2.156') 2016-07-12T18:50:25Z DEBUG flushing ldaps://ipa01-aws.rsinc.local from SchemaCache 2016-07-12T18:50:25Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa01-aws.rsinc.local conn= 2016-07-12T18:50:29Z DEBUG Check forward/reverse DNS resolution 2016-07-12T18:50:29Z DEBUG Search DNS server ipa01-aws.rsinc.local (['10.10.0.88', '10.10.0.88', '10.10.0.88']) for ipa01-aws.rsinc.local 2016-07-12T18:50:30Z DEBUG Check reverse address 10.10.0.88 (ipa01-aws.rsinc.local) 2016-07-12T18:50:30Z DEBUG Address 10.10.0.88 resolves to: ipa01-aws.rsinc.local.. 2016-07-12T18:50:35Z DEBUG Search DNS server ipa01-aws.rsinc.local (['10.10.0.88', '10.10.0.88', '10.10.0.88']) for ipa03-aws.rsinc.local 2016-07-12T18:50:37Z DEBUG Check reverse address 10.40.0.242 (ipa03-aws.rsinc.local) 2016-07-12T18:50:37Z DEBUG Address 10.40.0.242 resolves to: ipa03-aws.rsinc.local.. 2016-07-12T18:50:37Z DEBUG Destroyed connection context.ldap2_90329936 2016-07-12T18:50:37Z DEBUG Starting external process 2016-07-12T18:50:37Z DEBUG args='/sbin/ip' '-family' 'inet' '-oneline' 'address' 'show' 2016-07-12T18:50:37Z DEBUG Process finished, return code=0 2016-07-12T18:50:37Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 2: eth0 inet 10.40.0.242/24 brd 10.40.0.255 scope global dynamic eth0\ valid_lft 2160sec preferred_lft 2160sec 2016-07-12T18:50:37Z DEBUG stderr= 2016-07-12T18:50:37Z DEBUG Starting external process 2016-07-12T18:50:37Z DEBUG args='/usr/sbin/ipa-replica-conncheck' '--master' 'ipa01-aws.rsinc.local' '--auto-master-check' '--realm' 'RSINC.LOCAL' '--principal' 'admin' '--hostname' 'ipa03-aws.rsinc.local' 2016-07-12T18:51:19Z DEBUG Process finished, return code=0 2016-07-12T18:51:19Z DEBUG group dirsrv exists 2016-07-12T18:51:19Z DEBUG user dirsrv exists 2016-07-12T18:51:25Z DEBUG Created connection context.ldap2_90329936 2016-07-12T18:51:25Z DEBUG flushing ldaps://ipa01-aws.rsinc.local from SchemaCache 2016-07-12T18:51:25Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa01-aws.rsinc.local conn= 2016-07-12T18:51:25Z DEBUG Starting external process 2016-07-12T18:51:25Z DEBUG args='/bin/systemctl' 'is-enabled' 'chronyd.service' 2016-07-12T18:51:25Z DEBUG Process finished, return code=0 2016-07-12T18:51:25Z DEBUG stdout=enabled 2016-07-12T18:51:25Z DEBUG stderr= 2016-07-12T18:51:25Z DEBUG Starting external process 2016-07-12T18:51:25Z DEBUG args='/bin/systemctl' 'is-active' 'chronyd.service' 2016-07-12T18:51:25Z DEBUG Process finished, return code=0 2016-07-12T18:51:25Z DEBUG stdout=active 2016-07-12T18:51:25Z DEBUG stderr= 2016-07-12T18:51:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:25Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:25Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:25Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:25Z DEBUG Starting external process 2016-07-12T18:51:25Z DEBUG args='/bin/systemctl' 'stop' 'chronyd.service' 2016-07-12T18:51:25Z DEBUG Process finished, return code=0 2016-07-12T18:51:25Z DEBUG stdout= 2016-07-12T18:51:25Z DEBUG stderr= 2016-07-12T18:51:25Z DEBUG Starting external process 2016-07-12T18:51:25Z DEBUG args='/bin/systemctl' 'disable' 'chronyd.service' 2016-07-12T18:51:26Z DEBUG Process finished, return code=0 2016-07-12T18:51:26Z DEBUG stdout= 2016-07-12T18:51:26Z DEBUG stderr=Removed symlink /etc/systemd/system/multi-user.target.wants/chronyd.service. 2016-07-12T18:51:26Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:26Z DEBUG Configuring NTP daemon (ntpd) 2016-07-12T18:51:26Z DEBUG [1/4]: stopping ntpd 2016-07-12T18:51:26Z DEBUG Starting external process 2016-07-12T18:51:26Z DEBUG args='/bin/systemctl' 'is-active' 'ntpd.service' 2016-07-12T18:51:26Z DEBUG Process finished, return code=3 2016-07-12T18:51:26Z DEBUG stdout=unknown 2016-07-12T18:51:26Z DEBUG stderr= 2016-07-12T18:51:26Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Starting external process 2016-07-12T18:51:26Z DEBUG args='/bin/systemctl' 'stop' 'ntpd.service' 2016-07-12T18:51:26Z DEBUG Process finished, return code=0 2016-07-12T18:51:26Z DEBUG stdout= 2016-07-12T18:51:26Z DEBUG stderr= 2016-07-12T18:51:26Z DEBUG duration: 0 seconds 2016-07-12T18:51:26Z DEBUG [2/4]: writing configuration 2016-07-12T18:51:26Z DEBUG Backing up system configuration file '/etc/ntp.conf' 2016-07-12T18:51:26Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:26Z DEBUG Backing up system configuration file '/etc/sysconfig/ntpd' 2016-07-12T18:51:26Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:26Z DEBUG duration: 0 seconds 2016-07-12T18:51:26Z DEBUG [3/4]: configuring ntpd to start on boot 2016-07-12T18:51:26Z DEBUG Starting external process 2016-07-12T18:51:26Z DEBUG args='/bin/systemctl' 'is-enabled' 'ntpd.service' 2016-07-12T18:51:26Z DEBUG Process finished, return code=1 2016-07-12T18:51:26Z DEBUG stdout=disabled 2016-07-12T18:51:26Z DEBUG stderr= 2016-07-12T18:51:26Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Starting external process 2016-07-12T18:51:26Z DEBUG args='/bin/systemctl' 'enable' 'ntpd.service' 2016-07-12T18:51:26Z DEBUG Process finished, return code=0 2016-07-12T18:51:26Z DEBUG stdout= 2016-07-12T18:51:26Z DEBUG stderr=Created symlink from /etc/systemd/system/multi-user.target.wants/ntpd.service to /usr/lib/systemd/system/ntpd.service. 2016-07-12T18:51:26Z DEBUG duration: 0 seconds 2016-07-12T18:51:26Z DEBUG [4/4]: starting ntpd 2016-07-12T18:51:26Z DEBUG Starting external process 2016-07-12T18:51:26Z DEBUG args='/bin/systemctl' 'start' 'ntpd.service' 2016-07-12T18:51:26Z DEBUG Process finished, return code=0 2016-07-12T18:51:26Z DEBUG stdout= 2016-07-12T18:51:26Z DEBUG stderr= 2016-07-12T18:51:26Z DEBUG Starting external process 2016-07-12T18:51:26Z DEBUG args='/bin/systemctl' 'is-active' 'ntpd.service' 2016-07-12T18:51:26Z DEBUG Process finished, return code=0 2016-07-12T18:51:26Z DEBUG stdout=active 2016-07-12T18:51:26Z DEBUG stderr= 2016-07-12T18:51:26Z DEBUG duration: 0 seconds 2016-07-12T18:51:26Z DEBUG Done configuring NTP daemon (ntpd). 2016-07-12T18:51:26Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:26Z DEBUG Configuring directory server (dirsrv). Estimated time: 1 minute 2016-07-12T18:51:26Z DEBUG [1/38]: creating directory server user 2016-07-12T18:51:26Z DEBUG group dirsrv exists 2016-07-12T18:51:26Z DEBUG user dirsrv exists 2016-07-12T18:51:26Z DEBUG duration: 0 seconds 2016-07-12T18:51:26Z DEBUG [2/38]: creating directory server instance 2016-07-12T18:51:26Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:51:26Z DEBUG Backing up system configuration file '/etc/sysconfig/dirsrv' 2016-07-12T18:51:26Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:26Z DEBUG dn: dc=rsinc,dc=local objectClass: top objectClass: domain objectClass: pilotObject dc: rsinc info: IPA V2.0 2016-07-12T18:51:26Z DEBUG writing inf template 2016-07-12T18:51:26Z DEBUG [General] FullMachineName= ipa03-aws.rsinc.local SuiteSpotUserID= dirsrv SuiteSpotGroup= dirsrv ServerRoot= /usr/lib64/dirsrv [slapd] ServerPort= 389 ServerIdentifier= RSINC-LOCAL Suffix= dc=rsinc,dc=local RootDN= cn=Directory Manager InstallLdifFile= /var/lib/dirsrv/boot.ldif inst_dir= /var/lib/dirsrv/scripts-RSINC-LOCAL 2016-07-12T18:51:26Z DEBUG calling setup-ds.pl 2016-07-12T18:51:26Z DEBUG Starting external process 2016-07-12T18:51:26Z DEBUG args='/usr/sbin/setup-ds.pl' '--silent' '--logfile' '-' '-f' '/tmp/tmpl25s3I' 2016-07-12T18:51:29Z DEBUG Process finished, return code=0 2016-07-12T18:51:29Z DEBUG stdout=[16/07/12:18:51:29] - [Setup] Info Your new DS instance 'RSINC-LOCAL' was successfully created. Your new DS instance 'RSINC-LOCAL' was successfully created. [16/07/12:18:51:29] - [Setup] Success Exiting . . . Log file is '-' Exiting . . . Log file is '-' 2016-07-12T18:51:29Z DEBUG stderr= 2016-07-12T18:51:29Z DEBUG completed creating ds instance 2016-07-12T18:51:29Z DEBUG restarting ds instance 2016-07-12T18:51:29Z DEBUG Starting external process 2016-07-12T18:51:29Z DEBUG args='/bin/systemctl' '--system' 'daemon-reload' 2016-07-12T18:51:29Z DEBUG Process finished, return code=0 2016-07-12T18:51:29Z DEBUG stdout= 2016-07-12T18:51:29Z DEBUG stderr= 2016-07-12T18:51:29Z DEBUG Starting external process 2016-07-12T18:51:29Z DEBUG args='/bin/systemctl' 'restart' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:31Z DEBUG Process finished, return code=0 2016-07-12T18:51:31Z DEBUG stdout= 2016-07-12T18:51:31Z DEBUG stderr= 2016-07-12T18:51:31Z DEBUG Starting external process 2016-07-12T18:51:31Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:31Z DEBUG Process finished, return code=0 2016-07-12T18:51:31Z DEBUG stdout=active 2016-07-12T18:51:31Z DEBUG stderr= 2016-07-12T18:51:31Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=active 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG done restarting ds instance 2016-07-12T18:51:32Z DEBUG duration: 6 seconds 2016-07-12T18:51:32Z DEBUG [3/38]: adding default schema 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [4/38]: enabling memberof plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/memberof-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpaZTwky' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=replace nsslapd-pluginenabled: on add memberofgroupattr: memberUser add memberofgroupattr: memberHost modifying entry "cn=MemberOf Plugin,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [5/38]: enabling winsync plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/ipa-winsync-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpDGr86O' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: ipa-winsync add nsslapd-pluginpath: libipa_winsync add nsslapd-plugininitfunc: ipa_winsync_plugin_init add nsslapd-pluginDescription: Allows IPA to work with the DS windows sync feature add nsslapd-pluginid: ipa-winsync add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: Red Hat add nsslapd-plugintype: preoperation add nsslapd-pluginenabled: on add nsslapd-plugin-depends-on-type: database add ipaWinSyncRealmFilter: (objectclass=krbRealmContainer) add ipaWinSyncRealmAttr: cn add ipaWinSyncNewEntryFilter: (cn=ipaConfig) add ipaWinSyncNewUserOCAttr: ipauserobjectclasses add ipaWinSyncUserFlatten: true add ipaWinsyncHomeDirAttr: ipaHomesRootDir add ipaWinsyncLoginShellAttr: ipaDefaultLoginShell add ipaWinSyncDefaultGroupAttr: ipaDefaultPrimaryGroup add ipaWinSyncDefaultGroupFilter: (gidNumber=*)(objectclass=posixGroup)(objectclass=groupOfNames) add ipaWinSyncAcctDisable: both add ipaWinSyncForceSync: true add ipaWinSyncUserAttr: uidNumber -1 gidNumber -1 adding new entry "cn=ipa-winsync,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [6/38]: configuring replication version plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/version-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpVufx4k' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: IPA Version Replication add nsslapd-pluginpath: libipa_repl_version add nsslapd-plugininitfunc: repl_version_plugin_init add nsslapd-plugintype: preoperation add nsslapd-pluginenabled: off add nsslapd-pluginid: ipa_repl_version add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: Red Hat, Inc. add nsslapd-plugindescription: IPA Replication version plugin add nsslapd-plugin-depends-on-type: database add nsslapd-plugin-depends-on-named: Multimaster Replication Plugin adding new entry "cn=IPA Version Replication,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [7/38]: enabling IPA enrollment plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpvdwlJ_' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmp0DGRqi' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: ipa_enrollment_extop add nsslapd-pluginpath: libipa_enrollment_extop add nsslapd-plugininitfunc: ipaenrollment_init add nsslapd-plugintype: extendedop add nsslapd-pluginenabled: on add nsslapd-pluginid: ipa_enrollment_extop add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: RedHat add nsslapd-plugindescription: Enroll hosts into the IPA domain add nsslapd-plugin-depends-on-type: database add nsslapd-realmTree: dc=rsinc,dc=local adding new entry "cn=ipa_enrollment_extop,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [8/38]: enabling ldapi 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpKj0al8' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpgPe4By' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=replace nsslapd-ldapilisten: on modifying entry "cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [9/38]: configuring uniqueness plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpbK4ppH' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmprrUQX8' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectClass: top nsSlapdPlugin extensibleObject add cn: krbPrincipalName uniqueness add nsslapd-pluginPath: libattr-unique-plugin add nsslapd-pluginInitfunc: NSUniqueAttr_Init add nsslapd-pluginType: preoperation add nsslapd-pluginEnabled: on add uniqueness-attribute-name: krbPrincipalName add nsslapd-plugin-depends-on-type: database add nsslapd-pluginId: NSUniqueAttr add nsslapd-pluginVersion: 1.1.0 add nsslapd-pluginVendor: Fedora Project add nsslapd-pluginDescription: Enforce unique attribute values add uniqueness-subtrees: dc=rsinc,dc=local add uniqueness-exclude-subtrees: cn=staged users,cn=accounts,cn=provisioning,dc=rsinc,dc=local add uniqueness-across-all-subtrees: on adding new entry "cn=krbPrincipalName uniqueness,cn=plugins,cn=config" modify complete add objectClass: top nsSlapdPlugin extensibleObject add cn: krbCanonicalName uniqueness add nsslapd-pluginPath: libattr-unique-plugin add nsslapd-pluginInitfunc: NSUniqueAttr_Init add nsslapd-pluginType: preoperation add nsslapd-pluginEnabled: on add uniqueness-attribute-name: krbCanonicalName add nsslapd-plugin-depends-on-type: database add nsslapd-pluginId: NSUniqueAttr add nsslapd-pluginVersion: 1.1.0 add nsslapd-pluginVendor: Fedora Project add nsslapd-pluginDescription: Enforce unique attribute values add uniqueness-subtrees: dc=rsinc,dc=local add uniqueness-exclude-subtrees: cn=staged users,cn=accounts,cn=provisioning,dc=rsinc,dc=local add uniqueness-across-all-subtrees: on adding new entry "cn=krbCanonicalName uniqueness,cn=plugins,cn=config" modify complete add objectClass: top nsSlapdPlugin extensibleObject add cn: netgroup uniqueness add nsslapd-pluginPath: libattr-unique-plugin add nsslapd-pluginInitfunc: NSUniqueAttr_Init add nsslapd-pluginType: preoperation add nsslapd-pluginEnabled: on add uniqueness-attribute-name: cn add uniqueness-subtrees: cn=ng,cn=alt,dc=rsinc,dc=local add nsslapd-plugin-depends-on-type: database add nsslapd-pluginId: NSUniqueAttr add nsslapd-pluginVersion: 1.1.0 add nsslapd-pluginVendor: Fedora Project add nsslapd-pluginDescription: Enforce unique attribute values adding new entry "cn=netgroup uniqueness,cn=plugins,cn=config" modify complete add objectClass: top nsSlapdPlugin extensibleObject add cn: ipaUniqueID uniqueness add nsslapd-pluginPath: libattr-unique-plugin add nsslapd-pluginInitfunc: NSUniqueAttr_Init add nsslapd-pluginType: preoperation add nsslapd-pluginEnabled: on add uniqueness-attribute-name: ipaUniqueID add nsslapd-plugin-depends-on-type: database add nsslapd-pluginId: NSUniqueAttr add nsslapd-pluginVersion: 1.1.0 add nsslapd-pluginVendor: Fedora Project add nsslapd-pluginDescription: Enforce unique attribute values add uniqueness-subtrees: dc=rsinc,dc=local add uniqueness-exclude-subtrees: cn=staged users,cn=accounts,cn=provisioning,dc=rsinc,dc=local add uniqueness-across-all-subtrees: on adding new entry "cn=ipaUniqueID uniqueness,cn=plugins,cn=config" modify complete add objectClass: top nsSlapdPlugin extensibleObject add cn: sudorule name uniqueness add nsslapd-pluginDescription: Enforce unique attribute values add nsslapd-pluginPath: libattr-unique-plugin add nsslapd-pluginInitfunc: NSUniqueAttr_Init add nsslapd-pluginType: preoperation add nsslapd-pluginEnabled: on add uniqueness-attribute-name: cn add uniqueness-subtrees: cn=sudorules,cn=sudo,dc=rsinc,dc=local add nsslapd-plugin-depends-on-type: database add nsslapd-pluginId: NSUniqueAttr add nsslapd-pluginVersion: 1.1.0 add nsslapd-pluginVendor: Fedora Project adding new entry "cn=sudorule name uniqueness,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [10/38]: configuring uuid plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/uuid-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmp5x4unk' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: IPA UUID add nsslapd-pluginpath: libipa_uuid add nsslapd-plugininitfunc: ipauuid_init add nsslapd-plugintype: preoperation add nsslapd-pluginenabled: on add nsslapd-pluginid: ipauuid_version add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: Red Hat, Inc. add nsslapd-plugindescription: IPA UUID plugin add nsslapd-plugin-depends-on-type: database adding new entry "cn=IPA UUID,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpgvIJlO' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpcigfIB' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top extensibleObject add cn: IPA Unique IDs add ipaUuidAttr: ipaUniqueID add ipaUuidMagicRegen: autogenerate add ipaUuidFilter: (|(objectclass=ipaObject)(objectclass=ipaAssociation)) add ipaUuidScope: dc=rsinc,dc=local add ipaUuidEnforce: TRUE adding new entry "cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=config" modify complete add objectclass: top extensibleObject add cn: IPK11 Unique IDs add ipaUuidAttr: ipk11UniqueID add ipaUuidMagicRegen: autogenerate add ipaUuidFilter: (objectclass=ipk11Object) add ipaUuidScope: dc=rsinc,dc=local add ipaUuidEnforce: FALSE adding new entry "cn=IPK11 Unique IDs,cn=IPA UUID,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [11/38]: configuring modrdn plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/modrdn-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpL0SCll' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: IPA MODRDN add nsslapd-pluginpath: libipa_modrdn add nsslapd-plugininitfunc: ipamodrdn_init add nsslapd-plugintype: betxnpostoperation add nsslapd-pluginenabled: on add nsslapd-pluginid: ipamodrdn_version add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: Red Hat, Inc. add nsslapd-plugindescription: IPA MODRDN plugin add nsslapd-plugin-depends-on-type: database add nsslapd-pluginPrecedence: 60 adding new entry "cn=IPA MODRDN,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmp7a9Iy2' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpYqIrA8' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top extensibleObject add cn: Kerberos Principal Name add ipaModRDNsourceAttr: uid add ipaModRDNtargetAttr: krbPrincipalName add ipaModRDNsuffix: @RSINC.LOCAL add ipaModRDNfilter: (&(objectclass=posixaccount)(objectclass=krbPrincipalAux)) add ipaModRDNscope: dc=rsinc,dc=local adding new entry "cn=Kerberos Principal Name,cn=IPA MODRDN,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [12/38]: configuring DNS plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/ipa-dns-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpYTbMOB' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top nsslapdPlugin extensibleObject add cn: IPA DNS add nsslapd-plugindescription: IPA DNS support plugin add nsslapd-pluginenabled: on add nsslapd-pluginid: ipa_dns add nsslapd-plugininitfunc: ipadns_init add nsslapd-pluginpath: libipa_dns.so add nsslapd-plugintype: preoperation add nsslapd-pluginvendor: Red Hat, Inc. add nsslapd-pluginversion: 1.0 add nsslapd-plugin-depends-on-type: database adding new entry "cn=IPA DNS,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [13/38]: enabling entryUSN plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/entryusn.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpQNVKqh' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=replace nsslapd-entryusn-global: on modifying entry "cn=config" modify complete replace nsslapd-entryusn-import-initval: next modifying entry "cn=config" modify complete replace nsslapd-pluginenabled: on modifying entry "cn=USN,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [14/38]: configuring lockout plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/lockout-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpuM9MKr' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: IPA Lockout add nsslapd-pluginpath: libipa_lockout add nsslapd-plugininitfunc: ipalockout_init add nsslapd-plugintype: object add nsslapd-pluginenabled: on add nsslapd-pluginid: ipalockout_version add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: Red Hat, Inc. add nsslapd-plugindescription: IPA Lockout plugin add nsslapd-plugin-depends-on-type: database adding new entry "cn=IPA Lockout,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [15/38]: creating indices 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmptbeIHR' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=add objectClass: top nsIndex add cn: krbPrincipalName add nsSystemIndex: false add nsIndexType: eq sub adding new entry "cn=krbPrincipalName,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: ou add nsSystemIndex: false add nsIndexType: eq sub adding new entry "cn=ou,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: carLicense add nsSystemIndex: false add nsIndexType: eq sub adding new entry "cn=carLicense,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: title add nsSystemIndex: false add nsIndexType: eq sub adding new entry "cn=title,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: manager add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=manager,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: secretary add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=secretary,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: displayname add nsSystemIndex: false add nsIndexType: eq sub adding new entry "cn=displayname,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add nsIndexType: sub modifying entry "cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: uidnumber add nsSystemIndex: false add nsIndexType: eq add nsMatchingRule: integerOrderingMatch adding new entry "cn=uidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add objectClass: top nsIndex add cn: gidnumber add nsSystemIndex: false add nsIndexType: eq add nsMatchingRule: integerOrderingMatch adding new entry "cn=gidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete replace nsIndexType: eq pres modifying entry "cn=ntUniqueId,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete replace nsIndexType: eq pres modifying entry "cn=ntUserDomainId,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add ObjectClass: top nsIndex add cn: fqdn add nsSystemIndex: false add nsIndexType: eq pres adding new entry "cn=fqdn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add ObjectClass: top nsIndex add cn: macAddress add nsSystemIndex: false add nsIndexType: eq pres adding new entry "cn=macAddress,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: memberHost add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=memberHost,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: memberUser add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=memberUser,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: sourcehost add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=sourcehost,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: memberservice add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=memberservice,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: managedby add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=managedby,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: memberallowcmd add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=memberallowcmd,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: memberdenycmd add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=memberdenycmd,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: ipasudorunas add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=ipasudorunas,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: ipasudorunasgroup add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=ipasudorunasgroup,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: automountkey add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq adding new entry "cn=automountkey,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: ipakrbprincipalalias add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq adding new entry "cn=ipakrbprincipalalias,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: ipauniqueid add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq adding new entry "cn=ipauniqueid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: ipaMemberCa add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=ipaMemberCa,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: ipaMemberCertProfile add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres sub adding new entry "cn=ipaMemberCertProfile,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add cn: userCertificate add ObjectClass: top nsIndex add nsSystemIndex: false add nsIndexType: eq pres adding new entry "cn=userCertificate,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [16/38]: enabling referential integrity plugin 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/referint-conf.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpQ3LiVG' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=replace nsslapd-pluginenabled: on modifying entry "cn=referential integrity postoperation,cn=plugins,cn=config" modify complete 2016-07-12T18:51:32Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:32Z DEBUG duration: 0 seconds 2016-07-12T18:51:32Z DEBUG [17/38]: configuring ssl for ds instance 2016-07-12T18:51:32Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-N' '-f' '/etc/dirsrv/slapd-RSINC-LOCAL//pwdfile.txt' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout= 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/pk12util' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-i' '/tmp/tmp34bUDTipa/realm_info/dscert.p12' '-k' '/etc/dirsrv/slapd-RSINC-LOCAL//pwdfile.txt' '-v' '-w' '/dev/stdin' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=pk12util: PKCS12 IMPORT SUCCESSFUL 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-L' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u RSINC.LOCAL IPA CA ,, 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-A' '-n' 'CA 1' '-t' ',,' '-a' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout= 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-O' '-n' 'Server-Cert' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout="RSINC.LOCAL IPA CA" [CN=Certificate Authority,O=RSINC.LOCAL] "Server-Cert" [CN=ipa03-aws.rsinc.local,O=RSINC.LOCAL] 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-M' '-n' 'RSINC.LOCAL IPA CA' '-t' 'CT,C,C' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout= 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-O' '-n' 'Server-Cert' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout="RSINC.LOCAL IPA CA" [CN=Certificate Authority,O=RSINC.LOCAL] "Server-Cert" [CN=ipa03-aws.rsinc.local,O=RSINC.LOCAL] 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-L' '-n' 'RSINC.LOCAL IPA CA' '-a' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=-----BEGIN CERTIFICATE----- MIIDkTCCAnmgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtSU0lO Qy5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDMx MTE2NDMxNVoXDTM2MDMxMTE2NDMxNVowNjEUMBIGA1UECgwLUlNJTkMuTE9DQUwx HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMeuq3fFabQUU4lMQmLEQmN4ryu3bp6ekaBc/+4txdYg AYiSUvZOChcS+6l0XWl/d1u5txR5BIKdADCvO9rcIglQbvn1y6scjbmMqzd4xtCE IN28t1ywPQlWIAGSLw2VDuZ/lmKxmyG00RMxKRvZYuWe/pHZqiza9Rywyt+hjxDK GjghSMGujqYiGXuDviR79q+g7WFQP+8e3D59NmGa8N9iGHaVOBYiNBJIS9raDWmY LvpHY5cBUYrhBGsIIia3l+V2a+9RPXceF7dN5b3xVae5BK2r39ohFtzZw6b1StVS QLeuAexrabVUZEEltzcSUyZo1pZqfsOfyOA5LUWsIsUCAwEAAaOBqTCBpjAfBgNV HSMEGDAWgBS7H+9FH63CaSCM3WK2HMFJFSqzUjAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUux/vRR+twmkgjN1ithzBSRUqs1IwQwYI KwYBBQUHAQEENzA1MDMGCCsGAQUFBzABhidodHRwOi8vaXBhMDEtYXdzLnJzaW5j LmxvY2FsOjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAIuAZ1+x3we31MvO ZRB3fg3F8JVALb8iZ8EMSktNIlW71A6UwlwMwJi/1yGBuTAp6GwgZTKETBJ40hqx 1G7DSXaViXmIf8ERRvM/0LEba+Skokt9N+F+kQeOE340/YEMvUR/uiGaaEurA3dm WsoJ0z/X401qHLH7XIyTKubI+TK6unVFwO+p6OUb/n+/ZTBPY5CluwsH67qHxAFf WBsn6fd+2kl10LC6Z/drQ+yPbApn8wo0k1Pvht2w01nFji9z3C6zsk7JG+EJ0l8W LqXaFqEeRJlG+aPmadqEYDWBE8A05+5euoc8z/zLJXZLWSMs4PpKwcuWlWZ+84gV N2jzdNA= -----END CERTIFICATE----- 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-L' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u RSINC.LOCAL IPA CA CT,C,C 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-L' '-n' 'Server-Cert' '-a' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=-----BEGIN CERTIFICATE----- MIIEEzCCAvugAwIBAgIBOzANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtSU0lO Qy5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDcx MjE4NDczMloXDTE4MDcxMzE4NDczMlowNjEUMBIGA1UECgwLUlNJTkMuTE9DQUwx HjAcBgNVBAMMFWlwYTAzLWF3cy5yc2luYy5sb2NhbDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL71KZYz8sy6erF5VJH0HrZuzikcrEl/4y8MdqzV8NQ2 yRZDlDzLqcj5hs+RafbKFFQyksP1eO5YkeTllATMetFD8vqqFVIpunlr/u8dbTlM /vlKOZJ0wvlPjc5QeuGtFVZ/z5vqQKKtFHrFziglx8yMAH1C6R4afFhyMqnQigzT WHWdc3BLQy2xVyadt0oode1PnWu2diwwV3wEbtja4TA9e8lPKdMWHKIpd2l9+iso iXP+IvuTLJkMwXKEFjUEgNFetPEbOf+EzXtd6iU7BGKxDplxyvkOf3sG5psR1LJa Hd3Cp1DHf06XceqvzQbIbVPoL0qk560tz0rch30/Ek8CAwEAAaOCASowggEmMB8G A1UdIwQYMBaAFLsf70UfrcJpIIzdYrYcwUkVKrNSMD0GCCsGAQUFBwEBBDEwLzAt BggrBgEFBQcwAYYhaHR0cDovL2lwYS1jYS5yc2luYy5sb2NhbC9jYS9vY3NwMA4G A1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdgYD VR0fBG8wbTBroDOgMYYvaHR0cDovL2lwYS1jYS5yc2luYy5sb2NhbC9pcGEvY3Js L01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFLkqG3ftJkzasSZs+3Xrbu/0 967tMA0GCSqGSIb3DQEBCwUAA4IBAQC6C+6HRuRVotLiS6A1dV/5UQmVohfcIg6P bI7KSpDSLvcVJvA0rxr2QGfUvpgqa4I62mfxe7tefqs+QLwGLUpdG4OYGmOkiDzi PUuj7BFI9qRVqGrfH+pcsorY5Zz7Z2JjY3v0TSiPImUIw/s4R6izHT7iUCOhVBPf ZOeGRKbCihWygPeoz/0m0+P3AIT3U6MV/819Y3woLvyJC/OImkZZVI2HcfU/07Yh TsHUZsavZX4xfwk6pdKYwg4yw5KGUCWL/WR1QPdEr/QDQeo75jQmaS3fIBxQpCva 2YPxLYfcIdP30GCl9dEg4SE3b19L+6Nuv0rbMai4WtPNr6U/jjWM -----END CERTIFICATE----- 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:32Z DEBUG Starting external process 2016-07-12T18:51:32Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-L' '-n' 'Server-Cert' '-a' 2016-07-12T18:51:32Z DEBUG Process finished, return code=0 2016-07-12T18:51:32Z DEBUG stdout=-----BEGIN CERTIFICATE----- MIIEEzCCAvugAwIBAgIBOzANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtSU0lO Qy5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDcx MjE4NDczMloXDTE4MDcxMzE4NDczMlowNjEUMBIGA1UECgwLUlNJTkMuTE9DQUwx HjAcBgNVBAMMFWlwYTAzLWF3cy5yc2luYy5sb2NhbDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL71KZYz8sy6erF5VJH0HrZuzikcrEl/4y8MdqzV8NQ2 yRZDlDzLqcj5hs+RafbKFFQyksP1eO5YkeTllATMetFD8vqqFVIpunlr/u8dbTlM /vlKOZJ0wvlPjc5QeuGtFVZ/z5vqQKKtFHrFziglx8yMAH1C6R4afFhyMqnQigzT WHWdc3BLQy2xVyadt0oode1PnWu2diwwV3wEbtja4TA9e8lPKdMWHKIpd2l9+iso iXP+IvuTLJkMwXKEFjUEgNFetPEbOf+EzXtd6iU7BGKxDplxyvkOf3sG5psR1LJa Hd3Cp1DHf06XceqvzQbIbVPoL0qk560tz0rch30/Ek8CAwEAAaOCASowggEmMB8G A1UdIwQYMBaAFLsf70UfrcJpIIzdYrYcwUkVKrNSMD0GCCsGAQUFBwEBBDEwLzAt BggrBgEFBQcwAYYhaHR0cDovL2lwYS1jYS5yc2luYy5sb2NhbC9jYS9vY3NwMA4G A1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdgYD VR0fBG8wbTBroDOgMYYvaHR0cDovL2lwYS1jYS5yc2luYy5sb2NhbC9pcGEvY3Js L01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFLkqG3ftJkzasSZs+3Xrbu/0 967tMA0GCSqGSIb3DQEBCwUAA4IBAQC6C+6HRuRVotLiS6A1dV/5UQmVohfcIg6P bI7KSpDSLvcVJvA0rxr2QGfUvpgqa4I62mfxe7tefqs+QLwGLUpdG4OYGmOkiDzi PUuj7BFI9qRVqGrfH+pcsorY5Zz7Z2JjY3v0TSiPImUIw/s4R6izHT7iUCOhVBPf ZOeGRKbCihWygPeoz/0m0+P3AIT3U6MV/819Y3woLvyJC/OImkZZVI2HcfU/07Yh TsHUZsavZX4xfwk6pdKYwg4yw5KGUCWL/WR1QPdEr/QDQeo75jQmaS3fIBxQpCva 2YPxLYfcIdP30GCl9dEg4SE3b19L+6Nuv0rbMai4WtPNr6U/jjWM -----END CERTIFICATE----- 2016-07-12T18:51:32Z DEBUG stderr= 2016-07-12T18:51:33Z DEBUG flushing ldap://ipa03-aws.rsinc.local:389 from SchemaCache 2016-07-12T18:51:33Z DEBUG retrieving schema for SchemaCache url=ldap://ipa03-aws.rsinc.local:389 conn= 2016-07-12T18:51:33Z DEBUG duration: 0 seconds 2016-07-12T18:51:33Z DEBUG [18/38]: configuring certmap.conf 2016-07-12T18:51:33Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2016-07-12T18:51:33Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2016-07-12T18:51:33Z DEBUG Saving StateFile to '/var/lib/ipa/sysupgrade/sysupgrade.state' 2016-07-12T18:51:33Z DEBUG duration: 0 seconds 2016-07-12T18:51:33Z DEBUG [19/38]: configure autobind for root 2016-07-12T18:51:33Z DEBUG Starting external process 2016-07-12T18:51:33Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/root-autobind.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmp6rzPZX' 2016-07-12T18:51:33Z DEBUG Process finished, return code=0 2016-07-12T18:51:33Z DEBUG stdout=add objectClass: extensibleObject top add cn: root-autobind add uidNumber: 0 add gidNumber: 0 adding new entry "cn=root-autobind,cn=config" modify complete replace nsslapd-ldapiautobind: on modifying entry "cn=config" modify complete replace nsslapd-ldapimaptoentries: on modifying entry "cn=config" modify complete 2016-07-12T18:51:33Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:33Z DEBUG duration: 0 seconds 2016-07-12T18:51:33Z DEBUG [20/38]: configure new location for managed entries 2016-07-12T18:51:33Z DEBUG Starting external process 2016-07-12T18:51:33Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpcTTK6a' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpA3Dzpt' 2016-07-12T18:51:33Z DEBUG Process finished, return code=0 2016-07-12T18:51:33Z DEBUG stdout=add nsslapd-pluginConfigArea: cn=Definitions,cn=Managed Entries,cn=etc,dc=rsinc,dc=local modifying entry "cn=Managed Entries,cn=plugins,cn=config" modify complete 2016-07-12T18:51:33Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:33Z DEBUG duration: 0 seconds 2016-07-12T18:51:33Z DEBUG [21/38]: configure dirsrv ccache 2016-07-12T18:51:33Z DEBUG Backing up system configuration file '/etc/sysconfig/dirsrv' 2016-07-12T18:51:33Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:33Z DEBUG Starting external process 2016-07-12T18:51:33Z DEBUG args='/usr/sbin/selinuxenabled' 2016-07-12T18:51:33Z DEBUG Process finished, return code=0 2016-07-12T18:51:33Z DEBUG stdout= 2016-07-12T18:51:33Z DEBUG stderr= 2016-07-12T18:51:33Z DEBUG Starting external process 2016-07-12T18:51:33Z DEBUG args='/sbin/restorecon' '/etc/sysconfig/dirsrv' 2016-07-12T18:51:33Z DEBUG Process finished, return code=0 2016-07-12T18:51:33Z DEBUG stdout= 2016-07-12T18:51:33Z DEBUG stderr= 2016-07-12T18:51:33Z DEBUG duration: 0 seconds 2016-07-12T18:51:33Z DEBUG [22/38]: enable SASL mapping fallback 2016-07-12T18:51:33Z DEBUG Starting external process 2016-07-12T18:51:33Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpiDf5XR' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpU_gcYB' 2016-07-12T18:51:33Z DEBUG Process finished, return code=0 2016-07-12T18:51:33Z DEBUG stdout=replace nsslapd-sasl-mapping-fallback: on modifying entry "cn=config" modify complete 2016-07-12T18:51:33Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:33Z DEBUG duration: 0 seconds 2016-07-12T18:51:33Z DEBUG [23/38]: restarting directory server 2016-07-12T18:51:33Z DEBUG Starting external process 2016-07-12T18:51:33Z DEBUG args='/bin/systemctl' '--system' 'daemon-reload' 2016-07-12T18:51:33Z DEBUG Process finished, return code=0 2016-07-12T18:51:33Z DEBUG stdout= 2016-07-12T18:51:33Z DEBUG stderr= 2016-07-12T18:51:33Z DEBUG Starting external process 2016-07-12T18:51:33Z DEBUG args='/bin/systemctl' 'restart' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:34Z DEBUG Process finished, return code=0 2016-07-12T18:51:34Z DEBUG stdout= 2016-07-12T18:51:34Z DEBUG stderr= 2016-07-12T18:51:34Z DEBUG Starting external process 2016-07-12T18:51:34Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:34Z DEBUG Process finished, return code=0 2016-07-12T18:51:34Z DEBUG stdout=active 2016-07-12T18:51:34Z DEBUG stderr= 2016-07-12T18:51:34Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2016-07-12T18:51:35Z DEBUG Starting external process 2016-07-12T18:51:35Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:35Z DEBUG Process finished, return code=0 2016-07-12T18:51:35Z DEBUG stdout=active 2016-07-12T18:51:35Z DEBUG stderr= 2016-07-12T18:51:35Z DEBUG duration: 2 seconds 2016-07-12T18:51:35Z DEBUG [24/38]: setting up initial replication 2016-07-12T18:51:35Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-RSINC-LOCAL.socket from SchemaCache 2016-07-12T18:51:35Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-RSINC-LOCAL.socket conn= 2016-07-12T18:51:35Z DEBUG Starting external process 2016-07-12T18:51:35Z DEBUG args='/bin/systemctl' '--system' 'daemon-reload' 2016-07-12T18:51:35Z DEBUG Process finished, return code=0 2016-07-12T18:51:35Z DEBUG stdout= 2016-07-12T18:51:35Z DEBUG stderr= 2016-07-12T18:51:35Z DEBUG Starting external process 2016-07-12T18:51:35Z DEBUG args='/bin/systemctl' 'restart' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:36Z DEBUG Process finished, return code=0 2016-07-12T18:51:36Z DEBUG stdout= 2016-07-12T18:51:36Z DEBUG stderr= 2016-07-12T18:51:36Z DEBUG Starting external process 2016-07-12T18:51:36Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:51:36Z DEBUG Process finished, return code=0 2016-07-12T18:51:36Z DEBUG stdout=active 2016-07-12T18:51:36Z DEBUG stderr= 2016-07-12T18:51:36Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2016-07-12T18:51:38Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2016-07-12T18:51:38Z DEBUG flushing ldap://ipa01-aws.rsinc.local:389 from SchemaCache 2016-07-12T18:51:38Z DEBUG retrieving schema for SchemaCache url=ldap://ipa01-aws.rsinc.local:389 conn= 2016-07-12T18:51:39Z DEBUG Successfully updated nsDS5ReplicaId. 2016-07-12T18:51:39Z DEBUG flushing ldaps://ipa03-aws.rsinc.local:636 from SchemaCache 2016-07-12T18:51:39Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa03-aws.rsinc.local:636 conn= 2016-07-12T18:51:49Z DEBUG duration: 14 seconds 2016-07-12T18:51:49Z DEBUG [25/38]: updating schema 2016-07-12T18:51:49Z DEBUG Starting external process 2016-07-12T18:51:49Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/schema-update.ldif' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpWvrmTP' 2016-07-12T18:51:50Z DEBUG Process finished, return code=0 2016-07-12T18:51:50Z DEBUG stdout=add objectClasses: ( 2.16.840.1.113730.3.2.41 NAME 'nsslapdPlugin' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ nsslapd-pluginPath $ nsslapd-pluginInitFunc $ nsslapd-pluginType $ nsslapd-pluginId $ nsslapd-pluginVersion $ nsslapd-pluginVendor $ nsslapd-pluginDescription $ nsslapd-pluginEnabled ) MAY ( nsslapd-pluginConfigArea $ nsslapd-plugin-depends-on-type ) X-ORIGIN 'Netscape Directory Server' ) ( 2.16.840.1.113730.3.2.317 NAME 'nsSaslMapping' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ nsSaslMapRegexString $ nsSaslMapBaseDNTemplate $ nsSaslMapFilterTemplate ) MAY ( nsSaslMapPriority ) X-ORIGIN 'Netscape Directory Server' ) modifying entry "cn=schema" modify complete 2016-07-12T18:51:50Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [26/38]: setting Auto Member configuration 2016-07-12T18:51:50Z DEBUG Starting external process 2016-07-12T18:51:50Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmp1eCPZ_' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpVqf5cB' 2016-07-12T18:51:50Z DEBUG Process finished, return code=0 2016-07-12T18:51:50Z DEBUG stdout=add nsslapd-pluginConfigArea: cn=automember,cn=etc,dc=rsinc,dc=local modifying entry "cn=Auto Membership Plugin,cn=plugins,cn=config" modify complete 2016-07-12T18:51:50Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [27/38]: enabling S4U2Proxy delegation 2016-07-12T18:51:50Z DEBUG Starting external process 2016-07-12T18:51:50Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpY17efF' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmp8IK3SH' 2016-07-12T18:51:50Z DEBUG Process finished, return code=0 2016-07-12T18:51:50Z DEBUG stdout=add memberPrincipal: HTTP/ipa03-aws.rsinc.local at RSINC.LOCAL modifying entry "cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=rsinc,dc=local" modify complete add memberPrincipal: ldap/ipa03-aws.rsinc.local at RSINC.LOCAL modifying entry "cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=rsinc,dc=local" modify complete 2016-07-12T18:51:50Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [28/38]: importing CA certificates from LDAP 2016-07-12T18:51:50Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:51:50Z DEBUG flushing ldap://ipa03-aws.rsinc.local:389 from SchemaCache 2016-07-12T18:51:50Z DEBUG retrieving schema for SchemaCache url=ldap://ipa03-aws.rsinc.local:389 conn= 2016-07-12T18:51:50Z DEBUG Starting external process 2016-07-12T18:51:50Z DEBUG args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-RSINC-LOCAL/' '-A' '-n' 'RSINC.LOCAL IPA CA' '-t' 'CT,C,C' 2016-07-12T18:51:50Z DEBUG Process finished, return code=0 2016-07-12T18:51:50Z DEBUG stdout= 2016-07-12T18:51:50Z DEBUG stderr= 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [29/38]: initializing group membership 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [30/38]: adding master entry 2016-07-12T18:51:50Z DEBUG Starting external process 2016-07-12T18:51:50Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpxaLDRH' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpm2TMAE' 2016-07-12T18:51:50Z DEBUG Process finished, return code=0 2016-07-12T18:51:50Z DEBUG stdout=add objectclass: top nsContainer ipaReplTopoManagedServer ipaConfigObject ipaSupportedDomainLevelConfig add cn: ipa03-aws.rsinc.local add ipaReplTopoManagedSuffix: dc=rsinc,dc=local add ipaMinDomainLevel: 0 add ipaMaxDomainLevel: 0 adding new entry "cn=ipa03-aws.rsinc.local,cn=masters,cn=ipa,cn=etc,dc=rsinc,dc=local" modify complete 2016-07-12T18:51:50Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [31/38]: initializing domain level 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [32/38]: configuring Posix uid/gid generation 2016-07-12T18:51:50Z DEBUG Starting external process 2016-07-12T18:51:50Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpIYMDRE' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmp2EyXWe' 2016-07-12T18:51:50Z DEBUG Process finished, return code=0 2016-07-12T18:51:50Z DEBUG stdout=add objectclass: top extensibleObject add cn: Posix IDs add dnaType: uidNumber gidNumber add dnaNextValue: 1101 add dnaMaxValue: 1100 add dnaMagicRegen: -1 add dnaFilter: (|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject)) add dnaScope: dc=rsinc,dc=local add dnaThreshold: 500 add dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=rsinc,dc=local adding new entry "cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" modify complete 2016-07-12T18:51:50Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [33/38]: adding replication acis 2016-07-12T18:51:50Z DEBUG Starting external process 2016-07-12T18:51:50Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpfjnnUg' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmporl0Uz' 2016-07-12T18:51:50Z DEBUG Process finished, return code=0 2016-07-12T18:51:50Z DEBUG stdout=add aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";allow (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=rsinc,dc=local";) modifying entry "cn="dc=rsinc,dc=local",cn=mapping tree,cn=config" modify complete add aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreements"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=rsinc,dc=local";) modifying entry "cn="dc=rsinc,dc=local",cn=mapping tree,cn=config" modify complete add aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "permission:Remove Replication Agreements";allow (delete) groupdn = "ldap:///cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=rsinc,dc=local";) modifying entry "cn="dc=rsinc,dc=local",cn=mapping tree,cn=config" modify complete add aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA Range,cn=permissions,cn=pbac,dc=rsinc,dc=local";) modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" modify complete add aci: (targetattr=nsslapd-readonly)(version 3.0; acl "Allow marking the database readonly"; allow (write) groupdn = "ldap:///cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=rsinc,dc=local";) modifying entry "cn=userRoot,cn=ldbm database,cn=plugins,cn=config" modify complete add aci: (targetattr=*)(version 3.0; acl "Run tasks after replica re-initialization"; allow (add) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=rsinc,dc=local";) modifying entry "cn=tasks,cn=config" modify complete 2016-07-12T18:51:50Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:50Z DEBUG duration: 0 seconds 2016-07-12T18:51:50Z DEBUG [34/38]: enabling compatibility plugin 2016-07-12T18:51:50Z DEBUG importing all plugin modules in ipalib.plugins... 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.aci 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.automember 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.automount 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.baseldap 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.baseuser 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.batch 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.caacl 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.cert 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.certprofile 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.config 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.delegation 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.dns 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.domainlevel 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.group 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.hbacrule 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.hbacsvc 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.hbacsvcgroup 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.hbactest 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.host 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.hostgroup 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.idrange 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.idviews 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.internal 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.kerberos 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.krbtpolicy 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.migration 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.misc 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.netgroup 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.otpconfig 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.otptoken 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.otptoken_yubikey 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.passwd 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.permission 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.ping 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.pkinit 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.privilege 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.pwpolicy 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.radiusproxy 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.realmdomains 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.role 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.rpcclient 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.selfservice 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.selinuxusermap 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.server 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.service 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.servicedelegation 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.session 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.stageuser 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.sudocmd 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.sudocmdgroup 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.sudorule 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.topology 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.trust 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.user 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.vault 2016-07-12T18:51:50Z DEBUG importing plugin module ipalib.plugins.virtual 2016-07-12T18:51:50Z DEBUG importing all plugin modules in ipaserver.plugins... 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.plugins.dogtag 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.plugins.join 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.plugins.ldap2 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.plugins.rabase 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.plugins.xmlserver 2016-07-12T18:51:50Z DEBUG importing all plugin modules in ipaserver.install.plugins... 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.adtrust 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.ca_renewal_master 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.dns 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.fix_replica_agreements 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.rename_managed 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_idranges 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_managed_permissions 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_nis 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_pacs 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_passsync 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_referint 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_services 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.update_uniqueness 2016-07-12T18:51:50Z DEBUG importing plugin module ipaserver.install.plugins.upload_cacrt 2016-07-12T18:51:50Z DEBUG SessionAuthManager.register: name=jsonserver_session_146012624 2016-07-12T18:51:50Z DEBUG SessionAuthManager.register: name=xmlserver_session_146030864 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.jsonserver_kerb() at '/json' 2016-07-12T18:51:51Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.xmlserver_session() at '/session/xml' 2016-07-12T18:51:51Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:51:51Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.sync_token() at '/session/sync_token' 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.xmlserver() at '/xml' 2016-07-12T18:51:51Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.jsonserver_session() at '/session/json' 2016-07-12T18:51:51Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' 2016-07-12T18:51:51Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.login_password() at '/session/login_password' 2016-07-12T18:51:51Z DEBUG session_auth_duration: 0:20:00 2016-07-12T18:51:51Z DEBUG Mounting ipaserver.rpcserver.change_password() at '/session/change_password' 2016-07-12T18:51:52Z DEBUG Created connection context.ldap2_146012240 2016-07-12T18:51:52Z DEBUG Destroyed connection context.ldap2_146012240 2016-07-12T18:51:52Z DEBUG Created connection context.ldap2_146012240 2016-07-12T18:51:52Z DEBUG Parsing update file '/usr/share/ipa/schema_compat.uldif' 2016-07-12T18:51:52Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-RSINC-LOCAL.socket from SchemaCache 2016-07-12T18:51:52Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-RSINC-LOCAL.socket conn= 2016-07-12T18:51:52Z DEBUG New entry: cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Initial value 2016-07-12T18:51:52Z DEBUG dn: cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG nsslapd-pluginid: 2016-07-12T18:51:52Z DEBUG schema-compat-plugin 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG Schema Compatibility 2016-07-12T18:51:52Z DEBUG nsslapd-pluginbetxn: 2016-07-12T18:51:52Z DEBUG on 2016-07-12T18:51:52Z DEBUG objectclass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG nsSlapdPlugin 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG nsslapd-plugindescription: 2016-07-12T18:51:52Z DEBUG Schema Compatibility Plugin 2016-07-12T18:51:52Z DEBUG nsslapd-pluginenabled: 2016-07-12T18:51:52Z DEBUG on 2016-07-12T18:51:52Z DEBUG nsslapd-pluginpath: 2016-07-12T18:51:52Z DEBUG /usr/lib64/dirsrv/plugins/schemacompat-plugin.so 2016-07-12T18:51:52Z DEBUG nsslapd-pluginversion: 2016-07-12T18:51:52Z DEBUG 0.8 2016-07-12T18:51:52Z DEBUG nsslapd-pluginvendor: 2016-07-12T18:51:52Z DEBUG redhat.com 2016-07-12T18:51:52Z DEBUG nsslapd-pluginprecedence: 2016-07-12T18:51:52Z DEBUG 49 2016-07-12T18:51:52Z DEBUG nsslapd-plugintype: 2016-07-12T18:51:52Z DEBUG object 2016-07-12T18:51:52Z DEBUG nsslapd-plugininitfunc: 2016-07-12T18:51:52Z DEBUG schema_compat_plugin_init 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Final value after applying updates 2016-07-12T18:51:52Z DEBUG dn: cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG nsslapd-pluginid: 2016-07-12T18:51:52Z DEBUG schema-compat-plugin 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG Schema Compatibility 2016-07-12T18:51:52Z DEBUG nsslapd-pluginbetxn: 2016-07-12T18:51:52Z DEBUG on 2016-07-12T18:51:52Z DEBUG objectclass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG nsSlapdPlugin 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG nsslapd-plugindescription: 2016-07-12T18:51:52Z DEBUG Schema Compatibility Plugin 2016-07-12T18:51:52Z DEBUG nsslapd-pluginenabled: 2016-07-12T18:51:52Z DEBUG on 2016-07-12T18:51:52Z DEBUG nsslapd-pluginpath: 2016-07-12T18:51:52Z DEBUG /usr/lib64/dirsrv/plugins/schemacompat-plugin.so 2016-07-12T18:51:52Z DEBUG nsslapd-pluginversion: 2016-07-12T18:51:52Z DEBUG 0.8 2016-07-12T18:51:52Z DEBUG nsslapd-pluginvendor: 2016-07-12T18:51:52Z DEBUG redhat.com 2016-07-12T18:51:52Z DEBUG nsslapd-pluginprecedence: 2016-07-12T18:51:52Z DEBUG 49 2016-07-12T18:51:52Z DEBUG nsslapd-plugintype: 2016-07-12T18:51:52Z DEBUG object 2016-07-12T18:51:52Z DEBUG nsslapd-plugininitfunc: 2016-07-12T18:51:52Z DEBUG schema_compat_plugin_init 2016-07-12T18:51:52Z DEBUG New entry: cn=users,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Initial value 2016-07-12T18:51:52Z DEBUG dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG cn=%{cn} 2016-07-12T18:51:52Z DEBUG objectclass=posixAccount 2016-07-12T18:51:52Z DEBUG gidNumber=%{gidNumber} 2016-07-12T18:51:52Z DEBUG gecos=%{cn} 2016-07-12T18:51:52Z DEBUG ipaanchoruuid=%{ipaanchoruuid} 2016-07-12T18:51:52Z DEBUG uidNumber=%{uidNumber} 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:rsinc.local:%{ipauniqueid}","") 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG loginShell=%{loginShell} 2016-07-12T18:51:52Z DEBUG homeDirectory=%{homeDirectory} 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG users 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG objectclass=posixAccount 2016-07-12T18:51:52Z DEBUG schema-compat-container-rdn: 2016-07-12T18:51:52Z DEBUG cn=users 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG uid=%{uid} 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=users, cn=accounts, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG cn=compat, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Final value after applying updates 2016-07-12T18:51:52Z DEBUG dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG cn=%{cn} 2016-07-12T18:51:52Z DEBUG objectclass=posixAccount 2016-07-12T18:51:52Z DEBUG gidNumber=%{gidNumber} 2016-07-12T18:51:52Z DEBUG gecos=%{cn} 2016-07-12T18:51:52Z DEBUG ipaanchoruuid=%{ipaanchoruuid} 2016-07-12T18:51:52Z DEBUG uidNumber=%{uidNumber} 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:rsinc.local:%{ipauniqueid}","") 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG loginShell=%{loginShell} 2016-07-12T18:51:52Z DEBUG homeDirectory=%{homeDirectory} 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG users 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG objectclass=posixAccount 2016-07-12T18:51:52Z DEBUG schema-compat-container-rdn: 2016-07-12T18:51:52Z DEBUG cn=users 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG uid=%{uid} 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=users, cn=accounts, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG cn=compat, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG New entry: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Initial value 2016-07-12T18:51:52Z DEBUG dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG ipaanchoruuid=%{ipaanchoruuid} 2016-07-12T18:51:52Z DEBUG gidNumber=%{gidNumber} 2016-07-12T18:51:52Z DEBUG objectclass=posixGroup 2016-07-12T18:51:52Z DEBUG memberUid=%{memberUid} 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:rsinc.local:%{ipauniqueid}","") 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG memberUid=%deref_r("member","uid") 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG groups 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG objectclass=posixGroup 2016-07-12T18:51:52Z DEBUG schema-compat-container-rdn: 2016-07-12T18:51:52Z DEBUG cn=groups 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG cn=%{cn} 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=groups, cn=accounts, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG cn=compat, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Final value after applying updates 2016-07-12T18:51:52Z DEBUG dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG ipaanchoruuid=%{ipaanchoruuid} 2016-07-12T18:51:52Z DEBUG gidNumber=%{gidNumber} 2016-07-12T18:51:52Z DEBUG objectclass=posixGroup 2016-07-12T18:51:52Z DEBUG memberUid=%{memberUid} 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:rsinc.local:%{ipauniqueid}","") 2016-07-12T18:51:52Z DEBUG %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") 2016-07-12T18:51:52Z DEBUG memberUid=%deref_r("member","uid") 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG groups 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG objectclass=posixGroup 2016-07-12T18:51:52Z DEBUG schema-compat-container-rdn: 2016-07-12T18:51:52Z DEBUG cn=groups 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG cn=%{cn} 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=groups, cn=accounts, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG cn=compat, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG New entry: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Initial value 2016-07-12T18:51:52Z DEBUG dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG add: 'top' to objectClass, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['top'] 2016-07-12T18:51:52Z DEBUG add: 'extensibleObject' to objectClass, current value ['top'] 2016-07-12T18:51:52Z DEBUG add: updated value ['top', 'extensibleObject'] 2016-07-12T18:51:52Z DEBUG add: 'ng' to cn, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['ng'] 2016-07-12T18:51:52Z DEBUG add: 'cn=compat, dc=rsinc,dc=local' to schema-compat-container-group, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['cn=compat, dc=rsinc,dc=local'] 2016-07-12T18:51:52Z DEBUG add: 'cn=ng' to schema-compat-container-rdn, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['cn=ng'] 2016-07-12T18:51:52Z DEBUG add: 'yes' to schema-compat-check-access, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['yes'] 2016-07-12T18:51:52Z DEBUG add: 'cn=ng, cn=alt, dc=rsinc,dc=local' to schema-compat-search-base, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['cn=ng, cn=alt, dc=rsinc,dc=local'] 2016-07-12T18:51:52Z DEBUG add: '(objectclass=ipaNisNetgroup)' to schema-compat-search-filter, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['(objectclass=ipaNisNetgroup)'] 2016-07-12T18:51:52Z DEBUG add: 'cn=%{cn}' to schema-compat-entry-rdn, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['cn=%{cn}'] 2016-07-12T18:51:52Z DEBUG add: 'objectclass=nisNetgroup' to schema-compat-entry-attribute, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['objectclass=nisNetgroup'] 2016-07-12T18:51:52Z DEBUG add: 'memberNisNetgroup=%deref_r("member","cn")' to schema-compat-entry-attribute, current value ['objectclass=nisNetgroup'] 2016-07-12T18:51:52Z DEBUG add: updated value ['objectclass=nisNetgroup', 'memberNisNetgroup=%deref_r("member","cn")'] 2016-07-12T18:51:52Z DEBUG add: 'nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","-",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-})' to schema-compat-entry-attribute, current value ['memberNisNetgroup=%deref_r("member","cn")', 'objectclass=nisNetgroup'] 2016-07-12T18:51:52Z DEBUG add: updated value ['memberNisNetgroup=%deref_r("member","cn")', 'objectclass=nisNetgroup', 'nisNetgroupTriple=(%link("%ifeq(\\"hostCategory\\",\\"all\\",\\"\\",\\"%collect(\\\\\\"%{externalHost}\\\\\\",\\\\\\"%deref(\\\\\\\\\\\\\\"memberHost\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\")\\\\\\",\\\\\\"%deref_r(\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\")\\\\\\",\\\\\\"%deref_r(\\\\\\\\\\\\\\"memberHost\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\")\\\\\\")\\")","-",",","%ifeq(\\"userCategory\\",\\"all\\",\\"\\",\\"%collect(\\\\\\"%deref(\\\\\\\\\\\\\\"memberUser\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\")\\\\\\",\\\\\\"%deref_r(\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\")\\\\\\",\\\\\\"%deref_r(\\\\\\\\\\\\\\"memberUser\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\",\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\")\\\\\\")\\")","-"),%{nisDomainName:-})'] 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Final value after applying updates 2016-07-12T18:51:52Z DEBUG dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG memberNisNetgroup=%deref_r("member","cn") 2016-07-12T18:51:52Z DEBUG objectclass=nisNetgroup 2016-07-12T18:51:52Z DEBUG nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","-",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-}) 2016-07-12T18:51:52Z DEBUG schema-compat-check-access: 2016-07-12T18:51:52Z DEBUG yes 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG ng 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG (objectclass=ipaNisNetgroup) 2016-07-12T18:51:52Z DEBUG schema-compat-container-rdn: 2016-07-12T18:51:52Z DEBUG cn=ng 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG cn=%{cn} 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=ng, cn=alt, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG cn=compat, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG New entry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Initial value 2016-07-12T18:51:52Z DEBUG dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG add: 'top' to objectClass, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['top'] 2016-07-12T18:51:52Z DEBUG add: 'extensibleObject' to objectClass, current value ['top'] 2016-07-12T18:51:52Z DEBUG add: updated value ['top', 'extensibleObject'] 2016-07-12T18:51:52Z DEBUG add: 'sudoers' to cn, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoers'] 2016-07-12T18:51:52Z DEBUG add: 'ou=SUDOers, dc=rsinc,dc=local' to schema-compat-container-group, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['ou=SUDOers, dc=rsinc,dc=local'] 2016-07-12T18:51:52Z DEBUG add: 'cn=sudorules, cn=sudo, dc=rsinc,dc=local' to schema-compat-search-base, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['cn=sudorules, cn=sudo, dc=rsinc,dc=local'] 2016-07-12T18:51:52Z DEBUG add: '(&(objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))' to schema-compat-search-filter, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['(&(objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE)))'] 2016-07-12T18:51:52Z DEBUG add: '%ifeq("ipaEnabledFlag", "FALSE", "DISABLED", "cn=%{cn}")' to schema-compat-entry-rdn, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['%ifeq("ipaEnabledFlag", "FALSE", "DISABLED", "cn=%{cn}")'] 2016-07-12T18:51:52Z DEBUG add: 'objectclass=sudoRole' to schema-compat-entry-attribute, current value [] 2016-07-12T18:51:52Z DEBUG add: updated value ['objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")' to schema-compat-entry-attribute, current value ['objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\"memberUser\",\"(objectclass=posixAccount)\",\"uid\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\"memberUser\",\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\",\"member\",\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\",\"uid\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\"memberUser\",\"(objectclass=posixGroup)\",\"cn\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\"memberUser\",\"(objectclass=ipaNisNetgroup)\",\"cn\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\"memberHost\",\"(objectclass=ipaHost)\",\"fqdn\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\"memberHost\",\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\",\"member\",\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\",\"fqdn\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\"memberHost\",\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\",\"cn\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\"memberHost\",\"(objectclass=ipaNisNetgroup)\",\"cn\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\"memberAllowCmd\",\"sudoCmd\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\"memberAllowCmd\",\"member\",\"sudoCmd\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixAccount)\",\"uid\")")' to schema-compat-entry-attribute, current value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'objectclass=sudoRole', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixGroup)\",\"cn\")")' to schema-compat-entry-attribute, current value ['objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")' to schema-compat-entry-attribute, current value ['objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\"ipaSudoRunAsGroup\",\"(objectclass=posixGroup)\",\"cn\")")' to schema-compat-entry-attribute, current value ['sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\\"ipaSudoRunAsGroup\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")'] 2016-07-12T18:51:52Z DEBUG add: 'sudoOption=%{ipaSudoOpt}' to schema-compat-entry-attribute, current value ['sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\\"ipaSudoRunAsGroup\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")'] 2016-07-12T18:51:52Z DEBUG add: updated value ['sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}")', 'sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\\",\\"member\\",\\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\\",\\"fqdn\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\\"memberUser\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\\",\\"cn\\")")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\\"memberUser\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}")', 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\\"ipaSudoRunAsGroup\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\\"memberHost\\",\\"(objectclass=ipaHost)\\",\\"fqdn\\")")', 'objectclass=sudoRole', 'sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\\"memberUser\\",\\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\\",\\"member\\",\\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\\",\\"uid\\")")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\\"memberAllowCmd\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixAccount)\\",\\"uid\\")")', 'sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\\"memberUser\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\\"ipaSudoRunAs\\",\\"(objectclass=posixGroup)\\",\\"cn\\")")', 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}")', 'sudoCommand=!%deref("memberDenyCmd","sudoCmd")', 'sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd")', 'sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\\"memberAllowCmd\\",\\"member\\",\\"sudoCmd\\")")', 'sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\\"memberHost\\",\\"(objectclass=ipaNisNetgroup)\\",\\"cn\\")")', 'sudoOption=%{ipaSudoOpt}'] 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Final value after applying updates 2016-07-12T18:51:52Z DEBUG dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%{ipaSudoRunAsExtUserGroup}") 2016-07-12T18:51:52Z DEBUG sudoUser=%ifeq("userCategory","all","ALL","%{externalUser}") 2016-07-12T18:51:52Z DEBUG sudoHost=%ifeq("hostCategory","all","ALL","%deref_rf(\"memberHost\",\"(&(objectclass=ipaHostGroup)(!(objectclass=mepOriginEntry)))\",\"member\",\"(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\",\"fqdn\")") 2016-07-12T18:51:52Z DEBUG sudoUser=%ifeq("userCategory","all","ALL","%%%deref_f(\"memberUser\",\"(objectclass=posixGroup)\",\"cn\")") 2016-07-12T18:51:52Z DEBUG sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\"memberHost\",\"(&(objectclass=ipaHostGroup)(objectclass=mepOriginEntry))\",\"cn\")") 2016-07-12T18:51:52Z DEBUG sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}") 2016-07-12T18:51:52Z DEBUG sudoUser=%ifeq("userCategory","all","ALL","%deref_f(\"memberUser\",\"(objectclass=posixAccount)\",\"uid\")") 2016-07-12T18:51:52Z DEBUG sudoHost=%ifeq("hostCategory","all","ALL","+%deref_f(\"memberHost\",\"(objectclass=ipaNisNetgroup)\",\"cn\")") 2016-07-12T18:51:52Z DEBUG sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\"ipaSudoRunAsGroup\",\"(objectclass=posixGroup)\",\"cn\")") 2016-07-12T18:51:52Z DEBUG sudoHost=%ifeq("hostCategory","all","ALL","%deref_f(\"memberHost\",\"(objectclass=ipaHost)\",\"fqdn\")") 2016-07-12T18:51:52Z DEBUG objectclass=sudoRole 2016-07-12T18:51:52Z DEBUG sudoOption=%{ipaSudoOpt} 2016-07-12T18:51:52Z DEBUG sudoUser=%ifeq("userCategory","all","ALL","%deref_rf(\"memberUser\",\"(&(objectclass=ipaUserGroup)(!(objectclass=posixGroup)))\",\"member\",\"(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\",\"uid\")") 2016-07-12T18:51:52Z DEBUG sudoCommand=%ifeq("cmdCategory","all","ALL","%deref(\"memberAllowCmd\",\"sudoCmd\")") 2016-07-12T18:51:52Z DEBUG sudoHost=%ifeq("hostCategory","all","ALL","%{hostMask}") 2016-07-12T18:51:52Z DEBUG sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixAccount)\",\"uid\")") 2016-07-12T18:51:52Z DEBUG sudoUser=%ifeq("userCategory","all","ALL","+%deref_f(\"memberUser\",\"(objectclass=ipaNisNetgroup)\",\"cn\")") 2016-07-12T18:51:52Z DEBUG sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%%%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixGroup)\",\"cn\")") 2016-07-12T18:51:52Z DEBUG sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%{ipaSudoRunAsExtUser}") 2016-07-12T18:51:52Z DEBUG sudoCommand=!%deref("memberDenyCmd","sudoCmd") 2016-07-12T18:51:52Z DEBUG sudoCommand=!%deref_r("memberDenyCmd","member","sudoCmd") 2016-07-12T18:51:52Z DEBUG sudoCommand=%ifeq("cmdCategory","all","ALL","%deref_r(\"memberAllowCmd\",\"member\",\"sudoCmd\")") 2016-07-12T18:51:52Z DEBUG sudoHost=%ifeq("hostCategory","all","ALL","%{externalHost}") 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG sudoers 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG (&(objectclass=ipaSudoRule)(!(compatVisible=FALSE))(!(ipaEnabledFlag=FALSE))) 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG %ifeq("ipaEnabledFlag", "FALSE", "DISABLED", "cn=%{cn}") 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=sudorules, cn=sudo, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG ou=SUDOers, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG New entry: cn=computers,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Initial value 2016-07-12T18:51:52Z DEBUG dn: cn=computers,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG objectclass=device 2016-07-12T18:51:52Z DEBUG cn=%{fqdn} 2016-07-12T18:51:52Z DEBUG macAddress=%{macAddress} 2016-07-12T18:51:52Z DEBUG objectclass=ieee802Device 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG computers 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG (&(macAddress=*)(fqdn=*)(objectClass=ipaHost)) 2016-07-12T18:51:52Z DEBUG schema-compat-container-rdn: 2016-07-12T18:51:52Z DEBUG cn=computers 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG cn=%first("%{fqdn}") 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=computers, cn=accounts, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG cn=compat, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Final value after applying updates 2016-07-12T18:51:52Z DEBUG dn: cn=computers,cn=Schema Compatibility,cn=plugins,cn=config 2016-07-12T18:51:52Z DEBUG schema-compat-entry-attribute: 2016-07-12T18:51:52Z DEBUG objectclass=device 2016-07-12T18:51:52Z DEBUG cn=%{fqdn} 2016-07-12T18:51:52Z DEBUG macAddress=%{macAddress} 2016-07-12T18:51:52Z DEBUG objectclass=ieee802Device 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG computers 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG extensibleObject 2016-07-12T18:51:52Z DEBUG schema-compat-search-filter: 2016-07-12T18:51:52Z DEBUG (&(macAddress=*)(fqdn=*)(objectClass=ipaHost)) 2016-07-12T18:51:52Z DEBUG schema-compat-container-rdn: 2016-07-12T18:51:52Z DEBUG cn=computers 2016-07-12T18:51:52Z DEBUG schema-compat-entry-rdn: 2016-07-12T18:51:52Z DEBUG cn=%first("%{fqdn}") 2016-07-12T18:51:52Z DEBUG schema-compat-search-base: 2016-07-12T18:51:52Z DEBUG cn=computers, cn=accounts, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG schema-compat-container-group: 2016-07-12T18:51:52Z DEBUG cn=compat, dc=rsinc,dc=local 2016-07-12T18:51:52Z DEBUG Updating existing entry: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Initial value 2016-07-12T18:51:52Z DEBUG dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG directoryServerFeature 2016-07-12T18:51:52Z DEBUG aci: 2016-07-12T18:51:52Z DEBUG (targetattr != "aci")(version 3.0; acl "VLV Request Control"; allow( read, search, compare, proxy ) userdn = "ldap:///all";) 2016-07-12T18:51:52Z DEBUG oid: 2016-07-12T18:51:52Z DEBUG 2.16.840.1.113730.3.4.9 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG VLV Request Control 2016-07-12T18:51:52Z DEBUG only: set aci to '(targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read, search, compare, proxy) userdn = "ldap:///anyone"; )', current value ['(targetattr != "aci")(version 3.0; acl "VLV Request Control"; allow( read, search, compare, proxy ) userdn = "ldap:///all";)'] 2016-07-12T18:51:52Z DEBUG only: updated value ['(targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read, search, compare, proxy) userdn = "ldap:///anyone"; )'] 2016-07-12T18:51:52Z DEBUG --------------------------------------------- 2016-07-12T18:51:52Z DEBUG Final value after applying updates 2016-07-12T18:51:52Z DEBUG dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config 2016-07-12T18:51:52Z DEBUG objectClass: 2016-07-12T18:51:52Z DEBUG top 2016-07-12T18:51:52Z DEBUG directoryServerFeature 2016-07-12T18:51:52Z DEBUG aci: 2016-07-12T18:51:52Z DEBUG (targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read, search, compare, proxy) userdn = "ldap:///anyone"; ) 2016-07-12T18:51:52Z DEBUG oid: 2016-07-12T18:51:52Z DEBUG 2.16.840.1.113730.3.4.9 2016-07-12T18:51:52Z DEBUG cn: 2016-07-12T18:51:52Z DEBUG VLV Request Control 2016-07-12T18:51:52Z DEBUG [(0, u'aci', ['(targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read, search, compare, proxy) userdn = "ldap:///anyone"; )']), (1, u'aci', ['(targetattr != "aci")(version 3.0; acl "VLV Request Control"; allow( read, search, compare, proxy ) userdn = "ldap:///all";)'])] 2016-07-12T18:51:52Z DEBUG Updated 1 2016-07-12T18:51:52Z DEBUG Done 2016-07-12T18:51:52Z DEBUG Destroyed connection context.ldap2_146012240 2016-07-12T18:51:52Z DEBUG duration: 1 seconds 2016-07-12T18:51:52Z DEBUG [35/38]: activating sidgen plugin 2016-07-12T18:51:52Z DEBUG Starting external process 2016-07-12T18:51:52Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpHNifK0' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpu7gGVO' 2016-07-12T18:51:52Z DEBUG Process finished, return code=0 2016-07-12T18:51:52Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: IPA SIDGEN add nsslapd-pluginpath: libipa_sidgen add nsslapd-plugininitfunc: ipa_sidgen_init add nsslapd-plugintype: postoperation add nsslapd-pluginenabled: on add nsslapd-pluginid: ipa_sidgen_postop add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: Red Hat, Inc. add nsslapd-plugindescription: IPA SIDGEN post operation add nsslapd-plugin-depends-on-type: database add nsslapd-basedn: dc=rsinc,dc=local adding new entry "cn=IPA SIDGEN,cn=plugins,cn=config" modify complete 2016-07-12T18:51:52Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:52Z DEBUG duration: 0 seconds 2016-07-12T18:51:52Z DEBUG [36/38]: activating extdom plugin 2016-07-12T18:51:52Z DEBUG Starting external process 2016-07-12T18:51:52Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpIyfltw' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk7JxMO' 2016-07-12T18:51:52Z DEBUG Process finished, return code=0 2016-07-12T18:51:52Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: ipa_extdom_extop add nsslapd-pluginpath: libipa_extdom_extop add nsslapd-plugininitfunc: ipa_extdom_init add nsslapd-plugintype: extendedop add nsslapd-pluginenabled: on add nsslapd-pluginid: ipa_extdom_extop add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: RedHat add nsslapd-plugindescription: Support resolving IDs in trusted domains to names and back add nsslapd-plugin-depends-on-type: database add nsslapd-basedn: dc=rsinc,dc=local adding new entry "cn=ipa_extdom_extop,cn=plugins,cn=config" modify complete 2016-07-12T18:51:52Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:51:52Z DEBUG duration: 0 seconds 2016-07-12T18:51:52Z DEBUG [37/38]: tuning directory server 2016-07-12T18:51:52Z DEBUG Starting external process 2016-07-12T18:51:52Z DEBUG args='/usr/sbin/selinuxenabled' 2016-07-12T18:51:52Z DEBUG Process finished, return code=0 2016-07-12T18:51:52Z DEBUG stdout= 2016-07-12T18:51:52Z DEBUG stderr= 2016-07-12T18:51:52Z DEBUG Starting external process 2016-07-12T18:51:52Z DEBUG args='/sbin/restorecon' '/etc/sysconfig/dirsrv.systemd' 2016-07-12T18:51:52Z DEBUG Process finished, return code=0 2016-07-12T18:51:52Z DEBUG stdout= 2016-07-12T18:51:52Z DEBUG stderr= 2016-07-12T18:51:52Z DEBUG Starting external process 2016-07-12T18:51:52Z DEBUG args='/bin/systemctl' '--system' 'daemon-reload' 2016-07-12T18:51:52Z DEBUG Process finished, return code=0 2016-07-12T18:51:52Z DEBUG stdout= 2016-07-12T18:51:52Z DEBUG stderr= 2016-07-12T18:51:52Z DEBUG Starting external process 2016-07-12T18:51:52Z DEBUG args='/bin/systemctl' '--system' 'daemon-reload' 2016-07-12T18:51:52Z DEBUG Process finished, return code=0 2016-07-12T18:51:52Z DEBUG stdout= 2016-07-12T18:51:52Z DEBUG stderr= 2016-07-12T18:51:52Z DEBUG Starting external process 2016-07-12T18:51:52Z DEBUG args='/bin/systemctl' 'restart' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:52:01Z DEBUG Process finished, return code=0 2016-07-12T18:52:01Z DEBUG stdout= 2016-07-12T18:52:01Z DEBUG stderr= 2016-07-12T18:52:01Z DEBUG Starting external process 2016-07-12T18:52:01Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:52:01Z DEBUG Process finished, return code=0 2016-07-12T18:52:01Z DEBUG stdout=active 2016-07-12T18:52:01Z DEBUG stderr= 2016-07-12T18:52:01Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2016-07-12T18:52:02Z DEBUG Starting external process 2016-07-12T18:52:02Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:52:02Z DEBUG Process finished, return code=0 2016-07-12T18:52:02Z DEBUG stdout=active 2016-07-12T18:52:02Z DEBUG stderr= 2016-07-12T18:52:02Z DEBUG Starting external process 2016-07-12T18:52:02Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpBnJ9Ee' '-H' 'ldap://ipa03-aws.rsinc.local:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpYQYFCf' 2016-07-12T18:52:02Z DEBUG Process finished, return code=0 2016-07-12T18:52:02Z DEBUG stdout=replace nsslapd-maxdescriptors: 8192 replace nsslapd-reservedescriptors: 64 modifying entry "cn=config" modify complete 2016-07-12T18:52:02Z DEBUG stderr=ldap_initialize( ldap://ipa03-aws.rsinc.local:389/??base ) 2016-07-12T18:52:02Z DEBUG duration: 10 seconds 2016-07-12T18:52:02Z DEBUG [38/38]: configuring directory to start on boot 2016-07-12T18:52:02Z DEBUG Starting external process 2016-07-12T18:52:02Z DEBUG args='/bin/systemctl' 'is-enabled' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:52:02Z DEBUG Process finished, return code=0 2016-07-12T18:52:02Z DEBUG stdout=enabled 2016-07-12T18:52:02Z DEBUG stderr= 2016-07-12T18:52:02Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:02Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:02Z DEBUG Starting external process 2016-07-12T18:52:02Z DEBUG args='/bin/systemctl' 'disable' 'dirsrv at RSINC-LOCAL.service' 2016-07-12T18:52:02Z DEBUG Process finished, return code=0 2016-07-12T18:52:02Z DEBUG stdout= 2016-07-12T18:52:02Z DEBUG stderr=Removed symlink /etc/systemd/system/dirsrv.target.wants/dirsrv at RSINC-LOCAL.service. 2016-07-12T18:52:02Z DEBUG duration: 0 seconds 2016-07-12T18:52:02Z DEBUG Done configuring directory server (dirsrv). 2016-07-12T18:52:03Z DEBUG flushing ldaps://ipa01-aws.rsinc.local:636 from SchemaCache 2016-07-12T18:52:03Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa01-aws.rsinc.local:636 conn= 2016-07-12T18:52:04Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:04Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:04Z DEBUG raw: dnszone_show(u'242.0.40.10.in-addr.arpa.', version=u'2.156') 2016-07-12T18:52:04Z DEBUG dnszone_show(, rights=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:04Z DEBUG raw: dnszone_show(u'0.40.10.in-addr.arpa.', version=u'2.156') 2016-07-12T18:52:04Z DEBUG dnszone_show(, rights=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:04Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_ldap._tcp', srvrecord=u'0 100 389 ipa03-aws', version=u'2.156') 2016-07-12T18:52:04Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 389 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:06Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:06Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:06Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:06Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:06Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_kerberos._tcp', srvrecord=u'0 100 88 ipa03-aws', version=u'2.156') 2016-07-12T18:52:06Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 88 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:07Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:07Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:07Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_kerberos._udp', srvrecord=u'0 100 88 ipa03-aws', version=u'2.156') 2016-07-12T18:52:07Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 88 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:08Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:08Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:08Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_kerberos-master._tcp', srvrecord=u'0 100 88 ipa03-aws', version=u'2.156') 2016-07-12T18:52:08Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 88 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:09Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:09Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:09Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_kerberos-master._udp', srvrecord=u'0 100 88 ipa03-aws', version=u'2.156') 2016-07-12T18:52:09Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 88 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:10Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:10Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:10Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_kpasswd._tcp', srvrecord=u'0 100 464 ipa03-aws', version=u'2.156') 2016-07-12T18:52:10Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 464 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:11Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:11Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:11Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_kpasswd._udp', srvrecord=u'0 100 464 ipa03-aws', version=u'2.156') 2016-07-12T18:52:11Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 464 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:12Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:12Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:12Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'_ntp._udp', srvrecord=u'0 100 123 ipa03-aws', version=u'2.156') 2016-07-12T18:52:12Z DEBUG dnsrecord_add(, , a_extra_create_reverse=False, aaaa_extra_create_reverse=False, srvrecord=(u'0 100 123 ipa03-aws',), force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:15Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:15Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:15Z DEBUG raw: dnszone_show(u'rsinc.local', version=u'2.156') 2016-07-12T18:52:15Z DEBUG dnszone_show(, rights=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:15Z DEBUG raw: dnsrecord_add(u'rsinc.local', u'ipa03-aws', arecord=u'1', version=u'2.156') 2016-07-12T18:52:15Z DEBUG dnsrecord_add(, , arecord=(u'1',), a_extra_create_reverse=False, aaaa_extra_create_reverse=False, force=False, structured=False, all=False, raw=False, version=u'2.156') 2016-07-12T18:52:15Z INFO Replica DNS records could not be added on master: invalid 'ip_address': Gettext('invalid IP address format', domain='ipa', localedir=None) 2016-07-12T18:52:15Z DEBUG Destroyed connection context.ldap2_90329936 2016-07-12T18:52:15Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:15Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:15Z DEBUG Starting external process 2016-07-12T18:52:15Z DEBUG args='keyctl' 'get_persistent' '@s' '0' 2016-07-12T18:52:15Z DEBUG Process finished, return code=0 2016-07-12T18:52:15Z DEBUG stdout=173686621 2016-07-12T18:52:15Z DEBUG stderr= 2016-07-12T18:52:15Z DEBUG Enabling persistent keyring CCACHE 2016-07-12T18:52:15Z DEBUG Starting external process 2016-07-12T18:52:15Z DEBUG args='/bin/systemctl' 'is-active' 'krb5kdc.service' 2016-07-12T18:52:15Z DEBUG Process finished, return code=3 2016-07-12T18:52:15Z DEBUG stdout=unknown 2016-07-12T18:52:15Z DEBUG stderr= 2016-07-12T18:52:15Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:15Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2016-07-12T18:52:15Z DEBUG Starting external process 2016-07-12T18:52:15Z DEBUG args='/bin/systemctl' 'stop' 'krb5kdc.service' 2016-07-12T18:52:15Z DEBUG Process finished, return code=0 2016-07-12T18:52:15Z DEBUG stdout= 2016-07-12T18:52:15Z DEBUG stderr= 2016-07-12T18:52:15Z DEBUG Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds 2016-07-12T18:52:15Z DEBUG [1/8]: adding sasl mappings to the directory 2016-07-12T18:52:15Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-RSINC-LOCAL.socket from SchemaCache 2016-07-12T18:52:15Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-RSINC-LOCAL.socket conn= 2016-07-12T18:52:16Z DEBUG duration: 1 seconds 2016-07-12T18:52:16Z DEBUG [2/8]: configuring KDC 2016-07-12T18:52:16Z DEBUG Backing up system configuration file '/var/kerberos/krb5kdc/kdc.conf' 2016-07-12T18:52:16Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:16Z DEBUG Backing up system configuration file '/etc/krb5.conf' 2016-07-12T18:52:16Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:16Z DEBUG Backing up system configuration file '/usr/share/ipa/html/krb5.ini' 2016-07-12T18:52:16Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:16Z DEBUG Backing up system configuration file '/usr/share/ipa/html/krb.con' 2016-07-12T18:52:16Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:16Z DEBUG Backing up system configuration file '/usr/share/ipa/html/krbrealm.con' 2016-07-12T18:52:16Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:16Z DEBUG Starting external process 2016-07-12T18:52:16Z DEBUG args='klist' '-V' 2016-07-12T18:52:16Z DEBUG Process finished, return code=0 2016-07-12T18:52:16Z DEBUG stdout=Kerberos 5 version 1.13.2 2016-07-12T18:52:16Z DEBUG stderr= 2016-07-12T18:52:16Z DEBUG Backing up system configuration file '/etc/sysconfig/krb5kdc' 2016-07-12T18:52:16Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:16Z DEBUG Starting external process 2016-07-12T18:52:16Z DEBUG args='/usr/sbin/selinuxenabled' 2016-07-12T18:52:16Z DEBUG Process finished, return code=0 2016-07-12T18:52:16Z DEBUG stdout= 2016-07-12T18:52:16Z DEBUG stderr= 2016-07-12T18:52:16Z DEBUG Starting external process 2016-07-12T18:52:16Z DEBUG args='/sbin/restorecon' '/etc/sysconfig/krb5kdc' 2016-07-12T18:52:16Z DEBUG Process finished, return code=0 2016-07-12T18:52:16Z DEBUG stdout= 2016-07-12T18:52:16Z DEBUG stderr= 2016-07-12T18:52:16Z DEBUG duration: 0 seconds 2016-07-12T18:52:16Z DEBUG [3/8]: creating a keytab for the directory 2016-07-12T18:52:16Z DEBUG Starting external process 2016-07-12T18:52:16Z DEBUG args='kadmin.local' '-q' 'addprinc -randkey ldap/ipa03-aws.rsinc.local at RSINC.LOCAL' '-x' 'ipa-setup-override-restrictions' 2016-07-12T18:52:16Z DEBUG Process finished, return code=0 2016-07-12T18:52:16Z DEBUG stdout=Authenticating as principal root/admin at RSINC.LOCAL with password. Principal "ldap/ipa03-aws.rsinc.local at RSINC.LOCAL" created. 2016-07-12T18:52:16Z DEBUG stderr=WARNING: no policy specified for ldap/ipa03-aws.rsinc.local at RSINC.LOCAL; defaulting to no policy 2016-07-12T18:52:17Z DEBUG Backing up system configuration file '/etc/dirsrv/ds.keytab' 2016-07-12T18:52:17Z DEBUG -> Not backing up - '/etc/dirsrv/ds.keytab' doesn't exist 2016-07-12T18:52:17Z DEBUG Starting external process 2016-07-12T18:52:17Z DEBUG args='kadmin.local' '-q' 'ktadd -k /etc/dirsrv/ds.keytab ldap/ipa03-aws.rsinc.local at RSINC.LOCAL' '-x' 'ipa-setup-override-restrictions' 2016-07-12T18:52:17Z DEBUG Process finished, return code=0 2016-07-12T18:52:17Z DEBUG stdout=Authenticating as principal root/admin at RSINC.LOCAL with password. Entry for principal ldap/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/dirsrv/ds.keytab. Entry for principal ldap/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/dirsrv/ds.keytab. Entry for principal ldap/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/dirsrv/ds.keytab. Entry for principal ldap/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/dirsrv/ds.keytab. Entry for principal ldap/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type camellia128-cts-cmac added to keytab WRFILE:/etc/dirsrv/ds.keytab. Entry for principal ldap/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type camellia256-cts-cmac added to keytab WRFILE:/etc/dirsrv/ds.keytab. 2016-07-12T18:52:17Z DEBUG stderr= 2016-07-12T18:52:17Z DEBUG duration: 0 seconds 2016-07-12T18:52:17Z DEBUG [4/8]: creating a keytab for the machine 2016-07-12T18:52:17Z DEBUG Starting external process 2016-07-12T18:52:17Z DEBUG args='kadmin.local' '-q' 'addprinc -randkey host/ipa03-aws.rsinc.local at RSINC.LOCAL' '-x' 'ipa-setup-override-restrictions' 2016-07-12T18:52:17Z DEBUG Process finished, return code=0 2016-07-12T18:52:17Z DEBUG stdout=Authenticating as principal root/admin at RSINC.LOCAL with password. Principal "host/ipa03-aws.rsinc.local at RSINC.LOCAL" created. 2016-07-12T18:52:17Z DEBUG stderr=WARNING: no policy specified for host/ipa03-aws.rsinc.local at RSINC.LOCAL; defaulting to no policy 2016-07-12T18:52:17Z DEBUG Backing up system configuration file '/etc/krb5.keytab' 2016-07-12T18:52:17Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2016-07-12T18:52:17Z DEBUG Starting external process 2016-07-12T18:52:17Z DEBUG args='kadmin.local' '-q' 'ktadd -k /etc/krb5.keytab host/ipa03-aws.rsinc.local at RSINC.LOCAL' '-x' 'ipa-setup-override-restrictions' 2016-07-12T18:52:17Z DEBUG Process finished, return code=0 2016-07-12T18:52:17Z DEBUG stdout=Authenticating as principal root/admin at RSINC.LOCAL with password. Entry for principal host/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type camellia128-cts-cmac added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/ipa03-aws.rsinc.local at RSINC.LOCAL with kvno 2, encryption type camellia256-cts-cmac added to keytab WRFILE:/etc/krb5.keytab. 2016-07-12T18:52:17Z DEBUG stderr= 2016-07-12T18:52:17Z DEBUG duration: 0 seconds 2016-07-12T18:52:17Z DEBUG [5/8]: adding the password extension to the directory 2016-07-12T18:52:17Z DEBUG Starting external process 2016-07-12T18:52:17Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpsCS1tk' '-H' 'ldapi://%2fvar%2frun%2fslapd-RSINC-LOCAL.socket' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpO1Mz2N' 2016-07-12T18:52:17Z DEBUG Process finished, return code=0 2016-07-12T18:52:17Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: ipa_pwd_extop add nsslapd-pluginpath: libipa_pwd_extop add nsslapd-plugininitfunc: ipapwd_init add nsslapd-plugintype: extendedop add nsslapd-pluginbetxn: on add nsslapd-pluginenabled: on add nsslapd-pluginid: ipa_pwd_extop add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: RedHat add nsslapd-plugindescription: Support saving passwords in multiple formats for different consumers (krb5, samba, freeradius, etc.) add nsslapd-plugin-depends-on-type: database add nsslapd-realmTree: dc=rsinc,dc=local adding new entry "cn=ipa_pwd_extop,cn=plugins,cn=config" modify complete 2016-07-12T18:52:17Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-RSINC-LOCAL.socket/??base ) 2016-07-12T18:52:17Z DEBUG duration: 0 seconds 2016-07-12T18:52:17Z DEBUG [6/8]: enable GSSAPI for replication 2016-07-12T18:52:18Z DEBUG flushing ldaps://ipa03-aws.rsinc.local:636 from SchemaCache 2016-07-12T18:52:18Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa03-aws.rsinc.local:636 conn= 2016-07-12T18:52:18Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:19Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:20Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:20Z DEBUG flushing ldaps://ipa01-aws.rsinc.local:636 from SchemaCache 2016-07-12T18:52:20Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa01-aws.rsinc.local:636 conn= 2016-07-12T18:52:22Z INFO Setting agreement cn=meToipa03-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:24Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa03-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:26Z INFO Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 0: end: 0 2016-07-12T18:52:26Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:26Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:26Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:28Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:29Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:29Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:29Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:29Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:30Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:31Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:31Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:31Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:31Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:32Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:33Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:33Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:33Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:33Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:34Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:35Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:35Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:35Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:35Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:36Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:37Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:37Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:38Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:38Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:39Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:40Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:40Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:40Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:40Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:41Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:42Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:42Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:42Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:42Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:43Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:44Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:44Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:45Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:45Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:46Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:47Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:47Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:47Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:47Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:48Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:49Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:49Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:49Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:49Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:50Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:51Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:51Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:51Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:51Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:52Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:53Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:53Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:53Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:53Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:54Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:55Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:55Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:55Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:55Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:56Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:57Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:57Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:57Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:57Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:52:58Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:52:59Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:52:59Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:52:59Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:52:59Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:00Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:01Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:01Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:02Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:02Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:03Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:04Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:04Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:05Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:05Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:06Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:07Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:07Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:07Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:07Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:08Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:09Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:09Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:09Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:09Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:10Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:11Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:11Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:11Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:11Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:12Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:13Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:13Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:13Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:13Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:14Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:15Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:15Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:15Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:15Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:16Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:17Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:17Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:17Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:17Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:18Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:19Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:19Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:19Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:19Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:20Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:21Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:21Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:22Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:22Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:23Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:24Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:24Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:24Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:24Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:25Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:26Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:26Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:26Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:26Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:27Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:28Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:28Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:29Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:29Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:30Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:31Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:31Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:31Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:31Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:32Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:33Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:33Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:33Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:33Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:34Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:35Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:35Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:36Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:36Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:37Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:38Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:38Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:38Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:38Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:39Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:40Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:40Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:41Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:41Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:42Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:43Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:43Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:43Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:43Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:44Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:45Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:45Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:45Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:45Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:46Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:47Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:47Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:47Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:47Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:48Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:49Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:49Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:49Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:49Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:50Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:51Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:51Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:52Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:52Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:53Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:54Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:54Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:54Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:54Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:55Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:56Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:56Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:57Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:57Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:53:58Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:53:59Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:53:59Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:53:59Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:53:59Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:00Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:01Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:01Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:01Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:01Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:02Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:03Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:03Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:03Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:03Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:04Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:05Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:05Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:05Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:05Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:06Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:07Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:07Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:08Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:08Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:09Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:10Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:10Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:10Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:10Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:11Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:12Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:12Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:12Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:12Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:13Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:14Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:14Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:15Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:15Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:16Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:17Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:17Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:17Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:17Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:18Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:19Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:19Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:19Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:19Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:20Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:21Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:21Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:21Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:21Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:22Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:23Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:23Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:23Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:23Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:24Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:25Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:25Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:26Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:26Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:27Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:28Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:28Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:28Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:28Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:29Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:30Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:30Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:30Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:30Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:31Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:32Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:32Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:32Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:32Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:33Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:34Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:34Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:35Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:35Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:36Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:37Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:37Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:37Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:37Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:38Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:39Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:39Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:39Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:39Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:40Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:41Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:41Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:41Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:41Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:42Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:43Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:43Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:43Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:43Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:44Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:45Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:45Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:46Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:46Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:47Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:48Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:48Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:49Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:49Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:50Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:51Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:51Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:51Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:51Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:52Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:53Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:53Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:54Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:54Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:55Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:56Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:56Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:56Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:56Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:57Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:54:58Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:54:58Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:54:58Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:54:58Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:54:59Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:00Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:00Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:00Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:00Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:01Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:02Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:02Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:02Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:02Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:03Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:04Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:04Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:04Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:04Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:05Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:06Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:06Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:07Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:07Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:08Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:09Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:09Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:09Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:09Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:10Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:11Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:11Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:11Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:11Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:12Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:13Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:13Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:13Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:13Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:14Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:15Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:15Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:15Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:15Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:16Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:17Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:17Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:17Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:17Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:18Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:19Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:19Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:19Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:19Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:20Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:21Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:21Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:21Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:21Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:23Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:24Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:24Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:24Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:24Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:25Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:26Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:26Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:26Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:26Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:27Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:28Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:28Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:28Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:28Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:29Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:30Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:30Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:30Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:30Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:31Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:32Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:32Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:32Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:32Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:33Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:34Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:34Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:35Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:35Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:36Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:37Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:37Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:37Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:37Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:38Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:39Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:39Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:39Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:39Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:40Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:41Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:41Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:41Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:41Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:42Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:44Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:44Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:44Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:44Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:45Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:46Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:46Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:46Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:46Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:47Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:48Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:48Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:49Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:49Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:50Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:51Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:51Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:51Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:51Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:52Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:53Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:53Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:53Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:53Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:54Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:55Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:55Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:55Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:55Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:56Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:57Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:57Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:57Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:57Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:55:58Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:55:59Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:55:59Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:55:59Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:55:59Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:56:00Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:56:01Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:56:01Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:56:01Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:56:01Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:56:02Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:56:03Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:56:03Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:56:04Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:56:04Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:56:05Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:56:06Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:56:06Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:56:06Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:56:06Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:56:07Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:56:08Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:56:08Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local at RSINC.LOCAL) 2016-07-12T18:56:09Z DEBUG Unable to find entry for (krbprincipalname=ldap/ipa03-aws.rsinc.local at RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-07-12T18:56:09Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-07-12T18:56:10Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-07-12T18:56:11Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-07-12T18:56:11Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 418, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 408, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/krbinstance.py", line 438, in __convert_to_gssapi_replication r_bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 1104, in convert_to_gssapi_replication self.gssapi_update_agreements(self.conn, r_conn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 797, in gssapi_update_agreements self.setup_krb_princs_as_replica_binddns(a, b) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 767, in setup_krb_princs_as_replica_binddns (a_dn, b_dn) = self.get_replica_principal_dns(a, b, retries=100) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 751, in get_replica_principal_dns raise RuntimeError(error) RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Can't acquire busy replica 2016-07-12T18:56:11Z DEBUG [error] RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Can't acquire busy replica 2016-07-12T18:56:11Z 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/ipapython/install/cli.py", line 311, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 281, in run self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 303, in execute for nothing in self._executor(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 343, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 365, in _handle_exception util.raise_exc_info(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 333, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 87, in run_generator_with_yield_from raise_exc_info(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 65, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 539, in _configure executor.next() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 343, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 365, in _handle_exception util.raise_exc_info(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 418, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 365, in _handle_exception util.raise_exc_info(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 333, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 87, in run_generator_with_yield_from raise_exc_info(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 65, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 901, in main install(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 295, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 618, in install krb = install_krb(config, setup_pkinit=not options.no_pkinit) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 93, in install_krb setup_pkinit, pkcs12_info) File "/usr/lib/python2.7/site-packages/ipaserver/install/krbinstance.py", line 214, in create_replica self.start_creation(runtime=30) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 418, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 408, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/krbinstance.py", line 438, in __convert_to_gssapi_replication r_bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 1104, in convert_to_gssapi_replication self.gssapi_update_agreements(self.conn, r_conn) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 797, in gssapi_update_agreements self.setup_krb_princs_as_replica_binddns(a, b) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 767, in setup_krb_princs_as_replica_binddns (a_dn, b_dn) = self.get_replica_principal_dns(a, b, retries=100) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 751, in get_replica_principal_dns raise RuntimeError(error) 2016-07-12T18:56:11Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Can't acquire busy replica 2016-07-12T18:56:11Z ERROR One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Can't acquire busy replica From akasurde at redhat.com Wed Jul 13 03:54:23 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 13 Jul 2016 09:24:23 +0530 Subject: [Freeipa-devel] [PATCH 0018] Minor fix in ipa-replica-manage MAN page Message-ID: Hi All, Please review patch. Fixes: https://fedorahosted.org/freeipa/ticket/6058 -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0018-Minor-fix-in-ipa-replica-manage-MAN-page.patch Type: text/x-patch Size: 1657 bytes Desc: not available URL: From slaznick at redhat.com Wed Jul 13 06:26:59 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 13 Jul 2016 08:26:59 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> Message-ID: <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: > On 07/11/2016 04:27 PM, Petr Vobornik wrote: >> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>> https://fedorahosted.org/freeipa/ticket/6046 >>> >>> >>> >> Isn't the bug about something else? >> >> The issue was that ipa-replica-install doesn't have --force-ntpd option. >> It is an option of ipa-client-install which is run from replica >> installer. >> >> The unattended mode is unrelated. > > My understanding is that the bug says that '--force-ntpd' option > should not be shown when ipa-client-install is run during replica > installation. > > During replica installation, the ipa-client-install script is run with > the '--unattended' flag in the 'ensure_enrolled()' function. Being a > separate script, there's not many options on how to pass the > information not to show the message to ipa-client-install. Using the > already used flag to get rid of the message seemed easiest to me. > Introducing a new 'hidden' flag (like '--from-replica'), on the other > hand, seems a bit harsh. > Just to throw it out there - it's possible that the '--force-join' client option would also appear as a hint from the client install script (during replica installation). Should this also be muted somehow? To me, it seems reasonable to rather add it as an argument to ipa-replica-install to pass it to the client install script. From pvoborni at redhat.com Wed Jul 13 07:51:12 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 13 Jul 2016 09:51:12 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> Message-ID: <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> On 07/13/2016 08:26 AM, Stanislav Laznicka wrote: > On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: >> On 07/11/2016 04:27 PM, Petr Vobornik wrote: >>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>>> https://fedorahosted.org/freeipa/ticket/6046 >>>> >>>> >>>> >>> Isn't the bug about something else? >>> >>> The issue was that ipa-replica-install doesn't have --force-ntpd option. >>> It is an option of ipa-client-install which is run from replica >>> installer. >>> >>> The unattended mode is unrelated. >> >> My understanding is that the bug says that '--force-ntpd' option >> should not be shown when ipa-client-install is run during replica >> installation. >> >> During replica installation, the ipa-client-install script is run with >> the '--unattended' flag in the 'ensure_enrolled()' function. Being a >> separate script, there's not many options on how to pass the >> information not to show the message to ipa-client-install. Using the >> already used flag to get rid of the message seemed easiest to me. >> Introducing a new 'hidden' flag (like '--from-replica'), on the other >> hand, seems a bit harsh. >> > Just to throw it out there - it's possible that the '--force-join' > client option would also appear as a hint from the client install script > (during replica installation). Should this also be muted somehow? To me, > it seems reasonable to rather add it as an argument to > ipa-replica-install to pass it to the client install script. > IMO client installation initiated from replica needs to have a special option(hidden in help) similar to --on-server (or what's its name). E.g. the name can be --replica-install. Maybe --on-server can be used but it may have other implication which might not be valid for this use case. Anything else are just workarounds. Imagine that admin runs ipa-client-install with --unattended or --force-join. He would then not get the message as now. -- Petr Vobornik From slaznick at redhat.com Wed Jul 13 10:36:38 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 13 Jul 2016 12:36:38 +0200 Subject: [Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install In-Reply-To: <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> References: <4975c47e-ce78-9e73-7849-f0d77909db7f@redhat.com> <2337c1e9-8d5a-8329-4e11-426b7f231839@redhat.com> <235931cd-67d6-6266-06cb-bd294395e1f3@redhat.com> Message-ID: <5af4f271-4add-ea82-2179-c9357fdac3d9@redhat.com> On 07/13/2016 09:51 AM, Petr Vobornik wrote: > On 07/13/2016 08:26 AM, Stanislav Laznicka wrote: >> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote: >>> On 07/11/2016 04:27 PM, Petr Vobornik wrote: >>>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/6046 >>>>> >>>>> >>>>> >>>> Isn't the bug about something else? >>>> >>>> The issue was that ipa-replica-install doesn't have --force-ntpd option. >>>> It is an option of ipa-client-install which is run from replica >>>> installer. >>>> >>>> The unattended mode is unrelated. >>> My understanding is that the bug says that '--force-ntpd' option >>> should not be shown when ipa-client-install is run during replica >>> installation. >>> >>> During replica installation, the ipa-client-install script is run with >>> the '--unattended' flag in the 'ensure_enrolled()' function. Being a >>> separate script, there's not many options on how to pass the >>> information not to show the message to ipa-client-install. Using the >>> already used flag to get rid of the message seemed easiest to me. >>> Introducing a new 'hidden' flag (like '--from-replica'), on the other >>> hand, seems a bit harsh. >>> >> Just to throw it out there - it's possible that the '--force-join' >> client option would also appear as a hint from the client install script >> (during replica installation). Should this also be muted somehow? To me, >> it seems reasonable to rather add it as an argument to >> ipa-replica-install to pass it to the client install script. >> > IMO client installation initiated from replica needs to have a special > option(hidden in help) similar to --on-server (or what's its name). E.g. > the name can be --replica-install. Maybe --on-server can be used but it > may have other implication which might not be valid for this use case. > > Anything else are just workarounds. Imagine that admin runs > ipa-client-install with --unattended or --force-join. He would then not > get the message as now. The --on-master option won't do here as it seems that the client would require some IPA pre-configuration for successful install. A new option will have to be created, then. As I was trying to point out, the situation about --force-join is a bit different. The option again would be shown and is not available in ipa-replica-install. I think it should be available to allow direct replica installation even when previous installation failed/left some mess on the master (ofc the user could run `ipa-replica-manage del --cleanup` on the master instead). From mbabinsk at redhat.com Wed Jul 13 11:53:23 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Jul 2016 13:53:23 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <1468333156.15769.10.camel@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> Message-ID: On 07/12/2016 04:19 PM, Simo Sorce wrote: > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: >> On 07/12/2016 02:00 PM, Martin Babinsky wrote: >>> >>> On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: >>>> >>>> On Mon, 11 Jul 2016, Martin Babinsky wrote: >>>>> >>>>> From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 >>>>> 00:00:00 2001 >>>>> From: Martin Babinsky >>>>> Date: Fri, 1 Jul 2016 18:09:04 +0200 >>>>> Subject: [PATCH] Preserve user principal aliases during rename >>>>> operation >>>>> >>>>> When a MODRDN is performed on the user entry, the MODRDN plugin >>>>> resets >>>>> both >>>>> krbPrincipalName and krbCanonicalName to the value constructed >>>>> from >>>>> uid. In >>>>> doing so, hovewer, any principal aliases added to the >>>>> krbPrincipalName >>>>> are >>>>> wiped clean. In this patch old aliases are fetched before the >>>>> MODRDN >>>>> operation >>>>> takes place and inserted back after it is performed. >>>>> >>>>> This also preserves previous user logins which can be used >>>>> further for >>>>> authentication as aliases. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6028 >>>>> --- >>>>> ipaserver/plugins/baseuser.py | 46 >>>>> +++++++++++++++++++++++++++++++++++++++++++ >>>>> 1 file changed, 46 insertions(+) >>>>> >>>>> diff --git a/ipaserver/plugins/baseuser.py >>>>> b/ipaserver/plugins/baseuser.py >>>>> index >>>>> 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815ffb2 >>>>> 452692a7edb342f6ac3 >>>>> >>>>> 100644 >>>>> --- a/ipaserver/plugins/baseuser.py >>>>> +++ b/ipaserver/plugins/baseuser.py >>>>> @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): >>>>> len = >>>>> int(config.get('ipamaxusernamelength')[0]) >>>>> ) >>>>> ) >>>>> + >>>>> + def preserve_krbprincipalname_pre(self, ldap, entry_attrs, >>>>> *keys, >>>>> **options): >>>>> + """ >>>>> + preserve user principal aliases during rename >>>>> operation. This >>>>> is the >>>>> + pre-callback part of this. Another method called >>>>> during >>>>> post-callback >>>>> + shall insert the principals back >>>>> + """ >>>>> + if options.get('rename', None) is None: >>>>> + return >>>>> + >>>>> + try: >>>>> + old_entry = ldap.get_entry( >>>>> + entry_attrs.dn, attrs_list=( >>>>> + 'krbprincipalname', 'krbcanonicalname')) >>>>> + >>>>> + if 'krbcanonicalname' not in old_entry: >>>>> + return >>>>> + except errors.NotFound: >>>>> + self.obj.handle_not_found(*keys) >>>>> + >>>>> + self.context.krbprincipalname = old_entry.get( >>>>> + 'krbprincipalname', []) >>>>> + >>>>> + def preserve_krbprincipalname_post(self, ldap, >>>>> entry_attrs, >>>>> **options): >>>>> + """ >>>>> + Insert the preserved aliases back to the user entry >>>>> during >>>>> rename >>>>> + operation >>>>> + """ >>>>> + if options.get('rename', None) is None or not hasattr( >>>>> + self.context, 'krbprincipalname'): >>>>> + return >>>>> + >>>>> + obj_pkey = >>>>> self.obj.get_primary_key_from_dn(entry_attrs.dn) >>>>> + canonical_name = entry_attrs['krbcanonicalname'][0] >>>>> + >>>>> + principals_to_add = tuple(p for p in >>>>> self.context.krbprincipalname if >>>>> + p != canonical_name) >>>>> + >>>>> + if principals_to_add: >>>>> + result = self.api.Command.user_add_principal( >>>>> + obj_pkey, principals_to_add)['result'] >>>>> + >>>>> + entry_attrs['krbprincipalname'] = >>>>> result.get('krbprincipalname', []) >>>>> + >>>>> def check_mail(self, entry_attrs): >>>>> if 'mail' in entry_attrs: >>>>> entry_attrs['mail'] = >>>>> self.obj.normalize_and_validate_email(entry_attrs['mail']) >>>>> @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): >>>>> >>>>> self.check_objectclass(ldap, dn, entry_attrs) >>>>> self.obj.convert_usercertificate_pre(entry_attrs) >>>>> + self.preserve_krbprincipalname_pre(ldap, entry_attrs, >>>>> *keys, >>>>> **options) >>>>> >>>>> def post_common_callback(self, ldap, dn, entry_attrs, >>>>> *keys, >>>>> **options): >>>>> assert isinstance(dn, DN) >>>>> + self.preserve_krbprincipalname_post(ldap, entry_attrs, >>>>> **options) >>>>> if options.get('random', False): >>>>> try: >>>>> entry_attrs['randompassword'] = >>>>> unicode(getattr(context, 'randompassword')) >>>>> -- >>>>> 2.5.5 >>>>> >>>> The approach looks good. >>>> >>>> For the record, we also support aliases for hosts and service >>>> kerberos >>>> principals but we don't support rename options for them, so there >>>> is no >>>> need to add similar logic there. >>>> >>>> >>> That's right, I have updated the corresponding section of the >>> design >>> page [1] for future reference. >>> >>> [1] >>> http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Managemen >>> t_framework >>> >>> >> Adding Simo to the loop since he is not convinced that this is the >> right >> behavior. As I see it, it seems to not be a security issue but more >> of a >> different expectations about the perceived correct behavior in this >> particular situation. >> >> I can see the use case in keeping the old aliases, e.g. keeping the >> old >> credentials after legal name change, but I can also see the >> available >> space for user principal names piling up and cluttering quickly in >> large >> organizations. > > after some thinking I think it is ok to keep by default and then drop > as it avoid races if you do really want to keep the aliases. > > However the CLI/UI should probably offer a button/switch to allow to > drop all aliases on rename, what it would do would be to modify the > entry after the rename and drop the aliases. > > I am a bit uncertain what to do by default with the "original name". > I can see it going both ways on whether to keep it by default or not. > > Simo. > So let me summarize the proposed behavior just to see if I understand it correctly: 1.) when the user is renamed, all his kerberos aliases are added back to the attribute after rename 2.) a new Flag will be added to *user-mod (e.g. --remove-aliases) which will suppress this behavior when True so that all previous aliases will be erased as is done now. The administrator will use this flag to override the default behavior in 1.) We now have the following concerns: 3.) What to do with old canonical names: The proposed patch treats old canonical names as aliases which are re-added after rename (since krbPrincipalName before rename contains the alias equal to the original canonical name anyway, we get this for free). If we implement the alias-wiping flag from 2.), we have to decide whether the old canonical name should be wiped away as well, or implement an additional logic to preserve it. 4.) What to do with users coming from pre-4.4 FreeIPA versions. These have no krbCanonicalName attribute and have only one alias = canonical name, so the code does no special handling of them and behaves as before. If we want to keep his old principal after rename, we have to implement another path which constructs krbCanonicalName attribute for him during rename and adds old principal as an alias among his krbPrincipalNames. I would say that decoupling the preservation of old canonical principals from the preservation of aliases is relatively easy to implement, but I am bit afraid that it will increase the complexity and potential fragility of the solution. -- Martin^3 Babinsky From pvoborni at redhat.com Wed Jul 13 12:37:26 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 13 Jul 2016 14:37:26 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <1468333156.15769.10.camel@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> Message-ID: <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> On 07/12/2016 04:19 PM, Simo Sorce wrote: > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: >> On 07/12/2016 02:00 PM, Martin Babinsky wrote: >>> >>> On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: >>>> >>>> On Mon, 11 Jul 2016, Martin Babinsky wrote: >>>>> >>>>> From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 >>>>> 00:00:00 2001 >>>>> From: Martin Babinsky >>>>> Date: Fri, 1 Jul 2016 18:09:04 +0200 >>>>> Subject: [PATCH] Preserve user principal aliases during rename >>>>> operation >>>>> >>>>> When a MODRDN is performed on the user entry, the MODRDN plugin >>>>> resets >>>>> both >>>>> krbPrincipalName and krbCanonicalName to the value constructed >>>>> from >>>>> uid. In >>>>> doing so, hovewer, any principal aliases added to the >>>>> krbPrincipalName >>>>> are >>>>> wiped clean. In this patch old aliases are fetched before the >>>>> MODRDN >>>>> operation >>>>> takes place and inserted back after it is performed. >>>>> >>>>> This also preserves previous user logins which can be used >>>>> further for >>>>> authentication as aliases. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6028 >>>>> --- >>>>> ipaserver/plugins/baseuser.py | 46 >>>>> +++++++++++++++++++++++++++++++++++++++++++ >>>>> 1 file changed, 46 insertions(+) >>>>> >>>>> diff --git a/ipaserver/plugins/baseuser.py >>>>> b/ipaserver/plugins/baseuser.py >>>>> index >>>>> 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815ffb2 >>>>> 452692a7edb342f6ac3 >>>>> >>>>> 100644 >>>>> --- a/ipaserver/plugins/baseuser.py >>>>> +++ b/ipaserver/plugins/baseuser.py >>>>> @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): >>>>> len = >>>>> int(config.get('ipamaxusernamelength')[0]) >>>>> ) >>>>> ) >>>>> + >>>>> + def preserve_krbprincipalname_pre(self, ldap, entry_attrs, >>>>> *keys, >>>>> **options): >>>>> + """ >>>>> + preserve user principal aliases during rename >>>>> operation. This >>>>> is the >>>>> + pre-callback part of this. Another method called >>>>> during >>>>> post-callback >>>>> + shall insert the principals back >>>>> + """ >>>>> + if options.get('rename', None) is None: >>>>> + return >>>>> + >>>>> + try: >>>>> + old_entry = ldap.get_entry( >>>>> + entry_attrs.dn, attrs_list=( >>>>> + 'krbprincipalname', 'krbcanonicalname')) >>>>> + >>>>> + if 'krbcanonicalname' not in old_entry: >>>>> + return >>>>> + except errors.NotFound: >>>>> + self.obj.handle_not_found(*keys) >>>>> + >>>>> + self.context.krbprincipalname = old_entry.get( >>>>> + 'krbprincipalname', []) >>>>> + >>>>> + def preserve_krbprincipalname_post(self, ldap, >>>>> entry_attrs, >>>>> **options): >>>>> + """ >>>>> + Insert the preserved aliases back to the user entry >>>>> during >>>>> rename >>>>> + operation >>>>> + """ >>>>> + if options.get('rename', None) is None or not hasattr( >>>>> + self.context, 'krbprincipalname'): >>>>> + return >>>>> + >>>>> + obj_pkey = >>>>> self.obj.get_primary_key_from_dn(entry_attrs.dn) >>>>> + canonical_name = entry_attrs['krbcanonicalname'][0] >>>>> + >>>>> + principals_to_add = tuple(p for p in >>>>> self.context.krbprincipalname if >>>>> + p != canonical_name) >>>>> + >>>>> + if principals_to_add: >>>>> + result = self.api.Command.user_add_principal( >>>>> + obj_pkey, principals_to_add)['result'] >>>>> + >>>>> + entry_attrs['krbprincipalname'] = >>>>> result.get('krbprincipalname', []) >>>>> + >>>>> def check_mail(self, entry_attrs): >>>>> if 'mail' in entry_attrs: >>>>> entry_attrs['mail'] = >>>>> self.obj.normalize_and_validate_email(entry_attrs['mail']) >>>>> @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): >>>>> >>>>> self.check_objectclass(ldap, dn, entry_attrs) >>>>> self.obj.convert_usercertificate_pre(entry_attrs) >>>>> + self.preserve_krbprincipalname_pre(ldap, entry_attrs, >>>>> *keys, >>>>> **options) >>>>> >>>>> def post_common_callback(self, ldap, dn, entry_attrs, >>>>> *keys, >>>>> **options): >>>>> assert isinstance(dn, DN) >>>>> + self.preserve_krbprincipalname_post(ldap, entry_attrs, >>>>> **options) >>>>> if options.get('random', False): >>>>> try: >>>>> entry_attrs['randompassword'] = >>>>> unicode(getattr(context, 'randompassword')) >>>>> -- >>>>> 2.5.5 >>>>> >>>> The approach looks good. >>>> >>>> For the record, we also support aliases for hosts and service >>>> kerberos >>>> principals but we don't support rename options for them, so there >>>> is no >>>> need to add similar logic there. >>>> >>>> >>> That's right, I have updated the corresponding section of the >>> design >>> page [1] for future reference. >>> >>> [1] >>> http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Managemen >>> t_framework >>> >>> >> Adding Simo to the loop since he is not convinced that this is the >> right >> behavior. As I see it, it seems to not be a security issue but more >> of a >> different expectations about the perceived correct behavior in this >> particular situation. >> >> I can see the use case in keeping the old aliases, e.g. keeping the >> old >> credentials after legal name change, but I can also see the >> available >> space for user principal names piling up and cluttering quickly in >> large >> organizations. > > after some thinking I think it is ok to keep by default and then drop > as it avoid races if you do really want to keep the aliases. > > However the CLI/UI should probably offer a button/switch to allow to > drop all aliases on rename, what it would do would be to modify the > entry after the rename and drop the aliases. > > I am a bit uncertain what to do by default with the "original name". > I can see it going both ways on whether to keep it by default or not. Ideally we would have e.g. ipa user-rename oldCN --remove-aliases which would drop everything including oldCN (I would expect that). Unfortunately we have --rename in mod command ipa user-mod oldCN --rename newCn --remove-aliases And there --remove-aliases might not be the best thing. Do we want to support also: ipa user-mod CN --remove-aliases ? > > Simo. > -- Petr Vobornik From simo at redhat.com Wed Jul 13 12:39:56 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Jul 2016 08:39:56 -0400 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> Message-ID: <1468413596.15769.52.camel@redhat.com> On Wed, 2016-07-13 at 13:53 +0200, Martin Babinsky wrote: > On 07/12/2016 04:19 PM, Simo Sorce wrote: > > > > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: > > > > > > On 07/12/2016 02:00 PM, Martin Babinsky wrote: > > > > > > > > > > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: > > > > > > > > > > > > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote: > > > > > > > > > > > > > > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 > > > > > > 00:00:00 2001 > > > > > > From: Martin Babinsky > > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200 > > > > > > Subject: [PATCH] Preserve user principal aliases during > > > > > > rename > > > > > > operation > > > > > > > > > > > > When a MODRDN is performed on the user entry, the MODRDN > > > > > > plugin > > > > > > resets > > > > > > both > > > > > > krbPrincipalName and krbCanonicalName to the value > > > > > > constructed > > > > > > from > > > > > > uid. In > > > > > > doing so, hovewer, any principal aliases added to the > > > > > > krbPrincipalName > > > > > > are > > > > > > wiped clean. In this patch old aliases are fetched before > > > > > > the > > > > > > MODRDN > > > > > > operation > > > > > > takes place and inserted back after it is performed. > > > > > > > > > > > > This also preserves previous user logins which can be used > > > > > > further for > > > > > > authentication as aliases. > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6028 > > > > > > --- > > > > > > ipaserver/plugins/baseuser.py | 46 > > > > > > +++++++++++++++++++++++++++++++++++++++++++ > > > > > > 1 file changed, 46 insertions(+) > > > > > > > > > > > > diff --git a/ipaserver/plugins/baseuser.py > > > > > > b/ipaserver/plugins/baseuser.py > > > > > > index > > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815 > > > > > > ffb2 > > > > > > 452692a7edb342f6ac3 > > > > > > > > > > > > 100644 > > > > > > --- a/ipaserver/plugins/baseuser.py > > > > > > +++ b/ipaserver/plugins/baseuser.py > > > > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): > > > > > > ????????????????????????????len = > > > > > > int(config.get('ipamaxusernamelength')[0]) > > > > > > ????????????????????????) > > > > > > ????????????????????) > > > > > > + > > > > > > +????def preserve_krbprincipalname_pre(self, ldap, > > > > > > entry_attrs, > > > > > > *keys, > > > > > > **options): > > > > > > +????????""" > > > > > > +????????preserve user principal aliases during rename > > > > > > operation. This > > > > > > is the > > > > > > +????????pre-callback part of this. Another method called > > > > > > during > > > > > > post-callback > > > > > > +????????shall insert the principals back > > > > > > +????????""" > > > > > > +????????if options.get('rename', None) is None: > > > > > > +????????????return > > > > > > + > > > > > > +????????try: > > > > > > +????????????old_entry = ldap.get_entry( > > > > > > +????????????????entry_attrs.dn, attrs_list=( > > > > > > +????????????????????'krbprincipalname', > > > > > > 'krbcanonicalname')) > > > > > > + > > > > > > +????????????if 'krbcanonicalname' not in old_entry: > > > > > > +????????????????return > > > > > > +????????except errors.NotFound: > > > > > > +????????????self.obj.handle_not_found(*keys) > > > > > > + > > > > > > +????????self.context.krbprincipalname = old_entry.get( > > > > > > +????????????'krbprincipalname', []) > > > > > > + > > > > > > +????def preserve_krbprincipalname_post(self, ldap, > > > > > > entry_attrs, > > > > > > **options): > > > > > > +????????""" > > > > > > +????????Insert the preserved aliases back to the user > > > > > > entry > > > > > > during > > > > > > rename > > > > > > +????????operation > > > > > > +????????""" > > > > > > +????????if options.get('rename', None) is None or not > > > > > > hasattr( > > > > > > +????????????????self.context, 'krbprincipalname'): > > > > > > +????????????return > > > > > > + > > > > > > +????????obj_pkey = > > > > > > self.obj.get_primary_key_from_dn(entry_attrs.dn) > > > > > > +????????canonical_name = > > > > > > entry_attrs['krbcanonicalname'][0] > > > > > > + > > > > > > +????????principals_to_add = tuple(p for p in > > > > > > self.context.krbprincipalname if > > > > > > +??????????????????????????????????p != canonical_name) > > > > > > + > > > > > > +????????if principals_to_add: > > > > > > +????????????result = self.api.Command.user_add_principal( > > > > > > +????????????????obj_pkey, principals_to_add)['result'] > > > > > > + > > > > > > +????????????entry_attrs['krbprincipalname'] = > > > > > > result.get('krbprincipalname', []) > > > > > > + > > > > > > ????def check_mail(self, entry_attrs): > > > > > > ????????if 'mail' in entry_attrs: > > > > > > ????????????entry_attrs['mail'] = > > > > > > self.obj.normalize_and_validate_email(entry_attrs['mail']) > > > > > > @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): > > > > > > > > > > > > ????????self.check_objectclass(ldap, dn, entry_attrs) > > > > > > ????????self.obj.convert_usercertificate_pre(entry_attrs) > > > > > > +????????self.preserve_krbprincipalname_pre(ldap, > > > > > > entry_attrs, > > > > > > *keys, > > > > > > **options) > > > > > > > > > > > > ????def post_common_callback(self, ldap, dn, entry_attrs, > > > > > > *keys, > > > > > > **options): > > > > > > ????????assert isinstance(dn, DN) > > > > > > +????????self.preserve_krbprincipalname_post(ldap, > > > > > > entry_attrs, > > > > > > **options) > > > > > > ????????if options.get('random', False): > > > > > > ????????????try: > > > > > > ????????????????entry_attrs['randompassword'] = > > > > > > unicode(getattr(context, 'randompassword')) > > > > > > -- > > > > > > 2.5.5 > > > > > > > > > > > The approach looks good. > > > > > > > > > > For the record, we also support aliases for hosts and service > > > > > kerberos > > > > > principals but we don't support rename options for them, so > > > > > there > > > > > is no > > > > > need to add similar logic there. > > > > > > > > > > > > > > That's right, I have updated the corresponding section of the > > > > design > > > > page [1] for future reference. > > > > > > > > [1] > > > > http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Manag > > > > emen > > > > t_framework > > > > > > > > > > > Adding Simo to the loop since he is not convinced that this is > > > the > > > right > > > behavior. As I see it, it seems to not be a security issue but > > > more > > > of a > > > different expectations about the perceived correct behavior in > > > this > > > particular situation. > > > > > > I can see the use case in keeping the old aliases, e.g. keeping > > > the > > > old > > > credentials after legal name change, but I can also see the > > > available > > > space for user principal names piling up and cluttering quickly > > > in > > > large > > > organizations. > > after some thinking I think it is ok to keep by default and then > > drop > > as it avoid races if you do really want to keep the aliases. > > > > However the CLI/UI should probably offer a button/switch to allow > > to > > drop all aliases on rename, what it would do would be to modify the > > entry after the rename and drop the aliases. > > > > I am a bit uncertain what to do by default with the "original > > name". > > I can see it going both ways on whether to keep it by default or > > not. > > > > Simo. > > > So let me summarize the proposed behavior just to see if I understand > it? > correctly: > > 1.) when the user is renamed, all his kerberos aliases are added back > to? > the attribute after rename > > 2.) a new Flag will be added to *user-mod (e.g. --remove-aliases) > which? > will suppress this behavior when True so that all previous aliases > will? > be erased as is done now. The administrator will use this flag to? > override the default behavior in 1.) > > We now have the following concerns: > > 3.) What to do with old canonical names: > > The proposed patch treats old canonical names as aliases which are? > re-added after rename (since krbPrincipalName before rename contains > the? > alias equal to the original canonical name anyway, we get this for? > free). If we implement the alias-wiping flag from 2.), we have to > decide? > whether the old canonical name should be wiped away as well, or? > implement an additional logic to preserve it. > > 4.) What to do with users coming from pre-4.4 FreeIPA versions. > These? > have no krbCanonicalName attribute and have only one alias = > canonical? > name, so the code does no special handling of them and behaves as? > before. If we want to keep his old principal after rename, we have > to? > implement another path which constructs krbCanonicalName attribute > for? > him during rename and adds old principal as an alias among his? > krbPrincipalNames. > > I would say that decoupling the preservation of old canonical > principals? > from the preservation of aliases is relatively easy to implement, but > I? > am bit afraid that it will increase the complexity and potential? > fragility of the solution. I have your same concerns in general, but the behavior change ? I am concerned is the default preservation of the previous name. The current code does not preserve anything, if you rename the old name is gone. Do we think someone may depend on this behavior today ? Aliases are less of a concern because they are new and introduced in this version, so what behavior they'll have on rename is something we can decide now. The additional consideration is that on rename, with thye current patch, a user gain an alias, what do we do if --remove-aliases=True is set ? Simo. From simo at redhat.com Wed Jul 13 13:08:52 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Jul 2016 09:08:52 -0400 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> Message-ID: <1468415332.15769.59.camel@redhat.com> On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote: > On 07/12/2016 04:19 PM, Simo Sorce wrote: > > > > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: > > > > > > On 07/12/2016 02:00 PM, Martin Babinsky wrote: > > > > > > > > > > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: > > > > > > > > > > > > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote: > > > > > > > > > > > > > > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 > > > > > > 00:00:00 2001 > > > > > > From: Martin Babinsky > > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200 > > > > > > Subject: [PATCH] Preserve user principal aliases during > > > > > > rename > > > > > > operation > > > > > > > > > > > > When a MODRDN is performed on the user entry, the MODRDN > > > > > > plugin > > > > > > resets > > > > > > both > > > > > > krbPrincipalName and krbCanonicalName to the value > > > > > > constructed > > > > > > from > > > > > > uid. In > > > > > > doing so, hovewer, any principal aliases added to the > > > > > > krbPrincipalName > > > > > > are > > > > > > wiped clean. In this patch old aliases are fetched before > > > > > > the > > > > > > MODRDN > > > > > > operation > > > > > > takes place and inserted back after it is performed. > > > > > > > > > > > > This also preserves previous user logins which can be used > > > > > > further for > > > > > > authentication as aliases. > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6028 > > > > > > --- > > > > > > ipaserver/plugins/baseuser.py | 46 > > > > > > +++++++++++++++++++++++++++++++++++++++++++ > > > > > > 1 file changed, 46 insertions(+) > > > > > > > > > > > > diff --git a/ipaserver/plugins/baseuser.py > > > > > > b/ipaserver/plugins/baseuser.py > > > > > > index > > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815 > > > > > > ffb2 > > > > > > 452692a7edb342f6ac3 > > > > > > > > > > > > 100644 > > > > > > --- a/ipaserver/plugins/baseuser.py > > > > > > +++ b/ipaserver/plugins/baseuser.py > > > > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): > > > > > > ????????????????????????????len = > > > > > > int(config.get('ipamaxusernamelength')[0]) > > > > > > ????????????????????????) > > > > > > ????????????????????) > > > > > > + > > > > > > +????def preserve_krbprincipalname_pre(self, ldap, > > > > > > entry_attrs, > > > > > > *keys, > > > > > > **options): > > > > > > +????????""" > > > > > > +????????preserve user principal aliases during rename > > > > > > operation. This > > > > > > is the > > > > > > +????????pre-callback part of this. Another method called > > > > > > during > > > > > > post-callback > > > > > > +????????shall insert the principals back > > > > > > +????????""" > > > > > > +????????if options.get('rename', None) is None: > > > > > > +????????????return > > > > > > + > > > > > > +????????try: > > > > > > +????????????old_entry = ldap.get_entry( > > > > > > +????????????????entry_attrs.dn, attrs_list=( > > > > > > +????????????????????'krbprincipalname', > > > > > > 'krbcanonicalname')) > > > > > > + > > > > > > +????????????if 'krbcanonicalname' not in old_entry: > > > > > > +????????????????return > > > > > > +????????except errors.NotFound: > > > > > > +????????????self.obj.handle_not_found(*keys) > > > > > > + > > > > > > +????????self.context.krbprincipalname = old_entry.get( > > > > > > +????????????'krbprincipalname', []) > > > > > > + > > > > > > +????def preserve_krbprincipalname_post(self, ldap, > > > > > > entry_attrs, > > > > > > **options): > > > > > > +????????""" > > > > > > +????????Insert the preserved aliases back to the user > > > > > > entry > > > > > > during > > > > > > rename > > > > > > +????????operation > > > > > > +????????""" > > > > > > +????????if options.get('rename', None) is None or not > > > > > > hasattr( > > > > > > +????????????????self.context, 'krbprincipalname'): > > > > > > +????????????return > > > > > > + > > > > > > +????????obj_pkey = > > > > > > self.obj.get_primary_key_from_dn(entry_attrs.dn) > > > > > > +????????canonical_name = > > > > > > entry_attrs['krbcanonicalname'][0] > > > > > > + > > > > > > +????????principals_to_add = tuple(p for p in > > > > > > self.context.krbprincipalname if > > > > > > +??????????????????????????????????p != canonical_name) > > > > > > + > > > > > > +????????if principals_to_add: > > > > > > +????????????result = self.api.Command.user_add_principal( > > > > > > +????????????????obj_pkey, principals_to_add)['result'] > > > > > > + > > > > > > +????????????entry_attrs['krbprincipalname'] = > > > > > > result.get('krbprincipalname', []) > > > > > > + > > > > > > ????def check_mail(self, entry_attrs): > > > > > > ????????if 'mail' in entry_attrs: > > > > > > ????????????entry_attrs['mail'] = > > > > > > self.obj.normalize_and_validate_email(entry_attrs['mail']) > > > > > > @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): > > > > > > > > > > > > ????????self.check_objectclass(ldap, dn, entry_attrs) > > > > > > ????????self.obj.convert_usercertificate_pre(entry_attrs) > > > > > > +????????self.preserve_krbprincipalname_pre(ldap, > > > > > > entry_attrs, > > > > > > *keys, > > > > > > **options) > > > > > > > > > > > > ????def post_common_callback(self, ldap, dn, entry_attrs, > > > > > > *keys, > > > > > > **options): > > > > > > ????????assert isinstance(dn, DN) > > > > > > +????????self.preserve_krbprincipalname_post(ldap, > > > > > > entry_attrs, > > > > > > **options) > > > > > > ????????if options.get('random', False): > > > > > > ????????????try: > > > > > > ????????????????entry_attrs['randompassword'] = > > > > > > unicode(getattr(context, 'randompassword')) > > > > > > -- > > > > > > 2.5.5 > > > > > > > > > > > The approach looks good. > > > > > > > > > > For the record, we also support aliases for hosts and service > > > > > kerberos > > > > > principals but we don't support rename options for them, so > > > > > there > > > > > is no > > > > > need to add similar logic there. > > > > > > > > > > > > > > That's right, I have updated the corresponding section of the > > > > design > > > > page [1] for future reference. > > > > > > > > [1] > > > > http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Manag > > > > emen > > > > t_framework > > > > > > > > > > > Adding Simo to the loop since he is not convinced that this is > > > the > > > right? > > > behavior. As I see it, it seems to not be a security issue but > > > more > > > of a? > > > different expectations about the perceived correct behavior in > > > this? > > > particular situation. > > > > > > I can see the use case in keeping the old aliases, e.g. keeping > > > the > > > old? > > > credentials after legal name change, but I can also see the > > > available? > > > space for user principal names piling up and cluttering quickly > > > in > > > large? > > > organizations. > > after some thinking I think it is ok to keep by default and then > > drop > > as it avoid races if you do really want to keep the aliases. > > > > However the CLI/UI should probably offer a button/switch to allow > > to > > drop all aliases on rename, what it would do would be to modify the > > entry after the rename and drop the aliases. > > > > I am a bit uncertain what to do by default with the "original > > name". > > I can see it going both ways on whether to keep it by default or > > not. > Ideally we would have e.g. > > ?ipa user-rename oldCN --remove-aliases > > which would drop everything including oldCN (I would expect that). I lean toward this conclusion too given that a later "--remove-alias" would drop it, and we want to behave consistently. > Unfortunately we have --rename in mod command > ?ipa user-mod oldCN --rename newCn --remove-aliases > > And there --remove-aliases might not be the best thing. Why not ? > Do we want to support also: > ? ipa user-mod CN --remove-aliases Yes we probably want to give the option to drop aliases if an admin realizes he should have done it at rename time but didn't. Simo. From ldoudova at redhat.com Wed Jul 13 13:21:25 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 13 Jul 2016 15:21:25 +0200 Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember tests in 4.3 Message-ID: <4237887a-917f-4fb2-0a7c-1eeb79ee6996@redhat.com> Hi, providing patch to fix two failing automember tests in 4.3 branch. The reason of the failure was the output normalization (specifically manager attribute for user). The patch is intended for ipa-4-3 branch only. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0027-Tests-Fix-failing-automember-tests.patch Type: text/x-patch Size: 1656 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Jul 13 14:19:16 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Jul 2016 16:19:16 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <1468415332.15769.59.camel@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> <1468415332.15769.59.camel@redhat.com> Message-ID: On 07/13/2016 03:08 PM, Simo Sorce wrote: > On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote: >> On 07/12/2016 04:19 PM, Simo Sorce wrote: >>> >>> On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: >>>> >>>> On 07/12/2016 02:00 PM, Martin Babinsky wrote: >>>>> >>>>> >>>>> On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: >>>>>> >>>>>> >>>>>> On Mon, 11 Jul 2016, Martin Babinsky wrote: >>>>>>> >>>>>>> >>>>>>> From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17 >>>>>>> 00:00:00 2001 >>>>>>> From: Martin Babinsky >>>>>>> Date: Fri, 1 Jul 2016 18:09:04 +0200 >>>>>>> Subject: [PATCH] Preserve user principal aliases during >>>>>>> rename >>>>>>> operation >>>>>>> >>>>>>> When a MODRDN is performed on the user entry, the MODRDN >>>>>>> plugin >>>>>>> resets >>>>>>> both >>>>>>> krbPrincipalName and krbCanonicalName to the value >>>>>>> constructed >>>>>>> from >>>>>>> uid. In >>>>>>> doing so, hovewer, any principal aliases added to the >>>>>>> krbPrincipalName >>>>>>> are >>>>>>> wiped clean. In this patch old aliases are fetched before >>>>>>> the >>>>>>> MODRDN >>>>>>> operation >>>>>>> takes place and inserted back after it is performed. >>>>>>> >>>>>>> This also preserves previous user logins which can be used >>>>>>> further for >>>>>>> authentication as aliases. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6028 >>>>>>> --- >>>>>>> ipaserver/plugins/baseuser.py | 46 >>>>>>> +++++++++++++++++++++++++++++++++++++++++++ >>>>>>> 1 file changed, 46 insertions(+) >>>>>>> >>>>>>> diff --git a/ipaserver/plugins/baseuser.py >>>>>>> b/ipaserver/plugins/baseuser.py >>>>>>> index >>>>>>> 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815 >>>>>>> ffb2 >>>>>>> 452692a7edb342f6ac3 >>>>>>> >>>>>>> 100644 >>>>>>> --- a/ipaserver/plugins/baseuser.py >>>>>>> +++ b/ipaserver/plugins/baseuser.py >>>>>>> @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): >>>>>>> len = >>>>>>> int(config.get('ipamaxusernamelength')[0]) >>>>>>> ) >>>>>>> ) >>>>>>> + >>>>>>> + def preserve_krbprincipalname_pre(self, ldap, >>>>>>> entry_attrs, >>>>>>> *keys, >>>>>>> **options): >>>>>>> + """ >>>>>>> + preserve user principal aliases during rename >>>>>>> operation. This >>>>>>> is the >>>>>>> + pre-callback part of this. Another method called >>>>>>> during >>>>>>> post-callback >>>>>>> + shall insert the principals back >>>>>>> + """ >>>>>>> + if options.get('rename', None) is None: >>>>>>> + return >>>>>>> + >>>>>>> + try: >>>>>>> + old_entry = ldap.get_entry( >>>>>>> + entry_attrs.dn, attrs_list=( >>>>>>> + 'krbprincipalname', >>>>>>> 'krbcanonicalname')) >>>>>>> + >>>>>>> + if 'krbcanonicalname' not in old_entry: >>>>>>> + return >>>>>>> + except errors.NotFound: >>>>>>> + self.obj.handle_not_found(*keys) >>>>>>> + >>>>>>> + self.context.krbprincipalname = old_entry.get( >>>>>>> + 'krbprincipalname', []) >>>>>>> + >>>>>>> + def preserve_krbprincipalname_post(self, ldap, >>>>>>> entry_attrs, >>>>>>> **options): >>>>>>> + """ >>>>>>> + Insert the preserved aliases back to the user >>>>>>> entry >>>>>>> during >>>>>>> rename >>>>>>> + operation >>>>>>> + """ >>>>>>> + if options.get('rename', None) is None or not >>>>>>> hasattr( >>>>>>> + self.context, 'krbprincipalname'): >>>>>>> + return >>>>>>> + >>>>>>> + obj_pkey = >>>>>>> self.obj.get_primary_key_from_dn(entry_attrs.dn) >>>>>>> + canonical_name = >>>>>>> entry_attrs['krbcanonicalname'][0] >>>>>>> + >>>>>>> + principals_to_add = tuple(p for p in >>>>>>> self.context.krbprincipalname if >>>>>>> + p != canonical_name) >>>>>>> + >>>>>>> + if principals_to_add: >>>>>>> + result = self.api.Command.user_add_principal( >>>>>>> + obj_pkey, principals_to_add)['result'] >>>>>>> + >>>>>>> + entry_attrs['krbprincipalname'] = >>>>>>> result.get('krbprincipalname', []) >>>>>>> + >>>>>>> def check_mail(self, entry_attrs): >>>>>>> if 'mail' in entry_attrs: >>>>>>> entry_attrs['mail'] = >>>>>>> self.obj.normalize_and_validate_email(entry_attrs['mail']) >>>>>>> @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): >>>>>>> >>>>>>> self.check_objectclass(ldap, dn, entry_attrs) >>>>>>> self.obj.convert_usercertificate_pre(entry_attrs) >>>>>>> + self.preserve_krbprincipalname_pre(ldap, >>>>>>> entry_attrs, >>>>>>> *keys, >>>>>>> **options) >>>>>>> >>>>>>> def post_common_callback(self, ldap, dn, entry_attrs, >>>>>>> *keys, >>>>>>> **options): >>>>>>> assert isinstance(dn, DN) >>>>>>> + self.preserve_krbprincipalname_post(ldap, >>>>>>> entry_attrs, >>>>>>> **options) >>>>>>> if options.get('random', False): >>>>>>> try: >>>>>>> entry_attrs['randompassword'] = >>>>>>> unicode(getattr(context, 'randompassword')) >>>>>>> -- >>>>>>> 2.5.5 >>>>>>> >>>>>> The approach looks good. >>>>>> >>>>>> For the record, we also support aliases for hosts and service >>>>>> kerberos >>>>>> principals but we don't support rename options for them, so >>>>>> there >>>>>> is no >>>>>> need to add similar logic there. >>>>>> >>>>>> >>>>> That's right, I have updated the corresponding section of the >>>>> design >>>>> page [1] for future reference. >>>>> >>>>> [1] >>>>> http://www.freeipa.org/page/V4/Kerberos_principal_aliases#Manag >>>>> emen >>>>> t_framework >>>>> >>>>> >>>> Adding Simo to the loop since he is not convinced that this is >>>> the >>>> right >>>> behavior. As I see it, it seems to not be a security issue but >>>> more >>>> of a >>>> different expectations about the perceived correct behavior in >>>> this >>>> particular situation. >>>> >>>> I can see the use case in keeping the old aliases, e.g. keeping >>>> the >>>> old >>>> credentials after legal name change, but I can also see the >>>> available >>>> space for user principal names piling up and cluttering quickly >>>> in >>>> large >>>> organizations. >>> after some thinking I think it is ok to keep by default and then >>> drop >>> as it avoid races if you do really want to keep the aliases. >>> >>> However the CLI/UI should probably offer a button/switch to allow >>> to >>> drop all aliases on rename, what it would do would be to modify the >>> entry after the rename and drop the aliases. >>> >>> I am a bit uncertain what to do by default with the "original >>> name". >>> I can see it going both ways on whether to keep it by default or >>> not. >> Ideally we would have e.g. >> >> ipa user-rename oldCN --remove-aliases >> >> which would drop everything including oldCN (I would expect that). > > I lean toward this conclusion too given that a later "--remove-alias" > would drop it, and we want to behave consistently. > Makes sense to me, too. >> Unfortunately we have --rename in mod command >> ipa user-mod oldCN --rename newCn --remove-aliases >> >> And there --remove-aliases might not be the best thing. > > Why not ? > >> Do we want to support also: >> ipa user-mod CN --remove-aliases > > Yes we probably want to give the option to drop aliases if an admin > realizes he should have done it at rename time but didn't. > > Simo. > In that case he can still use `user-remove-principal` to manually remove them. -- Martin^3 Babinsky From simo at redhat.com Wed Jul 13 14:28:15 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Jul 2016 10:28:15 -0400 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> <1468415332.15769.59.camel@redhat.com> Message-ID: <1468420095.15769.65.camel@redhat.com> On Wed, 2016-07-13 at 16:19 +0200, Martin Babinsky wrote: > On 07/13/2016 03:08 PM, Simo Sorce wrote: > > > > On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote: > > > > > > On 07/12/2016 04:19 PM, Simo Sorce wrote: > > > > > > > > > > > > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: > > > > > > > > > > > > > > > On 07/12/2016 02:00 PM, Martin Babinsky wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep > > > > > > > > 17 > > > > > > > > 00:00:00 2001 > > > > > > > > From: Martin Babinsky > > > > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200 > > > > > > > > Subject: [PATCH] Preserve user principal aliases during > > > > > > > > rename > > > > > > > > operation > > > > > > > > > > > > > > > > When a MODRDN is performed on the user entry, the > > > > > > > > MODRDN > > > > > > > > plugin > > > > > > > > resets > > > > > > > > both > > > > > > > > krbPrincipalName and krbCanonicalName to the value > > > > > > > > constructed > > > > > > > > from > > > > > > > > uid. In > > > > > > > > doing so, hovewer, any principal aliases added to the > > > > > > > > krbPrincipalName > > > > > > > > are > > > > > > > > wiped clean. In this patch old aliases are fetched > > > > > > > > before > > > > > > > > the > > > > > > > > MODRDN > > > > > > > > operation > > > > > > > > takes place and inserted back after it is performed. > > > > > > > > > > > > > > > > This also preserves previous user logins which can be > > > > > > > > used > > > > > > > > further for > > > > > > > > authentication as aliases. > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6028 > > > > > > > > --- > > > > > > > > ipaserver/plugins/baseuser.py | 46 > > > > > > > > +++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > 1 file changed, 46 insertions(+) > > > > > > > > > > > > > > > > diff --git a/ipaserver/plugins/baseuser.py > > > > > > > > b/ipaserver/plugins/baseuser.py > > > > > > > > index > > > > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a13115 > > > > > > > > 7815 > > > > > > > > ffb2 > > > > > > > > 452692a7edb342f6ac3 > > > > > > > > > > > > > > > > 100644 > > > > > > > > --- a/ipaserver/plugins/baseuser.py > > > > > > > > +++ b/ipaserver/plugins/baseuser.py > > > > > > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): > > > > > > > > ????????????????????????????len = > > > > > > > > int(config.get('ipamaxusernamelength')[0]) > > > > > > > > ????????????????????????) > > > > > > > > ????????????????????) > > > > > > > > + > > > > > > > > +????def preserve_krbprincipalname_pre(self, ldap, > > > > > > > > entry_attrs, > > > > > > > > *keys, > > > > > > > > **options): > > > > > > > > +????????""" > > > > > > > > +????????preserve user principal aliases during rename > > > > > > > > operation. This > > > > > > > > is the > > > > > > > > +????????pre-callback part of this. Another method > > > > > > > > called > > > > > > > > during > > > > > > > > post-callback > > > > > > > > +????????shall insert the principals back > > > > > > > > +????????""" > > > > > > > > +????????if options.get('rename', None) is None: > > > > > > > > +????????????return > > > > > > > > + > > > > > > > > +????????try: > > > > > > > > +????????????old_entry = ldap.get_entry( > > > > > > > > +????????????????entry_attrs.dn, attrs_list=( > > > > > > > > +????????????????????'krbprincipalname', > > > > > > > > 'krbcanonicalname')) > > > > > > > > + > > > > > > > > +????????????if 'krbcanonicalname' not in old_entry: > > > > > > > > +????????????????return > > > > > > > > +????????except errors.NotFound: > > > > > > > > +????????????self.obj.handle_not_found(*keys) > > > > > > > > + > > > > > > > > +????????self.context.krbprincipalname = old_entry.get( > > > > > > > > +????????????'krbprincipalname', []) > > > > > > > > + > > > > > > > > +????def preserve_krbprincipalname_post(self, ldap, > > > > > > > > entry_attrs, > > > > > > > > **options): > > > > > > > > +????????""" > > > > > > > > +????????Insert the preserved aliases back to the user > > > > > > > > entry > > > > > > > > during > > > > > > > > rename > > > > > > > > +????????operation > > > > > > > > +????????""" > > > > > > > > +????????if options.get('rename', None) is None or not > > > > > > > > hasattr( > > > > > > > > +????????????????self.context, 'krbprincipalname'): > > > > > > > > +????????????return > > > > > > > > + > > > > > > > > +????????obj_pkey = > > > > > > > > self.obj.get_primary_key_from_dn(entry_attrs.dn) > > > > > > > > +????????canonical_name = > > > > > > > > entry_attrs['krbcanonicalname'][0] > > > > > > > > + > > > > > > > > +????????principals_to_add = tuple(p for p in > > > > > > > > self.context.krbprincipalname if > > > > > > > > +??????????????????????????????????p != canonical_name) > > > > > > > > + > > > > > > > > +????????if principals_to_add: > > > > > > > > +????????????result = > > > > > > > > self.api.Command.user_add_principal( > > > > > > > > +????????????????obj_pkey, principals_to_add)['result'] > > > > > > > > + > > > > > > > > +????????????entry_attrs['krbprincipalname'] = > > > > > > > > result.get('krbprincipalname', []) > > > > > > > > + > > > > > > > > ????def check_mail(self, entry_attrs): > > > > > > > > ????????if 'mail' in entry_attrs: > > > > > > > > ????????????entry_attrs['mail'] = > > > > > > > > self.obj.normalize_and_validate_email(entry_attrs['mail > > > > > > > > ']) > > > > > > > > @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): > > > > > > > > > > > > > > > > ????????self.check_objectclass(ldap, dn, entry_attrs) > > > > > > > > ????????self.obj.convert_usercertificate_pre(entry_attr > > > > > > > > s) > > > > > > > > +????????self.preserve_krbprincipalname_pre(ldap, > > > > > > > > entry_attrs, > > > > > > > > *keys, > > > > > > > > **options) > > > > > > > > > > > > > > > > ????def post_common_callback(self, ldap, dn, > > > > > > > > entry_attrs, > > > > > > > > *keys, > > > > > > > > **options): > > > > > > > > ????????assert isinstance(dn, DN) > > > > > > > > +????????self.preserve_krbprincipalname_post(ldap, > > > > > > > > entry_attrs, > > > > > > > > **options) > > > > > > > > ????????if options.get('random', False): > > > > > > > > ????????????try: > > > > > > > > ????????????????entry_attrs['randompassword'] = > > > > > > > > unicode(getattr(context, 'randompassword')) > > > > > > > > -- > > > > > > > > 2.5.5 > > > > > > > > > > > > > > > The approach looks good. > > > > > > > > > > > > > > For the record, we also support aliases for hosts and > > > > > > > service > > > > > > > kerberos > > > > > > > principals but we don't support rename options for them, > > > > > > > so > > > > > > > there > > > > > > > is no > > > > > > > need to add similar logic there. > > > > > > > > > > > > > > > > > > > > That's right, I have updated the corresponding section of > > > > > > the > > > > > > design > > > > > > page [1] for future reference. > > > > > > > > > > > > [1] > > > > > > http://www.freeipa.org/page/V4/Kerberos_principal_aliases#M > > > > > > anag > > > > > > emen > > > > > > t_framework > > > > > > > > > > > > > > > > > Adding Simo to the loop since he is not convinced that this > > > > > is > > > > > the > > > > > right > > > > > behavior. As I see it, it seems to not be a security issue > > > > > but > > > > > more > > > > > of a > > > > > different expectations about the perceived correct behavior > > > > > in > > > > > this > > > > > particular situation. > > > > > > > > > > I can see the use case in keeping the old aliases, e.g. > > > > > keeping > > > > > the > > > > > old > > > > > credentials after legal name change, but I can also see the > > > > > available > > > > > space for user principal names piling up and cluttering > > > > > quickly > > > > > in > > > > > large > > > > > organizations. > > > > after some thinking I think it is ok to keep by default and > > > > then > > > > drop > > > > as it avoid races if you do really want to keep the aliases. > > > > > > > > However the CLI/UI should probably offer a button/switch to > > > > allow > > > > to > > > > drop all aliases on rename, what it would do would be to modify > > > > the > > > > entry after the rename and drop the aliases. > > > > > > > > I am a bit uncertain what to do by default with the "original > > > > name". > > > > I can see it going both ways on whether to keep it by default > > > > or > > > > not. > > > Ideally we would have e.g. > > > > > > ?ipa user-rename oldCN --remove-aliases > > > > > > which would drop everything including oldCN (I would expect > > > that). > > I lean toward this conclusion too given that a later "--remove- > > alias" > > would drop it, and we want to behave consistently. > > > Makes sense to me, too. > > > > > > > > > Unfortunately we have --rename in mod command > > > ?ipa user-mod oldCN --rename newCn --remove-aliases > > > > > > And there --remove-aliases might not be the best thing. > > Why not ? > > > > > > > > Do we want to support also: > > > ? ipa user-mod CN --remove-aliases > > Yes we probably want to give the option to drop aliases if an admin > > realizes he should have done it at rename time but didn't. > > > > Simo. > > > In that case he can still use `user-remove-principal` to manually > remove ?them. True. Should we then not have --remove-aliases at all, and always force the admin to manually cleanup ? Simo. From mbabinsk at redhat.com Wed Jul 13 14:35:30 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Jul 2016 16:35:30 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <1468420095.15769.65.camel@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> <1468415332.15769.59.camel@redhat.com> <1468420095.15769.65.camel@redhat.com> Message-ID: On 07/13/2016 04:28 PM, Simo Sorce wrote: > On Wed, 2016-07-13 at 16:19 +0200, Martin Babinsky wrote: >> On 07/13/2016 03:08 PM, Simo Sorce wrote: >>> >>> On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote: >>>> >>>> On 07/12/2016 04:19 PM, Simo Sorce wrote: >>>>> >>>>> >>>>> On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: >>>>>> >>>>>> >>>>>> On 07/12/2016 02:00 PM, Martin Babinsky wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, 11 Jul 2016, Martin Babinsky wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep >>>>>>>>> 17 >>>>>>>>> 00:00:00 2001 >>>>>>>>> From: Martin Babinsky >>>>>>>>> Date: Fri, 1 Jul 2016 18:09:04 +0200 >>>>>>>>> Subject: [PATCH] Preserve user principal aliases during >>>>>>>>> rename >>>>>>>>> operation >>>>>>>>> >>>>>>>>> When a MODRDN is performed on the user entry, the >>>>>>>>> MODRDN >>>>>>>>> plugin >>>>>>>>> resets >>>>>>>>> both >>>>>>>>> krbPrincipalName and krbCanonicalName to the value >>>>>>>>> constructed >>>>>>>>> from >>>>>>>>> uid. In >>>>>>>>> doing so, hovewer, any principal aliases added to the >>>>>>>>> krbPrincipalName >>>>>>>>> are >>>>>>>>> wiped clean. In this patch old aliases are fetched >>>>>>>>> before >>>>>>>>> the >>>>>>>>> MODRDN >>>>>>>>> operation >>>>>>>>> takes place and inserted back after it is performed. >>>>>>>>> >>>>>>>>> This also preserves previous user logins which can be >>>>>>>>> used >>>>>>>>> further for >>>>>>>>> authentication as aliases. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/6028 >>>>>>>>> --- >>>>>>>>> ipaserver/plugins/baseuser.py | 46 >>>>>>>>> +++++++++++++++++++++++++++++++++++++++++++ >>>>>>>>> 1 file changed, 46 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/ipaserver/plugins/baseuser.py >>>>>>>>> b/ipaserver/plugins/baseuser.py >>>>>>>>> index >>>>>>>>> 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a13115 >>>>>>>>> 7815 >>>>>>>>> ffb2 >>>>>>>>> 452692a7edb342f6ac3 >>>>>>>>> >>>>>>>>> 100644 >>>>>>>>> --- a/ipaserver/plugins/baseuser.py >>>>>>>>> +++ b/ipaserver/plugins/baseuser.py >>>>>>>>> @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate): >>>>>>>>> len = >>>>>>>>> int(config.get('ipamaxusernamelength')[0]) >>>>>>>>> ) >>>>>>>>> ) >>>>>>>>> + >>>>>>>>> + def preserve_krbprincipalname_pre(self, ldap, >>>>>>>>> entry_attrs, >>>>>>>>> *keys, >>>>>>>>> **options): >>>>>>>>> + """ >>>>>>>>> + preserve user principal aliases during rename >>>>>>>>> operation. This >>>>>>>>> is the >>>>>>>>> + pre-callback part of this. Another method >>>>>>>>> called >>>>>>>>> during >>>>>>>>> post-callback >>>>>>>>> + shall insert the principals back >>>>>>>>> + """ >>>>>>>>> + if options.get('rename', None) is None: >>>>>>>>> + return >>>>>>>>> + >>>>>>>>> + try: >>>>>>>>> + old_entry = ldap.get_entry( >>>>>>>>> + entry_attrs.dn, attrs_list=( >>>>>>>>> + 'krbprincipalname', >>>>>>>>> 'krbcanonicalname')) >>>>>>>>> + >>>>>>>>> + if 'krbcanonicalname' not in old_entry: >>>>>>>>> + return >>>>>>>>> + except errors.NotFound: >>>>>>>>> + self.obj.handle_not_found(*keys) >>>>>>>>> + >>>>>>>>> + self.context.krbprincipalname = old_entry.get( >>>>>>>>> + 'krbprincipalname', []) >>>>>>>>> + >>>>>>>>> + def preserve_krbprincipalname_post(self, ldap, >>>>>>>>> entry_attrs, >>>>>>>>> **options): >>>>>>>>> + """ >>>>>>>>> + Insert the preserved aliases back to the user >>>>>>>>> entry >>>>>>>>> during >>>>>>>>> rename >>>>>>>>> + operation >>>>>>>>> + """ >>>>>>>>> + if options.get('rename', None) is None or not >>>>>>>>> hasattr( >>>>>>>>> + self.context, 'krbprincipalname'): >>>>>>>>> + return >>>>>>>>> + >>>>>>>>> + obj_pkey = >>>>>>>>> self.obj.get_primary_key_from_dn(entry_attrs.dn) >>>>>>>>> + canonical_name = >>>>>>>>> entry_attrs['krbcanonicalname'][0] >>>>>>>>> + >>>>>>>>> + principals_to_add = tuple(p for p in >>>>>>>>> self.context.krbprincipalname if >>>>>>>>> + p != canonical_name) >>>>>>>>> + >>>>>>>>> + if principals_to_add: >>>>>>>>> + result = >>>>>>>>> self.api.Command.user_add_principal( >>>>>>>>> + obj_pkey, principals_to_add)['result'] >>>>>>>>> + >>>>>>>>> + entry_attrs['krbprincipalname'] = >>>>>>>>> result.get('krbprincipalname', []) >>>>>>>>> + >>>>>>>>> def check_mail(self, entry_attrs): >>>>>>>>> if 'mail' in entry_attrs: >>>>>>>>> entry_attrs['mail'] = >>>>>>>>> self.obj.normalize_and_validate_email(entry_attrs['mail >>>>>>>>> ']) >>>>>>>>> @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate): >>>>>>>>> >>>>>>>>> self.check_objectclass(ldap, dn, entry_attrs) >>>>>>>>> self.obj.convert_usercertificate_pre(entry_attr >>>>>>>>> s) >>>>>>>>> + self.preserve_krbprincipalname_pre(ldap, >>>>>>>>> entry_attrs, >>>>>>>>> *keys, >>>>>>>>> **options) >>>>>>>>> >>>>>>>>> def post_common_callback(self, ldap, dn, >>>>>>>>> entry_attrs, >>>>>>>>> *keys, >>>>>>>>> **options): >>>>>>>>> assert isinstance(dn, DN) >>>>>>>>> + self.preserve_krbprincipalname_post(ldap, >>>>>>>>> entry_attrs, >>>>>>>>> **options) >>>>>>>>> if options.get('random', False): >>>>>>>>> try: >>>>>>>>> entry_attrs['randompassword'] = >>>>>>>>> unicode(getattr(context, 'randompassword')) >>>>>>>>> -- >>>>>>>>> 2.5.5 >>>>>>>>> >>>>>>>> The approach looks good. >>>>>>>> >>>>>>>> For the record, we also support aliases for hosts and >>>>>>>> service >>>>>>>> kerberos >>>>>>>> principals but we don't support rename options for them, >>>>>>>> so >>>>>>>> there >>>>>>>> is no >>>>>>>> need to add similar logic there. >>>>>>>> >>>>>>>> >>>>>>> That's right, I have updated the corresponding section of >>>>>>> the >>>>>>> design >>>>>>> page [1] for future reference. >>>>>>> >>>>>>> [1] >>>>>>> http://www.freeipa.org/page/V4/Kerberos_principal_aliases#M >>>>>>> anag >>>>>>> emen >>>>>>> t_framework >>>>>>> >>>>>>> >>>>>> Adding Simo to the loop since he is not convinced that this >>>>>> is >>>>>> the >>>>>> right >>>>>> behavior. As I see it, it seems to not be a security issue >>>>>> but >>>>>> more >>>>>> of a >>>>>> different expectations about the perceived correct behavior >>>>>> in >>>>>> this >>>>>> particular situation. >>>>>> >>>>>> I can see the use case in keeping the old aliases, e.g. >>>>>> keeping >>>>>> the >>>>>> old >>>>>> credentials after legal name change, but I can also see the >>>>>> available >>>>>> space for user principal names piling up and cluttering >>>>>> quickly >>>>>> in >>>>>> large >>>>>> organizations. >>>>> after some thinking I think it is ok to keep by default and >>>>> then >>>>> drop >>>>> as it avoid races if you do really want to keep the aliases. >>>>> >>>>> However the CLI/UI should probably offer a button/switch to >>>>> allow >>>>> to >>>>> drop all aliases on rename, what it would do would be to modify >>>>> the >>>>> entry after the rename and drop the aliases. >>>>> >>>>> I am a bit uncertain what to do by default with the "original >>>>> name". >>>>> I can see it going both ways on whether to keep it by default >>>>> or >>>>> not. >>>> Ideally we would have e.g. >>>> >>>> ipa user-rename oldCN --remove-aliases >>>> >>>> which would drop everything including oldCN (I would expect >>>> that). >>> I lean toward this conclusion too given that a later "--remove- >>> alias" >>> would drop it, and we want to behave consistently. >>> >> Makes sense to me, too. >> >>> >>>> >>>> Unfortunately we have --rename in mod command >>>> ipa user-mod oldCN --rename newCn --remove-aliases >>>> >>>> And there --remove-aliases might not be the best thing. >>> Why not ? >>> >>>> >>>> Do we want to support also: >>>> ipa user-mod CN --remove-aliases >>> Yes we probably want to give the option to drop aliases if an admin >>> realizes he should have done it at rename time but didn't. >>> >>> Simo. >>> >> In that case he can still use `user-remove-principal` to manually >> remove them. > > True. > Should we then not have --remove-aliases at all, and always force the > admin to manually cleanup ? > > > Simo. > I guess that would be the path of least resistance for us. We will document the change of behavior and leave current API intact for now. The option can easily be added later if community requests it. -- Martin^3 Babinsky From mkubik at redhat.com Wed Jul 13 14:48:45 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 13 Jul 2016 16:48:45 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> Message-ID: On 07/11/2016 01:34 PM, Lenka Doudova wrote: > > > > On 07/08/2016 02:24 PM, Milan Kub?k wrote: >> On 07/01/2016 05:13 PM, Lenka Doudova wrote: >>> >>> >>> >>> On 07/01/2016 02:42 PM, Milan Kub?k wrote: >>>> On 06/16/2016 03:23 PM, Lenka Doudova wrote: >>>>> Hi, >>>>> >>>>> attached are tests for authentication indicators. Please note: >>>>> >>>>> 1. newly created service tracker is not exactly complete, list of >>>>> unimplemented methods is in doc. These methods can be filled in >>>>> when existing declarative tests are refactored. >>>>> >>>>> 2. patch 0015 depends on 0014, so it should not be pushed without it. >>>>> >>>>> >>>>> Lenka >>>>> >>>>> >>>>> >>>> >>>> patch 0014: >>>> >>>> In the update method, what happens when the updated attributes >>>> contain addattr? It is not clear to me. Is it necessary? >>>> >>> Example: >>> ipa service-mod SRV --addattr="authind=radius" >>> >>> Result: >>> The way the tracker works, this adds >>> /u'addattr="authind=radius"'/ to the list of expected results >>> (result of /self.attrs.update(updates)/. Of course nothing like that >>> appears anywhere, so in case there's the /--addattr/ option, it's >>> necessary to ensure it won't get to the /self.attrs/ atribute. >>> >>>> patch 0015: >>>> >>>> host1 and service2 do not tell anything about the purpose of the >>>> fixture. Please assign more descriptive names to them. >>>> Why do the fixtures have 'function' scope? Does the service entry >>>> exist during the second and third test case? >>>> >>> Renamed. >>>> >>>> patch 0016: >>>> >>>> Per offline discussion, admin user has no special privileges here, >>>> LGTM. >>>> >>>> -- >>>> Milan Kubik >>> >>> Thanks for review, fixed patches (14.2 and 15.2) attached. >>> Lenka >> >> NACK, >> >> the update method of ServiceTracker creates the entry if it doesn't >> exist. Why? I know the base class has this problem also [1], though. >> Given this will be addressed, the fixtures in the xmlrpc test will >> fail since the fixture scope is wrong - function instead of class. >> >> [1]: https://fedorahosted.org/freeipa/ticket/6045 >> >> -- >> Milan Kubik > Hi, > > fixed patch attached. I chose to leave the scope as it was (in case > one test breaks and entry is not even created, the other tests can > still be successful), but I removed the creation command from > ServiceTracker update method and called it directly in the tests, so > there shouldn't be hidden actions. > > Lenka Thanks for the updated patches. There are still some issues I haven't noticed before: service tracker: track_create method doesn't set self.exists flag which is needed In the xmlrpc test method `test_adding_second_indicator` uses 'addattr' to set the indicator, why? -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Wed Jul 13 14:50:24 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 13 Jul 2016 16:50:24 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Bug in the ipapwd plugin Message-ID: <57865530.3000602@redhat.com> https://fedorahosted.org/freeipa/ticket/6030 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ticket-6030-Bug-in-the-ipapwd-plugin.patch Type: text/x-patch Size: 1422 bytes Desc: not available URL: From simo at redhat.com Wed Jul 13 15:00:56 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Jul 2016 11:00:56 -0400 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> <1468415332.15769.59.camel@redhat.com> <1468420095.15769.65.camel@redhat.com> Message-ID: <1468422056.15769.68.camel@redhat.com> On Wed, 2016-07-13 at 16:35 +0200, Martin Babinsky wrote: > On 07/13/2016 04:28 PM, Simo Sorce wrote: > > > > On Wed, 2016-07-13 at 16:19 +0200, Martin Babinsky wrote: > > > > > > On 07/13/2016 03:08 PM, Simo Sorce wrote: > > > > > > > > > > > > On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote: > > > > > > > > > > > > > > > On 07/12/2016 04:19 PM, Simo Sorce wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 07/12/2016 02:00 PM, Martin Babinsky wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon > > > > > > > > > > Sep > > > > > > > > > > 17 > > > > > > > > > > 00:00:00 2001 > > > > > > > > > > From: Martin Babinsky > > > > > > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200 > > > > > > > > > > Subject: [PATCH] Preserve user principal aliases > > > > > > > > > > during > > > > > > > > > > rename > > > > > > > > > > operation > > > > > > > > > > > > > > > > > > > > When a MODRDN is performed on the user entry, the > > > > > > > > > > MODRDN > > > > > > > > > > plugin > > > > > > > > > > resets > > > > > > > > > > both > > > > > > > > > > krbPrincipalName and krbCanonicalName to the value > > > > > > > > > > constructed > > > > > > > > > > from > > > > > > > > > > uid. In > > > > > > > > > > doing so, hovewer, any principal aliases added to > > > > > > > > > > the > > > > > > > > > > krbPrincipalName > > > > > > > > > > are > > > > > > > > > > wiped clean. In this patch old aliases are fetched > > > > > > > > > > before > > > > > > > > > > the > > > > > > > > > > MODRDN > > > > > > > > > > operation > > > > > > > > > > takes place and inserted back after it is > > > > > > > > > > performed. > > > > > > > > > > > > > > > > > > > > This also preserves previous user logins which can > > > > > > > > > > be > > > > > > > > > > used > > > > > > > > > > further for > > > > > > > > > > authentication as aliases. > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6028 > > > > > > > > > > --- > > > > > > > > > > ipaserver/plugins/baseuser.py | 46 > > > > > > > > > > +++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > 1 file changed, 46 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git a/ipaserver/plugins/baseuser.py > > > > > > > > > > b/ipaserver/plugins/baseuser.py > > > > > > > > > > index > > > > > > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a1 > > > > > > > > > > 3115 > > > > > > > > > > 7815 > > > > > > > > > > ffb2 > > > > > > > > > > 452692a7edb342f6ac3 > > > > > > > > > > > > > > > > > > > > 100644 > > > > > > > > > > --- a/ipaserver/plugins/baseuser.py > > > > > > > > > > +++ b/ipaserver/plugins/baseuser.py > > > > > > > > > > @@ -498,6 +498,50 @@ class > > > > > > > > > > baseuser_mod(LDAPUpdate): > > > > > > > > > > ????????????????????????????len = > > > > > > > > > > int(config.get('ipamaxusernamelength')[0]) > > > > > > > > > > ????????????????????????) > > > > > > > > > > ????????????????????) > > > > > > > > > > + > > > > > > > > > > +????def preserve_krbprincipalname_pre(self, ldap, > > > > > > > > > > entry_attrs, > > > > > > > > > > *keys, > > > > > > > > > > **options): > > > > > > > > > > +????????""" > > > > > > > > > > +????????preserve user principal aliases during > > > > > > > > > > rename > > > > > > > > > > operation. This > > > > > > > > > > is the > > > > > > > > > > +????????pre-callback part of this. Another method > > > > > > > > > > called > > > > > > > > > > during > > > > > > > > > > post-callback > > > > > > > > > > +????????shall insert the principals back > > > > > > > > > > +????????""" > > > > > > > > > > +????????if options.get('rename', None) is None: > > > > > > > > > > +????????????return > > > > > > > > > > + > > > > > > > > > > +????????try: > > > > > > > > > > +????????????old_entry = ldap.get_entry( > > > > > > > > > > +????????????????entry_attrs.dn, attrs_list=( > > > > > > > > > > +????????????????????'krbprincipalname', > > > > > > > > > > 'krbcanonicalname')) > > > > > > > > > > + > > > > > > > > > > +????????????if 'krbcanonicalname' not in > > > > > > > > > > old_entry: > > > > > > > > > > +????????????????return > > > > > > > > > > +????????except errors.NotFound: > > > > > > > > > > +????????????self.obj.handle_not_found(*keys) > > > > > > > > > > + > > > > > > > > > > +????????self.context.krbprincipalname = > > > > > > > > > > old_entry.get( > > > > > > > > > > +????????????'krbprincipalname', []) > > > > > > > > > > + > > > > > > > > > > +????def preserve_krbprincipalname_post(self, ldap, > > > > > > > > > > entry_attrs, > > > > > > > > > > **options): > > > > > > > > > > +????????""" > > > > > > > > > > +????????Insert the preserved aliases back to the > > > > > > > > > > user > > > > > > > > > > entry > > > > > > > > > > during > > > > > > > > > > rename > > > > > > > > > > +????????operation > > > > > > > > > > +????????""" > > > > > > > > > > +????????if options.get('rename', None) is None or > > > > > > > > > > not > > > > > > > > > > hasattr( > > > > > > > > > > +????????????????self.context, 'krbprincipalname'): > > > > > > > > > > +????????????return > > > > > > > > > > + > > > > > > > > > > +????????obj_pkey = > > > > > > > > > > self.obj.get_primary_key_from_dn(entry_attrs.dn) > > > > > > > > > > +????????canonical_name = > > > > > > > > > > entry_attrs['krbcanonicalname'][0] > > > > > > > > > > + > > > > > > > > > > +????????principals_to_add = tuple(p for p in > > > > > > > > > > self.context.krbprincipalname if > > > > > > > > > > +??????????????????????????????????p != > > > > > > > > > > canonical_name) > > > > > > > > > > + > > > > > > > > > > +????????if principals_to_add: > > > > > > > > > > +????????????result = > > > > > > > > > > self.api.Command.user_add_principal( > > > > > > > > > > +????????????????obj_pkey, > > > > > > > > > > principals_to_add)['result'] > > > > > > > > > > + > > > > > > > > > > +????????????entry_attrs['krbprincipalname'] = > > > > > > > > > > result.get('krbprincipalname', []) > > > > > > > > > > + > > > > > > > > > > ????def check_mail(self, entry_attrs): > > > > > > > > > > ????????if 'mail' in entry_attrs: > > > > > > > > > > ????????????entry_attrs['mail'] = > > > > > > > > > > self.obj.normalize_and_validate_email(entry_attrs[' > > > > > > > > > > mail > > > > > > > > > > ']) > > > > > > > > > > @@ -557,9 +601,11 @@ class > > > > > > > > > > baseuser_mod(LDAPUpdate): > > > > > > > > > > > > > > > > > > > > ????????self.check_objectclass(ldap, dn, > > > > > > > > > > entry_attrs) > > > > > > > > > > ????????self.obj.convert_usercertificate_pre(entry_ > > > > > > > > > > attr > > > > > > > > > > s) > > > > > > > > > > +????????self.preserve_krbprincipalname_pre(ldap, > > > > > > > > > > entry_attrs, > > > > > > > > > > *keys, > > > > > > > > > > **options) > > > > > > > > > > > > > > > > > > > > ????def post_common_callback(self, ldap, dn, > > > > > > > > > > entry_attrs, > > > > > > > > > > *keys, > > > > > > > > > > **options): > > > > > > > > > > ????????assert isinstance(dn, DN) > > > > > > > > > > +????????self.preserve_krbprincipalname_post(ldap, > > > > > > > > > > entry_attrs, > > > > > > > > > > **options) > > > > > > > > > > ????????if options.get('random', False): > > > > > > > > > > ????????????try: > > > > > > > > > > ????????????????entry_attrs['randompassword'] = > > > > > > > > > > unicode(getattr(context, 'randompassword')) > > > > > > > > > > -- > > > > > > > > > > 2.5.5 > > > > > > > > > > > > > > > > > > > The approach looks good. > > > > > > > > > > > > > > > > > > For the record, we also support aliases for hosts and > > > > > > > > > service > > > > > > > > > kerberos > > > > > > > > > principals but we don't support rename options for > > > > > > > > > them, > > > > > > > > > so > > > > > > > > > there > > > > > > > > > is no > > > > > > > > > need to add similar logic there. > > > > > > > > > > > > > > > > > > > > > > > > > > That's right, I have updated the corresponding section > > > > > > > > of > > > > > > > > the > > > > > > > > design > > > > > > > > page [1] for future reference. > > > > > > > > > > > > > > > > [1] > > > > > > > > http://www.freeipa.org/page/V4/Kerberos_principal_alias > > > > > > > > es#M > > > > > > > > anag > > > > > > > > emen > > > > > > > > t_framework > > > > > > > > > > > > > > > > > > > > > > > Adding Simo to the loop since he is not convinced that > > > > > > > this > > > > > > > is > > > > > > > the > > > > > > > right > > > > > > > behavior. As I see it, it seems to not be a security > > > > > > > issue > > > > > > > but > > > > > > > more > > > > > > > of a > > > > > > > different expectations about the perceived correct > > > > > > > behavior > > > > > > > in > > > > > > > this > > > > > > > particular situation. > > > > > > > > > > > > > > I can see the use case in keeping the old aliases, e.g. > > > > > > > keeping > > > > > > > the > > > > > > > old > > > > > > > credentials after legal name change, but I can also see > > > > > > > the > > > > > > > available > > > > > > > space for user principal names piling up and cluttering > > > > > > > quickly > > > > > > > in > > > > > > > large > > > > > > > organizations. > > > > > > after some thinking I think it is ok to keep by default and > > > > > > then > > > > > > drop > > > > > > as it avoid races if you do really want to keep the > > > > > > aliases. > > > > > > > > > > > > However the CLI/UI should probably offer a button/switch to > > > > > > allow > > > > > > to > > > > > > drop all aliases on rename, what it would do would be to > > > > > > modify > > > > > > the > > > > > > entry after the rename and drop the aliases. > > > > > > > > > > > > I am a bit uncertain what to do by default with the > > > > > > "original > > > > > > name". > > > > > > I can see it going both ways on whether to keep it by > > > > > > default > > > > > > or > > > > > > not. > > > > > Ideally we would have e.g. > > > > > > > > > > ?ipa user-rename oldCN --remove-aliases > > > > > > > > > > which would drop everything including oldCN (I would expect > > > > > that). > > > > I lean toward this conclusion too given that a later "--remove- > > > > alias" > > > > would drop it, and we want to behave consistently. > > > > > > > Makes sense to me, too. > > > > > > > > > > > > > > > > > > > > > > > > > > Unfortunately we have --rename in mod command > > > > > ?ipa user-mod oldCN --rename newCn --remove-aliases > > > > > > > > > > And there --remove-aliases might not be the best thing. > > > > Why not ? > > > > > > > > > > > > > > > > > > > Do we want to support also: > > > > > ? ipa user-mod CN --remove-aliases > > > > Yes we probably want to give the option to drop aliases if an > > > > admin > > > > realizes he should have done it at rename time but didn't. > > > > > > > > Simo. > > > > > > > In that case he can still use `user-remove-principal` to manually > > > remove??them. > > True. > > Should we then not have --remove-aliases at all, and always force > > the > > admin to manually cleanup ? > > > > > > Simo. > > > I guess that would be the path of least resistance for us. We will? > document the change of behavior and leave current API intact for > now.? > The option can easily be added later if community requests it. Ok, then, let's proceed. Simo. From mbabinsk at redhat.com Wed Jul 13 15:04:46 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Jul 2016 17:04:46 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <1468422056.15769.68.camel@redhat.com> References: <9461f928-1917-c22b-365d-6eb7c84ab4f9@redhat.com> <20160706152222.4znlybol7y5c35gg@redhat.com> <5f066bd1-05d1-3d02-7801-c0d6818306a9@redhat.com> <20160711110442.noea3ryuuqxngfyq@redhat.com> <827e53f6-b299-067f-a055-bd2eba9a45e1@redhat.com> <20160712110529.nrrkhnkdnndjvwax@redhat.com> <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> <1468415332.15769.59.camel@redhat.com> <1468420095.15769.65.camel@redhat.com> <1468422056.15769.68.camel@redhat.com> Message-ID: <921c7364-ac37-2847-a295-361d92183b92@redhat.com> On 07/13/2016 05:00 PM, Simo Sorce wrote: > On Wed, 2016-07-13 at 16:35 +0200, Martin Babinsky wrote: >> On 07/13/2016 04:28 PM, Simo Sorce wrote: >>> >>> On Wed, 2016-07-13 at 16:19 +0200, Martin Babinsky wrote: >>>> >>>> On 07/13/2016 03:08 PM, Simo Sorce wrote: >>>>> >>>>> >>>>> On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote: >>>>>> >>>>>> >>>>>> On 07/12/2016 04:19 PM, Simo Sorce wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 07/12/2016 02:00 PM, Martin Babinsky wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07/12/2016 01:05 PM, Alexander Bokovoy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, 11 Jul 2016, Martin Babinsky wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon >>>>>>>>>>> Sep >>>>>>>>>>> 17 >>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>> From: Martin Babinsky >>>>>>>>>>> Date: Fri, 1 Jul 2016 18:09:04 +0200 >>>>>>>>>>> Subject: [PATCH] Preserve user principal aliases >>>>>>>>>>> during >>>>>>>>>>> rename >>>>>>>>>>> operation >>>>>>>>>>> >>>>>>>>>>> When a MODRDN is performed on the user entry, the >>>>>>>>>>> MODRDN >>>>>>>>>>> plugin >>>>>>>>>>> resets >>>>>>>>>>> both >>>>>>>>>>> krbPrincipalName and krbCanonicalName to the value >>>>>>>>>>> constructed >>>>>>>>>>> from >>>>>>>>>>> uid. In >>>>>>>>>>> doing so, hovewer, any principal aliases added to >>>>>>>>>>> the >>>>>>>>>>> krbPrincipalName >>>>>>>>>>> are >>>>>>>>>>> wiped clean. In this patch old aliases are fetched >>>>>>>>>>> before >>>>>>>>>>> the >>>>>>>>>>> MODRDN >>>>>>>>>>> operation >>>>>>>>>>> takes place and inserted back after it is >>>>>>>>>>> performed. >>>>>>>>>>> >>>>>>>>>>> This also preserves previous user logins which can >>>>>>>>>>> be >>>>>>>>>>> used >>>>>>>>>>> further for >>>>>>>>>>> authentication as aliases. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6028 >>>>>>>>>>> --- >>>>>>>>>>> ipaserver/plugins/baseuser.py | 46 >>>>>>>>>>> +++++++++++++++++++++++++++++++++++++++++++ >>>>>>>>>>> 1 file changed, 46 insertions(+) >>>>>>>>>>> >>>>>>>>>>> diff --git a/ipaserver/plugins/baseuser.py >>>>>>>>>>> b/ipaserver/plugins/baseuser.py >>>>>>>>>>> index >>>>>>>>>>> 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a1 >>>>>>>>>>> 3115 >>>>>>>>>>> 7815 >>>>>>>>>>> ffb2 >>>>>>>>>>> 452692a7edb342f6ac3 >>>>>>>>>>> >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/ipaserver/plugins/baseuser.py >>>>>>>>>>> +++ b/ipaserver/plugins/baseuser.py >>>>>>>>>>> @@ -498,6 +498,50 @@ class >>>>>>>>>>> baseuser_mod(LDAPUpdate): >>>>>>>>>>> len = >>>>>>>>>>> int(config.get('ipamaxusernamelength')[0]) >>>>>>>>>>> ) >>>>>>>>>>> ) >>>>>>>>>>> + >>>>>>>>>>> + def preserve_krbprincipalname_pre(self, ldap, >>>>>>>>>>> entry_attrs, >>>>>>>>>>> *keys, >>>>>>>>>>> **options): >>>>>>>>>>> + """ >>>>>>>>>>> + preserve user principal aliases during >>>>>>>>>>> rename >>>>>>>>>>> operation. This >>>>>>>>>>> is the >>>>>>>>>>> + pre-callback part of this. Another method >>>>>>>>>>> called >>>>>>>>>>> during >>>>>>>>>>> post-callback >>>>>>>>>>> + shall insert the principals back >>>>>>>>>>> + """ >>>>>>>>>>> + if options.get('rename', None) is None: >>>>>>>>>>> + return >>>>>>>>>>> + >>>>>>>>>>> + try: >>>>>>>>>>> + old_entry = ldap.get_entry( >>>>>>>>>>> + entry_attrs.dn, attrs_list=( >>>>>>>>>>> + 'krbprincipalname', >>>>>>>>>>> 'krbcanonicalname')) >>>>>>>>>>> + >>>>>>>>>>> + if 'krbcanonicalname' not in >>>>>>>>>>> old_entry: >>>>>>>>>>> + return >>>>>>>>>>> + except errors.NotFound: >>>>>>>>>>> + self.obj.handle_not_found(*keys) >>>>>>>>>>> + >>>>>>>>>>> + self.context.krbprincipalname = >>>>>>>>>>> old_entry.get( >>>>>>>>>>> + 'krbprincipalname', []) >>>>>>>>>>> + >>>>>>>>>>> + def preserve_krbprincipalname_post(self, ldap, >>>>>>>>>>> entry_attrs, >>>>>>>>>>> **options): >>>>>>>>>>> + """ >>>>>>>>>>> + Insert the preserved aliases back to the >>>>>>>>>>> user >>>>>>>>>>> entry >>>>>>>>>>> during >>>>>>>>>>> rename >>>>>>>>>>> + operation >>>>>>>>>>> + """ >>>>>>>>>>> + if options.get('rename', None) is None or >>>>>>>>>>> not >>>>>>>>>>> hasattr( >>>>>>>>>>> + self.context, 'krbprincipalname'): >>>>>>>>>>> + return >>>>>>>>>>> + >>>>>>>>>>> + obj_pkey = >>>>>>>>>>> self.obj.get_primary_key_from_dn(entry_attrs.dn) >>>>>>>>>>> + canonical_name = >>>>>>>>>>> entry_attrs['krbcanonicalname'][0] >>>>>>>>>>> + >>>>>>>>>>> + principals_to_add = tuple(p for p in >>>>>>>>>>> self.context.krbprincipalname if >>>>>>>>>>> + p != >>>>>>>>>>> canonical_name) >>>>>>>>>>> + >>>>>>>>>>> + if principals_to_add: >>>>>>>>>>> + result = >>>>>>>>>>> self.api.Command.user_add_principal( >>>>>>>>>>> + obj_pkey, >>>>>>>>>>> principals_to_add)['result'] >>>>>>>>>>> + >>>>>>>>>>> + entry_attrs['krbprincipalname'] = >>>>>>>>>>> result.get('krbprincipalname', []) >>>>>>>>>>> + >>>>>>>>>>> def check_mail(self, entry_attrs): >>>>>>>>>>> if 'mail' in entry_attrs: >>>>>>>>>>> entry_attrs['mail'] = >>>>>>>>>>> self.obj.normalize_and_validate_email(entry_attrs[' >>>>>>>>>>> mail >>>>>>>>>>> ']) >>>>>>>>>>> @@ -557,9 +601,11 @@ class >>>>>>>>>>> baseuser_mod(LDAPUpdate): >>>>>>>>>>> >>>>>>>>>>> self.check_objectclass(ldap, dn, >>>>>>>>>>> entry_attrs) >>>>>>>>>>> self.obj.convert_usercertificate_pre(entry_ >>>>>>>>>>> attr >>>>>>>>>>> s) >>>>>>>>>>> + self.preserve_krbprincipalname_pre(ldap, >>>>>>>>>>> entry_attrs, >>>>>>>>>>> *keys, >>>>>>>>>>> **options) >>>>>>>>>>> >>>>>>>>>>> def post_common_callback(self, ldap, dn, >>>>>>>>>>> entry_attrs, >>>>>>>>>>> *keys, >>>>>>>>>>> **options): >>>>>>>>>>> assert isinstance(dn, DN) >>>>>>>>>>> + self.preserve_krbprincipalname_post(ldap, >>>>>>>>>>> entry_attrs, >>>>>>>>>>> **options) >>>>>>>>>>> if options.get('random', False): >>>>>>>>>>> try: >>>>>>>>>>> entry_attrs['randompassword'] = >>>>>>>>>>> unicode(getattr(context, 'randompassword')) >>>>>>>>>>> -- >>>>>>>>>>> 2.5.5 >>>>>>>>>>> >>>>>>>>>> The approach looks good. >>>>>>>>>> >>>>>>>>>> For the record, we also support aliases for hosts and >>>>>>>>>> service >>>>>>>>>> kerberos >>>>>>>>>> principals but we don't support rename options for >>>>>>>>>> them, >>>>>>>>>> so >>>>>>>>>> there >>>>>>>>>> is no >>>>>>>>>> need to add similar logic there. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> That's right, I have updated the corresponding section >>>>>>>>> of >>>>>>>>> the >>>>>>>>> design >>>>>>>>> page [1] for future reference. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://www.freeipa.org/page/V4/Kerberos_principal_alias >>>>>>>>> es#M >>>>>>>>> anag >>>>>>>>> emen >>>>>>>>> t_framework >>>>>>>>> >>>>>>>>> >>>>>>>> Adding Simo to the loop since he is not convinced that >>>>>>>> this >>>>>>>> is >>>>>>>> the >>>>>>>> right >>>>>>>> behavior. As I see it, it seems to not be a security >>>>>>>> issue >>>>>>>> but >>>>>>>> more >>>>>>>> of a >>>>>>>> different expectations about the perceived correct >>>>>>>> behavior >>>>>>>> in >>>>>>>> this >>>>>>>> particular situation. >>>>>>>> >>>>>>>> I can see the use case in keeping the old aliases, e.g. >>>>>>>> keeping >>>>>>>> the >>>>>>>> old >>>>>>>> credentials after legal name change, but I can also see >>>>>>>> the >>>>>>>> available >>>>>>>> space for user principal names piling up and cluttering >>>>>>>> quickly >>>>>>>> in >>>>>>>> large >>>>>>>> organizations. >>>>>>> after some thinking I think it is ok to keep by default and >>>>>>> then >>>>>>> drop >>>>>>> as it avoid races if you do really want to keep the >>>>>>> aliases. >>>>>>> >>>>>>> However the CLI/UI should probably offer a button/switch to >>>>>>> allow >>>>>>> to >>>>>>> drop all aliases on rename, what it would do would be to >>>>>>> modify >>>>>>> the >>>>>>> entry after the rename and drop the aliases. >>>>>>> >>>>>>> I am a bit uncertain what to do by default with the >>>>>>> "original >>>>>>> name". >>>>>>> I can see it going both ways on whether to keep it by >>>>>>> default >>>>>>> or >>>>>>> not. >>>>>> Ideally we would have e.g. >>>>>> >>>>>> ipa user-rename oldCN --remove-aliases >>>>>> >>>>>> which would drop everything including oldCN (I would expect >>>>>> that). >>>>> I lean toward this conclusion too given that a later "--remove- >>>>> alias" >>>>> would drop it, and we want to behave consistently. >>>>> >>>> Makes sense to me, too. >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> Unfortunately we have --rename in mod command >>>>>> ipa user-mod oldCN --rename newCn --remove-aliases >>>>>> >>>>>> And there --remove-aliases might not be the best thing. >>>>> Why not ? >>>>> >>>>>> >>>>>> >>>>>> Do we want to support also: >>>>>> ipa user-mod CN --remove-aliases >>>>> Yes we probably want to give the option to drop aliases if an >>>>> admin >>>>> realizes he should have done it at rename time but didn't. >>>>> >>>>> Simo. >>>>> >>>> In that case he can still use `user-remove-principal` to manually >>>> remove them. >>> True. >>> Should we then not have --remove-aliases at all, and always force >>> the >>> admin to manually cleanup ? >>> >>> >>> Simo. >>> >> I guess that would be the path of least resistance for us. We will >> document the change of behavior and leave current API intact for >> now. >> The option can easily be added later if community requests it. > > Ok, then, let's proceed. > > Simo. > In that case, if nobody objects then the second revision of the patch may be pushed since Alexander already acked it, right Alexander? -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Jul 13 15:40:29 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Jul 2016 17:40:29 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> Message-ID: <7cea5284-b23d-9f95-2be8-a477274ff98f@redhat.com> On 07/01/2016 04:15 PM, Lenka Doudova wrote: > > > On 07/01/2016 02:38 PM, Martin Babinsky wrote: >> On 07/01/2016 06:36 AM, Lenka Doudova wrote: >>> >>> >>> On 06/30/2016 05:01 PM, Martin Babinsky wrote: >>>> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>>>> Hi, >>>>> >>>>> attaching patch with some basic coverage for external trust >>>>> feature. Bit >>>>> more detailed info in commit message. >>>>> >>>>> Since the feature requires me to run commands previously used only for >>>>> forest root domains even for subdomains, I made some changes in >>>>> ipatests/test_integration/tasks.py file, so that it would enable me to >>>>> reuse existing function without copy-pasting them for one variable >>>>> change. >>>>> >>>>> >>>>> Lenka >>>>> >>>>> >>>>> >>>> >>>> Hi Lenka, >>>> >>>> I have a few comments: >>>> >>>> 1.) >>>> >>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>> +def establish_trust_with_ad(master, ad, extra_args=(), >>>> subdomain=False): >>>> >>>> This modification seems extremely kludgy to me. >>>> >>>> I would rather change the function signature to: >>>> >>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >>>> >>>> and pass the domain name itself to the function instead of doing magic >>>> inside. The same goes with `remove trust_with_ad`. You may want to fix >>>> the calls to them in existing code so that the domain is passed >>>> instead of the whole trust object. >>>> >>>> 2.) >>>> >>>> +def sync_time_hostname(host, srv_hostname): >>>> + """ >>>> + Syncs time with the remote server given by its hostname. >>>> + Please note that this function leaves ntpd stopped. >>>> + """ >>>> + host.run_command(['systemctl', 'stop', 'ntpd']) >>>> + host.run_command(['ntpdate', srv_hostname]) >>>> + >>>> + >>>> >>>> this looks like a duplicate of the function above it, why is it even >>>> needed? >>>> >>>> 3.) >>>> +class TestExternalTrustWithSubdomain(ADTrustBase): >>>> + """ >>>> + Test establishing external trust with subdomain >>>> + """ >>>> + >>>> + @classmethod >>>> + def install(cls, mh): >>>> + super(ADTrustBase, cls).install(mh) >>>> + cls.ad = cls.ad_domains[0].ads[0] >>>> + cls.install_adtrust() >>>> + cls.check_sid_generation() >>>> + >>>> + # Determine whether the subdomain AD is available >>>> + try: >>>> + child_ad = cls.host_by_role(cls.optional_extra_roles[0]) >>>> + cls.ad_subdomain = >>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>> + except LookupError: >>>> + cls.ad_subdomain = None >>>> + >>>> + cls.configure_dns_and_time() >>>> >>>> Please use proper OOP practices when overriding the behavior of the >>>> base test class. >>>> >>>> For starters you could rewrite the install method like this: >>>> >>>> + @classmethod >>>> + def install(cls, mh): >>>> + # Determine whether the subdomain AD is available >>>> + try: >>>> + cls.child_ad = >>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>> + cls.ad_subdomain = >>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>> + except LookupError: >>>> + raise nose.SkipTest("AFAIK this will skip the whole test >>>> class") >>>> + super(ADTrustBase, cls).install(mh) >>>> >>>> with child_ad stored as class attribute, you can override >>>> `configure_dns_and_time`: >>>> + def configure_dns_and_time(cls): >>>> + tasks.configure_dns_for_trust(cls.master, cls.ad_subdomain) >>>> # no need to re-implement the function just to get to the child >>>> AD DC hostname now >>>> + tasks.sync_time(cls.master, cls.child_ad.hostname) >>>> >>>> You can then use this class as an intermediary in the hierarchy and >>>> inherit the other external/non-external trust test classes from it, >>>> since most setup method in them are just copy-pasted from this one. >>>> >>> Hi, >>> thanks for review, fixed patch attached. >>> >>> Lenka >> >> Hi Lenka, >> >> I am still not happy about the patch underutilizing the potential for >> a proper inheritance hierarchy and instead relying on a staggering >> amounts of copy-pasting for implementation. >> >> I am attaching a quick untested patch illustrating how the >> implementation should look like. >> >> Also you have some leftovers from previous revision, please fix them: >> >> Pylint is running, please wait ... >> ************* Module ipatests.test_integration.test_trust >> ipatests/test_integration/test_trust.py:236: [E1101(no-member), >> TestExternalTrustWithSubdomain.configure_dns_and_time] Module >> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >> ipatests/test_integration/test_trust.py:243: >> [E1123(unexpected-keyword-arg), >> TestExternalTrustWithSubdomain.test_establish_trust] Unexpected >> keyword argument 'subdomain' in function call) >> ipatests/test_integration/test_trust.py:279: >> [E1123(unexpected-keyword-arg), >> TestExternalTrustWithSubdomain.test_remove_nonposix_trust] Unexpected >> keyword argument 'subdomain' in function call) >> ipatests/test_integration/test_trust.py:330: [E1101(no-member), >> TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module >> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >> Makefile:137: recipe for target 'lint' failed >> make: *** [lint] Error 1 >> sending incremental file list >> >> (this is before I started meddling with it) >> >> > Thank you very much for the example, fixed patch attached. > Lenka Hi Lenka, 'TestExternalTrustWithSubdomain' and 'TestExternalTrustWithRootDomain' suites fail due to incorrectly used '--external' option in the trust-add command. This option is Boolean, not Flag so it should be '--external=True'. -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Jul 13 16:04:08 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Jul 2016 18:04:08 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> <84d6fa1f-265c-9408-3ecd-65c640da1793@redhat.com> Message-ID: <76514b4d-63fe-f6e1-31a5-b1aff62b728a@redhat.com> On 07/01/2016 04:45 PM, Lenka Doudova wrote: > > > On 07/01/2016 03:04 PM, Martin Babinsky wrote: >> On 07/01/2016 11:13 AM, Lenka Doudova wrote: >>> And, of course, a patch file :) >>> >>> >>> On 07/01/2016 11:09 AM, Lenka Doudova wrote: >>>> Hi all, >>>> >>>> here's patch with basic test suite for support of UPN. >>>> >>>> Note: it needs to be applied on top of my patch 0025.2 (or later, if >>>> there's will be more fixes to that patch). >>>> >>>> >>>> Lenka >>>> >>> >>> >>> >> >> Hi Lenka, >> >> test data such as usernames, etc. should be stored either in separate >> resource files or at least as class attributes like this: >> >> diff --git a/ipatests/test_integration/test_trust.py >> b/ipatests/test_integration/test_trust.py >> index e8fdc6b..86ba7cc 100644 >> --- a/ipatests/test_integration/test_trust.py >> +++ b/ipatests/test_integration/test_trust.py >> @@ -394,28 +394,33 @@ class TestTrustWithUPN(ADTrustBase): >> """ >> Test support of UPN for trusted domains >> """ >> + upn_suffix = 'UPNsuffix.com' >> + upn_username = 'upnuser' >> + upn_princ = '{}@{}'.format(upn_username, upn_suffix) >> + upn_password = 'Secret123456' >> + >> def test_upn_in_nonposix_trust(self): >> """ Check that UPN is listed as trust attribute """ >> result = self.master.run_command(['ipa', 'trust-show', >> self.ad_domain, >> '--all', '--raw']) >> >> - assert "ipantadditionalsuffixes: UPNsuffix.com" in >> result.stdout_text >> + assert ("ipantadditionalsuffixes: {}".format(self.upn_suffix) in >> + result.stdout_text) >> >> def test_upn_user_resolution_in_nonposix_trust(self): >> """ Check that user with UPN can be resolved """ >> - upnuser = 'upnuser at UPNsuffix.com' >> - result = self.master.run_command(['getent', 'passwd', upnuser]) >> + result = self.master.run_command(['getent', 'passwd', >> self.upn_princ]) >> >> # result will contain AD domain, not UPN >> - upnuser_regex = "^upnuser@{0}:\*:(\d+):(\d+):UPN >> User:/:$".format( >> - self.ad_domain) >> + upnuser_regex = "^{}@{}:\*:(\d+):(\d+):UPN User:/:$".format( >> + self.upn_username, self.ad_domain) >> assert re.search(upnuser_regex, result.stdout_text) >> >> def test_upn_user_authentication(self): >> """ Check that AD user with UPN can authenticate in IPA """ >> self.master.run_command(['systemctl', 'restart', 'krb5kdc']) >> - self.master.run_command(['kinit', '-C', '-E', >> 'upnuser at UPNsuffix.com'], >> - stdin_text='Secret123456') >> + self.master.run_command(['kinit', '-C', '-E', self.upn_princ], >> + stdin_text=self.upn_password) >> >> otherwise LGTM. >> > Thanks for review, fixed patch attached. > > Few notes: > 1. mbabinsky's suggestion to store testdata as class attributes or > separate resource file: I decided to use the class attribute approach. > The separate resource file is a nice idea, which I have already put on > my "to do" list - there's a lot of hardcoded stuff in the trust tests, > even in the original ones (before my patches), so when there's time I'll > work on a way how to dynamically provide this data as test configuration > 2. previous discussion about getent vs. pwd.getpwnam(): I'll leave the > getent command, since according to mbasti the alternative would not work > in CI. > > Lenka Hi Lenka, I am not sure 'test_all_trustdomains_found' should be run as a part of this test suite. Maybe yes, I'm not sure. Also I would add a 60 second sleep after KDC restart in 'test_upn_user_authentication' so that MS-PAC cache gets refreshed before trying to kinit as enterprise principal. Two of the tests fail on my setup but that is probably due to https://fedorahosted.org/freeipa/ticket/6082 . -- Martin^3 Babinsky From abokovoy at redhat.com Wed Jul 13 16:07:49 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 13 Jul 2016 19:07:49 +0300 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <921c7364-ac37-2847-a295-361d92183b92@redhat.com> References: <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> <1468415332.15769.59.camel@redhat.com> <1468420095.15769.65.camel@redhat.com> <1468422056.15769.68.camel@redhat.com> <921c7364-ac37-2847-a295-361d92183b92@redhat.com> Message-ID: <20160713160749.i6mmcc26auqeqvjy@redhat.com> On Wed, 13 Jul 2016, Martin Babinsky wrote: >In that case, if nobody objects then the second revision of the patch >may be pushed since Alexander already acked it, right Alexander? Correct. ACK. -- / Alexander Bokovoy From mbabinsk at redhat.com Wed Jul 13 16:25:19 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Jul 2016 18:25:19 +0200 Subject: [Freeipa-devel] [PATCH 0185] messages: specify message type for ResultFormattingError Message-ID: <0549e1fe-234d-bcc6-1cf8-632e6bd3454d@redhat.com> https://fedorahosted.org/freeipa/ticket/6081 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0185-messages-specify-message-type-for-ResultFormattingEr.patch Type: text/x-patch Size: 914 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jul 13 16:34:42 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 13 Jul 2016 18:34:42 +0200 Subject: [Freeipa-devel] [PATCH] 0089 caacl: expand plugin documentation In-Reply-To: <20160712064552.azywmrlvmd2vstrb@redhat.com> References: <20160712051700.GT10771@dhcp-40-8.bne.redhat.com> <20160712064552.azywmrlvmd2vstrb@redhat.com> Message-ID: On 07/12/2016 08:45 AM, Alexander Bokovoy wrote: > On Tue, 12 Jul 2016, Fraser Tweedale wrote: >> Attached patch is a doc change, addressing >> https://fedorahosted.org/freeipa/ticket/6002. >> >> Thanks, >> Fraser > >> From 19c5fc60391d37c9d0500feb5d5d5a6628bc4d27 Mon Sep 17 00:00:00 2001 >> From: Fraser Tweedale >> Date: Tue, 12 Jul 2016 15:11:11 +1000 >> Subject: [PATCH] caacl: expand plugin documentation >> >> Expand the 'caacl' plugin documentation to explain some common >> confusions including the fact that CA ACLs apply to the target >> subject principal (not necessarily the principal requesting the >> cert), and the fact that CA-less CA ACL implies the 'ipa' CA. >> >> Fixes: https://fedorahosted.org/freeipa/ticket/6002 >> --- >> ipaserver/plugins/caacl.py | 34 ++++++++++++++++++++++++++++------ >> 1 file changed, 28 insertions(+), 6 deletions(-) >> >> diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py >> index >> 9a60f7e27809c4f41b160647efafde94dbe90bf0..d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a >> 100644 >> --- a/ipaserver/plugins/caacl.py >> +++ b/ipaserver/plugins/caacl.py >> @@ -23,14 +23,36 @@ if six.PY3: >> __doc__ = _(""" >> Manage CA ACL rules. >> >> -This plugin is used to define rules governing which principals are >> -permitted to have certificates issued using a given certificate >> -profile. >> +This plugin is used to define rules governing which CAs and profiles >> +may be used to issue certificates to particular principals or groups >> +of principals. >> >> -PROFILE ID SYNTAX: >> +SUBJECT PRINCIPAL SCOPE: >> >> -A Profile ID is a string without spaces or punctuation starting with >> a letter >> -and followed by a sequence of letters, digits or underscore ("_"). >> +For a certificate request to be allowed, the principal(s) that are >> +the subject of a certificate request (not necessarily the principal >> +actually requesting the certificate) must be included in the scope >> +of a CA ACL that also includes the target CA and profile. >> + >> +Users can be included by name, group or the "all users" category. >> +Hosts can be included by name, hostgroup or the "all hosts" >> +category. Services can be included by service name or the "all >> +services" category. CA ACLs may be associated with a single type of >> +principal, or multiple types. >> + >> +CERTIFICATE AUTHORITY SCOPE: >> + >> +A CA ACL can be associated with one or more CAs by name, or by the >> +"all CAs" category. For compatibility reasons, a CA ACL with no CA >> +association implies an association with the 'ipa' CA (and only this >> +CA). >> + >> +PROFILE SCOPE: >> + >> +A CA ACL can be associated with one or more profiles by Profile ID. >> +The Profile ID is a string without spaces or punctuation starting >> +with a letter and followed by a sequence of letters, digits or >> +underscore ("_"). >> >> EXAMPLES: >> > ACK. Reads well. > Pushed to master: 8cd87d12d53a98a8e386c06a7c5fddb1d38d990d -- Petr Vobornik From pvoborni at redhat.com Wed Jul 13 16:38:25 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 13 Jul 2016 18:38:25 +0200 Subject: [Freeipa-devel] [PATCH 0550] host-find: do not show SSH keys by default In-Reply-To: References: <83cd1331-5499-19c5-e1af-ccfb7b3056bc@redhat.com> Message-ID: <51a0a65b-ea2f-1367-e7cb-e7fad366e746@redhat.com> On 07/12/2016 12:33 PM, Stanislav Laznicka wrote: > On 07/08/2016 01:52 PM, Martin Basti wrote: >> Reproducible only with 2+ hosts, patch attached. >> >> https://fedorahosted.org/freeipa/ticket/6043 >> >> > ACK. > master: * 2874fdbfef1e191cf858dabdd34d5a0cbdc5ef16 host-find: do not show SSH key by default -- Petr Vobornik From pvoborni at redhat.com Wed Jul 13 16:40:45 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 13 Jul 2016 18:40:45 +0200 Subject: [Freeipa-devel] [PATCH 0056] removed unused parameter from migrate-ds In-Reply-To: <96656614-bcdc-b458-0776-ea600262654e@redhat.com> References: <5391b4ff-4ee3-92f6-f553-69fbbb9990b6@redhat.com> <96656614-bcdc-b458-0776-ea600262654e@redhat.com> Message-ID: <7dbce967-b290-018d-86ae-b48e03c06abd@redhat.com> On 07/12/2016 12:35 PM, Martin Babinsky wrote: > On 07/11/2016 12:40 PM, Stanislav Laznicka wrote: >> https://fedorahosted.org/freeipa/ticket/6034 >> >> >> > ACK > master: * 6c74bd2bcca46b586b07c3acd9670dae6e1f07b9 Removed unused method parameter from migrate-ds -- Petr Vobornik From pvoborni at redhat.com Wed Jul 13 16:47:02 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 13 Jul 2016 18:47:02 +0200 Subject: [Freeipa-devel] [PATCH 0184] vault-add: set the default vault type on the client side if none was given In-Reply-To: <686e40a5-9172-1c3f-f44c-98c4963c555d@redhat.com> References: <02cfb321-9f4e-6c79-795e-3d7c9ce64d06@redhat.com> <686e40a5-9172-1c3f-f44c-98c4963c555d@redhat.com> Message-ID: <713c46da-deee-2bc9-1536-9f406223775a@redhat.com> On 07/12/2016 03:53 PM, Stanislav Laznicka wrote: > On 07/12/2016 02:10 PM, Martin Babinsky wrote: >> Quick fix for https://fedorahosted.org/freeipa/ticket/6047 >> >> Note that it depends on mbasti's patch 552 (already acked) otherwise >> client-side vault commands would not be even visible in CLI. >> >> > ACK. > master: * a1a7ecdc7bf6686adf8558cedd3964f9e4805469 vault-add: set the default vault type on the client side if none was given -- Petr Vobornik From lslebodn at redhat.com Wed Jul 13 20:02:58 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 13 Jul 2016 22:02:58 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Bug in the ipapwd plugin In-Reply-To: <57865530.3000602@redhat.com> References: <57865530.3000602@redhat.com> Message-ID: <20160713200257.GA13575@10.4.128.1> On (13/07/16 16:50), thierry bordaz wrote: >https://fedorahosted.org/freeipa/ticket/6030 >>From 4efedc5e674db92f9f7c160429df543422ed8afb Mon Sep 17 00:00:00 2001 >From: Thierry Bordaz >Date: Wed, 13 Jul 2016 15:34:20 +0200 >Subject: [PATCH] Ticket 6030 Bug in the ipapwd plugin > >ipapwd_encrypt_encode_key allocates 'kset' on the heap but >with num_keys and keys not being initialized. >Then ipa_krb5_generate_key_data initializes them with the >generated keys. >If ipa_krb5_generate_key_data fails (here EINVAL meaning no >principal->realm.data), num_keys and keys are left uninitialized. >Upon failure, ipapwd_keyset_free is called to free 'kset' >that contains random num_keys and keys. > >allocates kset with calloc so that kset->num_keys==0 and >kset->keys==NULL > >https://fedorahosted.org/freeipa/ticket/6030 >--- > daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >index 5ca155d..46bf79a 100644 >--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >@@ -148,7 +148,7 @@ Slapi_Value **ipapwd_encrypt_encode_key(struct ipapwd_krbcfg *krbcfg, > pwd.length = strlen(data->password); > } > >- kset = malloc(sizeof(struct ipapwd_keyset)); >+ kset = calloc(sizeof(struct ipapwd_keyset)); I though that calloc need two arguments man malloc says: void *malloc(size_t size); void *calloc(size_t nmemb, size_t size); LS From blipton at redhat.com Wed Jul 13 20:46:38 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 13 Jul 2016 16:46:38 -0400 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos Message-ID: Nothing too exciting, just fixes a few typos I've noticed in comments. Thanks, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0003-Fix-several-small-typos.patch Type: text/x-patch Size: 3228 bytes Desc: not available URL: From ldoudova at redhat.com Thu Jul 14 07:20:36 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 14 Jul 2016 09:20:36 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> Message-ID: On 07/13/2016 04:48 PM, Milan Kub?k wrote: > On 07/11/2016 01:34 PM, Lenka Doudova wrote: >> >> >> >> On 07/08/2016 02:24 PM, Milan Kub?k wrote: >>> On 07/01/2016 05:13 PM, Lenka Doudova wrote: >>>> >>>> >>>> >>>> On 07/01/2016 02:42 PM, Milan Kub?k wrote: >>>>> On 06/16/2016 03:23 PM, Lenka Doudova wrote: >>>>>> Hi, >>>>>> >>>>>> attached are tests for authentication indicators. Please note: >>>>>> >>>>>> 1. newly created service tracker is not exactly complete, list of >>>>>> unimplemented methods is in doc. These methods can be filled in >>>>>> when existing declarative tests are refactored. >>>>>> >>>>>> 2. patch 0015 depends on 0014, so it should not be pushed without >>>>>> it. >>>>>> >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>>> >>>>> >>>>> patch 0014: >>>>> >>>>> In the update method, what happens when the updated attributes >>>>> contain addattr? It is not clear to me. Is it necessary? >>>>> >>>> Example: >>>> ipa service-mod SRV --addattr="authind=radius" >>>> >>>> Result: >>>> The way the tracker works, this adds >>>> /u'addattr="authind=radius"'/ to the list of expected results >>>> (result of /self.attrs.update(updates)/. Of course nothing like >>>> that appears anywhere, so in case there's the /--addattr/ option, >>>> it's necessary to ensure it won't get to the /self.attrs/ atribute. >>>> >>>>> patch 0015: >>>>> >>>>> host1 and service2 do not tell anything about the purpose of the >>>>> fixture. Please assign more descriptive names to them. >>>>> Why do the fixtures have 'function' scope? Does the service entry >>>>> exist during the second and third test case? >>>>> >>>> Renamed. >>>>> >>>>> patch 0016: >>>>> >>>>> Per offline discussion, admin user has no special privileges here, >>>>> LGTM. >>>>> >>>>> -- >>>>> Milan Kubik >>>> >>>> Thanks for review, fixed patches (14.2 and 15.2) attached. >>>> Lenka >>> >>> NACK, >>> >>> the update method of ServiceTracker creates the entry if it doesn't >>> exist. Why? I know the base class has this problem also [1], though. >>> Given this will be addressed, the fixtures in the xmlrpc test will >>> fail since the fixture scope is wrong - function instead of class. >>> >>> [1]: https://fedorahosted.org/freeipa/ticket/6045 >>> >>> -- >>> Milan Kubik >> Hi, >> >> fixed patch attached. I chose to leave the scope as it was (in case >> one test breaks and entry is not even created, the other tests can >> still be successful), but I removed the creation command from >> ServiceTracker update method and called it directly in the tests, so >> there shouldn't be hidden actions. >> >> Lenka > > Thanks for the updated patches. There are still some issues I haven't > noticed before: > > service tracker: track_create method doesn't set self.exists flag > which is needed > > In the xmlrpc test method `test_adding_second_indicator` uses > 'addattr' to set the indicator, why? > > -- > Milan Kubik Hi, fixes for comments in attached patches. After offline discussion, I removed the usage of "addattr" and replaced it with test to add two indicators in one command. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0014.4-Tests-Tracker-class-for-services.patch Type: text/x-patch Size: 7208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0015.4-Tests-Authentication-indicators-xmlrpc-tests.patch Type: text/x-patch Size: 2967 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jul 14 08:06:40 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 14 Jul 2016 11:06:40 +0300 Subject: [Freeipa-devel] [PATCH 0185] messages: specify message type for ResultFormattingError In-Reply-To: <0549e1fe-234d-bcc6-1cf8-632e6bd3454d@redhat.com> References: <0549e1fe-234d-bcc6-1cf8-632e6bd3454d@redhat.com> Message-ID: <20160714080640.yrlzvxlktjh4xuku@redhat.com> On Wed, 13 Jul 2016, Martin Babinsky wrote: >https://fedorahosted.org/freeipa/ticket/6081 > >-- >Martin^3 Babinsky >From dd2dfe4bf0a629716145af83c1b7f73595290079 Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Wed, 13 Jul 2016 18:22:04 +0200 >Subject: [PATCH] messages: specify message type for ResultFormattingError > >the ResultFormattingError message class was missing a `type` member which >could cause `otptoken-add` command to crash during QR image rendering using >suboptimal TTY settings > >https://fedorahosted.org/freeipa/ticket/6081 >--- > ipalib/messages.py | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/ipalib/messages.py b/ipalib/messages.py >index 7288606f6ac923c2c87fadba5f2a6a2d9dadb7f5..6abad64a8259a8e164db60f63e75bbb9c230e7bf 100644 >--- a/ipalib/messages.py >+++ b/ipalib/messages.py >@@ -363,6 +363,7 @@ class ResultFormattingError(PublicMessage): > """ > **13019** Unable to correctly format some part of the result > """ >+ type = "warning" > errno = 13019 > > ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jul 14 08:09:10 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 14 Jul 2016 11:09:10 +0300 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos In-Reply-To: References: Message-ID: <20160714080910.xmcnbqgqvi7evfds@redhat.com> On Wed, 13 Jul 2016, Ben Lipton wrote: >Nothing too exciting, just fixes a few typos I've noticed in comments. ACK. However, please file a ticket and mention it in the commit message. -- / Alexander Bokovoy From ldoudova at redhat.com Thu Jul 14 09:25:34 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 14 Jul 2016 11:25:34 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> Message-ID: <8d55e1b4-794e-db99-eb79-191ff1aee668@redhat.com> On 07/14/2016 09:20 AM, Lenka Doudova wrote: > > > > On 07/13/2016 04:48 PM, Milan Kub?k wrote: >> On 07/11/2016 01:34 PM, Lenka Doudova wrote: >>> >>> >>> >>> On 07/08/2016 02:24 PM, Milan Kub?k wrote: >>>> On 07/01/2016 05:13 PM, Lenka Doudova wrote: >>>>> >>>>> >>>>> >>>>> On 07/01/2016 02:42 PM, Milan Kub?k wrote: >>>>>> On 06/16/2016 03:23 PM, Lenka Doudova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> attached are tests for authentication indicators. Please note: >>>>>>> >>>>>>> 1. newly created service tracker is not exactly complete, list >>>>>>> of unimplemented methods is in doc. These methods can be filled >>>>>>> in when existing declarative tests are refactored. >>>>>>> >>>>>>> 2. patch 0015 depends on 0014, so it should not be pushed >>>>>>> without it. >>>>>>> >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> patch 0014: >>>>>> >>>>>> In the update method, what happens when the updated attributes >>>>>> contain addattr? It is not clear to me. Is it necessary? >>>>>> >>>>> Example: >>>>> ipa service-mod SRV --addattr="authind=radius" >>>>> >>>>> Result: >>>>> The way the tracker works, this adds >>>>> /u'addattr="authind=radius"'/ to the list of expected results >>>>> (result of /self.attrs.update(updates)/. Of course nothing like >>>>> that appears anywhere, so in case there's the /--addattr/ option, >>>>> it's necessary to ensure it won't get to the /self.attrs/ atribute. >>>>> >>>>>> patch 0015: >>>>>> >>>>>> host1 and service2 do not tell anything about the purpose of the >>>>>> fixture. Please assign more descriptive names to them. >>>>>> Why do the fixtures have 'function' scope? Does the service entry >>>>>> exist during the second and third test case? >>>>>> >>>>> Renamed. >>>>>> >>>>>> patch 0016: >>>>>> >>>>>> Per offline discussion, admin user has no special privileges >>>>>> here, LGTM. >>>>>> >>>>>> -- >>>>>> Milan Kubik >>>>> >>>>> Thanks for review, fixed patches (14.2 and 15.2) attached. >>>>> Lenka >>>> >>>> NACK, >>>> >>>> the update method of ServiceTracker creates the entry if it doesn't >>>> exist. Why? I know the base class has this problem also [1], though. >>>> Given this will be addressed, the fixtures in the xmlrpc test will >>>> fail since the fixture scope is wrong - function instead of class. >>>> >>>> [1]: https://fedorahosted.org/freeipa/ticket/6045 >>>> >>>> -- >>>> Milan Kubik >>> Hi, >>> >>> fixed patch attached. I chose to leave the scope as it was (in case >>> one test breaks and entry is not even created, the other tests can >>> still be successful), but I removed the creation command from >>> ServiceTracker update method and called it directly in the tests, so >>> there shouldn't be hidden actions. >>> >>> Lenka >> >> Thanks for the updated patches. There are still some issues I haven't >> noticed before: >> >> service tracker: track_create method doesn't set self.exists flag >> which is needed >> >> In the xmlrpc test method `test_adding_second_indicator` uses >> 'addattr' to set the indicator, why? >> >> -- >> Milan Kubik > > Hi, > fixes for comments in attached patches. > After offline discussion, I removed the usage of "addattr" and > replaced it with test to add two indicators in one command. > > Lenka > > One more problem was pointed out to me offline, attaching changed patch 0014. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0014.5-Tests-Tracker-class-for-services.patch Type: text/x-patch Size: 6392 bytes Desc: not available URL: From ldoudova at redhat.com Thu Jul 14 09:42:07 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 14 Jul 2016 11:42:07 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: <7cea5284-b23d-9f95-2be8-a477274ff98f@redhat.com> References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> <7cea5284-b23d-9f95-2be8-a477274ff98f@redhat.com> Message-ID: On 07/13/2016 05:40 PM, Martin Babinsky wrote: > On 07/01/2016 04:15 PM, Lenka Doudova wrote: >> >> >> On 07/01/2016 02:38 PM, Martin Babinsky wrote: >>> On 07/01/2016 06:36 AM, Lenka Doudova wrote: >>>> >>>> >>>> On 06/30/2016 05:01 PM, Martin Babinsky wrote: >>>>> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>>>>> Hi, >>>>>> >>>>>> attaching patch with some basic coverage for external trust >>>>>> feature. Bit >>>>>> more detailed info in commit message. >>>>>> >>>>>> Since the feature requires me to run commands previously used >>>>>> only for >>>>>> forest root domains even for subdomains, I made some changes in >>>>>> ipatests/test_integration/tasks.py file, so that it would enable >>>>>> me to >>>>>> reuse existing function without copy-pasting them for one variable >>>>>> change. >>>>>> >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>>> >>>>> >>>>> Hi Lenka, >>>>> >>>>> I have a few comments: >>>>> >>>>> 1.) >>>>> >>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>> +def establish_trust_with_ad(master, ad, extra_args=(), >>>>> subdomain=False): >>>>> >>>>> This modification seems extremely kludgy to me. >>>>> >>>>> I would rather change the function signature to: >>>>> >>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >>>>> >>>>> and pass the domain name itself to the function instead of doing >>>>> magic >>>>> inside. The same goes with `remove trust_with_ad`. You may want to >>>>> fix >>>>> the calls to them in existing code so that the domain is passed >>>>> instead of the whole trust object. >>>>> >>>>> 2.) >>>>> >>>>> +def sync_time_hostname(host, srv_hostname): >>>>> + """ >>>>> + Syncs time with the remote server given by its hostname. >>>>> + Please note that this function leaves ntpd stopped. >>>>> + """ >>>>> + host.run_command(['systemctl', 'stop', 'ntpd']) >>>>> + host.run_command(['ntpdate', srv_hostname]) >>>>> + >>>>> + >>>>> >>>>> this looks like a duplicate of the function above it, why is it even >>>>> needed? >>>>> >>>>> 3.) >>>>> +class TestExternalTrustWithSubdomain(ADTrustBase): >>>>> + """ >>>>> + Test establishing external trust with subdomain >>>>> + """ >>>>> + >>>>> + @classmethod >>>>> + def install(cls, mh): >>>>> + super(ADTrustBase, cls).install(mh) >>>>> + cls.ad = cls.ad_domains[0].ads[0] >>>>> + cls.install_adtrust() >>>>> + cls.check_sid_generation() >>>>> + >>>>> + # Determine whether the subdomain AD is available >>>>> + try: >>>>> + child_ad = cls.host_by_role(cls.optional_extra_roles[0]) >>>>> + cls.ad_subdomain = >>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>> + except LookupError: >>>>> + cls.ad_subdomain = None >>>>> + >>>>> + cls.configure_dns_and_time() >>>>> >>>>> Please use proper OOP practices when overriding the behavior of the >>>>> base test class. >>>>> >>>>> For starters you could rewrite the install method like this: >>>>> >>>>> + @classmethod >>>>> + def install(cls, mh): >>>>> + # Determine whether the subdomain AD is available >>>>> + try: >>>>> + cls.child_ad = >>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>> + cls.ad_subdomain = >>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>> + except LookupError: >>>>> + raise nose.SkipTest("AFAIK this will skip the whole test >>>>> class") >>>>> + super(ADTrustBase, cls).install(mh) >>>>> >>>>> with child_ad stored as class attribute, you can override >>>>> `configure_dns_and_time`: >>>>> + def configure_dns_and_time(cls): >>>>> + tasks.configure_dns_for_trust(cls.master, cls.ad_subdomain) >>>>> # no need to re-implement the function just to get to the child >>>>> AD DC hostname now >>>>> + tasks.sync_time(cls.master, cls.child_ad.hostname) >>>>> >>>>> You can then use this class as an intermediary in the hierarchy and >>>>> inherit the other external/non-external trust test classes from it, >>>>> since most setup method in them are just copy-pasted from this one. >>>>> >>>> Hi, >>>> thanks for review, fixed patch attached. >>>> >>>> Lenka >>> >>> Hi Lenka, >>> >>> I am still not happy about the patch underutilizing the potential for >>> a proper inheritance hierarchy and instead relying on a staggering >>> amounts of copy-pasting for implementation. >>> >>> I am attaching a quick untested patch illustrating how the >>> implementation should look like. >>> >>> Also you have some leftovers from previous revision, please fix them: >>> >>> Pylint is running, please wait ... >>> ************* Module ipatests.test_integration.test_trust >>> ipatests/test_integration/test_trust.py:236: [E1101(no-member), >>> TestExternalTrustWithSubdomain.configure_dns_and_time] Module >>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>> ipatests/test_integration/test_trust.py:243: >>> [E1123(unexpected-keyword-arg), >>> TestExternalTrustWithSubdomain.test_establish_trust] Unexpected >>> keyword argument 'subdomain' in function call) >>> ipatests/test_integration/test_trust.py:279: >>> [E1123(unexpected-keyword-arg), >>> TestExternalTrustWithSubdomain.test_remove_nonposix_trust] Unexpected >>> keyword argument 'subdomain' in function call) >>> ipatests/test_integration/test_trust.py:330: [E1101(no-member), >>> TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module >>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>> Makefile:137: recipe for target 'lint' failed >>> make: *** [lint] Error 1 >>> sending incremental file list >>> >>> (this is before I started meddling with it) >>> >>> >> Thank you very much for the example, fixed patch attached. >> Lenka > > Hi Lenka, > > 'TestExternalTrustWithSubdomain' and 'TestExternalTrustWithRootDomain' > suites fail due to incorrectly used '--external' option in the > trust-add command. This option is Boolean, not Flag so it should be > '--external=True'. > Hi, that must have changes since I sent the patch, it was fine before. Anyway, fixed patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0025.4-Tests-External-trust.patch Type: text/x-patch Size: 15486 bytes Desc: not available URL: From ldoudova at redhat.com Thu Jul 14 09:43:28 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 14 Jul 2016 11:43:28 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: <8d55e1b4-794e-db99-eb79-191ff1aee668@redhat.com> References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> <8d55e1b4-794e-db99-eb79-191ff1aee668@redhat.com> Message-ID: On 07/14/2016 11:25 AM, Lenka Doudova wrote: > > > > On 07/14/2016 09:20 AM, Lenka Doudova wrote: >> >> >> >> On 07/13/2016 04:48 PM, Milan Kub?k wrote: >>> On 07/11/2016 01:34 PM, Lenka Doudova wrote: >>>> >>>> >>>> >>>> On 07/08/2016 02:24 PM, Milan Kub?k wrote: >>>>> On 07/01/2016 05:13 PM, Lenka Doudova wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 07/01/2016 02:42 PM, Milan Kub?k wrote: >>>>>>> On 06/16/2016 03:23 PM, Lenka Doudova wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> attached are tests for authentication indicators. Please note: >>>>>>>> >>>>>>>> 1. newly created service tracker is not exactly complete, list >>>>>>>> of unimplemented methods is in doc. These methods can be filled >>>>>>>> in when existing declarative tests are refactored. >>>>>>>> >>>>>>>> 2. patch 0015 depends on 0014, so it should not be pushed >>>>>>>> without it. >>>>>>>> >>>>>>>> >>>>>>>> Lenka >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> patch 0014: >>>>>>> >>>>>>> In the update method, what happens when the updated attributes >>>>>>> contain addattr? It is not clear to me. Is it necessary? >>>>>>> >>>>>> Example: >>>>>> ipa service-mod SRV --addattr="authind=radius" >>>>>> >>>>>> Result: >>>>>> The way the tracker works, this adds >>>>>> /u'addattr="authind=radius"'/ to the list of expected results >>>>>> (result of /self.attrs.update(updates)/. Of course nothing like >>>>>> that appears anywhere, so in case there's the /--addattr/ option, >>>>>> it's necessary to ensure it won't get to the /self.attrs/ atribute. >>>>>> >>>>>>> patch 0015: >>>>>>> >>>>>>> host1 and service2 do not tell anything about the purpose of the >>>>>>> fixture. Please assign more descriptive names to them. >>>>>>> Why do the fixtures have 'function' scope? Does the service >>>>>>> entry exist during the second and third test case? >>>>>>> >>>>>> Renamed. >>>>>>> >>>>>>> patch 0016: >>>>>>> >>>>>>> Per offline discussion, admin user has no special privileges >>>>>>> here, LGTM. >>>>>>> >>>>>>> -- >>>>>>> Milan Kubik >>>>>> >>>>>> Thanks for review, fixed patches (14.2 and 15.2) attached. >>>>>> Lenka >>>>> >>>>> NACK, >>>>> >>>>> the update method of ServiceTracker creates the entry if it >>>>> doesn't exist. Why? I know the base class has this problem also >>>>> [1], though. >>>>> Given this will be addressed, the fixtures in the xmlrpc test will >>>>> fail since the fixture scope is wrong - function instead of class. >>>>> >>>>> [1]: https://fedorahosted.org/freeipa/ticket/6045 >>>>> >>>>> -- >>>>> Milan Kubik >>>> Hi, >>>> >>>> fixed patch attached. I chose to leave the scope as it was (in case >>>> one test breaks and entry is not even created, the other tests can >>>> still be successful), but I removed the creation command from >>>> ServiceTracker update method and called it directly in the tests, >>>> so there shouldn't be hidden actions. >>>> >>>> Lenka >>> >>> Thanks for the updated patches. There are still some issues I >>> haven't noticed before: >>> >>> service tracker: track_create method doesn't set self.exists flag >>> which is needed >>> >>> In the xmlrpc test method `test_adding_second_indicator` uses >>> 'addattr' to set the indicator, why? >>> >>> -- >>> Milan Kubik >> >> Hi, >> fixes for comments in attached patches. >> After offline discussion, I removed the usage of "addattr" and >> replaced it with test to add two indicators in one command. >> >> Lenka >> >> > One more problem was pointed out to me offline, attaching changed > patch 0014. > > Lenka > > > Resending the complete patch set. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0014.5-Tests-Tracker-class-for-services.patch Type: text/x-patch Size: 6392 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0015.4-Tests-Authentication-indicators-xmlrpc-tests.patch Type: text/x-patch Size: 2967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0016-Tests-Authentication-indicators-integration-tests.patch Type: text/x-patch Size: 3216 bytes Desc: not available URL: From dkupka at redhat.com Thu Jul 14 11:21:43 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 14 Jul 2016 13:21:43 +0200 Subject: [Freeipa-devel] [PATCH 0110] schema: Fix subtopic -> topic mapping Message-ID: <23c576a4-ce34-468f-a9fb-d9061e6410ce@redhat.com> https://fedorahosted.org/freeipa/ticket/6069 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0110.0-schema-Fix-subtopic-topic-mapping.patch Type: text/x-patch Size: 1074 bytes Desc: not available URL: From ftweedal at redhat.com Thu Jul 14 11:44:36 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 14 Jul 2016 21:44:36 +1000 Subject: [Freeipa-devel] [PATCH] cert-show: show subject alternative names Message-ID: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> Hi all, The attached patch includes SANs in cert-show output. If you have certs with esoteric altnames (especially any that are more than just ASN.1 string types), please test with those certs. https://fedorahosted.org/freeipa/ticket/6022 Thanks, Fraser -------------- next part -------------- From f56d698009f32a1b8760048848117148164fad33 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 14 Jul 2016 21:36:33 +1000 Subject: [PATCH] cert-show: show subject alternative names Update the cert-show command to return subject alternative name values. Also move GeneralName parsing code from ipalib.pkcs10 to ipalib.x509. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/pkcs10.py | 93 ++----------------------------------- ipalib/x509.py | 114 +++++++++++++++++++++++++++++++++++++++++++++- ipaserver/plugins/cert.py | 28 ++++++++++-- 3 files changed, 140 insertions(+), 95 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -22,9 +22,10 @@ from __future__ import print_function import sys import base64 import nss.nss as nss -from pyasn1.type import univ, char, namedtype, tag +from pyasn1.type import univ, namedtype, tag from pyasn1.codec.der import decoder import six +from ipalib import x509 if six.PY3: unicode = str @@ -32,11 +33,6 @@ if six.PY3: PEM = 0 DER = 1 -SAN_DNSNAME = 'DNS name' -SAN_RFC822NAME = 'RFC822 Name' -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' - def get_subject(csr, datatype=PEM): """ Given a CSR return the subject value. @@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM): return tuple(get_prefixed_oid_str(ext)[4:] for ext in request.extensions) -class _PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('name-type', univ.Integer().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -class _KRB5PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('realm', char.GeneralString().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('principalName', _PrincipalName().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -def _decode_krb5principalname(data): - principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] - realm = (str(principal['realm']).replace('\\', '\\\\') - .replace('@', '\\@')) - name = principal['principalName']['name-string'] - name = '/'.join(str(n).replace('\\', '\\\\') - .replace('/', '\\/') - .replace('@', '\\@') for n in name) - name = '%s@%s' % (name, realm) - return name - -class _AnotherName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('type-id', univ.ObjectIdentifier()), - namedtype.NamedType('value', univ.Any().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - ) - -class _GeneralName(univ.Choice): - componentType = namedtype.NamedTypes( - namedtype.NamedType('otherName', _AnotherName().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('rfc822Name', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - namedtype.NamedType('dNSName', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) - ), - namedtype.NamedType('x400Address', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) - ), - namedtype.NamedType('directoryName', univ.Choice().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) - ), - namedtype.NamedType('ediPartyName', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) - ), - namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) - ), - namedtype.NamedType('iPAddress', univ.OctetString().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) - ), - namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) - ), - ) - -class _SubjectAltName(univ.SequenceOf): - componentType = _GeneralName() def get_subjectaltname(csr, datatype=PEM): """ @@ -159,19 +83,8 @@ def get_subjectaltname(csr, datatype=PEM): return None del request - nss_names = nss.x509_alt_name(extension.value, nss.AsObject) - asn1_names = decoder.decode(extension.value.data, - asn1Spec=_SubjectAltName())[0] - names = [] - for nss_name, asn1_name in zip(nss_names, asn1_names): - name_type = nss_name.type_string - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: - name = _decode_krb5principalname(asn1_name['otherName']['value']) - else: - name = nss_name.name - names.append((name_type, name)) + return x509.decode_generalnames(extension.value) - return tuple(names) # Unfortunately, NSS can only parse the extension request attribute, so # we have to parse friendly name ourselves (see RFC 2986) diff --git a/ipalib/x509.py b/ipalib/x509.py index 82194922d151a1b0f2df03df3578ad45b43b71c9..15168de08240a84794efef409d022eaa983291c9 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -40,7 +40,7 @@ import re import nss.nss as nss from nss.error import NSPRError -from pyasn1.type import univ, namedtype, tag +from pyasn1.type import univ, char, namedtype, tag from pyasn1.codec.der import decoder, encoder import six @@ -63,6 +63,11 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' EKU_ANY = '2.5.29.37.0' EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' +SAN_DNSNAME = 'DNS name' +SAN_RFC822NAME = 'RFC822 Name' +SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' +SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' + _subject_base = None def subject_base(): @@ -374,6 +379,113 @@ def encode_ext_key_usage(ext_key_usage): eku = encoder.encode(eku) return _encode_extension('2.5.29.37', EKU_ANY not in ext_key_usage, eku) + +class _AnotherName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('type-id', univ.ObjectIdentifier()), + namedtype.NamedType('value', univ.Any().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + ) + + +class _GeneralName(univ.Choice): + componentType = namedtype.NamedTypes( + namedtype.NamedType('otherName', _AnotherName().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('rfc822Name', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + namedtype.NamedType('dNSName', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) + ), + namedtype.NamedType('x400Address', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) + ), + namedtype.NamedType('directoryName', univ.Choice().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) + ), + namedtype.NamedType('ediPartyName', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) + ), + namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) + ), + namedtype.NamedType('iPAddress', univ.OctetString().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) + ), + namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) + ), + ) + + +class _SubjectAltName(univ.SequenceOf): + componentType = _GeneralName() + + +class _PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('name-type', univ.Integer().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +class _KRB5PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('realm', char.GeneralString().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('principalName', _PrincipalName().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +def _decode_krb5principalname(data): + principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] + realm = (str(principal['realm']).replace('\\', '\\\\') + .replace('@', '\\@')) + name = principal['principalName']['name-string'] + name = '/'.join(str(n).replace('\\', '\\\\') + .replace('/', '\\/') + .replace('@', '\\@') for n in name) + name = '%s@%s' % (name, realm) + return name + + +def decode_generalnames(secitem): + """ + Decode a GeneralNames object (this the data for the Subject + Alt Name and Issuer Alt Name extensions, among others). + + ``secitem`` + The input is the DER-encoded extension data, without the + OCTET STRING header, as an nss SecItem object. + + Return a list of tuples of name types (as string, suitable for + presentation) and names (as string, suitable for presentation). + + """ + nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) + asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] + names = [] + for nss_name, asn1_name in zip(nss_names, asn1_names): + name_type = nss_name.type_string + if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: + name = _decode_krb5principalname(asn1_name['otherName']['value']) + else: + name = nss_name.name + names.append((name_type, name)) + + return names + + if __name__ == '__main__': # this can be run with: # python ipalib/x509.py < /etc/ipa/ca.crt diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 06041d3083565e8d093b610473d6083111d406d2..2a7c007e237a75f8a441e9056cdeb55191a147f9 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -293,6 +293,11 @@ class BaseCertObject(Object): label=_('Serial number (hex)'), flags={'no_create', 'no_update', 'no_search'}, ), + Str( + 'subject_alt_name*', + label=_('Subject Alternative Name'), + flags={'no_create', 'no_update', 'no_search'}, + ), ) def _parse(self, obj): @@ -307,6 +312,21 @@ class BaseCertObject(Object): nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) obj['serial_number'] = cert.serial_number obj['serial_number_hex'] = u'0x%X' % cert.serial_number + try: + type_strings = { + x509.SAN_DNSNAME: 'DNS', + x509.SAN_RFC822NAME: 'Email', + x509.SAN_OTHERNAME_UPN: 'UPN', + x509.SAN_OTHERNAME_KRB5PRINCIPALNAME: 'Kerberos Principal', + } + ext_san = cert.get_extension(nss.SEC_OID_X509_SUBJECT_ALT_NAME) + general_names = x509.decode_generalnames(ext_san.value) + obj['subject_alt_name'] = [ + '{}: {}'.format(type_strings.get(name_type, name_type), name) + for name_type, name in general_names + ] + except KeyError: + pass class BaseCertMethod(Method): @@ -535,7 +555,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): # Validate the subject alt name, if any for name_type, name in subjectaltname: - if name_type == pkcs10.SAN_DNSNAME: + if name_type == x509.SAN_DNSNAME: name = unicode(name) alt_principal_obj = None alt_principal_string = unicode(principal) @@ -566,13 +586,13 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "with subject alt name '%s'.") % name) if alt_principal_string is not None and not bypass_caacl: caacl_check(principal_type, principal, ca, profile_id) - elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, - pkcs10.SAN_OTHERNAME_UPN): + elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, + x509.SAN_OTHERNAME_UPN): if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) - elif name_type == pkcs10.SAN_RFC822NAME: + elif name_type == x509.SAN_RFC822NAME: if principal_type == USER: if name not in principal_obj.get('mail', []): raise errors.ValidationError( -- 2.5.5 From slaznick at redhat.com Thu Jul 14 12:36:33 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 14 Jul 2016 14:36:33 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument Message-ID: Hello, This patch fixes https://fedorahosted.org/freeipa/ticket/5640. With not so much experience with the framework, it raises question in my head whether ipaldap.get_entries is used properly throughout the system - does it always assume that it gets ALL the requested entries or just a few of those as configured by the 'ipaSearchRecordsLimit' attribute of ipaConfig.etc which it actually gets? One spot that I know the get_entries method was definitely not used properly before this patch is in the baseldap.LDAPObject.get_memberindirect() method: 692 result = self.backend.get_entries( 693 self.api.env.basedn, 694 filter=filter, 695 attrs_list=['member'], 696 size_limit=-1, # paged search will get everything anyway 697 paged_search=True) which to me seems kind of important if the environment size_limit is not set properly :) The patch does not fix the non-propagation of the paged_search, though. Cheers, Standa -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0058-Make-get_entries-not-ignore-size_limit-argument.patch Type: text/x-patch Size: 2511 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Jul 14 13:09:55 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 14 Jul 2016 15:09:55 +0200 Subject: [Freeipa-devel] [PATCH 0110] schema: Fix subtopic -> topic mapping In-Reply-To: <23c576a4-ce34-468f-a9fb-d9061e6410ce@redhat.com> References: <23c576a4-ce34-468f-a9fb-d9061e6410ce@redhat.com> Message-ID: <61277b2c-5f09-00d0-4520-3a32a046ef76@redhat.com> On 07/14/2016 01:21 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/6069 > > ACK. -- Martin^3 Babinsky From mkubik at redhat.com Thu Jul 14 13:11:01 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 14 Jul 2016 15:11:01 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> <8d55e1b4-794e-db99-eb79-191ff1aee668@redhat.com> Message-ID: <75ecc1a1-c135-e89a-24a9-e51eea97cc26@redhat.com> On 07/14/2016 11:43 AM, Lenka Doudova wrote: > > > > On 07/14/2016 11:25 AM, Lenka Doudova wrote: >> >> >> >> On 07/14/2016 09:20 AM, Lenka Doudova wrote: >>> >>> >>> >>> On 07/13/2016 04:48 PM, Milan Kub?k wrote: >>>> On 07/11/2016 01:34 PM, Lenka Doudova wrote: >>>>> >>>>> >>>>> >>>>> On 07/08/2016 02:24 PM, Milan Kub?k wrote: >>>>>> On 07/01/2016 05:13 PM, Lenka Doudova wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 07/01/2016 02:42 PM, Milan Kub?k wrote: >>>>>>>> On 06/16/2016 03:23 PM, Lenka Doudova wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> attached are tests for authentication indicators. Please note: >>>>>>>>> >>>>>>>>> 1. newly created service tracker is not exactly complete, list >>>>>>>>> of unimplemented methods is in doc. These methods can be >>>>>>>>> filled in when existing declarative tests are refactored. >>>>>>>>> >>>>>>>>> 2. patch 0015 depends on 0014, so it should not be pushed >>>>>>>>> without it. >>>>>>>>> >>>>>>>>> >>>>>>>>> Lenka >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> patch 0014: >>>>>>>> >>>>>>>> In the update method, what happens when the updated attributes >>>>>>>> contain addattr? It is not clear to me. Is it necessary? >>>>>>>> >>>>>>> Example: >>>>>>> ipa service-mod SRV --addattr="authind=radius" >>>>>>> >>>>>>> Result: >>>>>>> The way the tracker works, this adds >>>>>>> /u'addattr="authind=radius"'/ to the list of expected results >>>>>>> (result of /self.attrs.update(updates)/. Of course nothing like >>>>>>> that appears anywhere, so in case there's the /--addattr/ >>>>>>> option, it's necessary to ensure it won't get to the >>>>>>> /self.attrs/ atribute. >>>>>>> >>>>>>>> patch 0015: >>>>>>>> >>>>>>>> host1 and service2 do not tell anything about the purpose of >>>>>>>> the fixture. Please assign more descriptive names to them. >>>>>>>> Why do the fixtures have 'function' scope? Does the service >>>>>>>> entry exist during the second and third test case? >>>>>>>> >>>>>>> Renamed. >>>>>>>> >>>>>>>> patch 0016: >>>>>>>> >>>>>>>> Per offline discussion, admin user has no special privileges >>>>>>>> here, LGTM. >>>>>>>> >>>>>>>> -- >>>>>>>> Milan Kubik >>>>>>> >>>>>>> Thanks for review, fixed patches (14.2 and 15.2) attached. >>>>>>> Lenka >>>>>> >>>>>> NACK, >>>>>> >>>>>> the update method of ServiceTracker creates the entry if it >>>>>> doesn't exist. Why? I know the base class has this problem also >>>>>> [1], though. >>>>>> Given this will be addressed, the fixtures in the xmlrpc test >>>>>> will fail since the fixture scope is wrong - function instead of >>>>>> class. >>>>>> >>>>>> [1]: https://fedorahosted.org/freeipa/ticket/6045 >>>>>> >>>>>> -- >>>>>> Milan Kubik >>>>> Hi, >>>>> >>>>> fixed patch attached. I chose to leave the scope as it was (in >>>>> case one test breaks and entry is not even created, the other >>>>> tests can still be successful), but I removed the creation command >>>>> from ServiceTracker update method and called it directly in the >>>>> tests, so there shouldn't be hidden actions. >>>>> >>>>> Lenka >>>> >>>> Thanks for the updated patches. There are still some issues I >>>> haven't noticed before: >>>> >>>> service tracker: track_create method doesn't set self.exists flag >>>> which is needed >>>> >>>> In the xmlrpc test method `test_adding_second_indicator` uses >>>> 'addattr' to set the indicator, why? >>>> >>>> -- >>>> Milan Kubik >>> >>> Hi, >>> fixes for comments in attached patches. >>> After offline discussion, I removed the usage of "addattr" and >>> replaced it with test to add two indicators in one command. >>> >>> Lenka >>> >>> >> One more problem was pointed out to me offline, attaching changed >> patch 0014. >> >> Lenka >> >> >> > Resending the complete patch set. > L. > > Thanks, ACK. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldoudova at redhat.com Thu Jul 14 13:39:58 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 14 Jul 2016 15:39:58 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <76514b4d-63fe-f6e1-31a5-b1aff62b728a@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> <84d6fa1f-265c-9408-3ecd-65c640da1793@redhat.com> <76514b4d-63fe-f6e1-31a5-b1aff62b728a@redhat.com> Message-ID: <42931f20-6a19-f506-6982-c3c7be722553@redhat.com> On 07/13/2016 06:04 PM, Martin Babinsky wrote: > On 07/01/2016 04:45 PM, Lenka Doudova wrote: >> >> >> On 07/01/2016 03:04 PM, Martin Babinsky wrote: >>> On 07/01/2016 11:13 AM, Lenka Doudova wrote: >>>> And, of course, a patch file :) >>>> >>>> >>>> On 07/01/2016 11:09 AM, Lenka Doudova wrote: >>>>> Hi all, >>>>> >>>>> here's patch with basic test suite for support of UPN. >>>>> >>>>> Note: it needs to be applied on top of my patch 0025.2 (or later, if >>>>> there's will be more fixes to that patch). >>>>> >>>>> >>>>> Lenka >>>>> >>>> >>>> >>>> >>> >>> Hi Lenka, >>> >>> test data such as usernames, etc. should be stored either in separate >>> resource files or at least as class attributes like this: >>> >>> diff --git a/ipatests/test_integration/test_trust.py >>> b/ipatests/test_integration/test_trust.py >>> index e8fdc6b..86ba7cc 100644 >>> --- a/ipatests/test_integration/test_trust.py >>> +++ b/ipatests/test_integration/test_trust.py >>> @@ -394,28 +394,33 @@ class TestTrustWithUPN(ADTrustBase): >>> """ >>> Test support of UPN for trusted domains >>> """ >>> + upn_suffix = 'UPNsuffix.com' >>> + upn_username = 'upnuser' >>> + upn_princ = '{}@{}'.format(upn_username, upn_suffix) >>> + upn_password = 'Secret123456' >>> + >>> def test_upn_in_nonposix_trust(self): >>> """ Check that UPN is listed as trust attribute """ >>> result = self.master.run_command(['ipa', 'trust-show', >>> self.ad_domain, >>> '--all', '--raw']) >>> >>> - assert "ipantadditionalsuffixes: UPNsuffix.com" in >>> result.stdout_text >>> + assert ("ipantadditionalsuffixes: >>> {}".format(self.upn_suffix) in >>> + result.stdout_text) >>> >>> def test_upn_user_resolution_in_nonposix_trust(self): >>> """ Check that user with UPN can be resolved """ >>> - upnuser = 'upnuser at UPNsuffix.com' >>> - result = self.master.run_command(['getent', 'passwd', >>> upnuser]) >>> + result = self.master.run_command(['getent', 'passwd', >>> self.upn_princ]) >>> >>> # result will contain AD domain, not UPN >>> - upnuser_regex = "^upnuser@{0}:\*:(\d+):(\d+):UPN >>> User:/:$".format( >>> - self.ad_domain) >>> + upnuser_regex = "^{}@{}:\*:(\d+):(\d+):UPN User:/:$".format( >>> + self.upn_username, self.ad_domain) >>> assert re.search(upnuser_regex, result.stdout_text) >>> >>> def test_upn_user_authentication(self): >>> """ Check that AD user with UPN can authenticate in IPA """ >>> self.master.run_command(['systemctl', 'restart', 'krb5kdc']) >>> - self.master.run_command(['kinit', '-C', '-E', >>> 'upnuser at UPNsuffix.com'], >>> - stdin_text='Secret123456') >>> + self.master.run_command(['kinit', '-C', '-E', self.upn_princ], >>> + stdin_text=self.upn_password) >>> >>> otherwise LGTM. >>> >> Thanks for review, fixed patch attached. >> >> Few notes: >> 1. mbabinsky's suggestion to store testdata as class attributes or >> separate resource file: I decided to use the class attribute approach. >> The separate resource file is a nice idea, which I have already put on >> my "to do" list - there's a lot of hardcoded stuff in the trust tests, >> even in the original ones (before my patches), so when there's time I'll >> work on a way how to dynamically provide this data as test configuration >> 2. previous discussion about getent vs. pwd.getpwnam(): I'll leave the >> getent command, since according to mbasti the alternative would not work >> in CI. >> >> Lenka > > Hi Lenka, > > I am not sure 'test_all_trustdomains_found' should be run as a part of > this test suite. Maybe yes, I'm not sure. > > Also I would add a 60 second sleep after KDC restart in > 'test_upn_user_authentication' so that MS-PAC cache gets refreshed > before trying to kinit as enterprise principal. > > Two of the tests fail on my setup but that is probably due to > https://fedorahosted.org/freeipa/ticket/6082 . > Hi, the "test_all_trustdomains_found" method is inherited from parent class, and I believe it cannot hurt to have it there. I added the sleep as you requested. I also tried to run the tests with two way trust and since everything was fine then, the failures you experienced are really most likely due to the oddjob issue you linked. Of course the patch still contains tests with one way trusts, so until the oddjob issue is solved, the tests will probably fail, and should be fine once the fix is provided. Fixed patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0026.3-Tests-Support-of-UPN-for-trusted-domains.patch Type: text/x-patch Size: 3035 bytes Desc: not available URL: From blipton at redhat.com Thu Jul 14 14:11:06 2016 From: blipton at redhat.com (Ben Lipton) Date: Thu, 14 Jul 2016 10:11:06 -0400 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos In-Reply-To: <20160714080910.xmcnbqgqvi7evfds@redhat.com> References: <20160714080910.xmcnbqgqvi7evfds@redhat.com> Message-ID: On 07/14/2016 04:09 AM, Alexander Bokovoy wrote: > On Wed, 13 Jul 2016, Ben Lipton wrote: >> Nothing too exciting, just fixes a few typos I've noticed in comments. > ACK. However, please file a ticket and mention it in the commit message. > > Thanks, updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0003-2-Fix-several-small-typos.patch Type: text/x-patch Size: 3280 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Jul 14 15:51:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 14 Jul 2016 17:51:36 +0200 Subject: [Freeipa-devel] [PATCH 0186] DNS install: Ensure that DNS servers container exists Message-ID: https://fedorahosted.org/freeipa/ticket/6083 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0186-DNS-install-Ensure-that-DNS-servers-container-exists.patch Type: text/x-patch Size: 3523 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jul 15 05:04:48 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 15 Jul 2016 15:04:48 +1000 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name Message-ID: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> The attached patch is a work in progress for https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). I am sharing now to make the approach clear and solicit feedback. It has been tested for server install, replica install (with and without CA) and CA-replica install (all hosts running master+patch). Migration from earlier versions and server/replica/CA install on a CA-less deployment are not yet tested; these will be tested over coming days and patch will be tweaked as necessary. Commit message has a fair bit to say so I won't repeat here but let me know your questions and comments. Thanks, Fraser From ftweedal at redhat.com Fri Jul 15 05:05:39 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 15 Jul 2016 15:05:39 +1000 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name In-Reply-To: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> Message-ID: <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > The attached patch is a work in progress for > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > I am sharing now to make the approach clear and solicit feedback. > > It has been tested for server install, replica install (with and > without CA) and CA-replica install (all hosts running master+patch). > > Migration from earlier versions and server/replica/CA install on a > CA-less deployment are not yet tested; these will be tested over > coming days and patch will be tweaked as necessary. > > Commit message has a fair bit to say so I won't repeat here but let > me know your questions and comments. > > Thanks, > Fraser > It does help to attach the patch, of course ^_^ -------------- next part -------------- From 74102e13b041cd05396a579f12f26a9f80394ad1 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Jul 2016 12:57:11 +1000 Subject: [PATCH] Allow full customisability of IPA CA subject DN Currently only the "subject base" of the IPA CA subject DN can be customised via the installer's --subject option. The RDN "CN=Certificate Authority" is appended to form the subject DN, and this composition is widely assumed, hardcoded in many places. Some administrators need more control over the CA subject DN, especially to satisfy expectations of external CAs when the IPA CA is to be externally signed. This patch adds full customisability of the CA subject DN. The --subject argument can now be the full DN, and the subject base is derived from it. The full rules are as follows: - If --subject is not given, default to "CN=Certificate Authority, O=$REALM" (existing behaviour) - If --external-ca is used, subject is used as-is. - If and only if --external-ca is not used, to meet Dogtag's expectations, the "most specific" CN AVA encountered shall be the most specific RDN (it is moved if necessary); if the subject DN does not contain a CN AVA, then "CN=Certificate Authority" is appended. - The subject base is derived from the subject (after processing per preceding points) by extracting OU, O, L, ST, C and DC AVAs, preserving relative order. If the resulting DN is empty, it defaults to "O=$REALM". Fixes: https://fedorahosted.org/freeipa/ticket/2614 --- install/share/certmap.conf.template | 2 +- install/tools/ipa-ca-install | 14 +++++------- install/tools/man/ipa-server-install.1 | 2 +- ipapython/ipautil.py | 20 +++++++++++++++++ ipaserver/install/ca.py | 20 +++++++++-------- ipaserver/install/cainstance.py | 35 ++++++++++++++++++------------ ipaserver/install/certs.py | 9 ++++---- ipaserver/install/dsinstance.py | 29 +++++++++++++++---------- ipaserver/install/installutils.py | 35 +++++++++++++++++++++++++++--- ipaserver/install/ipa_cacert_manage.py | 9 ++++++-- ipaserver/install/krainstance.py | 9 +++++--- ipaserver/install/server/common.py | 4 ++-- ipaserver/install/server/install.py | 17 ++++++++++----- ipaserver/install/server/replicainstall.py | 27 ++++++++++++++++------- 14 files changed, 159 insertions(+), 73 deletions(-) diff --git a/install/share/certmap.conf.template b/install/share/certmap.conf.template index e76bf3c653a4f1d130ce8c264a28cac5dc63925c..d59b095faff804eae4cbd2ef984aa8ca3be52946 100644 --- a/install/share/certmap.conf.template +++ b/install/share/certmap.conf.template @@ -41,6 +41,6 @@ certmap default default #default:InitFn default:DNComps default:FilterComps uid -certmap ipaca CN=Certificate Authority,$SUBJECT_BASE +certmap ipaca $ISSUER_DN ipaca:CmapLdapAttr seeAlso ipaca:verifycert on diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install index ed685920cbadb9cd3fc80865afb1610ca42f8b13..8a8adb3984386bb88227d769a8c5132bb121b870 100755 --- a/install/tools/ipa-ca-install +++ b/install/tools/ipa-ca-install @@ -32,7 +32,7 @@ from ipaserver.install import bindinstance, dsinstance, ca from ipaserver.install import cainstance, custodiainstance, service from ipapython import version from ipalib import api -from ipalib.constants import DOMAIN_LEVEL_0 +from ipalib.constants import DOMAIN_LEVEL_0, IPA_CA_CN from ipapython.dn import DN from ipapython.config import IPAOptionParser from ipapython.ipa_log_manager import root_logger, standard_logging_setup @@ -160,9 +160,7 @@ def install_replica(safe_options, options, filename): conn.connect(bind_dn=DN(('cn', 'Directory Manager')), bind_pw=dirman_password) - if config.subject_base is None: - attrs = conn.get_ipa_config() - config.subject_base = attrs.get('ipacertificatesubjectbase')[0] + subject = api.Command.ca_show(IPA_CA_CN)['result']['ipacasubjectdn'][0] if config.master_host_name is None: config.ca_host_name = \ @@ -175,7 +173,7 @@ def install_replica(safe_options, options, filename): options.domain_name = config.domain_name options.dm_password = config.dirman_password options.host_name = config.host_name - options.subject = config.subject_base + options.subject = subject if os.path.exists(cafile): options.ca_cert_file = cafile else: @@ -193,7 +191,7 @@ def install_replica(safe_options, options, filename): host_name=config.host_name, dm_password=config.dirman_password) CA.configure_replica(config.ca_host_name, - subject_base=config.subject_base, + subject=subject, ca_cert_bundle=ca_data) # Install CA DNS records if bindinstance.dns_container_exists(api.env.host, api.env.basedn, @@ -220,13 +218,13 @@ def install_master(safe_options, options): bind_pw=dm_password) config = api.Command['config_show']()['result'] - subject_base = config['ipacertificatesubjectbase'][0] + subject = api.Command.ca_show(IPA_CA_CN)['result']['ipacasubjectdn'] options.realm_name = api.env.realm options.domain_name = api.env.domain options.dm_password = dm_password options.host_name = api.env.host - options.subject = subject_base + options.subject = subject ca.install_check(True, None, options) ca.install(True, None, options) diff --git a/install/tools/man/ipa-server-install.1 b/install/tools/man/ipa-server-install.1 index 55b49449e3c44aebfeefe5cb71d73e9abf07c5b2..775427de1a2a220fb01dc7b8892105dd40bf182d 100644 --- a/install/tools/man/ipa-server-install.1 +++ b/install/tools/man/ipa-server-install.1 @@ -130,7 +130,7 @@ Name of the Kerberos KDC SSL certificate to install File containing the CA certificate of the CA which issued the Directory Server, Apache Server and Kerberos KDC certificates. The file is accepted in PEM and DER certificate and PKCS#7 certificate chain formats. This option may be used multiple times. Use this option if the CA certificate is not present in the certificate files. .TP \fB\-\-subject\fR=\fISUBJECT\fR -The certificate subject base (default O=REALM.NAME) +The CA certificate subject DN (default CN=Certificate Authority,O=REALM.NAME) .TP \fB\-\-ca\-signing\-algorithm\fR=\fIALGORITHM\fR Signing algorithm of the IPA CA certificate. Possible values are SHA1withRSA, SHA256withRSA, SHA512withRSA. Default value is SHA256withRSA. Use this option with --external-ca if the external CA does not support the default signing algorithm. diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py index 763a99c117e22a4ac49d8d34b38230f3da7c8435..b2c5a9adf57522bb28583c03eb60ce74c4d14868 100644 --- a/ipapython/ipautil.py +++ b/ipapython/ipautil.py @@ -1469,3 +1469,23 @@ def is_fips_enabled(): # Consider that the host is not fips-enabled if the file does not exist pass return False + + +def extract_ca_subject_base(dn, realm_name): + """ + Extract a base DN from the given CA subject DN. + + Components extracted are OU, O, L, ST, C, DC. Relative order + is retained. If none of those attributes are present, return + O=. + + """ + base_attrs = ['ou', 'o', 'l', 'st', 'c', 'dc'] + l = [] + for rdn in DN(dn): + for ava in rdn: + if ava.attr.lower() in base_attrs: + l.append(ava) + if len(l) == 0: + l = [('O', realm_name)] + return DN(*l) diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py index bce804ac1c4e3eaf8dd08bed894ad45ea2d73ae1..e2d12e829ff24d2d317ed4d136363df35c40d07c 100644 --- a/ipaserver/install/ca.py +++ b/ipaserver/install/ca.py @@ -26,7 +26,8 @@ def install_check(standalone, replica_config, options): realm_name = options.realm_name host_name = options.host_name - subject_base = options.subject + subject_dn = options.subject + subject_base = ipautil.extract_ca_subject_base(subject_dn, realm_name) if replica_config is not None: if standalone and api.env.ra_plugin == 'selfsign': @@ -106,7 +107,7 @@ def install_check(standalone, replica_config, options): if not cert: continue subject = DN(str(x509.get_subject(cert))) - if subject in (DN('CN=Certificate Authority', subject_base), + if subject in (DN(subject_dn), DN('CN=IPA RA', subject_base), DN('CN=Object Signing Cert', subject_base)): print(("Certificate with subject %s is present in %s, " @@ -124,7 +125,6 @@ def install_step_0(standalone, replica_config, options): domain_name = options.domain_name dm_password = options.dm_password host_name = options.host_name - subject_base = options.subject if replica_config is not None: # Configure the CA if necessary @@ -136,8 +136,10 @@ def install_step_0(standalone, replica_config, options): if standalone: api.Backend.ldap2.disconnect() - cainstance.install_replica_ca(replica_config, postinstall, - ra_p12=getattr(options, 'ra_p12', None)) + cainstance.install_replica_ca( + replica_config, postinstall, + ra_p12=getattr(options, 'ra_p12', None), + subject=options.subject) if standalone and not api.Backend.ldap2.isconnected(): api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')), @@ -157,19 +159,19 @@ def install_step_0(standalone, replica_config, options): ca.create_ra_agent_db = False if external == 0: ca.configure_instance(host_name, dm_password, - dm_password, subject_base=subject_base, + dm_password, subject=options.subject, ca_signing_algorithm=options.ca_signing_algorithm) elif external == 1: ca.configure_instance(host_name, dm_password, dm_password, csr_file=paths.ROOT_IPA_CSR, - subject_base=subject_base, + subject=options.subject, ca_signing_algorithm=options.ca_signing_algorithm, ca_type=options.external_ca_type) else: ca.configure_instance(host_name, dm_password, dm_password, cert_file=external_cert_file.name, cert_chain_file=external_ca_file.name, - subject_base=subject_base, + subject=options.subject, ca_signing_algorithm=options.ca_signing_algorithm) @@ -178,7 +180,7 @@ def install_step_1(standalone, replica_config, options): domain_name = options.domain_name dm_password = options.dm_password host_name = options.host_name - subject_base = options.subject + subject_base = ipautil.extract_ca_subject_base(options.subject, realm_name) basedn = ipautil.realm_to_suffix(realm_name) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 070498fe8a394802ea55f848a268e2b6563ec472..afeb8007f47571f1de38f190e64cb6cae52b3d98 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -344,7 +344,7 @@ class CAInstance(DogtagInstance): pkcs12_info=None, master_host=None, csr_file=None, cert_file=None, cert_chain_file=None, master_replication_port=None, - subject_base=None, ca_signing_algorithm=None, + subject=None, ca_signing_algorithm=None, ca_type=None, ra_p12=None): """Create a CA instance. @@ -364,10 +364,14 @@ class CAInstance(DogtagInstance): self.clone = True self.master_host = master_host self.master_replication_port = master_replication_port - if subject_base is None: - self.subject_base = DN(('O', self.realm)) + + if subject is None: + self.subject = installutils.default_ca_subject_dn(self.realm) else: - self.subject_base = subject_base + self.subject = subject + self.subject_base = ipautil.extract_ca_subject_base( + self.subject, self.realm) + if ca_signing_algorithm is None: self.ca_signing_algorithm = 'SHA256withRSA' else: @@ -501,7 +505,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_audit_signing_subject_dn", str(DN(('cn', 'CA Audit'), self.subject_base))) config.set("CA", "pki_ca_signing_subject_dn", - str(DN(('cn', 'Certificate Authority'), self.subject_base))) + str(self.subject)) # Certificate nicknames config.set("CA", "pki_subsystem_nickname", "subsystemCert cert-pki-ca") @@ -775,7 +779,7 @@ class CAInstance(DogtagInstance): userCertificate=[cert_data], description=['2;%s;%s;%s' % ( cert.serial_number, - DN(('CN', 'Certificate Authority'), self.subject_base), + DN(self.subject), DN(('CN', 'IPA RA'), self.subject_base))]) conn.add_entry(entry) @@ -854,7 +858,7 @@ class CAInstance(DogtagInstance): st = 1 en = 0 subid = 0 - ca_dn = DN(('CN','Certificate Authority'), self.subject_base) + ca_dn = DN(self.subject) while st > 0: st = certlist.find('-----BEGIN', en) en = certlist.find('-----END', en+1) @@ -1305,7 +1309,7 @@ class CAInstance(DogtagInstance): basedn = ipautil.realm_to_suffix(self.realm) self.ldap_enable('CA', self.fqdn, None, basedn) - def configure_replica(self, master_host, subject_base=None, + def configure_replica(self, master_host, subject=None, ca_cert_bundle=None, ca_signing_algorithm=None, ca_type=None): """Creates a replica CA, creating a local DS backend and using @@ -1314,10 +1318,14 @@ class CAInstance(DogtagInstance): """ self.master_host = master_host self.master_replication_port = 389 - if subject_base is None: - self.subject_base = DN(('O', self.realm)) + + if subject is None: + self.subject = installutils.default_ca_subject_dn(self.realm) else: - self.subject_base = subject_base + self.subject = subject + self.subject_base = ipautil.extract_ca_subject_base( + self.subject, self.realm) + if ca_signing_algorithm is None: self.ca_signing_algorithm = 'SHA256withRSA' else: @@ -1489,7 +1497,7 @@ def replica_ca_install_check(config): exit('IPA schema missing on master CA directory server') -def install_replica_ca(config, postinstall=False, ra_p12=None): +def install_replica_ca(config, postinstall=False, ra_p12=None, subject=None): """ Install a CA on a replica. @@ -1509,7 +1517,6 @@ def install_replica_ca(config, postinstall=False, ra_p12=None): ca = CAInstance(config.realm_name, certs.NSS_DIR) ca.dm_password = config.dirman_password - ca.subject_base = config.subject_base if not config.setup_ca: # We aren't configuring the CA in this step but we still need @@ -1528,7 +1535,7 @@ def install_replica_ca(config, postinstall=False, ra_p12=None): 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) + subject=subject) # Restart httpd since we changed it's config and added ipa-pki-proxy.conf # Without the restart, CA service status check would fail due to missing diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index b3d273ff107f0493516845745c4f14242fc518ca..06248e2387c11ff69e26a61e4a0a584711afa7c9 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -93,15 +93,14 @@ class CertDB(object): self.certreq_fname = None self.certder_fname = None self.host_name = host_name - self.subject_base = subject_base + self.subject = subject_base or DN(('O', 'IPA')) + self.subject_base = ipautil.extract_ca_subject_base( + self.subject, realm) try: self.cwd = os.getcwd() except OSError as e: raise RuntimeError("Unable to determine the current directory: %s" % str(e)) - if not subject_base: - self.subject_base = DN(('O', 'IPA')) - self.cacert_name = get_ca_nickname(self.realm) self.valid_months = "120" self.keysize = "1024" @@ -253,7 +252,7 @@ class CertDB(object): certs = fd.read() fd.close() - ca_dn = DN(('CN','Certificate Authority'), self.subject_base) + ca_dn = self.subject st = 0 while True: try: diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index c93b3b4ff58c4102a9de448247966ad3dd8e4e7c..12cc838a1e42f89d1f6c1107ffc82ef02bd48fe7 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -227,6 +227,7 @@ class DsInstance(service.Service): self.dercert = None self.idstart = None self.idmax = None + self.subject = None self.subject_base = None self.open_ports = [] self.run_init_memberof = True @@ -244,6 +245,7 @@ class DsInstance(service.Service): self.fstore = sysrestore.FileStore(paths.SYSRESTORE) + subject = ipautil.dn_attribute_property('_subject') subject_base = ipautil.dn_attribute_property('_subject_base') def __common_setup(self, enable_ssl=False): @@ -292,7 +294,7 @@ class DsInstance(service.Service): self.step("configuring directory to start on boot", self.__enable) def init_info(self, realm_name, fqdn, domain_name, dm_password, - subject_base, idstart, idmax, pkcs12_info, ca_file=None): + subject, idstart, idmax, pkcs12_info, ca_file=None): self.realm = realm_name.upper() self.serverid = installutils.realm_to_serverid(self.realm) self.suffix = ipautil.realm_to_suffix(self.realm) @@ -300,7 +302,9 @@ class DsInstance(service.Service): self.dm_password = dm_password self.domain = domain_name self.principal = "ldap/%s@%s" % (self.fqdn, self.realm) - self.subject_base = subject_base + self.subject = subject + self.subject_base = ipautil.extract_ca_subject_base( + self.subject, self.realm) self.idstart = idstart self.idmax = idmax self.pkcs12_info = pkcs12_info @@ -312,11 +316,11 @@ class DsInstance(service.Service): def create_instance(self, realm_name, fqdn, domain_name, dm_password, pkcs12_info=None, - idstart=1100, idmax=999999, subject_base=None, + idstart=1100, idmax=999999, subject=None, hbac_allow=True, ca_file=None): self.init_info( realm_name, fqdn, domain_name, dm_password, - subject_base, idstart, idmax, pkcs12_info, ca_file=ca_file) + subject, idstart, idmax, pkcs12_info, ca_file=ca_file) self.__common_setup() self.step("restarting directory server", self.__restart_instance) @@ -350,7 +354,7 @@ class DsInstance(service.Service): self.start_creation(runtime=10) def create_replica(self, realm_name, master_fqdn, fqdn, - domain_name, dm_password, subject_base, api, + domain_name, dm_password, subject, api, pkcs12_info=None, ca_file=None, ca_is_configured=None, promote=False): # idstart and idmax are configured so that the range is seen as @@ -365,7 +369,7 @@ class DsInstance(service.Service): fqdn=fqdn, domain_name=domain_name, dm_password=dm_password, - subject_base=subject_base, + subject=subject, idstart=idstart, idmax=idmax, pkcs12_info=pkcs12_info, @@ -865,7 +869,7 @@ class DsInstance(service.Service): shutil.copyfile(ipautil.SHARE_DIR + "certmap.conf.template", config_dirname(self.serverid) + "certmap.conf") installutils.update_file(config_dirname(self.serverid) + "certmap.conf", - '$SUBJECT_BASE', str(self.subject_base)) + '$ISSUER_DN', str(self.subject)) sysupgrade.set_upgrade_state( 'certmap.conf', 'subject_base', @@ -1190,9 +1194,12 @@ class DsInstance(service.Service): ) try: with open(os.path.join(certmap_dir, 'certmap.conf')) as f: + prefix = 'certmap ipaca' for line in f: - if line.startswith('certmap ipaca'): - subject_base = line.strip().split(',')[-1] + if line.startswith(prefix): + subject_dn = line[len(prefix):].strip() + subject_base = ipautil.extract_ca_subject_base( + subject_dn, api.env.realm) root_logger.debug( 'Found certificate subject base in certmap.conf: ' '%s', subject_base) @@ -1237,9 +1244,9 @@ class DsInstance(service.Service): os.chown(paths.DS_KEYTAB, pent.pw_uid, pent.pw_gid) def __get_ds_cert(self): - subject = DN(('O', self.realm)) nssdb_dir = config_dirname(self.serverid) - db = certs.CertDB(self.realm, nssdir=nssdb_dir, subject_base=subject) + db = certs.CertDB( + self.realm, nssdir=nssdb_dir, subject_base=self.subject_base) db.request_service_cert(self.nickname, self.principal, self.fqdn) db.create_pin_file() diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py index 25f48aed1eeaa03353465bc40abf3484ec19bf3b..dd625868c0078359db81e4eaee80dd619778fbde 100644 --- a/ipaserver/install/installutils.py +++ b/ipaserver/install/installutils.py @@ -996,7 +996,7 @@ def check_entropy(): except ValueError as e: root_logger.debug("Invalid value in %s %s", paths.ENTROPY_AVAIL, e) -def load_external_cert(files, subject_base): +def load_external_cert(files, subject): """ Load and verify external CA certificate chain from multiple files. @@ -1004,7 +1004,7 @@ def load_external_cert(files, subject_base): chain formats. :param files: Names of files to import - :param subject_base: Subject name base for IPA certificates + :param subject: IPA CA subject DN :returns: Temporary file with the IPA CA certificate and temporary file with the external CA certificate chain """ @@ -1018,7 +1018,7 @@ def load_external_cert(files, subject_base): except RuntimeError as e: raise ScriptError(str(e)) - ca_subject = DN(('CN', 'Certificate Authority'), subject_base) + ca_subject = DN(subject) ca_nickname = None cache = {} for nickname, trust_flags in nssdb.list_certs(): @@ -1377,3 +1377,32 @@ def remove_ccache(ccache_path=None, run_as=None): except ipautil.CalledProcessError as e: root_logger.warning( "Failed to clear Kerberos credentials cache: {}".format(e)) + + +def default_ca_subject_dn(realm_name): + return DN(('CN', 'Certificate Authority'), ('O', realm_name)) + + +def normalize_dogtag_ca_subject_dn(dn): + """ + Prepare a CA subject DN to be compliant with Dogtag. + + Move the most specific CN AVA encountered to be the most + specific RDN, if it is not already so. + + If no CN AVA is encountered, add 'CN=Certificate Authority' as + the most specific RDN. + + """ + cn_ava = None + l = [] + for rdn in DN(dn): + for ava in rdn: + if cn_ava is None and ava.attr.lower() == 'cn': + cn_ava = ava + else: + l.append(ava) + if cn_ava is None: + cn_ava = ('cn', 'Certificate Authority') + l.insert(0, cn_ava) + return DN(*l) diff --git a/ipaserver/install/ipa_cacert_manage.py b/ipaserver/install/ipa_cacert_manage.py index de13ad39397ae5e9b924b0621521e5fc6016c8e6..f5e8a5f63396ad8ca887c1a41944c89c777e4311 100644 --- a/ipaserver/install/ipa_cacert_manage.py +++ b/ipaserver/install/ipa_cacert_manage.py @@ -24,6 +24,7 @@ from optparse import OptionGroup from nss import nss from nss.error import NSPRError import gssapi +import six from ipapython import admintool, certmonger, ipautil from ipapython.dn import DN @@ -31,6 +32,9 @@ from ipaplatform.paths import paths from ipalib import api, errors, x509, certstore from ipaserver.install import certs, cainstance, installutils +if six.PY3: + unicode = str + class CACertManage(admintool.AdminTool): command_name = 'ipa-cacert-manage' @@ -198,8 +202,6 @@ class CACertManage(admintool.AdminTool): options = self.options conn = api.Backend.ldap2 - cert_file, ca_file = installutils.load_external_cert( - options.external_cert_files, x509.subject_base()) nss_cert = None nss.nss_init(paths.PKI_TOMCAT_ALIAS_DIR) @@ -211,6 +213,9 @@ class CACertManage(admintool.AdminTool): pkinfo = nss_cert.subject_public_key_info.format() #pylint: enable=E1101 + cert_file, ca_file = installutils.load_external_cert( + options.external_cert_files, unicode(subject)) + nss_cert = x509.load_certificate_from_file(cert_file.name) cert = nss_cert.der_data if nss_cert.subject != subject: diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index dc44726887916c7216564679c6ea8e9902177b64..491c4e57f71a9aa89bb4736258b144681a93f061 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -93,9 +93,12 @@ class KRAInstance(DogtagInstance): self.clone = True self.master_host = master_host if subject_base is None: - self.subject_base = DN(('O', self.realm)) + self.subject = installutils.default_ca_subject_dn(realm_name) else: - self.subject_base = subject_base + self.subject = subject_base + self.subject_base = ipautil.extract_ca_subject_base( + self.subject, self.realm) + self.realm = realm_name self.suffix = ipautil.realm_to_suffix(realm_name) @@ -296,7 +299,7 @@ class KRAInstance(DogtagInstance): userCertificate=[cert_data], description=['2;%s;%s;%s' % ( cert.serial_number, - DN(('CN', 'Certificate Authority'), self.subject_base), + DN(self.subject), DN(('CN', 'IPA RA'), self.subject_base))]) conn.add_entry(entry) diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py index 45fb2dc17976a08acab16783584524721411fb4e..e2780acc96db8f19598468e2b694e419eb80fd8b 100644 --- a/ipaserver/install/server/common.py +++ b/ipaserver/install/server/common.py @@ -19,7 +19,7 @@ from ipapython.dnsutil import check_zone_overlap if six.PY3: unicode = str -VALID_SUBJECT_ATTRS = ['st', 'o', 'ou', 'dnqualifier', 'c', +VALID_SUBJECT_ATTRS = ['cn', 'st', 'o', 'ou', 'dnqualifier', 'c', 'serialnumber', 'l', 'title', 'sn', 'givenname', 'initials', 'generationqualifier', 'dc', 'mail', 'uid', 'postaladdress', 'postalcode', 'postofficebox', @@ -130,7 +130,7 @@ class BaseServerCA(common.Installable, core.Group, core.Composite): subject = Knob( str, None, - description="The certificate subject base (default O=)", + description="The CA certificate subject DN (default CN=Certificate Authority,O=)", ) @subject.validator diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py index c0c676b870b481696ae75742c7bf88074b0ecf9c..c3c4fce8f40ff52a6fb4f23a59feaa2bdeaa286b 100644 --- a/ipaserver/install/server/install.py +++ b/ipaserver/install/server/install.py @@ -238,7 +238,7 @@ def check_dirsrv(unattended): sys.exit(1) -def set_subject_in_config(realm_name, dm_password, suffix, subject_base): +def set_subject_base_in_config(realm_name, dm_password, suffix, subject_base): ldapuri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % ( installutils.realm_to_serverid(realm_name) ) @@ -479,7 +479,10 @@ def install_check(installer): realm_name = options.realm_name.upper() if not options.subject: - options.subject = DN(('O', realm_name)) + options.subject = installutils.default_ca_subject_dn(realm_name) + if not options.external_ca: + options.subject = installutils.normalize_dogtag_ca_subject_dn( + options.subject) if options.http_cert_files: if options.http_pin is None: @@ -733,7 +736,7 @@ def install(installer): ds.create_instance(realm_name, host_name, domain_name, dm_password, dirsrv_pkcs12_info, idstart=options.idstart, idmax=options.idmax, - subject_base=options.subject, + subject=options.subject, hbac_allow=not options.no_hbac_allow) else: ds = dsinstance.DsInstance(fstore=fstore, @@ -743,7 +746,7 @@ def install(installer): ds.create_instance(realm_name, host_name, domain_name, dm_password, idstart=options.idstart, idmax=options.idmax, - subject_base=options.subject, + subject=options.subject, hbac_allow=not options.no_hbac_allow) ntpinstance.ntp_ldap_enable(host_name, ds.suffix, realm_name) @@ -784,6 +787,7 @@ def install(installer): ds.enable_ssl() krb = krbinstance.KrbInstance(fstore) + subject_base = ipautil.extract_ca_subject_base(options.subject, realm_name) if options.pkinit_cert_files: krb.create_instance(realm_name, host_name, domain_name, dm_password, master_password, @@ -835,8 +839,9 @@ def install(installer): os.chmod(CACERT, 0o644) ca_db.publish_ca_cert(CACERT) - set_subject_in_config(realm_name, dm_password, - ipautil.realm_to_suffix(realm_name), options.subject) + set_subject_base_in_config( + realm_name, dm_password, + ipautil.realm_to_suffix(realm_name), subject_base) # Apply any LDAP updates. Needs to be done after the configuration file # is created diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py index 9d05a0be5a2679d825b4ee6bc2ea55ed358e8ff9..84bfb9966f11e628a76de74a266245b79c5afe44 100644 --- a/ipaserver/install/server/replicainstall.py +++ b/ipaserver/install/server/replicainstall.py @@ -19,6 +19,7 @@ import tempfile import six from ipapython import ipaldap, ipautil, sysrestore +from ipapython.certdb import get_ca_nickname from ipapython.dn import DN from ipapython.install.common import step from ipapython.install.core import Knob @@ -71,7 +72,7 @@ def make_pkcs12_info(directory, cert_name, password_name): return None -def install_http_certs(config, fstore, remote_api): +def install_http_certs(config, fstore, remote_api, subject_base): # Obtain keytab for the HTTP service fstore.backup_file(paths.IPA_KEYTAB) @@ -89,8 +90,7 @@ def install_http_certs(config, fstore, remote_api): # Obtain certificate for the HTTP service nssdir = certs.NSS_DIR - subject = DN(('O', config.realm_name)) - db = certs.CertDB(config.realm_name, nssdir=nssdir, subject_base=subject) + db = certs.CertDB(config.realm_name, nssdir=nssdir, subject_base=subject_base) db.request_service_cert('Server-Cert', principal, config.host_name, True) # FIXME: need Signing-Cert too ? @@ -119,7 +119,7 @@ def install_replica_ds(config, options, ca_is_configured, remote_api, fqdn=config.host_name, domain_name=config.domain_name, dm_password=config.dirman_password, - subject_base=config.subject_base, + subject=options.subject, pkcs12_info=pkcs12_info, ca_is_configured=ca_is_configured, ca_file=ca_file, @@ -625,6 +625,12 @@ def install_check(installer): finally: shutil.rmtree(tmp_db_dir) + # TODO look up CA subject name (needed for DS certmap.conf) + #ipa_ca_nickname = get_ca_nickname(config.realm_name) + #db = certs.CertDB(config.realm_name, nssdir=paths.IPA_NSSDB_DIR) + #cert = db.get_cert_from_db(ipa_ca_nickname) + #options.subject = unicode(cert.subject) + ldapuri = 'ldaps://%s' % ipautil.format_netloc(config.master_host_name) remote_api = create_api(mode=None) remote_api.bootstrap(in_server=True, context='installer', @@ -717,7 +723,6 @@ def install_check(installer): if options.setup_ca: options.realm_name = config.realm_name options.host_name = config.host_name - options.subject = config.subject_base ca.install_check(False, config, options) if config.setup_kra: @@ -1256,6 +1261,12 @@ def promote_check(installer): if subject_base is not None: config.subject_base = DN(subject_base) + # look up CA subject name (needed for DS certmap.conf) + ipa_ca_nickname = get_ca_nickname(config.realm_name) + db = certs.CertDB(config.realm_name, nssdir=paths.IPA_NSSDB_DIR) + cert = db.get_cert_from_db(ipa_ca_nickname) + options.subject = unicode(x509.load_certificate(cert).subject) + # Find if any server has a CA ca_host = service.find_providing_server('CA', conn, api.env.server) if ca_host is not None: @@ -1289,7 +1300,7 @@ def promote_check(installer): options.realm_name = config.realm_name options.host_name = config.host_name - options.subject = config.subject_base + ca.install_check(False, None, options) if config.setup_kra: @@ -1419,7 +1430,7 @@ def promote(installer): # Must install http certs before changing ipa configuration file # or certmonger will fail to contact the peer master - install_http_certs(config, fstore, remote_api) + install_http_certs(config, fstore, remote_api, config.subject_base) ntpinstance.ntp_ldap_enable(config.host_name, ds.suffix, remote_api.env.realm) @@ -1507,7 +1518,7 @@ def promote(installer): host_name=config.host_name, dm_password=config.dirman_password) ca.configure_replica(config.ca_host_name, - subject_base=config.subject_base, + subject=options.subject, ca_cert_bundle=ca_data) if options.setup_kra: -- 2.5.5 From mbabinsk at redhat.com Fri Jul 15 08:32:12 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 15 Jul 2016 10:32:12 +0200 Subject: [Freeipa-devel] [PATCH 0186] DNS install: Ensure that DNS servers container exists In-Reply-To: <3fabbf64-a6b7-ca0d-daef-06e730458b01@redhat.com> References: <3fabbf64-a6b7-ca0d-daef-06e730458b01@redhat.com> Message-ID: <3673e752-0069-be23-ac32-d47cbfe8908f@redhat.com> On 07/15/2016 10:32 AM, Stanislav Laznicka wrote: > On 07/14/2016 05:51 PM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6083 >> >> >> > ACK, works as expected. > ..and putting the list back into the loop -- Martin^3 Babinsky From dkupka at redhat.com Fri Jul 15 10:05:01 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 15 Jul 2016 12:05:01 +0200 Subject: [Freeipa-devel] [PATCH 0149] help: Add dnsserver commands to help topic 'dns' In-Reply-To: <8ba68b2a-af2f-ff4c-9621-05d207d71cdb@redhat.com> References: <8ba68b2a-af2f-ff4c-9621-05d207d71cdb@redhat.com> Message-ID: <8bf3db75-5639-5f2e-09a0-54457ab5f204@redhat.com> On 12/07/16 12:54, Petr Spacek wrote: > Hello, > > help: Add dnsserver commands to help topic 'dns' > > https://bugzilla.redhat.com/show_bug.cgi?id=1353888 > Hi! Your patch turns dnsserver topic to a subtopic of dns topic. I'm sorry I gave you wrong advice. Attached patch makes dnsserver-* commands appear in dns topic. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0111.0-help-Add-dnsserver-commands-to-help-topic-dns.patch Type: text/x-patch Size: 1928 bytes Desc: not available URL: From dkupka at redhat.com Fri Jul 15 10:53:52 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 15 Jul 2016 12:53:52 +0200 Subject: [Freeipa-devel] [PATCH 0112-3] Speeding up cli help Message-ID: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> Hello! After Honza introduced thin client that builds plugins and commands dynamically from schema client became much slower. This is only logical, instead of importing a module client now must fetch the schema from server, parse it and instantiate the commands using the data. First step to speed it up was addition of schema cache to client. That removed the RTT and download time of fetching schema every time. Now the most time consuming task became displaying help for lists of topics and command and displaying individual topics. This is simply because of the need to instantiate all the commands to find the relations between topics and commands. All the necessary bits for server commands and topics are already in the schema cache so we can skip this part and generate help from it, right? Not so fast! There are client plugins with commands and topics. So we can generate basic bits (list of all topics, list of all commands, list of commands for each topic) from schema and store it in cache. Then we need to go through all client plugins and get similar bits for client plugins. Then we can merge and print. Still the client response is not as fast as before and I this it even can't be. Also first time you display particular topic or list takes longer because it must be freshly generated and stored in cache for next use. And this is what the attached patches do. https://fedorahosted.org/freeipa/ticket/6048 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0112.0-schema-Generate-help-for-server-plugins-from-schema-.patch Type: text/x-patch Size: 7902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0113.0-cli-help-Use-cached-help-from-schema.patch Type: text/x-patch Size: 12548 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jul 15 11:51:26 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Jul 2016 13:51:26 +0200 Subject: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation In-Reply-To: <20160713160749.i6mmcc26auqeqvjy@redhat.com> References: <49e2e1ef-f4ee-49fa-c0da-81db2d34272a@redhat.com> <35b2b540-7891-1238-b9d7-102dd6f6fa87@redhat.com> <1468333156.15769.10.camel@redhat.com> <06fbb250-84a1-0726-9fee-a6649a989cb5@redhat.com> <1468415332.15769.59.camel@redhat.com> <1468420095.15769.65.camel@redhat.com> <1468422056.15769.68.camel@redhat.com> <921c7364-ac37-2847-a295-361d92183b92@redhat.com> <20160713160749.i6mmcc26auqeqvjy@redhat.com> Message-ID: <0cd33fe3-999e-7034-f3b4-af78a9906e57@redhat.com> On 07/13/2016 06:07 PM, Alexander Bokovoy wrote: > On Wed, 13 Jul 2016, Martin Babinsky wrote: >> In that case, if nobody objects then the second revision of the patch >> may be pushed since Alexander already acked it, right Alexander? > Correct. ACK. master: * 2f02ffed03beac43b26e8521eff87b9489a746f9 Preserve user principal aliases during rename operation -- Petr Vobornik From pvoborni at redhat.com Fri Jul 15 11:56:08 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Jul 2016 13:56:08 +0200 Subject: [Freeipa-devel] [PATCH 0185] messages: specify message type for ResultFormattingError In-Reply-To: <20160714080640.yrlzvxlktjh4xuku@redhat.com> References: <0549e1fe-234d-bcc6-1cf8-632e6bd3454d@redhat.com> <20160714080640.yrlzvxlktjh4xuku@redhat.com> Message-ID: On 07/14/2016 10:06 AM, Alexander Bokovoy wrote: > On Wed, 13 Jul 2016, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6081 >> >> -- >> Martin^3 Babinsky > >> From dd2dfe4bf0a629716145af83c1b7f73595290079 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Wed, 13 Jul 2016 18:22:04 +0200 >> Subject: [PATCH] messages: specify message type for ResultFormattingError >> >> the ResultFormattingError message class was missing a `type` member which >> could cause `otptoken-add` command to crash during QR image rendering >> using >> suboptimal TTY settings >> >> https://fedorahosted.org/freeipa/ticket/6081 >> --- >> ipalib/messages.py | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/ipalib/messages.py b/ipalib/messages.py >> index >> 7288606f6ac923c2c87fadba5f2a6a2d9dadb7f5..6abad64a8259a8e164db60f63e75bbb9c230e7bf >> 100644 >> --- a/ipalib/messages.py >> +++ b/ipalib/messages.py >> @@ -363,6 +363,7 @@ class ResultFormattingError(PublicMessage): >> """ >> **13019** Unable to correctly format some part of the result >> """ >> + type = "warning" >> errno = 13019 >> >> > ACK. > master: * a5c8c9880d62dca50caa1cc8a77c3ae40225570b messages: specify message type for ResultFormattingError -- Petr Vobornik From pvoborni at redhat.com Fri Jul 15 11:58:01 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Jul 2016 13:58:01 +0200 Subject: [Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators In-Reply-To: <75ecc1a1-c135-e89a-24a9-e51eea97cc26@redhat.com> References: <766fd34a-b83b-1105-57d0-bd51420720a7@redhat.com> <556ae9fd-a110-c5a3-b80a-f45d80b01c16@redhat.com> <0aa06017-fcd2-5867-73a9-4dfde6223215@redhat.com> <8eb18fba-f6dd-d4e9-d2c7-dfd85c035903@redhat.com> <8d55e1b4-794e-db99-eb79-191ff1aee668@redhat.com> <75ecc1a1-c135-e89a-24a9-e51eea97cc26@redhat.com> Message-ID: <6a2bcfe6-185a-2825-973f-389d647ea664@redhat.com> On 07/14/2016 03:11 PM, Milan Kub?k wrote: > On 07/14/2016 11:43 AM, Lenka Doudova wrote: >> >>> >>> >> Resending the complete patch set. >> L. >> >> > > Thanks, ACK. > > -- > Milan Kubik > master: * 0f9a5ce6b4c533647b8894f516e34bea8184f1b8 Tests: Tracker class for services * dcdbbb975927a24ec05f7addefd59c71823a57c2 Tests: Authentication indicators xmlrpc tests * aab861142d3aec503ebae4779fbfa1858e20f451 Tests: Authentication indicators integration tests -- Petr Vobornik From pvoborni at redhat.com Fri Jul 15 12:02:42 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Jul 2016 14:02:42 +0200 Subject: [Freeipa-devel] [PATCH 0110] schema: Fix subtopic -> topic mapping In-Reply-To: <61277b2c-5f09-00d0-4520-3a32a046ef76@redhat.com> References: <23c576a4-ce34-468f-a9fb-d9061e6410ce@redhat.com> <61277b2c-5f09-00d0-4520-3a32a046ef76@redhat.com> Message-ID: On 07/14/2016 03:09 PM, Martin Babinsky wrote: > On 07/14/2016 01:21 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/6069 >> >> > ACK. > master: * 92dea9b186611f7f1ba8aa5952b4cfdc363d75b8 schema: Fix subtopic -> topic mapping -- Petr Vobornik From slaznick at redhat.com Fri Jul 15 12:09:41 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 15 Jul 2016 14:09:41 +0200 Subject: [Freeipa-devel] [PATCH 0059] Fix to ipa-cacert-manage man and help differences Message-ID: <33e33813-1aeb-3d50-e05c-cadc3cb8e4bb@redhat.com> https://fedorahosted.org/freeipa/ticket/6013 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0059-Improvements-for-the-ipa-cacert-manage-man-and-help.patch Type: text/x-patch Size: 4003 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jul 15 12:10:26 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Jul 2016 14:10:26 +0200 Subject: [Freeipa-devel] [PATCH] spec: require Dogtag >= 10.3.3-3 In-Reply-To: <9e11a6bd-3026-42ba-0cd8-03a1ec2b3175@redhat.com> References: <0eab09f7-8d95-6651-1c8d-1412c08842eb@redhat.com> <20160708045245.GL10771@dhcp-40-8.bne.redhat.com> <9e11a6bd-3026-42ba-0cd8-03a1ec2b3175@redhat.com> Message-ID: <5fdf2beb-d5c7-0a9d-4805-b57148466b60@redhat.com> On 07/12/2016 03:10 PM, Petr Spacek wrote: > On 8.7.2016 06:52, Fraser Tweedale wrote: >> On Thu, Jul 07, 2016 at 01:16:04PM +0200, Petr Spacek wrote: >>> Hello, >>> >>> IPA 4.4.0 requires Dogtag >= 10.3.4. Is this version going to be built for >>> Fedora any time soon? >>> >>> Or should I update my scripts to automatically enable >>> COPR @freeipa/freeipa-master >>> in my testing VMs? >>> >>> Thanks. >>> Petr^2 Spacek >>> >> Hi Petr, >> >> The required features were released for Fedora as 10.3.3-3. >> Attached patch retracts the min required version accordingly. > > ACK > master: * 49389ed1e06c786df489c0fd9f6e8183f00eedff spec: require Dogtag >= 10.3.3-3 -- Petr Vobornik From simo at redhat.com Fri Jul 15 12:10:23 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Jul 2016 08:10:23 -0400 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> References: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> Message-ID: <1468584623.15769.145.camel@redhat.com> On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote: > On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: > > > > On Wed, 18 May 2016, Stanislav Laznicka wrote: > > > > > > > > > > > > > > > > > when removal succeeds but addition fails for some reason? > > > > > The? > > > > > operation is not atomic anymore. > > > > > > > > We offline-discussed this with Honza. There should be a new > > > command? > > > `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1? > > > --new-time=icalstr2`. As it would be derived from LDAPQuery, the? > > > atomicity is kept. This may not be very nice for CLI but should > > > work? > > > well for WebUI. Both icalstr1 and icalstr2 need to be encoded as? > > > newlines that appear so often in iCalendar strings would only > > > make a? > > > mess here. > > > > > > Example of use: > > > > > > ipa hbacrule-replace-accesstime rule_name? > > > --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j? > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r > > > \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2 > > > 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTH > > > LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALEN > > > DAR\\r\\n'"? > > > --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j? > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r > > > \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2 > > > 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTH > > > LY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCA > > > LENDAR\\r\\n'"? > > > > > > > > > to add Tuesdays to the timespan defined by the rule. > > I would really like to see a file input support here. It would be > > simpler to operate in CLI as you would anyway create vCal files -- > > no > > sane person is going to deal with these strings directly on the > > command > > line. > > > That is correct and some basic file support is already in the patches > I? > sent earlier, though replacing rules is not a part of it. However, > it? > does not solve the problem as you would still need access to the > files? > to work with the attributes and then change the files accordingly. > > However, we've had yet another brainstorm with Petr^2, Martin^2 and? > Honza. We really don't want the above so we came up with some ideas > that? > I'm listing below. Note that we also do not want more than one > VEVENT? > component in any of the time rules. So, the ideas: > ?????1) Have the time rules as separate objects. This approach got > most? > support here. Adding Simo and Jakub to CC should they have any input? > against this. > ?????2) Have the time rules stored as strings in the multi-valued? > accesstime attribute at each rule. These would be referenced by > their? > UID property of the VEVENT component of the iCalendar string (instead > of? > that pure hell above). As each of the strings can only contain one? > VEVENT which has to define a UID, the only problem would be to keep > the? > uniqueness of UIDs consistent. > > ?From my point of view, 1) seems rather better but your experience > might? > be different. Don't hesitate to share your opinions, please. Can you please give me an example ldif of a complete hbac rule including time rules with the 2 different proposals ? I do not really care a lot how the framework ends up managing the objetcs, I care mostly about how the information is stored in LDAP and how efficient the storage will be for SSSD retrieval. That's my evaluation pov. Keep in mind that rules are modified rarely but downloaded much more frequently, so it is ok to have a slightly harder way to store them to gain efficiency in retrieving and downloading them. Simo. From pvoborni at redhat.com Fri Jul 15 12:14:10 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Jul 2016 14:14:10 +0200 Subject: [Freeipa-devel] [PATCH 0186] DNS install: Ensure that DNS servers container exists In-Reply-To: <3673e752-0069-be23-ac32-d47cbfe8908f@redhat.com> References: <3fabbf64-a6b7-ca0d-daef-06e730458b01@redhat.com> <3673e752-0069-be23-ac32-d47cbfe8908f@redhat.com> Message-ID: On 07/15/2016 10:32 AM, Martin Babinsky wrote: > On 07/15/2016 10:32 AM, Stanislav Laznicka wrote: >> On 07/14/2016 05:51 PM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/6083 >>> >>> >>> >> ACK, works as expected. >> > > ..and putting the list back into the loop > master: * 37bfd1fdde8906b2b5712d1f99f3f4be8f91ca0a DNS install: Ensure that DNS servers container exists -- Petr Vobornik From slaznick at redhat.com Fri Jul 15 12:29:14 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 15 Jul 2016 14:29:14 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <1468584623.15769.145.camel@redhat.com> References: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> <1468584623.15769.145.camel@redhat.com> Message-ID: <6fcd2a49-9a5f-f295-d958-96a57521d589@redhat.com> On 07/15/2016 02:10 PM, Simo Sorce wrote: > On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote: >> On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: >>> On Wed, 18 May 2016, Stanislav Laznicka wrote: >>>>>> when removal succeeds but addition fails for some reason? >>>>>> The >>>>>> operation is not atomic anymore. >>>>>> >>>> We offline-discussed this with Honza. There should be a new >>>> command >>>> `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 >>>> --new-time=icalstr2`. As it would be derived from LDAPQuery, the >>>> atomicity is kept. This may not be very nice for CLI but should >>>> work >>>> well for WebUI. Both icalstr1 and icalstr2 need to be encoded as >>>> newlines that appear so often in iCalendar strings would only >>>> make a >>>> mess here. >>>> >>>> Example of use: >>>> >>>> ipa hbacrule-replace-accesstime rule_name >>>> --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j >>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r >>>> \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2 >>>> 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTH >>>> LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALEN >>>> DAR\\r\\n'" >>>> --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j >>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r >>>> \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2 >>>> 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTH >>>> LY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCA >>>> LENDAR\\r\\n'" >>>> >>>> >>>> to add Tuesdays to the timespan defined by the rule. >>> I would really like to see a file input support here. It would be >>> simpler to operate in CLI as you would anyway create vCal files -- >>> no >>> sane person is going to deal with these strings directly on the >>> command >>> line. >>> >> That is correct and some basic file support is already in the patches >> I >> sent earlier, though replacing rules is not a part of it. However, >> it >> does not solve the problem as you would still need access to the >> files >> to work with the attributes and then change the files accordingly. >> >> However, we've had yet another brainstorm with Petr^2, Martin^2 and >> Honza. We really don't want the above so we came up with some ideas >> that >> I'm listing below. Note that we also do not want more than one >> VEVENT >> component in any of the time rules. So, the ideas: >> 1) Have the time rules as separate objects. This approach got >> most >> support here. Adding Simo and Jakub to CC should they have any input >> against this. >> 2) Have the time rules stored as strings in the multi-valued >> accesstime attribute at each rule. These would be referenced by >> their >> UID property of the VEVENT component of the iCalendar string (instead >> of >> that pure hell above). As each of the strings can only contain one >> VEVENT which has to define a UID, the only problem would be to keep >> the >> uniqueness of UIDs consistent. >> >> From my point of view, 1) seems rather better but your experience >> might >> be different. Don't hesitate to share your opinions, please. > Can you please give me an example ldif of a complete hbac rule > including time rules with the 2 different proposals ? > > I do not really care a lot how the framework ends up managing the > objetcs, I care mostly about how the information is stored in LDAP and > how efficient the storage will be for SSSD retrieval. > > That's my evaluation pov. > Keep in mind that rules are modified rarely but downloaded much more > frequently, so it is ok to have a slightly harder way to store them to > gain efficiency in retrieving and downloading them. > > Simo. Please find the ldif files attached, with some additional changes than only to hbac rules. It's from my current implementations. OT: We had an offline discussion with Honza that to keep the backward compatibility, it might be good to introduce v2 of HBAC rules so that's what you see there. Perhaps accessTime should be in that v2 rule as well but that's even more off-topic here. -------------- next part -------------- A non-text attachment was scrubbed... Name: objects.ldif Type: text/x-ldif Size: 740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: templates.ldif Type: text/x-ldif Size: 868 bytes Desc: not available URL: From simo at redhat.com Fri Jul 15 13:11:39 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Jul 2016 09:11:39 -0400 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <6fcd2a49-9a5f-f295-d958-96a57521d589@redhat.com> References: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> <1468584623.15769.145.camel@redhat.com> <6fcd2a49-9a5f-f295-d958-96a57521d589@redhat.com> Message-ID: <1468588299.15769.151.camel@redhat.com> On Fri, 2016-07-15 at 14:29 +0200, Stanislav Laznicka wrote: > On 07/15/2016 02:10 PM, Simo Sorce wrote: > > > > On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote: > > > > > > On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: > > > > > > > > On Wed, 18 May 2016, Stanislav Laznicka wrote: > > > > > > > > > > > > > > > > > > > > > > > > > when removal succeeds but addition fails for some reason? > > > > > > > The > > > > > > > operation is not atomic anymore. > > > > > > > > > > > > We offline-discussed this with Honza. There should be a new > > > > > command > > > > > `ipa hbacrule-replace-accesstime rule_name --orig- > > > > > time=icalstr1 > > > > > --new-time=icalstr2`. As it would be derived from LDAPQuery, > > > > > the > > > > > atomicity is kept. This may not be very nice for CLI but > > > > > should > > > > > work > > > > > well for WebUI. Both icalstr1 and icalstr2 need to be encoded > > > > > as > > > > > newlines that appear so often in iCalendar strings would only > > > > > make a > > > > > mess here. > > > > > > > > > > Example of use: > > > > > > > > > > ipa hbacrule-replace-accesstime rule_name > > > > > --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The > > > > > Company//iCal4j > > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN > > > > > T\\r > > > > > \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA > > > > > RT:2 > > > > > 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=M > > > > > ONTH > > > > > LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VC > > > > > ALEN > > > > > DAR\\r\\n'" > > > > > --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The > > > > > Company//iCal4j > > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN > > > > > T\\r > > > > > \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA > > > > > RT:2 > > > > > 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=M > > > > > ONTH > > > > > LY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND > > > > > :VCA > > > > > LENDAR\\r\\n'" > > > > > > > > > > > > > > > to add Tuesdays to the timespan defined by the rule. > > > > I would really like to see a file input support here. It would > > > > be > > > > simpler to operate in CLI as you would anyway create vCal files > > > > -- > > > > no > > > > sane person is going to deal with these strings directly on the > > > > command > > > > line. > > > > > > > That is correct and some basic file support is already in the > > > patches > > > I > > > sent earlier, though replacing rules is not a part of it. > > > However, > > > it > > > does not solve the problem as you would still need access to the > > > files > > > to work with the attributes and then change the files > > > accordingly. > > > > > > However, we've had yet another brainstorm with Petr^2, Martin^2 > > > and > > > Honza. We really don't want the above so we came up with some > > > ideas > > > that > > > I'm listing below. Note that we also do not want more than one > > > VEVENT > > > component in any of the time rules. So, the ideas: > > > ??????1) Have the time rules as separate objects. This approach > > > got > > > most > > > support here. Adding Simo and Jakub to CC should they have any > > > input > > > against this. > > > ??????2) Have the time rules stored as strings in the multi- > > > valued > > > accesstime attribute at each rule. These would be referenced by > > > their > > > UID property of the VEVENT component of the iCalendar string > > > (instead > > > of > > > that pure hell above). As each of the strings can only contain > > > one > > > VEVENT which has to define a UID, the only problem would be to > > > keep > > > the > > > uniqueness of UIDs consistent. > > > > > > ? From my point of view, 1) seems rather better but your > > > experience > > > might > > > be different. Don't hesitate to share your opinions, please. > > Can you please give me an example ldif of a complete hbac rule > > including time rules with the 2 different proposals ? > > > > I do not really care a lot how the framework ends up managing the > > objetcs, I care mostly about how the information is stored in LDAP > > and > > how efficient the storage will be for SSSD retrieval. > > > > That's my evaluation pov. > > Keep in mind that rules are modified rarely but downloaded much > > more > > frequently, so it is ok to have a slightly harder way to store them > > to > > gain efficiency in retrieving and downloading them. > > > > Simo. > Please find the ldif files attached, with some additional changes > than? > only to hbac rules. It's from my current implementations. > > OT: We had an offline discussion with Honza that to keep the > backward? > compatibility, it might be good to introduce v2 of HBAC rules so > that's? > what you see there. Perhaps accessTime should be in that v2 rule as > well? > but that's even more off-topic here. I really would like an example ldif of a set of objects created with an actual time rule in effect, the schema tells me something but not all. You have ipaHBACRulev2 defined twice in different way in the two files, why ? What is accessTime ? Simo. From slaznick at redhat.com Fri Jul 15 13:50:37 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 15 Jul 2016 15:50:37 +0200 Subject: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies In-Reply-To: <1468588299.15769.151.camel@redhat.com> References: <2566215b-24b3-198b-97d4-9bea4144260b@redhat.com> <2ad650f9-86ec-a9ac-d05b-feb31f1765f0@redhat.com> <47873133-70eb-19ba-e08e-0719f1d219f8@redhat.com> <77eb465e-49d0-14e9-f26d-a1f910d312b8@redhat.com> <19bddc31-a584-e464-80dc-9f946122d96a@redhat.com> <60e623af-b244-dd3c-c49c-d883e9a8cf27@redhat.com> <52c6dc55-ccd8-088c-19ed-d9fca164dfd8@redhat.com> <5fe99ec2-bd00-2146-7a51-74374e5fb9bd@redhat.com> <20160518121903.l7d5jl425tvin7sv@redhat.com> <93c330b8-414f-f70a-5c15-1a8879df0b65@redhat.com> <1468584623.15769.145.camel@redhat.com> <6fcd2a49-9a5f-f295-d958-96a57521d589@redhat.com> <1468588299.15769.151.camel@redhat.com> Message-ID: <8b7ef30d-7a67-99b3-2f3d-f095c4e4aa9f@redhat.com> On 07/15/2016 03:11 PM, Simo Sorce wrote: > On Fri, 2016-07-15 at 14:29 +0200, Stanislav Laznicka wrote: >> On 07/15/2016 02:10 PM, Simo Sorce wrote: >>> On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote: >>>> On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: >>>>> On Wed, 18 May 2016, Stanislav Laznicka wrote: >>>>>>>> when removal succeeds but addition fails for some reason? >>>>>>>> The >>>>>>>> operation is not atomic anymore. >>>>>>>> >>>>>> We offline-discussed this with Honza. There should be a new >>>>>> command >>>>>> `ipa hbacrule-replace-accesstime rule_name --orig- >>>>>> time=icalstr1 >>>>>> --new-time=icalstr2`. As it would be derived from LDAPQuery, >>>>>> the >>>>>> atomicity is kept. This may not be very nice for CLI but >>>>>> should >>>>>> work >>>>>> well for WebUI. Both icalstr1 and icalstr2 need to be encoded >>>>>> as >>>>>> newlines that appear so often in iCalendar strings would only >>>>>> make a >>>>>> mess here. >>>>>> >>>>>> Example of use: >>>>>> >>>>>> ipa hbacrule-replace-accesstime rule_name >>>>>> --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The >>>>>> Company//iCal4j >>>>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN >>>>>> T\\r >>>>>> \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA >>>>>> RT:2 >>>>>> 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=M >>>>>> ONTH >>>>>> LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VC >>>>>> ALEN >>>>>> DAR\\r\\n'" >>>>>> --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The >>>>>> Company//iCal4j >>>>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN >>>>>> T\\r >>>>>> \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA >>>>>> RT:2 >>>>>> 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=M >>>>>> ONTH >>>>>> LY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND >>>>>> :VCA >>>>>> LENDAR\\r\\n'" >>>>>> >>>>>> >>>>>> to add Tuesdays to the timespan defined by the rule. >>>>> I would really like to see a file input support here. It would >>>>> be >>>>> simpler to operate in CLI as you would anyway create vCal files >>>>> -- >>>>> no >>>>> sane person is going to deal with these strings directly on the >>>>> command >>>>> line. >>>>> >>>> That is correct and some basic file support is already in the >>>> patches >>>> I >>>> sent earlier, though replacing rules is not a part of it. >>>> However, >>>> it >>>> does not solve the problem as you would still need access to the >>>> files >>>> to work with the attributes and then change the files >>>> accordingly. >>>> >>>> However, we've had yet another brainstorm with Petr^2, Martin^2 >>>> and >>>> Honza. We really don't want the above so we came up with some >>>> ideas >>>> that >>>> I'm listing below. Note that we also do not want more than one >>>> VEVENT >>>> component in any of the time rules. So, the ideas: >>>> 1) Have the time rules as separate objects. This approach >>>> got >>>> most >>>> support here. Adding Simo and Jakub to CC should they have any >>>> input >>>> against this. >>>> 2) Have the time rules stored as strings in the multi- >>>> valued >>>> accesstime attribute at each rule. These would be referenced by >>>> their >>>> UID property of the VEVENT component of the iCalendar string >>>> (instead >>>> of >>>> that pure hell above). As each of the strings can only contain >>>> one >>>> VEVENT which has to define a UID, the only problem would be to >>>> keep >>>> the >>>> uniqueness of UIDs consistent. >>>> >>>> From my point of view, 1) seems rather better but your >>>> experience >>>> might >>>> be different. Don't hesitate to share your opinions, please. >>> Can you please give me an example ldif of a complete hbac rule >>> including time rules with the 2 different proposals ? >>> >>> I do not really care a lot how the framework ends up managing the >>> objetcs, I care mostly about how the information is stored in LDAP >>> and >>> how efficient the storage will be for SSSD retrieval. >>> >>> That's my evaluation pov. >>> Keep in mind that rules are modified rarely but downloaded much >>> more >>> frequently, so it is ok to have a slightly harder way to store them >>> to >>> gain efficiency in retrieving and downloading them. >>> >>> Simo. >> Please find the ldif files attached, with some additional changes >> than >> only to hbac rules. It's from my current implementations. >> >> OT: We had an offline discussion with Honza that to keep the >> backward >> compatibility, it might be good to introduce v2 of HBAC rules so >> that's >> what you see there. Perhaps accessTime should be in that v2 rule as >> well >> but that's even more off-topic here. > I really would like an example ldif of a set of objects created with an > actual time rule in effect, the schema tells me something but not all. > > You have ipaHBACRulev2 defined twice in different way in the two files, > why ? > > What is accessTime ? > > Simo. Those two files show two different implementations - templates.ldif of the template approach, objects.ldif of "time rules as objects" approach. Should have probably mentioned that. Also, like I said, I should have probably included "accessTime" in the objects.ldif ipaHBACRulev2, which I believe is the only difference there that does not have to do anything with how this works. "accessTime" is an attributeType defined in some IPA 2.0 version or so which should bear the time policy information. Each of the time rules objects should bear one single-valued "accessTime" attribute. "accessTime" is originally defined as multi-valued so we may want to have a new attribute defined for that use. Time rules would have their own container somewhere in LDAP, currently working with it being in the realm tree. There, you would add the time rule objects - objects with a name and the information of when such rule would apply. These you would be able to add as members to an HBAC rule. With templates, it's very similar, except that you are able to rewrite/set the accessTime attribute value directly at the HBAC rule object (as nothing is actually stored there because CoSTemplates), thus saving the string directly within the HBAC rule object. This, however, makes it very hard for the time rules to be worked with as you basically lose the information about which of the time rules you want to change in that multivalued HBAC attribute as you can probably imagine. As for how the time policy string is stored - it's an iCalendar string. Is it more clear now? I don't currently have ldifs of any interesting use of either approach. Standa From pvoborni at redhat.com Fri Jul 15 14:29:55 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Jul 2016 16:29:55 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install Message-ID: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> ipa-ca-install said that it used /var/log/ipareplica-ca-install.log but in fact it used /var/log/ipaserver-ca-install.log This patch unites it to ipaserver-ca-install.log It was chosen because ipa-ca-install can be also used on master on CA-less -> CA conversion. Term "server" is valid for both master and replica. https://fedorahosted.org/freeipa/ticket/6088 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0963-unite-log-file-name-of-ipa-ca-install.patch Type: text/x-patch Size: 2463 bytes Desc: not available URL: From ldoudova at redhat.com Fri Jul 15 16:10:00 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 15 Jul 2016 18:10:00 +0200 Subject: [Freeipa-devel] [PATCH 0028][Tests] Fix failing user tests Message-ID: Hi, here's patch with fix for failing user tests, specifically tests with renaming users. Failures were caused by RFE Kerberos principal aliases. As part of the fix, I had to rewrite few of the tests themselves, since they used "--setattr" option rather than "--rename" option, which produces different results. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0028-Tests-Fix-for-failing-user-tests.patch Type: text/x-patch Size: 4548 bytes Desc: not available URL: From jglenz at gmail.com Sat Jul 16 10:26:22 2016 From: jglenz at gmail.com (James Glenz) Date: Sat, 16 Jul 2016 06:26:22 -0400 Subject: [Freeipa-devel] PKI-CA fails to start / CA Services IndexError: Message-ID: <005301d1df4c$804c7d20$80e57760$@gmail.com> Passing on recent event of CA.cfg being clobbered / corrupted / truncated by patching process (yum update) This took few hours to find for I did not expect this to happen to a file that normally would not be changed. The clobbered file, CA.cfg, was truncated by over 500 lines. Errors that shows on the console and the boot.log ~... Starting HTTP Service Starting httpd: [ OK ] Starting CA Service Traceback (most recent call last): File "/usr/sbin/pki-server", line 89, in cli.execute(sys.argv) File "/usr/sbin/pki-server", line 84, in execute super(PKIServerCLI, self).execute(args) File "/usr/lib/python2.6/site-packages/pki/cli.py", line 195, in execute module.execute(module_args) File "/usr/lib/python2.6/site-packages/pki/server/cli/upgrade.py", line 79, in execute subsystem = pki.server.PKISubsystem(subsystem_dir) File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 47, in __init__ self.load() File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 52, in load PKISubsystem.load_config_file(self.cs_conf, self.config) File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 71, in load_config_file value = parts[1] IndexError: list index out of range Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... ~... Here is partial list yum.log Jul 14 14:29:24 Updated: libipa_hbac-1.13.3-22.el6_8.4.x86_64 Jul 14 14:29:41 Installed: python-libipa_hbac-1.13.3-22.el6_8.4.x86_64 Jul 14 14:29:43 Updated: ipa-python-3.0.0-50.el6.1.x86_64 Jul 14 14:31:54 Updated: sssd-ipa-1.13.3-22.el6_8.4.x86_64 Jul 14 14:32:45 Updated: ipa-client-3.0.0-50.el6.1.x86_64 Jul 14 14:32:45 Updated: ipa-admintools-3.0.0-50.el6.1.x86_64 Jul 14 14:33:25 Updated: ipa-server-3.0.0-50.el6.1.x86_64 Jul 14 14:34:04 Updated: ipa-server-selinux-3.0.0-50.el6.1.x86_64 Jul 14 14:36:23 Erased: libipa_hbac-python Jul 14 14:29:21 Updated: ca-certificates-2015.2.6-65.0.1.el6_7.noarch Jul 14 14:29:39 Updated: pki-native-tools-9.0.3-49.el6.x86_64 Jul 14 14:30:33 Updated: pki-symkey-9.0.3-49.el6.x86_64 Jul 14 14:30:33 Updated: pki-util-9.0.3-49.el6.noarch Jul 14 14:30:34 Updated: pki-java-tools-9.0.3-49.el6.noarch Jul 14 14:31:54 Updated: pki-selinux-9.0.3-49.el6.noarch Jul 14 14:32:45 Updated: pki-setup-9.0.3-49.el6.noarch Jul 14 14:32:46 Updated: pki-common-9.0.3-49.el6.noarch Jul 14 14:32:46 Updated: pki-silent-9.0.3-49.el6.noarch Jul 14 14:32:46 Updated: pki-ca-9.0.3-49.el6.noarch Assuming one of these may be the culprit. Regards Jim From abokovoy at redhat.com Sat Jul 16 10:46:55 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 16 Jul 2016 13:46:55 +0300 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices Message-ID: <20160716104655.crbov36a63cq7dcj@redhat.com> Hi, I had some time and was blocked by these bugs to do my tickets so I actually fixed these three problems that are assigned to Martin Babinsky. Hopefully, Martin wouldn't be offended by that. :) ------ Output entry elements may have multiple types allowed. We need to check all of them to properly validate the output. Right now, thin client receives type specifications for elements as tuples of types, so what is seen as 'None' on the server side becomes (type(None),) tuple on the thin client side. Change validation to account this by processing each separate type of the element and account for both None and type(None). Raise type error only if all of the type checks failed. https://fedorahosted.org/freeipa/ticket/6061 -- / Alexander Bokovoy -------------- next part -------------- From e5483de1a84b1bf777e98fa5ac2258168ef10686 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 16 Jul 2016 12:52:40 +0300 Subject: [PATCH 1/3] frontend: fix output validation for multiple type choices Output entry elements may have multiple types allowed. We need to check all of them to properly validate the output. Right now, thin client receives type specifications for elements as tuples of types, so what is seen as 'None' on the server side becomes (type(None),) tuple on the thin client side. Change validation to account this by processing each separate type of the element and account for both None and type(None). Raise type error only if all of the type checks failed. https://fedorahosted.org/freeipa/ticket/6061 --- ipalib/frontend.py | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/ipalib/frontend.py b/ipalib/frontend.py index cb00841..2aeaa93 100644 --- a/ipalib/frontend.py +++ b/ipalib/frontend.py @@ -986,9 +986,21 @@ class Command(HasParam): raise ValueError('%s: unexpected keys %r in %r' % ( nice, sorted(extra), output) ) + # Validate each field of the output + # Multiple types can be allowed for the field, + # thus, we have to verify against each possible one. + # Also, there might be None and type(None) as a type, + # thus they need to be checked separately. + # Raise exception only if all possible type checks failed for o in self.output(): value = output[o.name] - if not (o.type is None or isinstance(value, o.type)): + types = o.type if isinstance(o.type, tuple) else (o.type,) + r = False + for t in types: + r = t is None or t is type(None) or isinstance(value, t) + if r: + break + if not r: raise TypeError('%s:\n output[%r]: need %r; got %r: %r' % ( nice, o.name, o.type, type(value), value) ) -- 2.7.4 From abokovoy at redhat.com Sat Jul 16 10:50:05 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 16 Jul 2016 13:50:05 +0300 Subject: [Freeipa-devel] [PATCH] 0211-0212 Make sure --raw option works for trust-add Message-ID: <20160716105005.3nbpdxd2bsr2o2op@redhat.com> Hi, I had some time and was blocked by these bugs to do my tickets so I actually fixed these three problems that are assigned to Martin Babinsky. Hopefully, Martin wouldn't be offended by that. :) Note that this fix (patch 0211) has potential for a break but also introduces a correct behavior in my view as we should not really have non-lower cased keys in LDAP dictionaries in entry_to_dict() for both normal and --raw modes. ----- 0211 Since commit a8dd7aa337f25abd938a582d0fcba51d3b356410 if IPA command is called with --raw option, a retrieved LDAP entry's attribute names aren't normalized to lower case when converting the entry to a dictionary. This breaks overall assumption that dictionary keys are in lower case. Partially fixes 'ipa trust-add --raw' issues. https://fedorahosted.org/freeipa/ticket/6059 ----- 0212 Make sure we display raw values for 'trust-add --raw' case. https://fedorahosted.org/freeipa/ticket/6059 -- / Alexander Bokovoy -------------- next part -------------- From 8642a9b96a4c6b4f363790f74c1e63e0b98b3676 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 16 Jul 2016 13:35:25 +0300 Subject: [PATCH 2/3] baseldap: make sure entry_to_dict always creates lower-cased keys Since commit a8dd7aa337f25abd938a582d0fcba51d3b356410 if IPA command is called with --raw option, a retrieved LDAP entry's attribute names aren't normalized to lower case when converting the entry to a dictionary. This breaks overall assumption that dictionary keys are in lower case. Partially fixes 'ipa trust-add --raw' issues. https://fedorahosted.org/freeipa/ticket/6059 --- ipaserver/plugins/baseldap.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/plugins/baseldap.py b/ipaserver/plugins/baseldap.py index 6107e43..726a8b7 100644 --- a/ipaserver/plugins/baseldap.py +++ b/ipaserver/plugins/baseldap.py @@ -258,7 +258,7 @@ def entry_to_dict(entry, **options): value[i] = v.decode('utf-8') except UnicodeDecodeError: pass - result[attr] = value + result[attr.lower()] = value else: result = dict((k.lower(), v) for (k, v) in entry.items()) if options.get('all', False): -- 2.7.4 -------------- next part -------------- From 966edb92aadc5ae754a0e4be510f18dc69160e64 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 16 Jul 2016 13:41:49 +0300 Subject: [PATCH 3/3] trust: don't translate attributes when trust-add is called with --raw Make sure we display raw values for 'trust-add --raw' case. https://fedorahosted.org/freeipa/ticket/6059 --- ipaserver/plugins/trust.py | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py index 8536202..c6394f2 100644 --- a/ipaserver/plugins/trust.py +++ b/ipaserver/plugins/trust.py @@ -761,16 +761,17 @@ sides. # add_new_domains_from_trust() on its own. fetch_trusted_domains_over_dbus(self.api, self.log, result['value']) - # Format the output into human-readable values - attributes = int(result['result'].get('ipanttrustattributes', [0])[0]) - result['result']['trusttype'] = [trust_type_string( - result['result']['ipanttrusttype'][0], attributes)] - result['result']['trustdirection'] = [trust_direction_string( - result['result']['ipanttrustdirection'][0])] - result['result']['truststatus'] = [trust_status_string( - result['verified'])] - if attributes: - result['result'].pop('ipanttrustattributes', None) + if options.get('raw', False): + # Format the output into human-readable values + attributes = int(result['result'].get('ipanttrustattributes', [0])[0]) + result['result']['trusttype'] = [trust_type_string( + result['result'].get('ipanttrusttype', [0])[0], attributes)] + result['result']['trustdirection'] = [trust_direction_string( + result['result'].get('ipanttrustdirection', [0])[0])] + result['result']['truststatus'] = [trust_status_string( + result['verified'])] + if attributes: + result['result'].pop('ipanttrustattributes', None) del result['verified'] result['result'].pop('ipanttrustauthoutgoing', None) -- 2.7.4 From jcholast at redhat.com Mon Jul 18 06:20:10 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 18 Jul 2016 08:20:10 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> Message-ID: <296df9f1-1f62-b3aa-d395-13411c95d9e0@redhat.com> Hi, On 7.7.2016 16:40, Florence Blanc-Renaud wrote: > On 07/07/2016 01:23 PM, Petr Vobornik wrote: >> On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >>> Hi, >>> >>> the output of ipa selinuxusermap-add-hostgroup and >>> selinuxusermap-add-user does not display any more the host/host group or >>> user/group that could not be added. This patch fixes this regression by >>> adding the labels host/hostgroup/user/group to the list of >>> _failed_member_output_params of the class ClientMethod. >>> >>> >>> https://fedorahosted.org/freeipa/ticket/6026 >>> >> >> I've a feeling that this issue is more general and multiple commands >> regressed. Would be good to check other member options, e.g. also in >> user plugin. >> > Hi Petr, > > you are right, a lot of other commands regressed. So far I checked only > user and sudocmd but it is likely to be a long task. Are there > regression tests that could help me make sure that the fix is exhaustive? > > Flo See attachment for a patch with an universal fix. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-677-frontend-copy-command-arguments-to-output-params-on-.patch Type: text/x-patch Size: 1373 bytes Desc: not available URL: From jcholast at redhat.com Mon Jul 18 06:22:58 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 18 Jul 2016 08:22:58 +0200 Subject: [Freeipa-devel] CA-less installs: passive certmonger - watch-and-warn mode In-Reply-To: <577FB1B0.7090509@redhat.com> References: <577FAB41.7030909@redhat.com> <2e9575f4-a599-1bb7-045d-ff2e589720b8@redhat.com> <577FB1B0.7090509@redhat.com> Message-ID: <05c3ec25-1d51-0955-f3f0-533886783bc9@redhat.com> On 8.7.2016 15:59, Rob Crittenden wrote: > Petr Spacek wrote: >> On 8.7.2016 15:31, Rob Crittenden wrote: >>> Petr Spacek wrote: >>>> Hi, >>>> >>>> our docs >>>> >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-ca >>>> >>>> >>>> >>>> claim this: >>>> "The certmonger service is not used to track certificates. >>>> Therefore, it does >>>> not warn you of impending certificate expiration." >>>> >>>> Is this correct? >>>> >>>> Can we at least configure certmonger to passively track the >>>> certificates and >>>> throw warning about impending expiration into logs? +1, I have already suggested we do this several times. >>>> >>> >>> Throw a warning where? Register an e-mail address as part of the >>> tracking >>> perhaps? >>> >>> It would probably be fairly easy to write a "CA" that sends an >>> e-mail. The >>> trick, and this has always tripped us up, is having an MTA configured. >> >> I would start with logs, as I wrote in the original message. This will >> naturally evolve into something else when we finally get >> user-configurable hooks. >> >> In any case, having certmonger configured to track the certs is >> prerequisite >> for all cases... > > "Logs" is not very specific, do you mean syslog/journal? > > Feel free to open an RFE against certmonger with your proposal. I > suspect that anything logged will just get lost in most cases. For IPA CA certificate, we log warnings to syslog with ALERT level. I think doing that for other certs would be good enough for starters. > > rob > -- Jan Cholasta From jcholast at redhat.com Mon Jul 18 06:46:25 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 18 Jul 2016 08:46:25 +0200 Subject: [Freeipa-devel] [PATCH 0183] ipa-advise: correct handling of plugin namespace iteration In-Reply-To: <610683a7-079b-cd36-c28c-e4b0b4415aad@redhat.com> References: <610683a7-079b-cd36-c28c-e4b0b4415aad@redhat.com> Message-ID: Hi, On 11.7.2016 14:18, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/6044 Note that you should use .name rather than .__name__ to get plugin names, otherwise the code won't work with plugins with non-default names. There currently aren't any Advice plugins with non-default name, but I would rather fix this now to avoid surprises later. Honza -- Jan Cholasta From mbasti at redhat.com Mon Jul 18 07:55:21 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 18 Jul 2016 09:55:21 +0200 Subject: [Freeipa-devel] [PATCH] 0089 caacl: expand plugin documentation In-Reply-To: References: <20160712051700.GT10771@dhcp-40-8.bne.redhat.com> <20160712064552.azywmrlvmd2vstrb@redhat.com> Message-ID: <5c292583-aeac-7316-7cb8-df133a4df8eb@redhat.com> On 13.07.2016 18:34, Petr Vobornik wrote: > On 07/12/2016 08:45 AM, Alexander Bokovoy wrote: >> On Tue, 12 Jul 2016, Fraser Tweedale wrote: >>> Attached patch is a doc change, addressing >>> https://fedorahosted.org/freeipa/ticket/6002. >>> >>> Thanks, >>> Fraser >>> From 19c5fc60391d37c9d0500feb5d5d5a6628bc4d27 Mon Sep 17 00:00:00 2001 >>> From: Fraser Tweedale >>> Date: Tue, 12 Jul 2016 15:11:11 +1000 >>> Subject: [PATCH] caacl: expand plugin documentation >>> >>> Expand the 'caacl' plugin documentation to explain some common >>> confusions including the fact that CA ACLs apply to the target >>> subject principal (not necessarily the principal requesting the >>> cert), and the fact that CA-less CA ACL implies the 'ipa' CA. >>> >>> Fixes: https://fedorahosted.org/freeipa/ticket/6002 >>> --- >>> ipaserver/plugins/caacl.py | 34 ++++++++++++++++++++++++++++------ >>> 1 file changed, 28 insertions(+), 6 deletions(-) >>> >>> diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py >>> index >>> 9a60f7e27809c4f41b160647efafde94dbe90bf0..d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a >>> 100644 >>> --- a/ipaserver/plugins/caacl.py >>> +++ b/ipaserver/plugins/caacl.py >>> @@ -23,14 +23,36 @@ if six.PY3: >>> __doc__ = _(""" >>> Manage CA ACL rules. >>> >>> -This plugin is used to define rules governing which principals are >>> -permitted to have certificates issued using a given certificate >>> -profile. >>> +This plugin is used to define rules governing which CAs and profiles >>> +may be used to issue certificates to particular principals or groups >>> +of principals. >>> >>> -PROFILE ID SYNTAX: >>> +SUBJECT PRINCIPAL SCOPE: >>> >>> -A Profile ID is a string without spaces or punctuation starting with >>> a letter >>> -and followed by a sequence of letters, digits or underscore ("_"). >>> +For a certificate request to be allowed, the principal(s) that are >>> +the subject of a certificate request (not necessarily the principal >>> +actually requesting the certificate) must be included in the scope >>> +of a CA ACL that also includes the target CA and profile. >>> + >>> +Users can be included by name, group or the "all users" category. >>> +Hosts can be included by name, hostgroup or the "all hosts" >>> +category. Services can be included by service name or the "all >>> +services" category. CA ACLs may be associated with a single type of >>> +principal, or multiple types. >>> + >>> +CERTIFICATE AUTHORITY SCOPE: >>> + >>> +A CA ACL can be associated with one or more CAs by name, or by the >>> +"all CAs" category. For compatibility reasons, a CA ACL with no CA >>> +association implies an association with the 'ipa' CA (and only this >>> +CA). >>> + >>> +PROFILE SCOPE: >>> + >>> +A CA ACL can be associated with one or more profiles by Profile ID. >>> +The Profile ID is a string without spaces or punctuation starting >>> +with a letter and followed by a sequence of letters, digits or >>> +underscore ("_"). >>> >>> EXAMPLES: >>> >> ACK. Reads well. >> > Pushed to master: 8cd87d12d53a98a8e386c06a7c5fddb1d38d990d > Please note for future, that long string should be splitted, to make life of translators easier http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings Martin^2 From jcholast at redhat.com Mon Jul 18 08:01:36 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 18 Jul 2016 10:01:36 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <20160716104655.crbov36a63cq7dcj@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> Message-ID: Hi, On 16.7.2016 12:46, Alexander Bokovoy wrote: > Hi, > > I had some time and was blocked by these bugs to do my tickets so I > actually fixed these three problems that are assigned to Martin > Babinsky. Hopefully, Martin wouldn't be offended by that. :) > > ------ > > Output entry elements may have multiple types allowed. We need to check > all of them to properly validate the output. Right now, thin client > receives type specifications for elements as tuples of types, so > what is seen as 'None' on the server side becomes (type(None),) tuple > on the thin client side. > > Change validation to account this by processing each separate type > of the element and account for both None and type(None). Raise type > error only if all of the type checks failed. > > https://fedorahosted.org/freeipa/ticket/6061 NACK, this only hides the real issue, which is that trustconfig-show (and automember-set-default in #6037) claims to return the primary key of the object in the 'value' output field, but the object does not have a primary key, so the client rightfully expects None. A proper fix would be to set "has_output = output.simple_value" for these commands (all of automember_default_group_{set,remove,show}, trustconfig_{mod,show}). Honza -- Jan Cholasta From abokovoy at redhat.com Mon Jul 18 08:12:32 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 Jul 2016 11:12:32 +0300 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: References: <20160716104655.crbov36a63cq7dcj@redhat.com> Message-ID: <20160718081232.qj3klx4r6usbyw3d@redhat.com> On Mon, 18 Jul 2016, Jan Cholasta wrote: >Hi, > >On 16.7.2016 12:46, Alexander Bokovoy wrote: >>Hi, >> >>I had some time and was blocked by these bugs to do my tickets so I >>actually fixed these three problems that are assigned to Martin >>Babinsky. Hopefully, Martin wouldn't be offended by that. :) >> >>------ >> >>Output entry elements may have multiple types allowed. We need to check >>all of them to properly validate the output. Right now, thin client >>receives type specifications for elements as tuples of types, so >>what is seen as 'None' on the server side becomes (type(None),) tuple >>on the thin client side. >> >>Change validation to account this by processing each separate type >>of the element and account for both None and type(None). Raise type >>error only if all of the type checks failed. >> >>https://fedorahosted.org/freeipa/ticket/6061 > >NACK, this only hides the real issue, which is that trustconfig-show >(and automember-set-default in #6037) claims to return the primary key >of the object in the 'value' output field, but the object does not >have a primary key, so the client rightfully expects None. Why did it work before introducing thin client? Aside from that, comparing "(type(None),) is None" will never give you True on the thin client side. At the server side we have "None is None" and that works. So the question is also why there is a change like that between client and server sides? >A proper fix would be to set "has_output = output.simple_value" for >these commands (all of automember_default_group_{set,remove,show}, >trustconfig_{mod,show}). > >Honza > >-- >Jan Cholasta -- / Alexander Bokovoy From mbabinsk at redhat.com Mon Jul 18 08:28:26 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 10:28:26 +0200 Subject: [Freeipa-devel] Please use https:// url for freeipa.git repo Message-ID: <53cc7361-9ffa-9a66-cebd-ee2bc9cb9a3d@redhat.com> It seems that access to upstream freeipa.git repo through Git protocol does not work (or was deliberately disabled by Fedora infra). Please use HTTPS for fetching/cloning/pulling/etc., so replace git://git.fedorahosted.org/git/freeipa.git with https://git.fedorahosted.org/git/freeipa.git in the repo config. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Jul 18 08:30:49 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 10:30:49 +0200 Subject: [Freeipa-devel] [PATCH 0187] Use server API in com.redhat.idm.trust-fetch-domains oddjob helper Message-ID: <94057997-9ae9-892b-c518-b8ef7a2b2b53@redhat.com> https://fedorahosted.org/freeipa/ticket/6082 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0187-Use-server-API-in-com.redhat.idm.trust-fetch-domains.patch Type: text/x-patch Size: 1079 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jul 18 08:53:01 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 Jul 2016 11:53:01 +0300 Subject: [Freeipa-devel] [PATCH 0187] Use server API in com.redhat.idm.trust-fetch-domains oddjob helper In-Reply-To: <94057997-9ae9-892b-c518-b8ef7a2b2b53@redhat.com> References: <94057997-9ae9-892b-c518-b8ef7a2b2b53@redhat.com> Message-ID: <20160718085301.daefz4po5ptvsjzs@redhat.com> On Mon, 18 Jul 2016, Martin Babinsky wrote: >https://fedorahosted.org/freeipa/ticket/6082 > >-- >Martin^3 Babinsky >From 990f29cbfb457c6179ffc0bed452dc358ba30d21 Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Thu, 14 Jul 2016 09:31:22 +0200 >Subject: [PATCH] Use server API in com.redhat.idm.trust-fetch-domains oddjob > helper > >https://fedorahosted.org/freeipa/ticket/6082 >--- > install/oddjob/com.redhat.idm.trust-fetch-domains | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains b/install/oddjob/com.redhat.idm.trust-fetch-domains >index a6b87cde917cfa5bfedf28442a6d1b2b512706f9..7c948fd53bd54bf3638ef3cc4407576b9011f4fb 100755 >--- a/install/oddjob/com.redhat.idm.trust-fetch-domains >+++ b/install/oddjob/com.redhat.idm.trust-fetch-domains >@@ -76,7 +76,7 @@ env._bootstrap(debug=options.debug, log=None) > env._finalize_core(**dict(DEFAULT_CONFIG)) > > # Initialize the API with the proper debug level >-api.bootstrap(debug=env.debug, log=None) >+api.bootstrap(in_server=True, debug=env.debug, log=None) > api.finalize() > > # Only import trust plugin after api is initialized or internal imports ACK. -- / Alexander Bokovoy From mbasti at redhat.com Mon Jul 18 10:00:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 18 Jul 2016 12:00:17 +0200 Subject: [Freeipa-devel] [PATCH 031] RedHatCAService should wait for local Dogtag instance In-Reply-To: <9d374af6-c688-849b-0889-d6fb82ed379b@redhat.com> References: <487d6952-20b5-a7e6-7283-07a25956c49e@redhat.com> <8072770e-c508-2f45-46d3-8df3450cd49d@redhat.com> <9751cf00-78b4-0dfd-4c70-7a04cb930215@redhat.com> <5e7f167e-b5d3-fd5a-1ec0-599df9ce0b31@redhat.com> <9d374af6-c688-849b-0889-d6fb82ed379b@redhat.com> Message-ID: <8e9e0a26-2d28-8723-414c-f85f2a287f15@redhat.com> On 12.07.2016 16:41, Christian Heimes wrote: > On 2016-07-07 14:54, Martin Basti wrote: >> Patch needs changes in ipa-4-3 branch > My patch? Do you want me to submit a patch for 4.3 branch? > > Christian > > The ticket is in 4.3.2 milestone, so we need patch for ipa-4-3 branch too. Current patch does not apply (too much conflicts) Martin^2 From mbabinsk at redhat.com Mon Jul 18 10:06:44 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 12:06:44 +0200 Subject: [Freeipa-devel] [PATCH] 0211-0212 Make sure --raw option works for trust-add In-Reply-To: <20160716105005.3nbpdxd2bsr2o2op@redhat.com> References: <20160716105005.3nbpdxd2bsr2o2op@redhat.com> Message-ID: <0183c16f-21a2-59ab-25cc-b4964a2111a4@redhat.com> On 07/16/2016 12:50 PM, Alexander Bokovoy wrote: > Hi, > > > I had some time and was blocked by these bugs to do my tickets so I > actually fixed these three problems that are assigned to Martin > Babinsky. Hopefully, Martin wouldn't be offended by that. :) > > Note that this fix (patch 0211) has potential for a break but also > introduces a correct behavior in my view as we should not really have > non-lower cased keys in LDAP dictionaries in entry_to_dict() for both > normal and --raw modes. > > ----- 0211 > > Since commit a8dd7aa337f25abd938a582d0fcba51d3b356410 if IPA command > is called with --raw option, a retrieved LDAP entry's attribute > names aren't normalized to lower case when converting the entry > to a dictionary. This breaks overall assumption that dictionary > keys are in lower case. > > Partially fixes 'ipa trust-add --raw' issues. > > https://fedorahosted.org/freeipa/ticket/6059 > > ----- 0212 > > Make sure we display raw values for 'trust-add --raw' case. > > https://fedorahosted.org/freeipa/ticket/6059 > > > > Hi Alexander, I am CC'ing Jan since I hope he knows why a8dd7aa337f25abd938a582d0fcba51d3b356410 was implemented in this way. I think there was a reason behind this decision and we should not revert it without further discussion. I had the fix for trust-add ready on Friday but was unable to test it properly because of some issues with my VMs. I am attaching it for reference, since it is similar to your patch 212 but relies on attrs_list passed in to LDAP search in order to fetch lowercased attributes. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0188-trust-add-handle-all-raw-options-properly.patch Type: text/x-patch Size: 3653 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Jul 18 10:29:21 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 12:29:21 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: References: <20160716104655.crbov36a63cq7dcj@redhat.com> Message-ID: <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> On 07/18/2016 10:01 AM, Jan Cholasta wrote: > Hi, > > On 16.7.2016 12:46, Alexander Bokovoy wrote: >> Hi, >> >> I had some time and was blocked by these bugs to do my tickets so I >> actually fixed these three problems that are assigned to Martin >> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >> >> ------ >> >> Output entry elements may have multiple types allowed. We need to check >> all of them to properly validate the output. Right now, thin client >> receives type specifications for elements as tuples of types, so >> what is seen as 'None' on the server side becomes (type(None),) tuple >> on the thin client side. >> >> Change validation to account this by processing each separate type >> of the element and account for both None and type(None). Raise type >> error only if all of the type checks failed. >> >> https://fedorahosted.org/freeipa/ticket/6061 > > NACK, this only hides the real issue, which is that trustconfig-show > (and automember-set-default in #6037) claims to return the primary key > of the object in the 'value' output field, but the object does not have > a primary key, so the client rightfully expects None. > > A proper fix would be to set "has_output = output.simple_value" for > these commands (all of automember_default_group_{set,remove,show}, > trustconfig_{mod,show}). > > Honza > The problem is that these commands do not return a simple boolean in 'result' but a full entry dict, so 'simple_value' won't do the trick in this case. But I agree, we should rather fix misbehaving commands rather than bend the framework to accomodate their idiosyncracies, we have enough of that already. -- Martin^3 Babinsky From jcholast at redhat.com Mon Jul 18 10:56:25 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 18 Jul 2016 12:56:25 +0200 Subject: [Freeipa-devel] [PATCH 0552] Vault: enable client side plugins CLI In-Reply-To: References: <76be79d2-785d-7fd2-e248-1fdac6e636de@redhat.com> <20160708143645.6wrqqapbknr4ac2j@redhat.com> <409d00eb-9dd5-0e96-f66c-b7745fc9b88d@redhat.com> Message-ID: <0d55adf6-4465-9f2b-b4c2-e164c6734e31@redhat.com> Hi, On 12.7.2016 16:03, Petr Vobornik wrote: > On 07/12/2016 02:06 PM, Martin Babinsky wrote: >> On 07/08/2016 04:36 PM, Alexander Bokovoy wrote: >>> On Fri, 08 Jul 2016, Martin Basti wrote: >>>> Patch attached. >>>> https://fedorahosted.org/freeipa/ticket/6035 >>> >>>> From 2c97c316c1db49daeda15c709f082ee083a741ad Mon Sep 17 00:00:00 2001 >>>> From: Martin Basti >>>> Date: Fri, 8 Jul 2016 15:53:25 +0200 >>>> Subject: [PATCH] Enable vault-* commands on client >>>> >>>> Client plugins fot vault commands were disabled by NO_CLI=True, >>>> inherited from vault_add_interal, that is always NO_CLI=True. >>>> Introduced by this commit 8278da6967dbe425b4e0c6cf37dc1c53052525b2 >>>> >>>> Removed NO_CLI=True from client side plugins for vault. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6035 >>> ACK. >>> >>> I haven't tested it but the change is obvious. >>> >> >> And it works as expected, so ACK also from me. >> > > master: > * 9feeaca9fb552229638ce98086aa75905a45b48d Enable vault-* commands on client The intent of the NO_CLI properties was to hide the commands when the server does not support them. It didn't exactly work for vault commands, but must be done anyway. Ticket: Honza -- Jan Cholasta From pspacek at redhat.com Mon Jul 18 11:18:23 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Jul 2016 13:18:23 +0200 Subject: [Freeipa-devel] CI DNS locations: basic test for SRV records In-Reply-To: <3522a067-8d58-28cb-d09b-02928a811128@redhat.com> References: <3522a067-8d58-28cb-d09b-02928a811128@redhat.com> Message-ID: On 8.7.2016 14:01, Martin Basti wrote: > See commit message for details. Patch attached. > > > This test does not cover: > > * NTP service records > > * ipa-ca A/AAAA records > > * ADTrust records > > Should I open tickets to cover cases above? ACK -- Petr^2 Spacek From mbasti at redhat.com Mon Jul 18 11:31:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 18 Jul 2016 13:31:44 +0200 Subject: [Freeipa-devel] CI DNS locations: basic test for SRV records In-Reply-To: References: <3522a067-8d58-28cb-d09b-02928a811128@redhat.com> Message-ID: <9a69416c-6fa7-a926-023b-15b2db855a7a@redhat.com> On 18.07.2016 13:18, Petr Spacek wrote: > On 8.7.2016 14:01, Martin Basti wrote: >> See commit message for details. Patch attached. >> >> >> This test does not cover: >> >> * NTP service records >> >> * ipa-ca A/AAAA records >> >> * ADTrust records >> >> Should I open tickets to cover cases above? > ACK > Pushed to master: 72b2c8a54de09d6e5c1cc82c951d5bfd06938e88 From mbabinsk at redhat.com Mon Jul 18 11:50:20 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 13:50:20 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> Message-ID: On 07/18/2016 12:29 PM, Martin Babinsky wrote: > On 07/18/2016 10:01 AM, Jan Cholasta wrote: >> Hi, >> >> On 16.7.2016 12:46, Alexander Bokovoy wrote: >>> Hi, >>> >>> I had some time and was blocked by these bugs to do my tickets so I >>> actually fixed these three problems that are assigned to Martin >>> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>> >>> ------ >>> >>> Output entry elements may have multiple types allowed. We need to check >>> all of them to properly validate the output. Right now, thin client >>> receives type specifications for elements as tuples of types, so >>> what is seen as 'None' on the server side becomes (type(None),) tuple >>> on the thin client side. >>> >>> Change validation to account this by processing each separate type >>> of the element and account for both None and type(None). Raise type >>> error only if all of the type checks failed. >>> >>> https://fedorahosted.org/freeipa/ticket/6061 >> >> NACK, this only hides the real issue, which is that trustconfig-show >> (and automember-set-default in #6037) claims to return the primary key >> of the object in the 'value' output field, but the object does not have >> a primary key, so the client rightfully expects None. >> >> A proper fix would be to set "has_output = output.simple_value" for >> these commands (all of automember_default_group_{set,remove,show}, >> trustconfig_{mod,show}). >> >> Honza >> > > The problem is that these commands do not return a simple boolean in > 'result' but a full entry dict, so 'simple_value' won't do the trick in > this case. > > But I agree, we should rather fix misbehaving commands rather than bend > the framework to accomodate their idiosyncracies, we have enough of that > already. > I am attaching a patch that adds a custom shim for misbehaving commands so that they work as before. There is also a big fat warning added to discourage implementation of such commands. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0189-allow-value-output-param-in-commands-without-primary.patch Type: text/x-patch Size: 5957 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Jul 18 11:51:39 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 13:51:39 +0200 Subject: [Freeipa-devel] [PATCH 190] expose `--secret` option in radiusproxy-* commands Message-ID: https://fedorahosted.org/freeipa/ticket/6078 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0190-expose-secret-option-in-radiusproxy-commands.patch Type: text/x-patch Size: 1147 bytes Desc: not available URL: From flo at redhat.com Mon Jul 18 12:52:31 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Mon, 18 Jul 2016 14:52:31 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: <296df9f1-1f62-b3aa-d395-13411c95d9e0@redhat.com> References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> <296df9f1-1f62-b3aa-d395-13411c95d9e0@redhat.com> Message-ID: <70117590-1a61-8284-7680-c922fba8f7cc@redhat.com> On 07/18/2016 08:20 AM, Jan Cholasta wrote: > Hi, > > On 7.7.2016 16:40, Florence Blanc-Renaud wrote: >> On 07/07/2016 01:23 PM, Petr Vobornik wrote: >>> On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >>>> Hi, >>>> >>>> the output of ipa selinuxusermap-add-hostgroup and >>>> selinuxusermap-add-user does not display any more the host/host >>>> group or >>>> user/group that could not be added. This patch fixes this regression by >>>> adding the labels host/hostgroup/user/group to the list of >>>> _failed_member_output_params of the class ClientMethod. >>>> >>>> >>>> https://fedorahosted.org/freeipa/ticket/6026 >>>> >>> >>> I've a feeling that this issue is more general and multiple commands >>> regressed. Would be good to check other member options, e.g. also in >>> user plugin. >>> >> Hi Petr, >> >> you are right, a lot of other commands regressed. So far I checked only >> user and sudocmd but it is likely to be a long task. Are there >> regression tests that could help me make sure that the fix is exhaustive? >> >> Flo > > See attachment for a patch with an universal fix. > > Honza > Hi Honza, the patch fixes most of the issues. I still see some CLI that do not print everything (while they used to before the regression): ipa servicedelegationrule-add-member ipa servicedelegationrule-remove-member ipa servicedelegationtarget-add-member ipa servicedelegationtarget-remove-member And the following CLI do not print the failed members (but they never did): ipa automember-add-condition ipa automember-remove-condition ipa sudorule-add-allow-command ipa sudorule-remove-allow-command ipa sudorule-add-deny-command ipa sudorule-remove-deny-command It is probably ok to commit this patch and investigate in another ticket the remaining issues, Flo. From pspacek at redhat.com Mon Jul 18 14:38:58 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Jul 2016 16:38:58 +0200 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos In-Reply-To: References: <20160714080910.xmcnbqgqvi7evfds@redhat.com> Message-ID: On 14.7.2016 16:11, Ben Lipton wrote: > On 07/14/2016 04:09 AM, Alexander Bokovoy wrote: >> On Wed, 13 Jul 2016, Ben Lipton wrote: >>> Nothing too exciting, just fixes a few typos I've noticed in comments. >> ACK. However, please file a ticket and mention it in the commit message. Is it worth the bureaucracy? I do not think so. We will certainly not backport typo fixes in comments to older branches so I would say that ticket is useless. Just my two cents. -- Petr^2 Spacek From mbabinsk at redhat.com Mon Jul 18 14:55:25 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 16:55:25 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> <7cea5284-b23d-9f95-2be8-a477274ff98f@redhat.com> Message-ID: <91683398-3c15-e5ac-6fef-f48c8a5e6a5a@redhat.com> On 07/14/2016 11:42 AM, Lenka Doudova wrote: > > > On 07/13/2016 05:40 PM, Martin Babinsky wrote: >> On 07/01/2016 04:15 PM, Lenka Doudova wrote: >>> >>> >>> On 07/01/2016 02:38 PM, Martin Babinsky wrote: >>>> On 07/01/2016 06:36 AM, Lenka Doudova wrote: >>>>> >>>>> >>>>> On 06/30/2016 05:01 PM, Martin Babinsky wrote: >>>>>> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> attaching patch with some basic coverage for external trust >>>>>>> feature. Bit >>>>>>> more detailed info in commit message. >>>>>>> >>>>>>> Since the feature requires me to run commands previously used >>>>>>> only for >>>>>>> forest root domains even for subdomains, I made some changes in >>>>>>> ipatests/test_integration/tasks.py file, so that it would enable >>>>>>> me to >>>>>>> reuse existing function without copy-pasting them for one variable >>>>>>> change. >>>>>>> >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Hi Lenka, >>>>>> >>>>>> I have a few comments: >>>>>> >>>>>> 1.) >>>>>> >>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>> +def establish_trust_with_ad(master, ad, extra_args=(), >>>>>> subdomain=False): >>>>>> >>>>>> This modification seems extremely kludgy to me. >>>>>> >>>>>> I would rather change the function signature to: >>>>>> >>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >>>>>> >>>>>> and pass the domain name itself to the function instead of doing >>>>>> magic >>>>>> inside. The same goes with `remove trust_with_ad`. You may want to >>>>>> fix >>>>>> the calls to them in existing code so that the domain is passed >>>>>> instead of the whole trust object. >>>>>> >>>>>> 2.) >>>>>> >>>>>> +def sync_time_hostname(host, srv_hostname): >>>>>> + """ >>>>>> + Syncs time with the remote server given by its hostname. >>>>>> + Please note that this function leaves ntpd stopped. >>>>>> + """ >>>>>> + host.run_command(['systemctl', 'stop', 'ntpd']) >>>>>> + host.run_command(['ntpdate', srv_hostname]) >>>>>> + >>>>>> + >>>>>> >>>>>> this looks like a duplicate of the function above it, why is it even >>>>>> needed? >>>>>> >>>>>> 3.) >>>>>> +class TestExternalTrustWithSubdomain(ADTrustBase): >>>>>> + """ >>>>>> + Test establishing external trust with subdomain >>>>>> + """ >>>>>> + >>>>>> + @classmethod >>>>>> + def install(cls, mh): >>>>>> + super(ADTrustBase, cls).install(mh) >>>>>> + cls.ad = cls.ad_domains[0].ads[0] >>>>>> + cls.install_adtrust() >>>>>> + cls.check_sid_generation() >>>>>> + >>>>>> + # Determine whether the subdomain AD is available >>>>>> + try: >>>>>> + child_ad = cls.host_by_role(cls.optional_extra_roles[0]) >>>>>> + cls.ad_subdomain = >>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>> + except LookupError: >>>>>> + cls.ad_subdomain = None >>>>>> + >>>>>> + cls.configure_dns_and_time() >>>>>> >>>>>> Please use proper OOP practices when overriding the behavior of the >>>>>> base test class. >>>>>> >>>>>> For starters you could rewrite the install method like this: >>>>>> >>>>>> + @classmethod >>>>>> + def install(cls, mh): >>>>>> + # Determine whether the subdomain AD is available >>>>>> + try: >>>>>> + cls.child_ad = >>>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>>> + cls.ad_subdomain = >>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>> + except LookupError: >>>>>> + raise nose.SkipTest("AFAIK this will skip the whole test >>>>>> class") >>>>>> + super(ADTrustBase, cls).install(mh) >>>>>> >>>>>> with child_ad stored as class attribute, you can override >>>>>> `configure_dns_and_time`: >>>>>> + def configure_dns_and_time(cls): >>>>>> + tasks.configure_dns_for_trust(cls.master, cls.ad_subdomain) >>>>>> # no need to re-implement the function just to get to the child >>>>>> AD DC hostname now >>>>>> + tasks.sync_time(cls.master, cls.child_ad.hostname) >>>>>> >>>>>> You can then use this class as an intermediary in the hierarchy and >>>>>> inherit the other external/non-external trust test classes from it, >>>>>> since most setup method in them are just copy-pasted from this one. >>>>>> >>>>> Hi, >>>>> thanks for review, fixed patch attached. >>>>> >>>>> Lenka >>>> >>>> Hi Lenka, >>>> >>>> I am still not happy about the patch underutilizing the potential for >>>> a proper inheritance hierarchy and instead relying on a staggering >>>> amounts of copy-pasting for implementation. >>>> >>>> I am attaching a quick untested patch illustrating how the >>>> implementation should look like. >>>> >>>> Also you have some leftovers from previous revision, please fix them: >>>> >>>> Pylint is running, please wait ... >>>> ************* Module ipatests.test_integration.test_trust >>>> ipatests/test_integration/test_trust.py:236: [E1101(no-member), >>>> TestExternalTrustWithSubdomain.configure_dns_and_time] Module >>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>>> ipatests/test_integration/test_trust.py:243: >>>> [E1123(unexpected-keyword-arg), >>>> TestExternalTrustWithSubdomain.test_establish_trust] Unexpected >>>> keyword argument 'subdomain' in function call) >>>> ipatests/test_integration/test_trust.py:279: >>>> [E1123(unexpected-keyword-arg), >>>> TestExternalTrustWithSubdomain.test_remove_nonposix_trust] Unexpected >>>> keyword argument 'subdomain' in function call) >>>> ipatests/test_integration/test_trust.py:330: [E1101(no-member), >>>> TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module >>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>>> Makefile:137: recipe for target 'lint' failed >>>> make: *** [lint] Error 1 >>>> sending incremental file list >>>> >>>> (this is before I started meddling with it) >>>> >>>> >>> Thank you very much for the example, fixed patch attached. >>> Lenka >> >> Hi Lenka, >> >> 'TestExternalTrustWithSubdomain' and 'TestExternalTrustWithRootDomain' >> suites fail due to incorrectly used '--external' option in the >> trust-add command. This option is Boolean, not Flag so it should be >> '--external=True'. >> > Hi, > that must have changes since I sent the patch, it was fine before. > Anyway, fixed patch attached. > > Lenka Hi Lenka, one of the tests keep failing on non-posix user UID/GID resolution. Is it a bug of the test or incorrect setup of AD machines? https://paste.fedoraproject.org/392195/68853561/ -- Martin^3 Babinsky From ldoudova at redhat.com Mon Jul 18 14:59:52 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 18 Jul 2016 16:59:52 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: <91683398-3c15-e5ac-6fef-f48c8a5e6a5a@redhat.com> References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> <7cea5284-b23d-9f95-2be8-a477274ff98f@redhat.com> <91683398-3c15-e5ac-6fef-f48c8a5e6a5a@redhat.com> Message-ID: <46c489d2-a9d5-0d6b-bfd2-3e789484a77e@redhat.com> On 07/18/2016 04:55 PM, Martin Babinsky wrote: > On 07/14/2016 11:42 AM, Lenka Doudova wrote: >> >> >> On 07/13/2016 05:40 PM, Martin Babinsky wrote: >>> On 07/01/2016 04:15 PM, Lenka Doudova wrote: >>>> >>>> >>>> On 07/01/2016 02:38 PM, Martin Babinsky wrote: >>>>> On 07/01/2016 06:36 AM, Lenka Doudova wrote: >>>>>> >>>>>> >>>>>> On 06/30/2016 05:01 PM, Martin Babinsky wrote: >>>>>>> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> attaching patch with some basic coverage for external trust >>>>>>>> feature. Bit >>>>>>>> more detailed info in commit message. >>>>>>>> >>>>>>>> Since the feature requires me to run commands previously used >>>>>>>> only for >>>>>>>> forest root domains even for subdomains, I made some changes in >>>>>>>> ipatests/test_integration/tasks.py file, so that it would enable >>>>>>>> me to >>>>>>>> reuse existing function without copy-pasting them for one variable >>>>>>>> change. >>>>>>>> >>>>>>>> >>>>>>>> Lenka >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hi Lenka, >>>>>>> >>>>>>> I have a few comments: >>>>>>> >>>>>>> 1.) >>>>>>> >>>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>>> +def establish_trust_with_ad(master, ad, extra_args=(), >>>>>>> subdomain=False): >>>>>>> >>>>>>> This modification seems extremely kludgy to me. >>>>>>> >>>>>>> I would rather change the function signature to: >>>>>>> >>>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>>> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >>>>>>> >>>>>>> and pass the domain name itself to the function instead of doing >>>>>>> magic >>>>>>> inside. The same goes with `remove trust_with_ad`. You may want to >>>>>>> fix >>>>>>> the calls to them in existing code so that the domain is passed >>>>>>> instead of the whole trust object. >>>>>>> >>>>>>> 2.) >>>>>>> >>>>>>> +def sync_time_hostname(host, srv_hostname): >>>>>>> + """ >>>>>>> + Syncs time with the remote server given by its hostname. >>>>>>> + Please note that this function leaves ntpd stopped. >>>>>>> + """ >>>>>>> + host.run_command(['systemctl', 'stop', 'ntpd']) >>>>>>> + host.run_command(['ntpdate', srv_hostname]) >>>>>>> + >>>>>>> + >>>>>>> >>>>>>> this looks like a duplicate of the function above it, why is it >>>>>>> even >>>>>>> needed? >>>>>>> >>>>>>> 3.) >>>>>>> +class TestExternalTrustWithSubdomain(ADTrustBase): >>>>>>> + """ >>>>>>> + Test establishing external trust with subdomain >>>>>>> + """ >>>>>>> + >>>>>>> + @classmethod >>>>>>> + def install(cls, mh): >>>>>>> + super(ADTrustBase, cls).install(mh) >>>>>>> + cls.ad = cls.ad_domains[0].ads[0] >>>>>>> + cls.install_adtrust() >>>>>>> + cls.check_sid_generation() >>>>>>> + >>>>>>> + # Determine whether the subdomain AD is available >>>>>>> + try: >>>>>>> + child_ad = >>>>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>>>> + cls.ad_subdomain = >>>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>>> + except LookupError: >>>>>>> + cls.ad_subdomain = None >>>>>>> + >>>>>>> + cls.configure_dns_and_time() >>>>>>> >>>>>>> Please use proper OOP practices when overriding the behavior of the >>>>>>> base test class. >>>>>>> >>>>>>> For starters you could rewrite the install method like this: >>>>>>> >>>>>>> + @classmethod >>>>>>> + def install(cls, mh): >>>>>>> + # Determine whether the subdomain AD is available >>>>>>> + try: >>>>>>> + cls.child_ad = >>>>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>>>> + cls.ad_subdomain = >>>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>>> + except LookupError: >>>>>>> + raise nose.SkipTest("AFAIK this will skip the whole >>>>>>> test >>>>>>> class") >>>>>>> + super(ADTrustBase, cls).install(mh) >>>>>>> >>>>>>> with child_ad stored as class attribute, you can override >>>>>>> `configure_dns_and_time`: >>>>>>> + def configure_dns_and_time(cls): >>>>>>> + tasks.configure_dns_for_trust(cls.master, >>>>>>> cls.ad_subdomain) >>>>>>> # no need to re-implement the function just to get to the >>>>>>> child >>>>>>> AD DC hostname now >>>>>>> + tasks.sync_time(cls.master, cls.child_ad.hostname) >>>>>>> >>>>>>> You can then use this class as an intermediary in the hierarchy and >>>>>>> inherit the other external/non-external trust test classes from it, >>>>>>> since most setup method in them are just copy-pasted from this one. >>>>>>> >>>>>> Hi, >>>>>> thanks for review, fixed patch attached. >>>>>> >>>>>> Lenka >>>>> >>>>> Hi Lenka, >>>>> >>>>> I am still not happy about the patch underutilizing the potential for >>>>> a proper inheritance hierarchy and instead relying on a staggering >>>>> amounts of copy-pasting for implementation. >>>>> >>>>> I am attaching a quick untested patch illustrating how the >>>>> implementation should look like. >>>>> >>>>> Also you have some leftovers from previous revision, please fix them: >>>>> >>>>> Pylint is running, please wait ... >>>>> ************* Module ipatests.test_integration.test_trust >>>>> ipatests/test_integration/test_trust.py:236: [E1101(no-member), >>>>> TestExternalTrustWithSubdomain.configure_dns_and_time] Module >>>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>>>> ipatests/test_integration/test_trust.py:243: >>>>> [E1123(unexpected-keyword-arg), >>>>> TestExternalTrustWithSubdomain.test_establish_trust] Unexpected >>>>> keyword argument 'subdomain' in function call) >>>>> ipatests/test_integration/test_trust.py:279: >>>>> [E1123(unexpected-keyword-arg), >>>>> TestExternalTrustWithSubdomain.test_remove_nonposix_trust] Unexpected >>>>> keyword argument 'subdomain' in function call) >>>>> ipatests/test_integration/test_trust.py:330: [E1101(no-member), >>>>> TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module >>>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>>>> Makefile:137: recipe for target 'lint' failed >>>>> make: *** [lint] Error 1 >>>>> sending incremental file list >>>>> >>>>> (this is before I started meddling with it) >>>>> >>>>> >>>> Thank you very much for the example, fixed patch attached. >>>> Lenka >>> >>> Hi Lenka, >>> >>> 'TestExternalTrustWithSubdomain' and 'TestExternalTrustWithRootDomain' >>> suites fail due to incorrectly used '--external' option in the >>> trust-add command. This option is Boolean, not Flag so it should be >>> '--external=True'. >>> >> Hi, >> that must have changes since I sent the patch, it was fine before. >> Anyway, fixed patch attached. >> >> Lenka > > Hi Lenka, > > one of the tests keep failing on non-posix user UID/GID resolution. Is > it a bug of the test or incorrect setup of AD machines? > > https://paste.fedoraproject.org/392195/68853561/ > Hi, this is due to incorrect setup of AD machines - some attributes are missing for AD users. Same issue should arise in any trust test that includes this method, i.e. also in the tests from patch 0026. Lenka From mbabinsk at redhat.com Mon Jul 18 16:07:42 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 18:07:42 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: <46c489d2-a9d5-0d6b-bfd2-3e789484a77e@redhat.com> References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> <7cea5284-b23d-9f95-2be8-a477274ff98f@redhat.com> <91683398-3c15-e5ac-6fef-f48c8a5e6a5a@redhat.com> <46c489d2-a9d5-0d6b-bfd2-3e789484a77e@redhat.com> Message-ID: On 07/18/2016 04:59 PM, Lenka Doudova wrote: > > > On 07/18/2016 04:55 PM, Martin Babinsky wrote: >> On 07/14/2016 11:42 AM, Lenka Doudova wrote: >>> >>> >>> On 07/13/2016 05:40 PM, Martin Babinsky wrote: >>>> On 07/01/2016 04:15 PM, Lenka Doudova wrote: >>>>> >>>>> >>>>> On 07/01/2016 02:38 PM, Martin Babinsky wrote: >>>>>> On 07/01/2016 06:36 AM, Lenka Doudova wrote: >>>>>>> >>>>>>> >>>>>>> On 06/30/2016 05:01 PM, Martin Babinsky wrote: >>>>>>>> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> attaching patch with some basic coverage for external trust >>>>>>>>> feature. Bit >>>>>>>>> more detailed info in commit message. >>>>>>>>> >>>>>>>>> Since the feature requires me to run commands previously used >>>>>>>>> only for >>>>>>>>> forest root domains even for subdomains, I made some changes in >>>>>>>>> ipatests/test_integration/tasks.py file, so that it would enable >>>>>>>>> me to >>>>>>>>> reuse existing function without copy-pasting them for one variable >>>>>>>>> change. >>>>>>>>> >>>>>>>>> >>>>>>>>> Lenka >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Hi Lenka, >>>>>>>> >>>>>>>> I have a few comments: >>>>>>>> >>>>>>>> 1.) >>>>>>>> >>>>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>>>> +def establish_trust_with_ad(master, ad, extra_args=(), >>>>>>>> subdomain=False): >>>>>>>> >>>>>>>> This modification seems extremely kludgy to me. >>>>>>>> >>>>>>>> I would rather change the function signature to: >>>>>>>> >>>>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>>>> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >>>>>>>> >>>>>>>> and pass the domain name itself to the function instead of doing >>>>>>>> magic >>>>>>>> inside. The same goes with `remove trust_with_ad`. You may want to >>>>>>>> fix >>>>>>>> the calls to them in existing code so that the domain is passed >>>>>>>> instead of the whole trust object. >>>>>>>> >>>>>>>> 2.) >>>>>>>> >>>>>>>> +def sync_time_hostname(host, srv_hostname): >>>>>>>> + """ >>>>>>>> + Syncs time with the remote server given by its hostname. >>>>>>>> + Please note that this function leaves ntpd stopped. >>>>>>>> + """ >>>>>>>> + host.run_command(['systemctl', 'stop', 'ntpd']) >>>>>>>> + host.run_command(['ntpdate', srv_hostname]) >>>>>>>> + >>>>>>>> + >>>>>>>> >>>>>>>> this looks like a duplicate of the function above it, why is it >>>>>>>> even >>>>>>>> needed? >>>>>>>> >>>>>>>> 3.) >>>>>>>> +class TestExternalTrustWithSubdomain(ADTrustBase): >>>>>>>> + """ >>>>>>>> + Test establishing external trust with subdomain >>>>>>>> + """ >>>>>>>> + >>>>>>>> + @classmethod >>>>>>>> + def install(cls, mh): >>>>>>>> + super(ADTrustBase, cls).install(mh) >>>>>>>> + cls.ad = cls.ad_domains[0].ads[0] >>>>>>>> + cls.install_adtrust() >>>>>>>> + cls.check_sid_generation() >>>>>>>> + >>>>>>>> + # Determine whether the subdomain AD is available >>>>>>>> + try: >>>>>>>> + child_ad = >>>>>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>>>>> + cls.ad_subdomain = >>>>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>>>> + except LookupError: >>>>>>>> + cls.ad_subdomain = None >>>>>>>> + >>>>>>>> + cls.configure_dns_and_time() >>>>>>>> >>>>>>>> Please use proper OOP practices when overriding the behavior of the >>>>>>>> base test class. >>>>>>>> >>>>>>>> For starters you could rewrite the install method like this: >>>>>>>> >>>>>>>> + @classmethod >>>>>>>> + def install(cls, mh): >>>>>>>> + # Determine whether the subdomain AD is available >>>>>>>> + try: >>>>>>>> + cls.child_ad = >>>>>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>>>>> + cls.ad_subdomain = >>>>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>>>> + except LookupError: >>>>>>>> + raise nose.SkipTest("AFAIK this will skip the whole >>>>>>>> test >>>>>>>> class") >>>>>>>> + super(ADTrustBase, cls).install(mh) >>>>>>>> >>>>>>>> with child_ad stored as class attribute, you can override >>>>>>>> `configure_dns_and_time`: >>>>>>>> + def configure_dns_and_time(cls): >>>>>>>> + tasks.configure_dns_for_trust(cls.master, >>>>>>>> cls.ad_subdomain) >>>>>>>> # no need to re-implement the function just to get to the >>>>>>>> child >>>>>>>> AD DC hostname now >>>>>>>> + tasks.sync_time(cls.master, cls.child_ad.hostname) >>>>>>>> >>>>>>>> You can then use this class as an intermediary in the hierarchy and >>>>>>>> inherit the other external/non-external trust test classes from it, >>>>>>>> since most setup method in them are just copy-pasted from this one. >>>>>>>> >>>>>>> Hi, >>>>>>> thanks for review, fixed patch attached. >>>>>>> >>>>>>> Lenka >>>>>> >>>>>> Hi Lenka, >>>>>> >>>>>> I am still not happy about the patch underutilizing the potential for >>>>>> a proper inheritance hierarchy and instead relying on a staggering >>>>>> amounts of copy-pasting for implementation. >>>>>> >>>>>> I am attaching a quick untested patch illustrating how the >>>>>> implementation should look like. >>>>>> >>>>>> Also you have some leftovers from previous revision, please fix them: >>>>>> >>>>>> Pylint is running, please wait ... >>>>>> ************* Module ipatests.test_integration.test_trust >>>>>> ipatests/test_integration/test_trust.py:236: [E1101(no-member), >>>>>> TestExternalTrustWithSubdomain.configure_dns_and_time] Module >>>>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>>>>> ipatests/test_integration/test_trust.py:243: >>>>>> [E1123(unexpected-keyword-arg), >>>>>> TestExternalTrustWithSubdomain.test_establish_trust] Unexpected >>>>>> keyword argument 'subdomain' in function call) >>>>>> ipatests/test_integration/test_trust.py:279: >>>>>> [E1123(unexpected-keyword-arg), >>>>>> TestExternalTrustWithSubdomain.test_remove_nonposix_trust] Unexpected >>>>>> keyword argument 'subdomain' in function call) >>>>>> ipatests/test_integration/test_trust.py:330: [E1101(no-member), >>>>>> TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module >>>>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' member) >>>>>> Makefile:137: recipe for target 'lint' failed >>>>>> make: *** [lint] Error 1 >>>>>> sending incremental file list >>>>>> >>>>>> (this is before I started meddling with it) >>>>>> >>>>>> >>>>> Thank you very much for the example, fixed patch attached. >>>>> Lenka >>>> >>>> Hi Lenka, >>>> >>>> 'TestExternalTrustWithSubdomain' and 'TestExternalTrustWithRootDomain' >>>> suites fail due to incorrectly used '--external' option in the >>>> trust-add command. This option is Boolean, not Flag so it should be >>>> '--external=True'. >>>> >>> Hi, >>> that must have changes since I sent the patch, it was fine before. >>> Anyway, fixed patch attached. >>> >>> Lenka >> >> Hi Lenka, >> >> one of the tests keep failing on non-posix user UID/GID resolution. Is >> it a bug of the test or incorrect setup of AD machines? >> >> https://paste.fedoraproject.org/392195/68853561/ >> > Hi, > > this is due to incorrect setup of AD machines - some attributes are > missing for AD users. Same issue should arise in any trust test that > includes this method, i.e. also in the tests from patch 0026. > > Lenka Ok, ACK then. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Jul 18 16:09:18 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 18 Jul 2016 18:09:18 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <42931f20-6a19-f506-6982-c3c7be722553@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> <84d6fa1f-265c-9408-3ecd-65c640da1793@redhat.com> <76514b4d-63fe-f6e1-31a5-b1aff62b728a@redhat.com> <42931f20-6a19-f506-6982-c3c7be722553@redhat.com> Message-ID: <58bc6fec-8652-c9ec-36c3-c313ae7c8ccb@redhat.com> On 07/14/2016 03:39 PM, Lenka Doudova wrote: > > > On 07/13/2016 06:04 PM, Martin Babinsky wrote: >> On 07/01/2016 04:45 PM, Lenka Doudova wrote: >>> >>> >>> On 07/01/2016 03:04 PM, Martin Babinsky wrote: >>>> On 07/01/2016 11:13 AM, Lenka Doudova wrote: >>>>> And, of course, a patch file :) >>>>> >>>>> >>>>> On 07/01/2016 11:09 AM, Lenka Doudova wrote: >>>>>> Hi all, >>>>>> >>>>>> here's patch with basic test suite for support of UPN. >>>>>> >>>>>> Note: it needs to be applied on top of my patch 0025.2 (or later, if >>>>>> there's will be more fixes to that patch). >>>>>> >>>>>> >>>>>> Lenka >>>>>> >>>>> >>>>> >>>>> >>>> >>>> Hi Lenka, >>>> >>>> test data such as usernames, etc. should be stored either in separate >>>> resource files or at least as class attributes like this: >>>> >>>> diff --git a/ipatests/test_integration/test_trust.py >>>> b/ipatests/test_integration/test_trust.py >>>> index e8fdc6b..86ba7cc 100644 >>>> --- a/ipatests/test_integration/test_trust.py >>>> +++ b/ipatests/test_integration/test_trust.py >>>> @@ -394,28 +394,33 @@ class TestTrustWithUPN(ADTrustBase): >>>> """ >>>> Test support of UPN for trusted domains >>>> """ >>>> + upn_suffix = 'UPNsuffix.com' >>>> + upn_username = 'upnuser' >>>> + upn_princ = '{}@{}'.format(upn_username, upn_suffix) >>>> + upn_password = 'Secret123456' >>>> + >>>> def test_upn_in_nonposix_trust(self): >>>> """ Check that UPN is listed as trust attribute """ >>>> result = self.master.run_command(['ipa', 'trust-show', >>>> self.ad_domain, >>>> '--all', '--raw']) >>>> >>>> - assert "ipantadditionalsuffixes: UPNsuffix.com" in >>>> result.stdout_text >>>> + assert ("ipantadditionalsuffixes: >>>> {}".format(self.upn_suffix) in >>>> + result.stdout_text) >>>> >>>> def test_upn_user_resolution_in_nonposix_trust(self): >>>> """ Check that user with UPN can be resolved """ >>>> - upnuser = 'upnuser at UPNsuffix.com' >>>> - result = self.master.run_command(['getent', 'passwd', >>>> upnuser]) >>>> + result = self.master.run_command(['getent', 'passwd', >>>> self.upn_princ]) >>>> >>>> # result will contain AD domain, not UPN >>>> - upnuser_regex = "^upnuser@{0}:\*:(\d+):(\d+):UPN >>>> User:/:$".format( >>>> - self.ad_domain) >>>> + upnuser_regex = "^{}@{}:\*:(\d+):(\d+):UPN User:/:$".format( >>>> + self.upn_username, self.ad_domain) >>>> assert re.search(upnuser_regex, result.stdout_text) >>>> >>>> def test_upn_user_authentication(self): >>>> """ Check that AD user with UPN can authenticate in IPA """ >>>> self.master.run_command(['systemctl', 'restart', 'krb5kdc']) >>>> - self.master.run_command(['kinit', '-C', '-E', >>>> 'upnuser at UPNsuffix.com'], >>>> - stdin_text='Secret123456') >>>> + self.master.run_command(['kinit', '-C', '-E', self.upn_princ], >>>> + stdin_text=self.upn_password) >>>> >>>> otherwise LGTM. >>>> >>> Thanks for review, fixed patch attached. >>> >>> Few notes: >>> 1. mbabinsky's suggestion to store testdata as class attributes or >>> separate resource file: I decided to use the class attribute approach. >>> The separate resource file is a nice idea, which I have already put on >>> my "to do" list - there's a lot of hardcoded stuff in the trust tests, >>> even in the original ones (before my patches), so when there's time I'll >>> work on a way how to dynamically provide this data as test configuration >>> 2. previous discussion about getent vs. pwd.getpwnam(): I'll leave the >>> getent command, since according to mbasti the alternative would not work >>> in CI. >>> >>> Lenka >> >> Hi Lenka, >> >> I am not sure 'test_all_trustdomains_found' should be run as a part of >> this test suite. Maybe yes, I'm not sure. >> >> Also I would add a 60 second sleep after KDC restart in >> 'test_upn_user_authentication' so that MS-PAC cache gets refreshed >> before trying to kinit as enterprise principal. >> >> Two of the tests fail on my setup but that is probably due to >> https://fedorahosted.org/freeipa/ticket/6082 . >> > Hi, > > the "test_all_trustdomains_found" method is inherited from parent class, > and I believe it cannot hurt to have it there. > I added the sleep as you requested. > I also tried to run the tests with two way trust and since everything > was fine then, the failures you experienced are really most likely due > to the oddjob issue you linked. Of course the patch still contains tests > with one way trusts, so until the oddjob issue is solved, the tests will > probably fail, and should be fine once the fix is provided. > > Fixed patch attached. > Lenka Yes I think that the failing tests are due to bugs in trust, not the test code. ACK. -- Martin^3 Babinsky From flo at redhat.com Mon Jul 18 16:50:47 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Mon, 18 Jul 2016 18:50:47 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> Message-ID: <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> On 07/15/2016 04:29 PM, Petr Vobornik wrote: > ipa-ca-install said that it used > /var/log/ipareplica-ca-install.log > but in fact it used > /var/log/ipaserver-ca-install.log > > This patch unites it to ipaserver-ca-install.log > > It was chosen because ipa-ca-install can be also used on > master on CA-less -> CA conversion. > > Term "server" is valid for both master and replica. > > https://fedorahosted.org/freeipa/ticket/6088 > > > Looks good to me. Ack From jglenz at gmail.com Mon Jul 18 17:44:14 2016 From: jglenz at gmail.com (Jim Glenz) Date: Mon, 18 Jul 2016 13:44:14 -0400 Subject: [Freeipa-devel] Using RPZ to overcome multi Kerberos domains and multiple DNS authorities. Message-ID: IPA DNS configuration using Response Policy Zone (RPZ). IPA utilizes DNS extensively to locate service records (SRV) and text records (TXT) associated with the Kerberos realm. IPA also heavily require DNS A records and PTR records to function correctly. Normally all A,SRV,TXT,PTR records are part of the same DNS domain zone. The following shows how to decouple IPA "TXT and SRV" records only, and pass (forward) all other records to another internal DNS server when required to have all records (except SRV and TXT) records in the other DNS system. Note: Below is very customized for specific environment, your environment may be different. Just wanted to pass on this DNS trick. Methodology used was to implement a BIND instance on at least two servers and then configuring a Response Policy Zone (RPZ). The RPZ is configured to respond to specific DNS records and forward other DNS records onward to next hop DNS. All A and PTR records should exist in the next hop DNS authoritative server. As mentioned, the following solution is very specific to a unique environment. IPA members and clinet servers must have their primary/secondary DNS resolvers set to the DNS RPZ BIND servers. Steps Create your Master and Slave Bind DNS where RPZ will be used (can be your IPA server or any other server having Bind DNS installed) Create Response Policy Zone (RPZ) files. Test configuration. Search below for " nslookup nslookup . nslookup . nslookup nslookup . nslookup -type=TXT _kerberos. nslookup -type=SRV _kerberos-master._tcp. nslookup -type=SRV _kerberos-master._udp. nslookup -type=SRV _kerberos._tcp. nslookup -type=SRV _kerberos._udp. nslookup -type=SRV _kpasswd._tcp. nslookup -type=SRV _kpasswd._udp. nslookup -type=SRV _ldap._tcp. nslookup nslookup . nslookup -type=TXT _kerberos. nslookup -type=SRV _kerberos-master._tcp. nslookup -type=SRV _kerberos-master._udp. nslookup -type=SRV _kerberos._tcp. nslookup -type=SRV _kerberos._udp. nslookup -type=SRV _kpasswd._tcp. nslookup -type=SRV _kpasswd._udp. nslookup -type=SRV _ldap._tcp. nslookup google.com nslookup google.com nslookup -type=ptr nslookup -type=ptr nslookup -type=ptr nslookup -type=ptr Will be referencing reverse.arpa zone 10.x.x.x internal network. Adjust as necessary for your environment. Appendix A: Primary IPA DNS /etc/named.conf file # cat named.conf options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // the default dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; #forward first; forwarders { ; ; }; response-policy {zone ""; }; // Any host is permitted to issue recursive queries allow-recursion { any; }; tkey-gssapi-credential "DNS/"; tkey-domain ""; }; /* If you want to enable debugging, eg. using the 'rndc trace' command, * By default, SELinux policy does not allow named to modify the /var/named directory, * so put the default debug log file in data/ : */ logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "" IN { type master; file ""; also-notify {;}; }; zone "10.in-addr.arpa" IN { type forward; forwarders { ; ; }; }; include "/etc/named.rfc1912.zones"; # dynamic not used, remark out. #dynamic-db "ipa" { # library "ldap.so"; #}; Appendix B: Primary IPA DNS /var/named/ file $ORIGIN . $TTL 86400 ; 1 day .rpz IN SOA localhost. root.localhost. ( 201505162150 ; serial 3600 ; refresh (1 hour) 1800 ; retry (30 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS localhost. $ORIGIN .rpz. _kerberos TXT "" _ntp_udp SRV 0 100 123 ". $ORIGIN _tcp..rpz. _kerberos SRV 0 100 88 ". SRV 0 100 88 ". _kerberos-master SRV 0 100 88 ". SRV 0 100 88 ". _kpasswd SRV 0 100 464 ". SRV 0 100 464 ". _ldap SRV 0 100 389 ". SRV 0 100 389 ". $ORIGIN _udp..rpz. _kerberos SRV 0 100 88 ". SRV 0 100 88 ". _kerberos-master SRV 0 100 88 ". SRV 0 100 88 ". _kpasswd SRV 0 100 464 ". SRV 0 100 464 ". Appendix C: Secondary IPA DNS /etc/named.conf file # cat /etc/named.conf options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // the default dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; #forward first; forwarders { ; ; }; response-policy {zone ""; }; // Any host is permitted to issue recursive queries allow-recursion { any; }; tkey-gssapi-credential "DNS/"; tkey-domain ""; }; /* If you want to enable debugging, eg. using the 'rndc trace' command, * By default, SELinux policy does not allow named to modify the /var/named directory, * so put the default debug log file in data/ : */ logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "" IN { type slave; file "slaves/"; masters {";}; }; zone "10.in-addr.arpa" IN { type forward; forwarders { ; ; }; }; include "/etc/named.rfc1912.zones"; # dynamic not used #dynamic-db "ipa" { # library "ldap.so"; #}; Appendix D: Secondary IPA DNS /var/named/slaves/ NOTE: Autogenerated by Master/Slave. Delete this file and then increment SOA serial on Master. Reload Master named. cat /var/named/slaves/ $ORIGIN . $TTL 86400 ; 1 day .rpz IN SOA localhost. root.localhost. ( 3936666534 ; serial 3600 ; refresh (1 hour) 1800 ; retry (30 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS localhost. $ORIGIN .rpz. _kerberos TXT "" _ntp_udp SRV 0 100 123 ". $ORIGIN _tcp..rpz. _kerberos SRV 0 100 88 ". SRV 0 100 88 ". _kerberos-master SRV 0 100 88 ". SRV 0 100 88 ". _kpasswd SRV 0 100 464 ". SRV 0 100 464 ". _ldap SRV 0 100 389 ". SRV 0 100 389 ". $ORIGIN _udp..rpz. _kerberos SRV 0 100 88 ". SRV 0 100 88 ". _kerberos-master SRV 0 100 88 ". SRV 0 100 88 ". _kpasswd SRV 0 100 464 ". SRV 0 100 464 ". In conclusion. RPZ is very powerful, DNS mangling in a way. This scenario was how I was able to overcome a tough/strict DNS environment that I had zero control of. Regards Jim Glenz -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon Jul 18 20:54:58 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 18 Jul 2016 22:54:58 +0200 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos In-Reply-To: References: <20160714080910.xmcnbqgqvi7evfds@redhat.com> Message-ID: <20160718205457.GA13618@10.4.128.1> On (18/07/16 16:38), Petr Spacek wrote: >On 14.7.2016 16:11, Ben Lipton wrote: >> On 07/14/2016 04:09 AM, Alexander Bokovoy wrote: >>> On Wed, 13 Jul 2016, Ben Lipton wrote: >>>> Nothing too exciting, just fixes a few typos I've noticed in comments. >>> ACK. However, please file a ticket and mention it in the commit message. > >Is it worth the bureaucracy? I do not think so. We will certainly not backport >typo fixes in comments to older branches so I would say that ticket is useless. > >Just my two cents. > +1 LS From ftweedal at redhat.com Tue Jul 19 00:49:17 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 19 Jul 2016 10:49:17 +1000 Subject: [Freeipa-devel] [PATCH] 0089 caacl: expand plugin documentation In-Reply-To: <5c292583-aeac-7316-7cb8-df133a4df8eb@redhat.com> References: <20160712051700.GT10771@dhcp-40-8.bne.redhat.com> <20160712064552.azywmrlvmd2vstrb@redhat.com> <5c292583-aeac-7316-7cb8-df133a4df8eb@redhat.com> Message-ID: <20160719004917.GM10771@dhcp-40-8.bne.redhat.com> On Mon, Jul 18, 2016 at 09:55:21AM +0200, Martin Basti wrote: > > > On 13.07.2016 18:34, Petr Vobornik wrote: > > On 07/12/2016 08:45 AM, Alexander Bokovoy wrote: > > > On Tue, 12 Jul 2016, Fraser Tweedale wrote: > > > > Attached patch is a doc change, addressing > > > > https://fedorahosted.org/freeipa/ticket/6002. > > > > > > > > Thanks, > > > > Fraser > > > > From 19c5fc60391d37c9d0500feb5d5d5a6628bc4d27 Mon Sep 17 00:00:00 2001 > > > > From: Fraser Tweedale > > > > Date: Tue, 12 Jul 2016 15:11:11 +1000 > > > > Subject: [PATCH] caacl: expand plugin documentation > > > > > > > > Expand the 'caacl' plugin documentation to explain some common > > > > confusions including the fact that CA ACLs apply to the target > > > > subject principal (not necessarily the principal requesting the > > > > cert), and the fact that CA-less CA ACL implies the 'ipa' CA. > > > > > > > > Fixes: https://fedorahosted.org/freeipa/ticket/6002 > > > > --- > > > > ipaserver/plugins/caacl.py | 34 ++++++++++++++++++++++++++++------ > > > > 1 file changed, 28 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py > > > > index > > > > 9a60f7e27809c4f41b160647efafde94dbe90bf0..d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a > > > > 100644 > > > > --- a/ipaserver/plugins/caacl.py > > > > +++ b/ipaserver/plugins/caacl.py > > > > @@ -23,14 +23,36 @@ if six.PY3: > > > > __doc__ = _(""" > > > > Manage CA ACL rules. > > > > > > > > -This plugin is used to define rules governing which principals are > > > > -permitted to have certificates issued using a given certificate > > > > -profile. > > > > +This plugin is used to define rules governing which CAs and profiles > > > > +may be used to issue certificates to particular principals or groups > > > > +of principals. > > > > > > > > -PROFILE ID SYNTAX: > > > > +SUBJECT PRINCIPAL SCOPE: > > > > > > > > -A Profile ID is a string without spaces or punctuation starting with > > > > a letter > > > > -and followed by a sequence of letters, digits or underscore ("_"). > > > > +For a certificate request to be allowed, the principal(s) that are > > > > +the subject of a certificate request (not necessarily the principal > > > > +actually requesting the certificate) must be included in the scope > > > > +of a CA ACL that also includes the target CA and profile. > > > > + > > > > +Users can be included by name, group or the "all users" category. > > > > +Hosts can be included by name, hostgroup or the "all hosts" > > > > +category. Services can be included by service name or the "all > > > > +services" category. CA ACLs may be associated with a single type of > > > > +principal, or multiple types. > > > > + > > > > +CERTIFICATE AUTHORITY SCOPE: > > > > + > > > > +A CA ACL can be associated with one or more CAs by name, or by the > > > > +"all CAs" category. For compatibility reasons, a CA ACL with no CA > > > > +association implies an association with the 'ipa' CA (and only this > > > > +CA). > > > > + > > > > +PROFILE SCOPE: > > > > + > > > > +A CA ACL can be associated with one or more profiles by Profile ID. > > > > +The Profile ID is a string without spaces or punctuation starting > > > > +with a letter and followed by a sequence of letters, digits or > > > > +underscore ("_"). > > > > > > > > EXAMPLES: > > > > > > > ACK. Reads well. > > > > > Pushed to master: 8cd87d12d53a98a8e386c06a7c5fddb1d38d990d > > > Please note for future, that long string should be splitted, to make life of > translators easier > > http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings > > Martin^2 > I see; thanks for pointing this out Martin. From jcholast at redhat.com Tue Jul 19 06:01:02 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 08:01:02 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> Message-ID: Hi, On 18.7.2016 18:50, Florence Blanc-Renaud wrote: > On 07/15/2016 04:29 PM, Petr Vobornik wrote: >> ipa-ca-install said that it used >> /var/log/ipareplica-ca-install.log >> but in fact it used >> /var/log/ipaserver-ca-install.log >> >> This patch unites it to ipaserver-ca-install.log >> >> It was chosen because ipa-ca-install can be also used on >> master on CA-less -> CA conversion. >> >> Term "server" is valid for both master and replica. >> >> https://fedorahosted.org/freeipa/ticket/6088 >> >> >> > > Looks good to me. > Ack Does not look so good to me, "ipareplica-ca-install.log" is in fact the original file name used since ipa-ca-install was introduced (in commit 8a32bb3746802a29b2655e4ad2cbbba8481e1eaf), so why the switch to "ipaserver-ca-install.log"? Honza -- Jan Cholasta From jcholast at redhat.com Tue Jul 19 06:26:22 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 08:26:22 +0200 Subject: [Freeipa-devel] [freeipa] #6002: Default CA can be used without an ACL In-Reply-To: <20160704070616.GA10771@dhcp-40-8.bne.redhat.com> References: <040.c455dd24c0d77033bb69ad9540d2e83b@fedorahosted.org> <055.a874b9e24d14ff50c7966339031dfb11@fedorahosted.org> <20160704070616.GA10771@dhcp-40-8.bne.redhat.com> Message-ID: <9fb35b8f-c4e7-7c24-6070-dd70b046dac4@redhat.com> Hi, On 4.7.2016 09:06, Fraser Tweedale wrote: > On Tue, Jun 28, 2016 at 01:47:23PM -0000, freeipa wrote: >> #6002: Default CA can be used without an ACL >> >> Comment (by ftweedal): >> >> This is expected behaviour; if a CA ACL does not reference any CAs, >> and does not have cacat=all, then it is assumed to refer to the >> default CA. This is for backwards compatibility with existing >> CA ACLs, which do not reference any CAs but did (and still do) >> allow access to IPA CA. >> >> Leaving open for discussion about whether to break compatibility >> for a more consistent behaviour. >> > Didn't get any feedback in the ticket yet so raising on list for > visibility. If people agree with current behaviour I can add a > clarification to caacl plugin help text and close out this ticket. (Sorry for the late reply, I was on vacation the last 2 weeks.) I would very much prefer if this was consistent with (literally) every other member list+category attribute, that is, no member and no category means the rule never matches. While documenting this as an exception to the above rule is the easy way out, IMHO adhering to the rule is even better - anyone who touched HBAC or sudo in IPA would immediately know their way around CA ACLs without having to read the documentation at all, which is a win, because people don't generally read documentation until something goes wrong. The current behavior might surprise them, even if documented properly (it sure surprised me at first :-). BTW I think this can be done without breaking compatibility, e.g. by using a new objectclass to distinguish between "old" (CA is always implicitly the top-level CA) and "new" (CAs are specified using the member and category attributes) CA ACLs. Honza -- Jan Cholasta From jcholast at redhat.com Tue Jul 19 06:40:54 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 08:40:54 +0200 Subject: [Freeipa-devel] [PATCH] 0001: Silence sshd messages during install In-Reply-To: References: <3fe0b9ae-9b22-3a9a-3d4a-067c51a22452@redhat.com> Message-ID: <19dd378c-cc99-90f5-411c-7f472b87775f@redhat.com> Hi, On 9.7.2016 14:46, Ben Lipton wrote: > On 07/07/2016 11:19 AM, Ben Lipton wrote: >> >> Thanks for the review! Comments below. >> >> >> On 07/01/2016 07:42 AM, Martin Basti wrote: >>> >>> >>> >>> On 29.06.2016 20:46, Ben Lipton wrote: >>>> The attached patch silences some annoying messages I've been getting >>>> when upgrading the freeipa-client package on F24: >>>> """ >>>> WARNING: 'UseLogin yes' is not supported in Fedora and may cause >>>> several problems. >> This will be fixed by openssh-7.2p2-9.fc24 >> (https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably >> shouldn't worry about it. >>>> Could not load host key: /etc/ssh/ssh_host_dsa_key >> This is because by default sshd looks for all of >> /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key, >> /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but >> Fedora doesn't generate a DSA key by default. >>>> """ >>>> >>>> Since the script causing the message only looks at the return code >>>> from sshd to determine the right options to use, I thought it might >>>> be ok to discard the output. What do you think? >>>> >>>> Ben >>>> >>>> >>> >>> Hello, I don't like to hiding errors/warnings. Can you determine and >>> solve the root cause? >> >> I definitely agree with this in principle, but in this case the >> purpose of this code is to try different, potentially wrong, >> parameters to sshd until it finds a combination that it accepts. It >> seems like in some environments this would produce error messages that >> aren't actionable and don't indicate any problem for package function, >> which is why I didn't think these messages were necessarily worth >> preserving. >> >> On the other hand, if the code makes the wrong decision about sshd >> version we might be interested in error logs that show why. Can we log >> this to a file instead of the console, maybe? >> >> If you'd prefer just addressing the root cause, a patch that prevents >> the missing host key error is attached, but it won't stop the error >> messages showing up when openssh is an older version. >> >> Thanks, >> Ben >> >> > Whoops, realized that my patch created a tempfile and didn't delete it. > Updated. I think the first version of the patch was OK. sshd is called only to check which set of authorized keys options to use, we don't really care about anything else, so we can safely ignore whatever it puts to stderr. Honza -- Jan Cholasta From jcholast at redhat.com Tue Jul 19 06:50:34 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 08:50:34 +0200 Subject: [Freeipa-devel] [PATCH] cert-show: show subject alternative names In-Reply-To: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> Message-ID: Hi, On 14.7.2016 13:44, Fraser Tweedale wrote: > Hi all, > > The attached patch includes SANs in cert-show output. If you have > certs with esoteric altnames (especially any that are more than just > ASN.1 string types), please test with those certs. > > https://fedorahosted.org/freeipa/ticket/6022 I think it would be better to have a separate attribute for each supported SAN type rather than cramming everything into subject_alt_name. That way if you care only about a single specific type you won't have to go through all the values and parse them. Also it would allow you to use param types appropriate to the SAN types (DNSNameParam for DNS names, Principal for principal names, etc.) Nitpick: please don't mix moving existing stuff and adding new stuff in a single patch. Honza -- Jan Cholasta From ftweedal at redhat.com Tue Jul 19 07:01:55 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 19 Jul 2016 17:01:55 +1000 Subject: [Freeipa-devel] [freeipa] #6002: Default CA can be used without an ACL In-Reply-To: <9fb35b8f-c4e7-7c24-6070-dd70b046dac4@redhat.com> References: <040.c455dd24c0d77033bb69ad9540d2e83b@fedorahosted.org> <055.a874b9e24d14ff50c7966339031dfb11@fedorahosted.org> <20160704070616.GA10771@dhcp-40-8.bne.redhat.com> <9fb35b8f-c4e7-7c24-6070-dd70b046dac4@redhat.com> Message-ID: <20160719070154.GS10771@dhcp-40-8.bne.redhat.com> On Tue, Jul 19, 2016 at 08:26:22AM +0200, Jan Cholasta wrote: > Hi, > > On 4.7.2016 09:06, Fraser Tweedale wrote: > > On Tue, Jun 28, 2016 at 01:47:23PM -0000, freeipa wrote: > > > #6002: Default CA can be used without an ACL > > > > > > Comment (by ftweedal): > > > > > > This is expected behaviour; if a CA ACL does not reference any CAs, > > > and does not have cacat=all, then it is assumed to refer to the > > > default CA. This is for backwards compatibility with existing > > > CA ACLs, which do not reference any CAs but did (and still do) > > > allow access to IPA CA. > > > > > > Leaving open for discussion about whether to break compatibility > > > for a more consistent behaviour. > > > > > Didn't get any feedback in the ticket yet so raising on list for > > visibility. If people agree with current behaviour I can add a > > clarification to caacl plugin help text and close out this ticket. > > (Sorry for the late reply, I was on vacation the last 2 weeks.) > > I would very much prefer if this was consistent with (literally) every other > member list+category attribute, that is, no member and no category means the > rule never matches. > > While documenting this as an exception to the above rule is the easy way > out, IMHO adhering to the rule is even better - anyone who touched HBAC or > sudo in IPA would immediately know their way around CA ACLs without having > to read the documentation at all, which is a win, because people don't > generally read documentation until something goes wrong. The current > behavior might surprise them, even if documented properly (it sure surprised > me at first :-). > > BTW I think this can be done without breaking compatibility, e.g. by using a > new objectclass to distinguish between "old" (CA is always implicitly the > top-level CA) and "new" (CAs are specified using the member and category > attributes) CA ACLs. > > Honza > Is there precedent of "varying behaviour based on objectclass" in IPA? Would it go along the lines of... 1. subtype 'ipaCaAcl' object class (let us call it 'ipaCaAclWithCa' for sake of discussion). (Note that moving the 'ipaCa' attribute to be part of 'ipaCaAclWithCa' would not be backwards compatible with v4.4 as currently released, so it would remain in 'ipaCaAcl' objectclass.) 2. Upgrade script to take 'ipaCaAcl' objects that are NOT 'ipaCaAclWithCa', and make them so, while adding the IPA CA. Is this what you have in mind? If so, I don't think there is actually a need to vary the behaviour based on object class, other than during upgrade. The reason I was not doing upgrades in the first place was because I could not in distinguish between "old" CA ACLs, and "new" CA ACLs that don't have any CAs defined. However, adding a new objectclass resolves this ambiguity. Lmk what you think; I could be way off track :) Cheers, Fraser From ftweedal at redhat.com Tue Jul 19 07:03:52 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 19 Jul 2016 17:03:52 +1000 Subject: [Freeipa-devel] [PATCH] cert-show: show subject alternative names In-Reply-To: References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> Message-ID: <20160719070352.GT10771@dhcp-40-8.bne.redhat.com> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: > Hi, > > On 14.7.2016 13:44, Fraser Tweedale wrote: > > Hi all, > > > > The attached patch includes SANs in cert-show output. If you have > > certs with esoteric altnames (especially any that are more than just > > ASN.1 string types), please test with those certs. > > > > https://fedorahosted.org/freeipa/ticket/6022 > > I think it would be better to have a separate attribute for each supported > SAN type rather than cramming everything into subject_alt_name. That way if > you care only about a single specific type you won't have to go through all > the values and parse them. Also it would allow you to use param types > appropriate to the SAN types (DNSNameParam for DNS names, Principal for > principal names, etc.) > You are right; that would be much better. > Nitpick: please don't mix moving existing stuff and adding new stuff in a > single patch. > Will cut new patches to address both of these points. Thanks, Fraser From mbabinsk at redhat.com Tue Jul 19 07:15:19 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 Jul 2016 09:15:19 +0200 Subject: [Freeipa-devel] [PATCH 0183] ipa-advise: correct handling of plugin namespace iteration In-Reply-To: References: <610683a7-079b-cd36-c28c-e4b0b4415aad@redhat.com> Message-ID: On 07/18/2016 08:46 AM, Jan Cholasta wrote: > Hi, > > On 11.7.2016 14:18, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6044 > > Note that you should use .name rather than .__name__ to get plugin > names, otherwise the code won't work with plugins with non-default names. > > There currently aren't any Advice plugins with non-default name, but I > would rather fix this now to avoid surprises later. > > Honza > I didn't realize this when doing the patch, here's the fix for that. I have attached the original closed ticket to the commit message, should I create a new ticket for such a small change? -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0191-advise-Use-name-instead-of-__name__-to-get-plugin-na.patch Type: text/x-patch Size: 1323 bytes Desc: not available URL: From jcholast at redhat.com Tue Jul 19 07:20:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 09:20:21 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: References: Message-ID: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> Hi, On 14.7.2016 14:36, Stanislav Laznicka wrote: > Hello, > > This patch fixes https://fedorahosted.org/freeipa/ticket/5640. > > With not so much experience with the framework, it raises question in my > head whether ipaldap.get_entries is used properly throughout the system > - does it always assume that it gets ALL the requested entries or just a > few of those as configured by the 'ipaSearchRecordsLimit' attribute of > ipaConfig.etc which it actually gets? That depends. If you call get_entries() on the ldap2 plugin (which is usually the case in the framework), then ipaSearchRecordsLimit is used. If you call it on some arbitrary LDAPClient instance, the hardcoded default (= unlimited) is used. > > One spot that I know the get_entries method was definitely not used > properly before this patch is in the > baseldap.LDAPObject.get_memberindirect() method: > > 692 result = self.backend.get_entries( > 693 self.api.env.basedn, > 694 filter=filter, > 695 attrs_list=['member'], > 696 size_limit=-1, # paged search will get everything > anyway > 697 paged_search=True) > > which to me seems kind of important if the environment size_limit is not > set properly :) The patch does not fix the non-propagation of the > paged_search, though. Why do you think size_limit is not used properly here? Anyway, this ticket is not really easily fixable without more profound changes. Often, multiple LDAP searches are done during command execution. What do you do with the size limit then? Do you pass the same size limit to all the searches? Do you subtract the result size from the size limit after each search? Do you do something else with it? ... The answer is that it depends on the purpose of each individual LDAP search (like in get_memberindirect() above, we have to do unlimited search, otherwise the resulting entry would be incomplete), and fixing this accross the whole framework is a non-trivial task. Honza -- Jan Cholasta From pvoborni at redhat.com Tue Jul 19 07:27:25 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 19 Jul 2016 09:27:25 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> Message-ID: On 07/19/2016 08:01 AM, Jan Cholasta wrote: > Hi, > > On 18.7.2016 18:50, Florence Blanc-Renaud wrote: >> On 07/15/2016 04:29 PM, Petr Vobornik wrote: >>> ipa-ca-install said that it used >>> /var/log/ipareplica-ca-install.log >>> but in fact it used >>> /var/log/ipaserver-ca-install.log >>> >>> This patch unites it to ipaserver-ca-install.log >>> >>> It was chosen because ipa-ca-install can be also used on >>> master on CA-less -> CA conversion. >>> >>> Term "server" is valid for both master and replica. >>> >>> https://fedorahosted.org/freeipa/ticket/6088 >>> >>> >>> >> >> Looks good to me. >> Ack > > Does not look so good to me, "ipareplica-ca-install.log" is in fact the > original file name used since ipa-ca-install was introduced (in commit > 8a32bb3746802a29b2655e4ad2cbbba8481e1eaf), so why the switch to > "ipaserver-ca-install.log"? > > Honza > Ideally it would be ipa-ca-install.log but for backwards compatibility, let's stick with one which we have. AFAIK the framework(run_script method? doesn't support switching the log name which is printed in error message depending on usage. Therefore the universal was chosen - ipaserver-ca-install.log. It was introduced by your commit d27e77adc56f5a04f3bdd1aaed5440a89ed3acad And I see, that I used wrong ticket number in the commit. Correct is https://fedorahosted.org/freeipa/ticket/6086 Proper solution might be to rework main and __main__ function in ipa-ca-install but IMO we spent too much time on this already. -- Petr Vobornik From jcholast at redhat.com Tue Jul 19 07:36:17 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 09:36:17 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name In-Reply-To: <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> Message-ID: <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> Hi, On 15.7.2016 07:05, Fraser Tweedale wrote: > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: >> The attached patch is a work in progress for >> https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). >> >> I am sharing now to make the approach clear and solicit feedback. >> >> It has been tested for server install, replica install (with and >> without CA) and CA-replica install (all hosts running master+patch). >> >> Migration from earlier versions and server/replica/CA install on a >> CA-less deployment are not yet tested; these will be tested over >> coming days and patch will be tweaked as necessary. >> >> Commit message has a fair bit to say so I won't repeat here but let >> me know your questions and comments. >> >> Thanks, >> Fraser >> > It does help to attach the patch, of course ^_^ IMO explicit is better than implicit, so instead of introducing additional magic around --subject, I would rather add a new separate option for specifying the CA subject name (I think --ca-subject, for consistency with --ca-signing-algorithm). By specifying the option you would override the default "CN=Certificate Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, additional validation would be done to make sure the subject name meets Dogtag's expectations. Actually, it might make sense to always do the additional validation, to be able to print a warning that if a Dogtag-incompatible subject name is used, it won't be possible to change the CA cert chaining from externally signed to self-signed later. Honza -- Jan Cholasta From jcholast at redhat.com Tue Jul 19 07:41:20 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 09:41:20 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> Message-ID: <96011678-10bc-6031-bd05-612b19759488@redhat.com> On 19.7.2016 09:27, Petr Vobornik wrote: > On 07/19/2016 08:01 AM, Jan Cholasta wrote: >> Hi, >> >> On 18.7.2016 18:50, Florence Blanc-Renaud wrote: >>> On 07/15/2016 04:29 PM, Petr Vobornik wrote: >>>> ipa-ca-install said that it used >>>> /var/log/ipareplica-ca-install.log >>>> but in fact it used >>>> /var/log/ipaserver-ca-install.log >>>> >>>> This patch unites it to ipaserver-ca-install.log >>>> >>>> It was chosen because ipa-ca-install can be also used on >>>> master on CA-less -> CA conversion. >>>> >>>> Term "server" is valid for both master and replica. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6088 >>>> >>>> >>>> >>> >>> Looks good to me. >>> Ack >> >> Does not look so good to me, "ipareplica-ca-install.log" is in fact the >> original file name used since ipa-ca-install was introduced (in commit >> 8a32bb3746802a29b2655e4ad2cbbba8481e1eaf), so why the switch to >> "ipaserver-ca-install.log"? >> >> Honza >> > > Ideally it would be ipa-ca-install.log but for backwards compatibility, > let's stick with one which we have. AFAIK the framework(run_script > method? doesn't support switching the log name which is printed in error > message depending on usage. Therefore the universal was chosen - > ipaserver-ca-install.log. It was introduced by your commit > d27e77adc56f5a04f3bdd1aaed5440a89ed3acad Correct, but only for CA-less to CA-ful conversion. It is used exclusively only since commit 958996b9cc55b6e9ecdc23981e79599ec6826b4c and by accident, AFAICT. > > And I see, that I used wrong ticket number in the commit. Correct is > https://fedorahosted.org/freeipa/ticket/6086 > > Proper solution might be to rework main and __main__ function in > ipa-ca-install but IMO we spent too much time on this already. > -- Jan Cholasta From tbordaz at redhat.com Tue Jul 19 08:17:27 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 19 Jul 2016 10:17:27 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Bug in the ipapwd plugin In-Reply-To: <20160713200257.GA13575@10.4.128.1> References: <57865530.3000602@redhat.com> <20160713200257.GA13575@10.4.128.1> Message-ID: <578DE217.70502@redhat.com> On 07/13/2016 10:02 PM, Lukas Slebodnik wrote: > On (13/07/16 16:50), thierry bordaz wrote: >> https://fedorahosted.org/freeipa/ticket/6030 >> >From 4efedc5e674db92f9f7c160429df543422ed8afb Mon Sep 17 00:00:00 2001 >> From: Thierry Bordaz >> Date: Wed, 13 Jul 2016 15:34:20 +0200 >> Subject: [PATCH] Ticket 6030 Bug in the ipapwd plugin >> >> ipapwd_encrypt_encode_key allocates 'kset' on the heap but >> with num_keys and keys not being initialized. >> Then ipa_krb5_generate_key_data initializes them with the >> generated keys. >> If ipa_krb5_generate_key_data fails (here EINVAL meaning no >> principal->realm.data), num_keys and keys are left uninitialized. >> Upon failure, ipapwd_keyset_free is called to free 'kset' >> that contains random num_keys and keys. >> >> allocates kset with calloc so that kset->num_keys==0 and >> kset->keys==NULL >> >> https://fedorahosted.org/freeipa/ticket/6030 >> --- >> daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >> index 5ca155d..46bf79a 100644 >> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >> @@ -148,7 +148,7 @@ Slapi_Value **ipapwd_encrypt_encode_key(struct ipapwd_krbcfg *krbcfg, >> pwd.length = strlen(data->password); >> } >> >> - kset = malloc(sizeof(struct ipapwd_keyset)); >> + kset = calloc(sizeof(struct ipapwd_keyset)); > I though that calloc need two arguments > > man malloc says: > void *malloc(size_t size); > void *calloc(size_t nmemb, size_t size); > > LS Oppss, sorry for this dummy patch. Here is the right one thanks thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-44-tbordaz-0023-2-Heap-corruption-in-ipapwd-plugin.patch Type: text/x-patch Size: 1446 bytes Desc: not available URL: From flo at redhat.com Tue Jul 19 08:25:16 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 19 Jul 2016 10:25:16 +0200 Subject: [Freeipa-devel] [PATCH 0059] Fix to ipa-cacert-manage man and help differences In-Reply-To: <33e33813-1aeb-3d50-e05c-cadc3cb8e4bb@redhat.com> References: <33e33813-1aeb-3d50-e05c-cadc3cb8e4bb@redhat.com> Message-ID: <182017ec-6015-c99a-8e96-cbeefaefa970@redhat.com> On 07/15/2016 02:09 PM, Stanislav Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/6013 > > > Hi Stanislav, thanks for your patch. As CERTFILE is added in the arguments for install, I would suggest to mention it in the command description. For instance: install - Install a CA certificate This command can be used to install the certificate contained in CERTFILE as a new CA certificate to IPA. Flo. From jcholast at redhat.com Tue Jul 19 08:34:29 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 10:34:29 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <20160718081232.qj3klx4r6usbyw3d@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> Message-ID: On 18.7.2016 10:12, Alexander Bokovoy wrote: > On Mon, 18 Jul 2016, Jan Cholasta wrote: >> Hi, >> >> On 16.7.2016 12:46, Alexander Bokovoy wrote: >>> Hi, >>> >>> I had some time and was blocked by these bugs to do my tickets so I >>> actually fixed these three problems that are assigned to Martin >>> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>> >>> ------ >>> >>> Output entry elements may have multiple types allowed. We need to check >>> all of them to properly validate the output. Right now, thin client >>> receives type specifications for elements as tuples of types, so >>> what is seen as 'None' on the server side becomes (type(None),) tuple >>> on the thin client side. >>> >>> Change validation to account this by processing each separate type >>> of the element and account for both None and type(None). Raise type >>> error only if all of the type checks failed. >>> >>> https://fedorahosted.org/freeipa/ticket/6061 >> >> NACK, this only hides the real issue, which is that trustconfig-show >> (and automember-set-default in #6037) claims to return the primary key >> of the object in the 'value' output field, but the object does not >> have a primary key, so the client rightfully expects None. > Why did it work before introducing thin client? Because I took the liberty of not putting any extra effort just to keep old hacks working on thin client. In this case, output.PrimaryKey was used for the 'value' output field before, which always allowed unicode in addition to the primary key type. On thin client, output.Output with the primary key type is used instead, which is less forgiving and uncovers bogus command definitions. (There aren't any besides the ones already mentioned, I remember fixing them but the commit got lost somehow. Oh well.) > > Aside from that, comparing "(type(None),) is None" will never give you > True on the thin client side. At the server side we have "None is None" > and that works. So the question is also why there is a change like that > between client and server sides? I don't see how this has anything to do with anything. In output validation, "type = None" means that value of any type is allowed, "type = (type(None),)" means that only None is allowed. Nothing changed with regard to that in thin client. > >> A proper fix would be to set "has_output = output.simple_value" for >> these commands (all of automember_default_group_{set,remove,show}, >> trustconfig_{mod,show}). >> >> Honza >> >> -- >> Jan Cholasta > -- Jan Cholasta From abokovoy at redhat.com Tue Jul 19 08:40:49 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 19 Jul 2016 11:40:49 +0300 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> Message-ID: <20160719084049.fgtfsvvp7foxbnxj@redhat.com> On Tue, 19 Jul 2016, Jan Cholasta wrote: >On 18.7.2016 10:12, Alexander Bokovoy wrote: >>On Mon, 18 Jul 2016, Jan Cholasta wrote: >>>Hi, >>> >>>On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>Hi, >>>> >>>>I had some time and was blocked by these bugs to do my tickets so I >>>>actually fixed these three problems that are assigned to Martin >>>>Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>> >>>>------ >>>> >>>>Output entry elements may have multiple types allowed. We need to check >>>>all of them to properly validate the output. Right now, thin client >>>>receives type specifications for elements as tuples of types, so >>>>what is seen as 'None' on the server side becomes (type(None),) tuple >>>>on the thin client side. >>>> >>>>Change validation to account this by processing each separate type >>>>of the element and account for both None and type(None). Raise type >>>>error only if all of the type checks failed. >>>> >>>>https://fedorahosted.org/freeipa/ticket/6061 >>> >>>NACK, this only hides the real issue, which is that trustconfig-show >>>(and automember-set-default in #6037) claims to return the primary key >>>of the object in the 'value' output field, but the object does not >>>have a primary key, so the client rightfully expects None. >>Why did it work before introducing thin client? > >Because I took the liberty of not putting any extra effort just to >keep old hacks working on thin client. In this case, output.PrimaryKey >was used for the 'value' output field before, which always allowed >unicode in addition to the primary key type. On thin client, >output.Output with the primary key type is used instead, which is less >forgiving and uncovers bogus command definitions. (There aren't any >besides the ones already mentioned, I remember fixing them but the >commit got lost somehow. Oh well.) This means thin client would not work against old server which would return a non-primary key value. I think it is unacceptable. >>Aside from that, comparing "(type(None),) is None" will never give you >>True on the thin client side. At the server side we have "None is None" >>and that works. So the question is also why there is a change like that >>between client and server sides? > >I don't see how this has anything to do with anything. In output >validation, "type = None" means that value of any type is allowed, >"type = (type(None),)" means that only None is allowed. Nothing >changed with regard to that in thin client. Really? Previous code worked against corresponding server, new code doesn't work against the very same server. I consider it a breakage. -- / Alexander Bokovoy From ldoudova at redhat.com Tue Jul 19 08:41:45 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 19 Jul 2016 10:41:45 +0200 Subject: [Freeipa-devel] [PATCH 0029][Tests] Adding authentication test to trust test suite Message-ID: <2a1cdafa-b75e-7789-6834-a5197f159ea6@redhat.com> Hi, this patch adds authentication test (specifically "kinit -E ipauser at IPADOMAIN") to basic trust test suite, as requested by Sumit. Intended to be applied after my patches 25.4 and 26.3 (already waiting to be pushed). Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0029-Tests-Adding-authentication-test-to-basic-trust-test.patch Type: text/x-patch Size: 2780 bytes Desc: not available URL: From jcholast at redhat.com Tue Jul 19 09:02:09 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 11:02:09 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <20160719084049.fgtfsvvp7foxbnxj@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> <20160719084049.fgtfsvvp7foxbnxj@redhat.com> Message-ID: <4eb1c8b4-88c8-2036-ca3e-08b602e9421b@redhat.com> On 19.7.2016 10:40, Alexander Bokovoy wrote: > On Tue, 19 Jul 2016, Jan Cholasta wrote: >> On 18.7.2016 10:12, Alexander Bokovoy wrote: >>> On Mon, 18 Jul 2016, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> I had some time and was blocked by these bugs to do my tickets so I >>>>> actually fixed these three problems that are assigned to Martin >>>>> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>>> >>>>> ------ >>>>> >>>>> Output entry elements may have multiple types allowed. We need to >>>>> check >>>>> all of them to properly validate the output. Right now, thin client >>>>> receives type specifications for elements as tuples of types, so >>>>> what is seen as 'None' on the server side becomes (type(None),) tuple >>>>> on the thin client side. >>>>> >>>>> Change validation to account this by processing each separate type >>>>> of the element and account for both None and type(None). Raise type >>>>> error only if all of the type checks failed. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6061 >>>> >>>> NACK, this only hides the real issue, which is that trustconfig-show >>>> (and automember-set-default in #6037) claims to return the primary key >>>> of the object in the 'value' output field, but the object does not >>>> have a primary key, so the client rightfully expects None. >>> Why did it work before introducing thin client? >> >> Because I took the liberty of not putting any extra effort just to >> keep old hacks working on thin client. In this case, output.PrimaryKey >> was used for the 'value' output field before, which always allowed >> unicode in addition to the primary key type. On thin client, >> output.Output with the primary key type is used instead, which is less >> forgiving and uncovers bogus command definitions. (There aren't any >> besides the ones already mentioned, I remember fixing them but the >> commit got lost somehow. Oh well.) > This means thin client would not work against old server which would > return a non-primary key value. I think it is unacceptable. Not true, as this only applies to servers with API schema (4.4+). > >>> Aside from that, comparing "(type(None),) is None" will never give you >>> True on the thin client side. At the server side we have "None is None" >>> and that works. So the question is also why there is a change like that >>> between client and server sides? >> >> I don't see how this has anything to do with anything. In output >> validation, "type = None" means that value of any type is allowed, >> "type = (type(None),)" means that only None is allowed. Nothing >> changed with regard to that in thin client. > Really? Previous code worked against corresponding server, new code > doesn't work against the very same server. I consider it a breakage. Really, since commit b6e4972e. If something is broken, please file a ticket. -- Jan Cholasta From jcholast at redhat.com Tue Jul 19 09:02:52 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 11:02:52 +0200 Subject: [Freeipa-devel] [PATCH] 0211-0212 Make sure --raw option works for trust-add In-Reply-To: <0183c16f-21a2-59ab-25cc-b4964a2111a4@redhat.com> References: <20160716105005.3nbpdxd2bsr2o2op@redhat.com> <0183c16f-21a2-59ab-25cc-b4964a2111a4@redhat.com> Message-ID: <214270d7-2930-3977-33ff-d0ef2bd2c454@redhat.com> On 18.7.2016 12:06, Martin Babinsky wrote: > On 07/16/2016 12:50 PM, Alexander Bokovoy wrote: >> Hi, >> >> >> I had some time and was blocked by these bugs to do my tickets so I >> actually fixed these three problems that are assigned to Martin >> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >> >> Note that this fix (patch 0211) has potential for a break but also >> introduces a correct behavior in my view as we should not really have >> non-lower cased keys in LDAP dictionaries in entry_to_dict() for both >> normal and --raw modes. >> >> ----- 0211 >> >> Since commit a8dd7aa337f25abd938a582d0fcba51d3b356410 if IPA command >> is called with --raw option, a retrieved LDAP entry's attribute >> names aren't normalized to lower case when converting the entry >> to a dictionary. This breaks overall assumption that dictionary >> keys are in lower case. >> >> Partially fixes 'ipa trust-add --raw' issues. >> >> https://fedorahosted.org/freeipa/ticket/6059 >> >> ----- 0212 >> >> Make sure we display raw values for 'trust-add --raw' case. >> >> https://fedorahosted.org/freeipa/ticket/6059 >> >> >> >> > > Hi Alexander, > > I am CC'ing Jan since I hope he knows why > a8dd7aa337f25abd938a582d0fcba51d3b356410 was implemented in this way. I > think there was a reason behind this decision and we should not revert > it without further discussion. I think it was just because with --raw, the raw LDAP entry should be returned, letter case and all. I don't really care if the names are lowercased or not, but you should never assume anything about raw results in your code anyway, so I think the revert would be pointless. There were a few bugs with --raw unrelated to letter case in the past and most of the offending code was fixed, the same should be done here IMO. > > I had the fix for trust-add ready on Friday but was unable to test it > properly because of some issues with my VMs. I am attaching it for > reference, since it is similar to your patch 212 but relies on > attrs_list passed in to LDAP search in order to fetch lowercased > attributes. > -- Jan Cholasta From pspacek at redhat.com Tue Jul 19 09:27:47 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 19 Jul 2016 11:27:47 +0200 Subject: [Freeipa-devel] Using RPZ to overcome multi Kerberos domains and multiple DNS authorities. In-Reply-To: References: Message-ID: <7a358172-cea6-bb38-692e-8c9c817518f9@redhat.com> On 18.7.2016 19:44, Jim Glenz wrote: > IPA DNS configuration using Response Policy Zone (RPZ). > > IPA utilizes DNS extensively to locate service records (SRV) and text > records (TXT) associated with the Kerberos realm. > IPA also heavily require DNS A records and PTR records to function > correctly. > Normally all A,SRV,TXT,PTR records are part of the same DNS domain zone. > > The following shows how to decouple IPA "TXT and SRV" records only, and > pass (forward) all other records to another internal DNS server when > required to have all records (except SRV and TXT) records in the other DNS > system. > > Note: Below is very customized for specific environment, your environment > may be different. Just wanted to pass on this DNS trick. > Methodology used was to implement a BIND instance on at least two servers > and then configuring a Response Policy Zone (RPZ). > The RPZ is configured to respond to specific DNS records and forward other > DNS records onward to next hop DNS. > > All A and PTR records should exist in the next hop DNS authoritative server. > As mentioned, the following solution is very specific to a unique > environment. > > IPA members and clinet servers must have their primary/secondary DNS > resolvers set to the DNS RPZ BIND servers. > > > Steps > Create your Master and Slave Bind DNS where RPZ will be used (can be your > IPA server or any other server having Bind DNS installed) > Create Response Policy Zone (RPZ) files. > Test configuration. > > Search below for " > nslookup > nslookup > > nslookup . > nslookup . > > nslookup > nslookup . > nslookup -type=TXT _kerberos. Bind-DNS-RPZ2-IP-address> > nslookup -type=SRV _kerberos-master._tcp. Bind-DNS-RPZ2-IP-address> > nslookup -type=SRV _kerberos-master._udp. Bind-DNS-RPZ2-IP-address> > nslookup -type=SRV _kerberos._tcp. Bind-DNS-RPZ2-IP-address> > nslookup -type=SRV _kerberos._udp. Bind-DNS-RPZ2-IP-address> > nslookup -type=SRV _kpasswd._tcp. Bind-DNS-RPZ2-IP-address> > nslookup -type=SRV _kpasswd._udp. Bind-DNS-RPZ2-IP-address> > nslookup -type=SRV _ldap._tcp. Bind-DNS-RPZ2-IP-address> > > nslookup > nslookup . > nslookup -type=TXT _kerberos. Bind-DNS-RPZ1-IP-address> > nslookup -type=SRV _kerberos-master._tcp. Bind-DNS-RPZ1-IP-address> > nslookup -type=SRV _kerberos-master._udp. Bind-DNS-RPZ1-IP-address> > nslookup -type=SRV _kerberos._tcp. Bind-DNS-RPZ1-IP-address> > nslookup -type=SRV _kerberos._udp. Bind-DNS-RPZ1-IP-address> > nslookup -type=SRV _kpasswd._tcp. Bind-DNS-RPZ1-IP-address> > nslookup -type=SRV _kpasswd._udp. Bind-DNS-RPZ1-IP-address> > nslookup -type=SRV _ldap._tcp. Bind-DNS-RPZ1-IP-address> > > nslookup google.com > nslookup google.com > > nslookup -type=ptr Bind-DNS-RPZ2-IP-address> > nslookup -type=ptr Bind-DNS-RPZ1-IP-address> > nslookup -type=ptr Bind-DNS-RPZ2-IP-address> > nslookup -type=ptr Bind-DNS-RPZ1-IP-address> > > > Will be referencing reverse.arpa zone 10.x.x.x internal network. Adjust as > necessary for your environment. > > Appendix A: Primary IPA DNS /etc/named.conf file > # cat named.conf > options { > // Put files that named is allowed to write in the data/ directory: > directory "/var/named"; // the default > dump-file "data/cache_dump.db"; > statistics-file "data/named_stats.txt"; > memstatistics-file "data/named_mem_stats.txt"; > #forward first; > forwarders { > ; > ; > }; > response-policy {zone ""; }; > > // Any host is permitted to issue recursive queries > allow-recursion { any; }; > > tkey-gssapi-credential "DNS/"; > tkey-domain ""; > }; > > /* If you want to enable debugging, eg. using the 'rndc trace' command, > * By default, SELinux policy does not allow named to modify the /var/named > directory, > * so put the default debug log file in data/ : > */ > logging { > channel default_debug { > file "data/named.run"; > severity dynamic; > }; > }; > > zone "" IN { > type master; > file ""; > also-notify {;}; > }; > > zone "10.in-addr.arpa" IN { > type forward; > forwarders { > ; > ; > }; > }; > > include "/etc/named.rfc1912.zones"; > > # dynamic not used, remark out. > #dynamic-db "ipa" { > # library "ldap.so"; > #}; > > Appendix B: Primary IPA DNS /var/named/ file > $ORIGIN . > $TTL 86400 ; 1 day > .rpz IN SOA localhost. root.localhost. ( > 201505162150 ; serial > 3600 ; refresh (1 hour) > 1800 ; retry (30 minutes) > 604800 ; expire (1 week) > 86400 ; minimum (1 day) > ) > NS localhost. > $ORIGIN .rpz. > _kerberos TXT "" > _ntp_udp SRV 0 100 123 ". > $ORIGIN _tcp..rpz. > _kerberos SRV 0 100 88 ". > SRV 0 100 88 ". > _kerberos-master SRV 0 100 88 ". > SRV 0 100 88 ". > _kpasswd SRV 0 100 464 ". > SRV 0 100 464 ". > _ldap SRV 0 100 389 ". > SRV 0 100 389 ". > $ORIGIN _udp..rpz. > _kerberos SRV 0 100 88 ". > SRV 0 100 88 ". > _kerberos-master SRV 0 100 88 ". > SRV 0 100 88 ". > _kpasswd SRV 0 100 464 ". > SRV 0 100 464 ". > > > Appendix C: Secondary IPA DNS /etc/named.conf file > # cat /etc/named.conf > options { > // Put files that named is allowed to write in the data/ directory: > directory "/var/named"; // the default > dump-file "data/cache_dump.db"; > statistics-file "data/named_stats.txt"; > memstatistics-file "data/named_mem_stats.txt"; > #forward first; > forwarders { > ; > ; > }; > response-policy {zone ""; }; > > // Any host is permitted to issue recursive queries > allow-recursion { any; }; > > tkey-gssapi-credential "DNS/"; > tkey-domain ""; > }; > > /* If you want to enable debugging, eg. using the 'rndc trace' command, > * By default, SELinux policy does not allow named to modify the /var/named > directory, > * so put the default debug log file in data/ : > */ > logging { > channel default_debug { > file "data/named.run"; > severity dynamic; > }; > }; > > zone "" IN { > type slave; > file "slaves/"; > masters {";}; > }; > > zone "10.in-addr.arpa" IN { > type forward; > forwarders { > ; > ; > }; > }; > > include "/etc/named.rfc1912.zones"; > > # dynamic not used > #dynamic-db "ipa" { > # library "ldap.so"; > #}; > > Appendix D: Secondary IPA DNS /var/named/slaves/ > NOTE: Autogenerated by Master/Slave. Delete this file and then increment > SOA serial on Master. Reload Master named. > > cat /var/named/slaves/ > $ORIGIN . > $TTL 86400 ; 1 day > .rpz IN SOA localhost. root.localhost. ( > 3936666534 ; serial > 3600 ; refresh (1 hour) > 1800 ; retry (30 minutes) > 604800 ; expire (1 week) > 86400 ; minimum (1 day) > ) > NS localhost. > $ORIGIN .rpz. > _kerberos TXT "" > _ntp_udp SRV 0 100 123 ". > $ORIGIN _tcp..rpz. > _kerberos SRV 0 100 88 ". > SRV 0 100 88 ". > _kerberos-master SRV 0 100 88 ". > SRV 0 100 88 ". > _kpasswd SRV 0 100 464 ". > SRV 0 100 464 ". > _ldap SRV 0 100 389 ". > SRV 0 100 389 ". > $ORIGIN _udp..rpz. > _kerberos SRV 0 100 88 ". > SRV 0 100 88 ". > _kerberos-master SRV 0 100 88 ". > SRV 0 100 88 ". > _kpasswd SRV 0 100 464 ". > SRV 0 100 464 ". > > > In conclusion. > RPZ is very powerful, DNS mangling in a way. > This scenario was how I was able to overcome a tough/strict DNS environment > that I had zero control of. Thanks for the trick! Let me repeat that this example is not complete (AD trusts are missing) and it is tied to specific configuration. It will break/needs manual intervention at multiple occasions: - any replica addition/removal - any change in IPA replica naming - AD trust re-configuration - IPA upgrade (when a new DNS record is introduced) - any change to IPA DNS locations (new feature in IPA 4.4) It needs to be understood that this is option of the *very last* resort. We are looking into ways how to integrate FreeIPA in better ways with existing DNS systems. Comments regarding your existing setups and deficiencies you see are more than welcome! -- Petr^2 Spacek From abokovoy at redhat.com Tue Jul 19 09:32:04 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 19 Jul 2016 12:32:04 +0300 Subject: [Freeipa-devel] [PATCH] 0211-0212 Make sure --raw option works for trust-add In-Reply-To: <214270d7-2930-3977-33ff-d0ef2bd2c454@redhat.com> References: <20160716105005.3nbpdxd2bsr2o2op@redhat.com> <0183c16f-21a2-59ab-25cc-b4964a2111a4@redhat.com> <214270d7-2930-3977-33ff-d0ef2bd2c454@redhat.com> Message-ID: <20160719093204.n44lfk66thkhlfjc@redhat.com> On Tue, 19 Jul 2016, Jan Cholasta wrote: >On 18.7.2016 12:06, Martin Babinsky wrote: >>On 07/16/2016 12:50 PM, Alexander Bokovoy wrote: >>>Hi, >>> >>> >>>I had some time and was blocked by these bugs to do my tickets so I >>>actually fixed these three problems that are assigned to Martin >>>Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>> >>>Note that this fix (patch 0211) has potential for a break but also >>>introduces a correct behavior in my view as we should not really have >>>non-lower cased keys in LDAP dictionaries in entry_to_dict() for both >>>normal and --raw modes. >>> >>>----- 0211 >>> >>>Since commit a8dd7aa337f25abd938a582d0fcba51d3b356410 if IPA command >>>is called with --raw option, a retrieved LDAP entry's attribute >>>names aren't normalized to lower case when converting the entry >>>to a dictionary. This breaks overall assumption that dictionary >>>keys are in lower case. >>> >>>Partially fixes 'ipa trust-add --raw' issues. >>> >>>https://fedorahosted.org/freeipa/ticket/6059 >>> >>>----- 0212 >>> >>>Make sure we display raw values for 'trust-add --raw' case. >>> >>>https://fedorahosted.org/freeipa/ticket/6059 >>> >>> >>> >>> >> >>Hi Alexander, >> >>I am CC'ing Jan since I hope he knows why >>a8dd7aa337f25abd938a582d0fcba51d3b356410 was implemented in this way. I >>think there was a reason behind this decision and we should not revert >>it without further discussion. > >I think it was just because with --raw, the raw LDAP entry should be >returned, letter case and all. I don't really care if the names are >lowercased or not, but you should never assume anything about raw >results in your code anyway, so I think the revert would be pointless. >There were a few bugs with --raw unrelated to letter case in the past >and most of the offending code was fixed, the same should be done here >IMO. This is not about LDAP entry, this is about Python dictionary from entry_to_dict(). LDAP attribute name is case-insensitive. We call entry_to_dict() in multiple places and we expect that dictionary keys are lowcased in Python code. I don't think it is fair to have this assumption broken when --raw is used -- after all, we are dealing with Python dictionary and LDAP attributes are case insensitive. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Jul 19 09:36:10 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 19 Jul 2016 12:36:10 +0300 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <4eb1c8b4-88c8-2036-ca3e-08b602e9421b@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> <20160719084049.fgtfsvvp7foxbnxj@redhat.com> <4eb1c8b4-88c8-2036-ca3e-08b602e9421b@redhat.com> Message-ID: <20160719093610.iqy3hau6xpju4aa7@redhat.com> On Tue, 19 Jul 2016, Jan Cholasta wrote: >On 19.7.2016 10:40, Alexander Bokovoy wrote: >>On Tue, 19 Jul 2016, Jan Cholasta wrote: >>>On 18.7.2016 10:12, Alexander Bokovoy wrote: >>>>On Mon, 18 Jul 2016, Jan Cholasta wrote: >>>>>Hi, >>>>> >>>>>On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>>>Hi, >>>>>> >>>>>>I had some time and was blocked by these bugs to do my tickets so I >>>>>>actually fixed these three problems that are assigned to Martin >>>>>>Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>>>> >>>>>>------ >>>>>> >>>>>>Output entry elements may have multiple types allowed. We need to >>>>>>check >>>>>>all of them to properly validate the output. Right now, thin client >>>>>>receives type specifications for elements as tuples of types, so >>>>>>what is seen as 'None' on the server side becomes (type(None),) tuple >>>>>>on the thin client side. >>>>>> >>>>>>Change validation to account this by processing each separate type >>>>>>of the element and account for both None and type(None). Raise type >>>>>>error only if all of the type checks failed. >>>>>> >>>>>>https://fedorahosted.org/freeipa/ticket/6061 >>>>> >>>>>NACK, this only hides the real issue, which is that trustconfig-show >>>>>(and automember-set-default in #6037) claims to return the primary key >>>>>of the object in the 'value' output field, but the object does not >>>>>have a primary key, so the client rightfully expects None. >>>>Why did it work before introducing thin client? >>> >>>Because I took the liberty of not putting any extra effort just to >>>keep old hacks working on thin client. In this case, output.PrimaryKey >>>was used for the 'value' output field before, which always allowed >>>unicode in addition to the primary key type. On thin client, >>>output.Output with the primary key type is used instead, which is less >>>forgiving and uncovers bogus command definitions. (There aren't any >>>besides the ones already mentioned, I remember fixing them but the >>>commit got lost somehow. Oh well.) >>This means thin client would not work against old server which would >>return a non-primary key value. I think it is unacceptable. > >Not true, as this only applies to servers with API schema (4.4+). Only because thin client does not work against servers without API schema at all: [root at f24-master ~]# ipa -vv -e xmlrpc_uri=https://id.vda.li/ipa/xml config-show ipa: INFO: trying https://id.vda.li/ipa/json ipa: INFO: Request: { "id": 0, "method": "ping", "params": [ [], {} ] } ipa: INFO: Response: { "error": null, "id": 0, "principal": "admin at VDA.LI", "result": { "messages": [ { "code": 13001, "message": "API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.156", "name": "VersionMissing", "type": "warning" } ], "summary": "IPA server version 4.2.3. API version 2.156" }, "version": "4.2.3" } ipa: INFO: Forwarding 'config_show/1' to json server 'https://id.vda.li/ipa/json' ipa: INFO: Request: { "id": 0, "method": "config_show/1", "params": [ [], { "version": "2.210" } ] } ipa: INFO: Response: { "error": { "code": 905, "message": "unknown command 'config_show/1'", "name": "CommandError" }, "id": 0, "principal": "admin at VDA.LI", "result": null, "version": "4.2.3" } ipa: ERROR: unknown command 'config_show/1' Same happens for every other command so I cannot even test the behavior. It works against the same server as the thin client is. [root at f24-master ~]# ipa -vv config-show ipa: INFO: trying https://f24-master.ipa.ad.test/ipa/json ipa: INFO: Forwarding 'config_show/1' to json server 'https://f24-master.ipa.ad.test/ipa/json' ipa: INFO: Request: { "id": 0, "method": "config_show/1", "params": [ [], { "version": "2.210" } ] } ipa: INFO: Response: { "error": null, "id": 0, "principal": "admin at IPA.AD.TEST", "result": { "result": { "ca_renewal_master_server": "f24-master.ipa.ad.test", "ca_server_server": [ "f24-master.ipa.ad.test" ], "dn": "cn=ipaConfig,cn=etc,dc=ipa,dc=ad,dc=test", "ipa_master_server": [ "f24-master.ipa.ad.test" ], "ipacertificatesubjectbase": [ "O=IPA.AD.TEST" ], "ipaconfigstring": [ "AllowNThash" ], "ipadefaultemaildomain": [ "ipa.ad.test" ], "ipadefaultloginshell": [ "/bin/sh" ], "ipadefaultprimarygroup": [ "ipausers" ], "ipagroupsearchfields": [ "cn,description" ], "ipahomesrootdir": [ "/home" ], "ipakrbauthzdata": [ "nfs:NONE", "MS-PAC" ], "ipamaxusernamelength": [ "32" ], "ipamigrationenabled": [ "FALSE" ], "ipapwdexpadvnotify": [ "4" ], "ipasearchrecordslimit": [ "100" ], "ipasearchtimelimit": [ "2" ], "ipaselinuxusermapdefault": [ "unconfined_u:s0-s0:c0.c1023" ], "ipaselinuxusermaporder": [ "guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023" ], "ipausersearchfields": [ "uid,givenname,sn,telephonenumber,ou,title" ], "ntp_server_server": [ "f24-master.ipa.ad.test" ] }, "summary": null, "value": null }, "version": "4.4.0.201607151226GIT37bfd1f" } Maximum username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: ipa.ad.test Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=IPA.AD.TEST Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: nfs:NONE, MS-PAC IPA masters: f24-master.ipa.ad.test IPA CA servers: f24-master.ipa.ad.test IPA NTP servers: f24-master.ipa.ad.test IPA CA renewal master: f24-master.ipa.ad.test > >> >>>>Aside from that, comparing "(type(None),) is None" will never give you >>>>True on the thin client side. At the server side we have "None is None" >>>>and that works. So the question is also why there is a change like that >>>>between client and server sides? >>> >>>I don't see how this has anything to do with anything. In output >>>validation, "type = None" means that value of any type is allowed, >>>"type = (type(None),)" means that only None is allowed. Nothing >>>changed with regard to that in thin client. >>Really? Previous code worked against corresponding server, new code >>doesn't work against the very same server. I consider it a breakage. > >Really, since commit b6e4972e. If something is broken, please file a ticket. See above. How should I test? -- / Alexander Bokovoy From ftweedal at redhat.com Tue Jul 19 09:54:45 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 19 Jul 2016 19:54:45 +1000 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name In-Reply-To: <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> Message-ID: <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: > Hi, > > On 15.7.2016 07:05, Fraser Tweedale wrote: > > On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: > > > The attached patch is a work in progress for > > > https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). > > > > > > I am sharing now to make the approach clear and solicit feedback. > > > > > > It has been tested for server install, replica install (with and > > > without CA) and CA-replica install (all hosts running master+patch). > > > > > > Migration from earlier versions and server/replica/CA install on a > > > CA-less deployment are not yet tested; these will be tested over > > > coming days and patch will be tweaked as necessary. > > > > > > Commit message has a fair bit to say so I won't repeat here but let > > > me know your questions and comments. > > > > > > Thanks, > > > Fraser > > > > > It does help to attach the patch, of course ^_^ > > IMO explicit is better than implicit, so instead of introducing additional > magic around --subject, I would rather add a new separate option for > specifying the CA subject name (I think --ca-subject, for consistency with > --ca-signing-algorithm). > The current situation - the --subject argument which specifies the not the subject but the subject base, is confusing enough (to say nothing of the limitations that give rise to the RFE). Retaining --subject for specifying the subject base and adding --ca-subject for specifying the *actual* subject DN gets us over the line in terms of the RFE, but does not make the installer less confusing. This is why I made --subject accept the full subject DN, with provisions to retain existing behaviour. IMO if we want to have separate arguments for subject DN and subject base (I am not against it), let's bite the bullet and name arguments accordingly. --subject should be used to specify full Subject DN, --subject-base (or similar) for specifying subject base. (I intentionally defer discussion of specific behaviour if one, none or both are specified; let's resolve the question or renaming / changing meaning of arguments first). > By specifying the option you would override the default "CN=Certificate > Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, > additional validation would be done to make sure the subject name meets > Dogtag's expectations. Actually, it might make sense to always do the > additional validation, to be able to print a warning that if a > Dogtag-incompatible subject name is used, it won't be possible to change the > CA cert chaining from externally signed to self-signed later. > > Honza > > -- > Jan Cholasta From jcholast at redhat.com Tue Jul 19 10:05:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 12:05:21 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Allow full customisability of CA subject name In-Reply-To: <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> References: <20160715050448.GE10771@dhcp-40-8.bne.redhat.com> <20160715050539.GF10771@dhcp-40-8.bne.redhat.com> <83eb61a6-4e1f-d33a-1bbb-dacf8de522af@redhat.com> <20160719095445.GU10771@dhcp-40-8.bne.redhat.com> Message-ID: <4f7384ee-e648-2adb-3c86-26e297ede481@redhat.com> On 19.7.2016 11:54, Fraser Tweedale wrote: > On Tue, Jul 19, 2016 at 09:36:17AM +0200, Jan Cholasta wrote: >> Hi, >> >> On 15.7.2016 07:05, Fraser Tweedale wrote: >>> On Fri, Jul 15, 2016 at 03:04:48PM +1000, Fraser Tweedale wrote: >>>> The attached patch is a work in progress for >>>> https://fedorahosted.org/freeipa/ticket/2614 (BZ 828866). >>>> >>>> I am sharing now to make the approach clear and solicit feedback. >>>> >>>> It has been tested for server install, replica install (with and >>>> without CA) and CA-replica install (all hosts running master+patch). >>>> >>>> Migration from earlier versions and server/replica/CA install on a >>>> CA-less deployment are not yet tested; these will be tested over >>>> coming days and patch will be tweaked as necessary. >>>> >>>> Commit message has a fair bit to say so I won't repeat here but let >>>> me know your questions and comments. >>>> >>>> Thanks, >>>> Fraser >>>> >>> It does help to attach the patch, of course ^_^ >> >> IMO explicit is better than implicit, so instead of introducing additional >> magic around --subject, I would rather add a new separate option for >> specifying the CA subject name (I think --ca-subject, for consistency with >> --ca-signing-algorithm). >> > The current situation - the --subject argument which specifies the > not the subject but the subject base, is confusing enough (to say > nothing of the limitations that give rise to the RFE). > > Retaining --subject for specifying the subject base and adding > --ca-subject for specifying the *actual* subject DN gets us over the > line in terms of the RFE, but does not make the installer less > confusing. This is why I made --subject accept the full subject DN, > with provisions to retain existing behaviour. > > IMO if we want to have separate arguments for subject DN and subject > base (I am not against it), let's bite the bullet and name arguments > accordingly. --subject should be used to specify full Subject DN, > --subject-base (or similar) for specifying subject base. IMHO --ca-subject is better than --subject, because it is more explicit whose subject name that is (the CA's). I agree that --subject should be deprecated and replaced with --subject-base. > > (I intentionally defer discussion of specific behaviour if one, none > or both are specified; let's resolve the question or renaming / > changing meaning of arguments first). > > >> By specifying the option you would override the default "CN=Certificate >> Authority,$SUBJECT_BASE" subject name. If --external-ca was not used, >> additional validation would be done to make sure the subject name meets >> Dogtag's expectations. Actually, it might make sense to always do the >> additional validation, to be able to print a warning that if a >> Dogtag-incompatible subject name is used, it won't be possible to change the >> CA cert chaining from externally signed to self-signed later. >> >> Honza >> >> -- >> Jan Cholasta -- Jan Cholasta From simo at redhat.com Tue Jul 19 10:21:55 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 19 Jul 2016 06:21:55 -0400 Subject: [Freeipa-devel] [PATCH] 0023 Bug in the ipapwd plugin In-Reply-To: <578DE217.70502@redhat.com> References: <57865530.3000602@redhat.com> <20160713200257.GA13575@10.4.128.1> <578DE217.70502@redhat.com> Message-ID: <1468923715.21393.3.camel@redhat.com> On Tue, 2016-07-19 at 10:17 +0200, thierry bordaz wrote: > > > On 07/13/2016 10:02 PM, Lukas Slebodnik wrote: > > On (13/07/16 16:50), thierry bordaz wrote: > >> https://fedorahosted.org/freeipa/ticket/6030 > >> >From 4efedc5e674db92f9f7c160429df543422ed8afb Mon Sep 17 00:00:00 > 2001 > >> From: Thierry Bordaz > >> Date: Wed, 13 Jul 2016 15:34:20 +0200 > >> Subject: [PATCH] Ticket 6030 Bug in the ipapwd plugin > >> > >> ipapwd_encrypt_encode_key allocates 'kset' on the heap but > >> with num_keys and keys not being initialized. > >> Then ipa_krb5_generate_key_data initializes them with the > >> generated keys. > >> If ipa_krb5_generate_key_data fails (here EINVAL meaning no > >> principal->realm.data), num_keys and keys are left uninitialized. > >> Upon failure, ipapwd_keyset_free is called to free 'kset' > >> that contains random num_keys and keys. > >> > >> allocates kset with calloc so that kset->num_keys==0 and > >> kset->keys==NULL > >> > >> https://fedorahosted.org/freeipa/ticket/6030 > >> --- > >> daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c > b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c > >> index 5ca155d..46bf79a 100644 > >> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c > >> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c > >> @@ -148,7 +148,7 @@ Slapi_Value **ipapwd_encrypt_encode_key(struct > ipapwd_krbcfg *krbcfg, > >>????????? pwd.length = strlen(data->password); > >>????? } > >> > >> -??? kset = malloc(sizeof(struct ipapwd_keyset)); > >> +??? kset = calloc(sizeof(struct ipapwd_keyset)); > > I though that calloc need two arguments > > > > man malloc says: > >???????? void *malloc(size_t size); > >???????? void *calloc(size_t nmemb, size_t size); > > > > LS > Oppss,? sorry for this dummy patch. Here is the right one ACK, Simo. From abokovoy at redhat.com Tue Jul 19 10:23:57 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 19 Jul 2016 13:23:57 +0300 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <20160719093610.iqy3hau6xpju4aa7@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> <20160719084049.fgtfsvvp7foxbnxj@redhat.com> <4eb1c8b4-88c8-2036-ca3e-08b602e9421b@redhat.com> <20160719093610.iqy3hau6xpju4aa7@redhat.com> Message-ID: <20160719102357.f3dj6fqa5bgxkeik@redhat.com> On Tue, 19 Jul 2016, Alexander Bokovoy wrote: >On Tue, 19 Jul 2016, Jan Cholasta wrote: >>On 19.7.2016 10:40, Alexander Bokovoy wrote: >>>On Tue, 19 Jul 2016, Jan Cholasta wrote: >>>>On 18.7.2016 10:12, Alexander Bokovoy wrote: >>>>>On Mon, 18 Jul 2016, Jan Cholasta wrote: >>>>>>Hi, >>>>>> >>>>>>On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>>>>Hi, >>>>>>> >>>>>>>I had some time and was blocked by these bugs to do my tickets so I >>>>>>>actually fixed these three problems that are assigned to Martin >>>>>>>Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>>>>> >>>>>>>------ >>>>>>> >>>>>>>Output entry elements may have multiple types allowed. We need to >>>>>>>check >>>>>>>all of them to properly validate the output. Right now, thin client >>>>>>>receives type specifications for elements as tuples of types, so >>>>>>>what is seen as 'None' on the server side becomes (type(None),) tuple >>>>>>>on the thin client side. >>>>>>> >>>>>>>Change validation to account this by processing each separate type >>>>>>>of the element and account for both None and type(None). Raise type >>>>>>>error only if all of the type checks failed. >>>>>>> >>>>>>>https://fedorahosted.org/freeipa/ticket/6061 >>>>>> >>>>>>NACK, this only hides the real issue, which is that trustconfig-show >>>>>>(and automember-set-default in #6037) claims to return the primary key >>>>>>of the object in the 'value' output field, but the object does not >>>>>>have a primary key, so the client rightfully expects None. >>>>>Why did it work before introducing thin client? >>>> >>>>Because I took the liberty of not putting any extra effort just to >>>>keep old hacks working on thin client. In this case, output.PrimaryKey >>>>was used for the 'value' output field before, which always allowed >>>>unicode in addition to the primary key type. On thin client, >>>>output.Output with the primary key type is used instead, which is less >>>>forgiving and uncovers bogus command definitions. (There aren't any >>>>besides the ones already mentioned, I remember fixing them but the >>>>commit got lost somehow. Oh well.) >>>This means thin client would not work against old server which would >>>return a non-primary key value. I think it is unacceptable. >> >>Not true, as this only applies to servers with API schema (4.4+). >Only because thin client does not work against servers without API >schema at all: > >[root at f24-master ~]# ipa -vv -e xmlrpc_uri=https://id.vda.li/ipa/xml config-show >ipa: INFO: trying https://id.vda.li/ipa/json >ipa: INFO: Request: { > "id": 0, "method": "ping", "params": [ > [], {} > ] >} >ipa: INFO: Response: { > "error": null, "id": 0, "principal": "admin at VDA.LI", >"result": { > "messages": [ > { > "code": 13001, "message": "API Version >number was not sent, forward compatibility not guaranteed. Assuming >server's API version, 2.156", "name": "VersionMissing", >"type": "warning" > } > ], "summary": "IPA server version 4.2.3. API version >2.156" > }, "version": "4.2.3" >} >ipa: INFO: Forwarding 'config_show/1' to json server 'https://id.vda.li/ipa/json' >ipa: INFO: Request: { > "id": 0, "method": "config_show/1", "params": [ > [], { > "version": "2.210" > } > ] >} >ipa: INFO: Response: { > "error": { > "code": 905, "message": "unknown command >'config_show/1'", "name": "CommandError" > }, "id": 0, "principal": "admin at VDA.LI", "result": null, >"version": "4.2.3" >} >ipa: ERROR: unknown command 'config_show/1' > >Same happens for every other command so I cannot even test the behavior. >It works against the same server as the thin client is. > >[root at f24-master ~]# ipa -vv config-show >ipa: INFO: trying https://f24-master.ipa.ad.test/ipa/json >ipa: INFO: Forwarding 'config_show/1' to json server 'https://f24-master.ipa.ad.test/ipa/json' >ipa: INFO: Request: { > "id": 0, "method": "config_show/1", "params": [ > [], { > "version": "2.210" > } > ] >} >ipa: INFO: Response: { > "error": null, "id": 0, "principal": "admin at IPA.AD.TEST", >"result": { > "result": { > "ca_renewal_master_server": "f24-master.ipa.ad.test", >"ca_server_server": [ > "f24-master.ipa.ad.test" > ], "dn": >"cn=ipaConfig,cn=etc,dc=ipa,dc=ad,dc=test", >"ipa_master_server": [ > "f24-master.ipa.ad.test" > ], "ipacertificatesubjectbase": [ > "O=IPA.AD.TEST" > ], "ipaconfigstring": [ > "AllowNThash" > ], "ipadefaultemaildomain": [ > "ipa.ad.test" > ], "ipadefaultloginshell": [ > "/bin/sh" > ], "ipadefaultprimarygroup": [ > "ipausers" > ], "ipagroupsearchfields": [ > "cn,description" > ], "ipahomesrootdir": [ > "/home" > ], "ipakrbauthzdata": [ > "nfs:NONE", "MS-PAC" > ], "ipamaxusernamelength": [ > "32" > ], "ipamigrationenabled": [ > "FALSE" > ], "ipapwdexpadvnotify": [ > "4" > ], "ipasearchrecordslimit": [ > "100" > ], "ipasearchtimelimit": [ > "2" > ], "ipaselinuxusermapdefault": [ > "unconfined_u:s0-s0:c0.c1023" > ], "ipaselinuxusermaporder": [ > "guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023" > ], "ipausersearchfields": [ > "uid,givenname,sn,telephonenumber,ou,title" > ], "ntp_server_server": [ > "f24-master.ipa.ad.test" > ] > }, "summary": null, "value": null > }, "version": "4.4.0.201607151226GIT37bfd1f" >} > Maximum username length: 32 > Home directory base: /home > Default shell: /bin/sh > Default users group: ipausers > Default e-mail domain: ipa.ad.test > Search time limit: 2 > Search size limit: 100 > User search fields: uid,givenname,sn,telephonenumber,ou,title > Group search fields: cn,description > Enable migration mode: FALSE > Certificate Subject base: O=IPA.AD.TEST > Password Expiration Notification (days): 4 > Password plugin features: AllowNThash > SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 > Default SELinux user: unconfined_u:s0-s0:c0.c1023 > Default PAC types: nfs:NONE, MS-PAC > IPA masters: f24-master.ipa.ad.test > IPA CA servers: f24-master.ipa.ad.test > IPA NTP servers: f24-master.ipa.ad.test > IPA CA renewal master: f24-master.ipa.ad.test > > > >> >>> >>>>>Aside from that, comparing "(type(None),) is None" will never give you >>>>>True on the thin client side. At the server side we have "None is None" >>>>>and that works. So the question is also why there is a change like that >>>>>between client and server sides? >>>> >>>>I don't see how this has anything to do with anything. In output >>>>validation, "type = None" means that value of any type is allowed, >>>>"type = (type(None),)" means that only None is allowed. Nothing >>>>changed with regard to that in thin client. >>>Really? Previous code worked against corresponding server, new code >>>doesn't work against the very same server. I consider it a breakage. >> >>Really, since commit b6e4972e. If something is broken, please file a ticket. >See above. How should I test? I filed a ticket https://fedorahosted.org/freeipa/ticket/6092 for thin client incapability to talk to old servers. -- / Alexander Bokovoy From jcholast at redhat.com Tue Jul 19 10:29:18 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 12:29:18 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <20160719093610.iqy3hau6xpju4aa7@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> <20160719084049.fgtfsvvp7foxbnxj@redhat.com> <4eb1c8b4-88c8-2036-ca3e-08b602e9421b@redhat.com> <20160719093610.iqy3hau6xpju4aa7@redhat.com> Message-ID: <816e5a83-5069-5568-d074-6d040070516f@redhat.com> On 19.7.2016 11:36, Alexander Bokovoy wrote: > On Tue, 19 Jul 2016, Jan Cholasta wrote: >> On 19.7.2016 10:40, Alexander Bokovoy wrote: >>> On Tue, 19 Jul 2016, Jan Cholasta wrote: >>>> On 18.7.2016 10:12, Alexander Bokovoy wrote: >>>>> On Mon, 18 Jul 2016, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I had some time and was blocked by these bugs to do my tickets so I >>>>>>> actually fixed these three problems that are assigned to Martin >>>>>>> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>>>>> >>>>>>> ------ >>>>>>> >>>>>>> Output entry elements may have multiple types allowed. We need to >>>>>>> check >>>>>>> all of them to properly validate the output. Right now, thin client >>>>>>> receives type specifications for elements as tuples of types, so >>>>>>> what is seen as 'None' on the server side becomes (type(None),) >>>>>>> tuple >>>>>>> on the thin client side. >>>>>>> >>>>>>> Change validation to account this by processing each separate type >>>>>>> of the element and account for both None and type(None). Raise type >>>>>>> error only if all of the type checks failed. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6061 >>>>>> >>>>>> NACK, this only hides the real issue, which is that trustconfig-show >>>>>> (and automember-set-default in #6037) claims to return the primary >>>>>> key >>>>>> of the object in the 'value' output field, but the object does not >>>>>> have a primary key, so the client rightfully expects None. >>>>> Why did it work before introducing thin client? >>>> >>>> Because I took the liberty of not putting any extra effort just to >>>> keep old hacks working on thin client. In this case, output.PrimaryKey >>>> was used for the 'value' output field before, which always allowed >>>> unicode in addition to the primary key type. On thin client, >>>> output.Output with the primary key type is used instead, which is less >>>> forgiving and uncovers bogus command definitions. (There aren't any >>>> besides the ones already mentioned, I remember fixing them but the >>>> commit got lost somehow. Oh well.) >>> This means thin client would not work against old server which would >>> return a non-primary key value. I think it is unacceptable. >> >> Not true, as this only applies to servers with API schema (4.4+). > Only because thin client does not work against servers without API > schema at all: > > [root at f24-master ~]# ipa -vv -e xmlrpc_uri=https://id.vda.li/ipa/xml > config-show > ipa: INFO: trying https://id.vda.li/ipa/json > ipa: INFO: Request: { > "id": 0, "method": "ping", "params": [ > [], {} > ] > } > ipa: INFO: Response: { > "error": null, "id": 0, "principal": "admin at VDA.LI", > "result": { > "messages": [ > { > "code": 13001, "message": "API Version > number was not sent, forward compatibility not guaranteed. Assuming > server's API version, 2.156", "name": "VersionMissing", > "type": "warning" > } > ], "summary": "IPA server version 4.2.3. API version 2.156" > }, "version": "4.2.3" > } > ipa: INFO: Forwarding 'config_show/1' to json server > 'https://id.vda.li/ipa/json' > ipa: INFO: Request: { > "id": 0, "method": "config_show/1", "params": [ > [], { > "version": "2.210" > } > ] > } > ipa: INFO: Response: { > "error": { > "code": 905, "message": "unknown command 'config_show/1'", > "name": "CommandError" > }, "id": 0, "principal": "admin at VDA.LI", "result": null, > "version": "4.2.3" > } > ipa: ERROR: unknown command 'config_show/1' Works fine for me: $ rpm -q freeipa-client freeipa-client-4.4.0.201607180602GITa2891af3-0.fc24.x86_64 $ ipa ping ------------------------------------------- IPA server version 4.2.3. API version 2.156 ------------------------------------------- $ ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: abc.idm.lab.eng.brq.redhat.com Search time limit: -1 Search size limit: -1 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: nfs:NONE, MS-PAC Try removing ~/.cache/ipa/servers/ - if you reinstalled the server in the last hour (the default cache TTL), it should help. > > Same happens for every other command so I cannot even test the behavior. > It works against the same server as the thin client is. > > [root at f24-master ~]# ipa -vv config-show > ipa: INFO: trying https://f24-master.ipa.ad.test/ipa/json > ipa: INFO: Forwarding 'config_show/1' to json server > 'https://f24-master.ipa.ad.test/ipa/json' > ipa: INFO: Request: { > "id": 0, "method": "config_show/1", "params": [ > [], { > "version": "2.210" > } > ] > } > ipa: INFO: Response: { > "error": null, "id": 0, "principal": "admin at IPA.AD.TEST", > "result": { > "result": { > "ca_renewal_master_server": "f24-master.ipa.ad.test", > "ca_server_server": [ > "f24-master.ipa.ad.test" > ], "dn": > "cn=ipaConfig,cn=etc,dc=ipa,dc=ad,dc=test", > "ipa_master_server": [ > "f24-master.ipa.ad.test" > ], "ipacertificatesubjectbase": [ > "O=IPA.AD.TEST" > ], "ipaconfigstring": [ > "AllowNThash" > ], "ipadefaultemaildomain": [ > "ipa.ad.test" > ], "ipadefaultloginshell": [ > "/bin/sh" > ], "ipadefaultprimarygroup": [ > "ipausers" > ], "ipagroupsearchfields": [ > "cn,description" > ], "ipahomesrootdir": [ > "/home" > ], "ipakrbauthzdata": [ > "nfs:NONE", "MS-PAC" > ], "ipamaxusernamelength": [ > "32" > ], "ipamigrationenabled": [ > "FALSE" > ], "ipapwdexpadvnotify": [ > "4" > ], "ipasearchrecordslimit": [ > "100" > ], "ipasearchtimelimit": [ > "2" > ], "ipaselinuxusermapdefault": [ > "unconfined_u:s0-s0:c0.c1023" > ], "ipaselinuxusermaporder": [ > > "guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023" > > ], "ipausersearchfields": [ > "uid,givenname,sn,telephonenumber,ou,title" > ], "ntp_server_server": [ > "f24-master.ipa.ad.test" > ] > }, "summary": null, "value": null > }, "version": "4.4.0.201607151226GIT37bfd1f" > } > Maximum username length: 32 > Home directory base: /home > Default shell: /bin/sh > Default users group: ipausers > Default e-mail domain: ipa.ad.test > Search time limit: 2 > Search size limit: 100 > User search fields: uid,givenname,sn,telephonenumber,ou,title > Group search fields: cn,description > Enable migration mode: FALSE > Certificate Subject base: O=IPA.AD.TEST > Password Expiration Notification (days): 4 > Password plugin features: AllowNThash > SELinux user map order: > guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 > > Default SELinux user: unconfined_u:s0-s0:c0.c1023 > Default PAC types: nfs:NONE, MS-PAC > IPA masters: f24-master.ipa.ad.test > IPA CA servers: f24-master.ipa.ad.test > IPA NTP servers: f24-master.ipa.ad.test > IPA CA renewal master: f24-master.ipa.ad.test > > > >> >>> >>>>> Aside from that, comparing "(type(None),) is None" will never give you >>>>> True on the thin client side. At the server side we have "None is >>>>> None" >>>>> and that works. So the question is also why there is a change like >>>>> that >>>>> between client and server sides? >>>> >>>> I don't see how this has anything to do with anything. In output >>>> validation, "type = None" means that value of any type is allowed, >>>> "type = (type(None),)" means that only None is allowed. Nothing >>>> changed with regard to that in thin client. >>> Really? Previous code worked against corresponding server, new code >>> doesn't work against the very same server. I consider it a breakage. >> >> Really, since commit b6e4972e. If something is broken, please file a >> ticket. > See above. How should I test? -- Jan Cholasta From jcholast at redhat.com Tue Jul 19 10:32:30 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 12:32:30 +0200 Subject: [Freeipa-devel] [PATCH 190] expose `--secret` option in radiusproxy-* commands In-Reply-To: References: Message-ID: <4619e944-47d6-e181-c42d-073f479d4f85@redhat.com> Hi, On 18.7.2016 13:51, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/6078 I don't think we want the secret searchable. Add a 'no_search' flag to the param to fix that. Honza -- Jan Cholasta From abokovoy at redhat.com Tue Jul 19 10:31:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 19 Jul 2016 13:31:50 +0300 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <816e5a83-5069-5568-d074-6d040070516f@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> <20160719084049.fgtfsvvp7foxbnxj@redhat.com> <4eb1c8b4-88c8-2036-ca3e-08b602e9421b@redhat.com> <20160719093610.iqy3hau6xpju4aa7@redhat.com> <816e5a83-5069-5568-d074-6d040070516f@redhat.com> Message-ID: <20160719103150.ep3h6ghaktzktoqn@redhat.com> On Tue, 19 Jul 2016, Jan Cholasta wrote: >On 19.7.2016 11:36, Alexander Bokovoy wrote: >>On Tue, 19 Jul 2016, Jan Cholasta wrote: >>>On 19.7.2016 10:40, Alexander Bokovoy wrote: >>>>On Tue, 19 Jul 2016, Jan Cholasta wrote: >>>>>On 18.7.2016 10:12, Alexander Bokovoy wrote: >>>>>>On Mon, 18 Jul 2016, Jan Cholasta wrote: >>>>>>>Hi, >>>>>>> >>>>>>>On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>>>>>Hi, >>>>>>>> >>>>>>>>I had some time and was blocked by these bugs to do my tickets so I >>>>>>>>actually fixed these three problems that are assigned to Martin >>>>>>>>Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>>>>>> >>>>>>>>------ >>>>>>>> >>>>>>>>Output entry elements may have multiple types allowed. We need to >>>>>>>>check >>>>>>>>all of them to properly validate the output. Right now, thin client >>>>>>>>receives type specifications for elements as tuples of types, so >>>>>>>>what is seen as 'None' on the server side becomes (type(None),) >>>>>>>>tuple >>>>>>>>on the thin client side. >>>>>>>> >>>>>>>>Change validation to account this by processing each separate type >>>>>>>>of the element and account for both None and type(None). Raise type >>>>>>>>error only if all of the type checks failed. >>>>>>>> >>>>>>>>https://fedorahosted.org/freeipa/ticket/6061 >>>>>>> >>>>>>>NACK, this only hides the real issue, which is that trustconfig-show >>>>>>>(and automember-set-default in #6037) claims to return the primary >>>>>>>key >>>>>>>of the object in the 'value' output field, but the object does not >>>>>>>have a primary key, so the client rightfully expects None. >>>>>>Why did it work before introducing thin client? >>>>> >>>>>Because I took the liberty of not putting any extra effort just to >>>>>keep old hacks working on thin client. In this case, output.PrimaryKey >>>>>was used for the 'value' output field before, which always allowed >>>>>unicode in addition to the primary key type. On thin client, >>>>>output.Output with the primary key type is used instead, which is less >>>>>forgiving and uncovers bogus command definitions. (There aren't any >>>>>besides the ones already mentioned, I remember fixing them but the >>>>>commit got lost somehow. Oh well.) >>>>This means thin client would not work against old server which would >>>>return a non-primary key value. I think it is unacceptable. >>> >>>Not true, as this only applies to servers with API schema (4.4+). >>Only because thin client does not work against servers without API >>schema at all: >> >>[root at f24-master ~]# ipa -vv -e xmlrpc_uri=https://id.vda.li/ipa/xml >>config-show >>ipa: INFO: trying https://id.vda.li/ipa/json >>ipa: INFO: Request: { >> "id": 0, "method": "ping", "params": [ >> [], {} >> ] >>} >>ipa: INFO: Response: { >> "error": null, "id": 0, "principal": "admin at VDA.LI", >>"result": { >> "messages": [ >> { >> "code": 13001, "message": "API Version >>number was not sent, forward compatibility not guaranteed. Assuming >>server's API version, 2.156", "name": "VersionMissing", >> "type": "warning" >> } >> ], "summary": "IPA server version 4.2.3. API version 2.156" >> }, "version": "4.2.3" >>} >>ipa: INFO: Forwarding 'config_show/1' to json server >>'https://id.vda.li/ipa/json' >>ipa: INFO: Request: { >> "id": 0, "method": "config_show/1", "params": [ >> [], { >> "version": "2.210" >> } >> ] >>} >>ipa: INFO: Response: { >> "error": { >> "code": 905, "message": "unknown command 'config_show/1'", >> "name": "CommandError" >> }, "id": 0, "principal": "admin at VDA.LI", "result": null, >>"version": "4.2.3" >>} >>ipa: ERROR: unknown command 'config_show/1' > >Works fine for me: > >$ rpm -q freeipa-client >freeipa-client-4.4.0.201607180602GITa2891af3-0.fc24.x86_64 > >$ ipa ping >------------------------------------------- >IPA server version 4.2.3. API version 2.156 >------------------------------------------- > >$ ipa config-show > Maximum username length: 32 > Home directory base: /home > Default shell: /bin/sh > Default users group: ipausers > Default e-mail domain: abc.idm.lab.eng.brq.redhat.com > Search time limit: -1 > Search size limit: -1 > User search fields: uid,givenname,sn,telephonenumber,ou,title > Group search fields: cn,description > Enable migration mode: FALSE > Certificate Subject base: O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM > Password Expiration Notification (days): 4 > Password plugin features: AllowNThash > SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 > Default SELinux user: unconfined_u:s0-s0:c0.c1023 > Default PAC types: nfs:NONE, MS-PAC > > >Try removing ~/.cache/ipa/servers/ - if you >reinstalled the server in the last hour (the default cache TTL), it >should help. Yes, this did help, thanks. I didn't reinstall the server at all but I ran ipa command before adding CA cert of that install to my client's NSS database. I guess it was the cache from that attempt that broke it. Coming back to trustconfig-show, older server response's 'value' field is ignored. I guess we can actually remove the value completely because it is of no use anywhere. As to other commands without primary key and returning value, may be you can revive your patch? -- / Alexander Bokovoy From jcholast at redhat.com Tue Jul 19 10:40:56 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Jul 2016 12:40:56 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <20160719103150.ep3h6ghaktzktoqn@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <20160718081232.qj3klx4r6usbyw3d@redhat.com> <20160719084049.fgtfsvvp7foxbnxj@redhat.com> <4eb1c8b4-88c8-2036-ca3e-08b602e9421b@redhat.com> <20160719093610.iqy3hau6xpju4aa7@redhat.com> <816e5a83-5069-5568-d074-6d040070516f@redhat.com> <20160719103150.ep3h6ghaktzktoqn@redhat.com> Message-ID: On 19.7.2016 12:31, Alexander Bokovoy wrote: > On Tue, 19 Jul 2016, Jan Cholasta wrote: >> On 19.7.2016 11:36, Alexander Bokovoy wrote: >>> On Tue, 19 Jul 2016, Jan Cholasta wrote: >>>> On 19.7.2016 10:40, Alexander Bokovoy wrote: >>>>> On Tue, 19 Jul 2016, Jan Cholasta wrote: >>>>>> On 18.7.2016 10:12, Alexander Bokovoy wrote: >>>>>>> On Mon, 18 Jul 2016, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I had some time and was blocked by these bugs to do my tickets >>>>>>>>> so I >>>>>>>>> actually fixed these three problems that are assigned to Martin >>>>>>>>> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>>>>>>> >>>>>>>>> ------ >>>>>>>>> >>>>>>>>> Output entry elements may have multiple types allowed. We need to >>>>>>>>> check >>>>>>>>> all of them to properly validate the output. Right now, thin >>>>>>>>> client >>>>>>>>> receives type specifications for elements as tuples of types, so >>>>>>>>> what is seen as 'None' on the server side becomes (type(None),) >>>>>>>>> tuple >>>>>>>>> on the thin client side. >>>>>>>>> >>>>>>>>> Change validation to account this by processing each separate type >>>>>>>>> of the element and account for both None and type(None). Raise >>>>>>>>> type >>>>>>>>> error only if all of the type checks failed. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/6061 >>>>>>>> >>>>>>>> NACK, this only hides the real issue, which is that >>>>>>>> trustconfig-show >>>>>>>> (and automember-set-default in #6037) claims to return the primary >>>>>>>> key >>>>>>>> of the object in the 'value' output field, but the object does not >>>>>>>> have a primary key, so the client rightfully expects None. >>>>>>> Why did it work before introducing thin client? >>>>>> >>>>>> Because I took the liberty of not putting any extra effort just to >>>>>> keep old hacks working on thin client. In this case, >>>>>> output.PrimaryKey >>>>>> was used for the 'value' output field before, which always allowed >>>>>> unicode in addition to the primary key type. On thin client, >>>>>> output.Output with the primary key type is used instead, which is >>>>>> less >>>>>> forgiving and uncovers bogus command definitions. (There aren't any >>>>>> besides the ones already mentioned, I remember fixing them but the >>>>>> commit got lost somehow. Oh well.) >>>>> This means thin client would not work against old server which would >>>>> return a non-primary key value. I think it is unacceptable. >>>> >>>> Not true, as this only applies to servers with API schema (4.4+). >>> Only because thin client does not work against servers without API >>> schema at all: >>> >>> [root at f24-master ~]# ipa -vv -e xmlrpc_uri=https://id.vda.li/ipa/xml >>> config-show >>> ipa: INFO: trying https://id.vda.li/ipa/json >>> ipa: INFO: Request: { >>> "id": 0, "method": "ping", "params": [ >>> [], {} >>> ] >>> } >>> ipa: INFO: Response: { >>> "error": null, "id": 0, "principal": "admin at VDA.LI", >>> "result": { >>> "messages": [ >>> { >>> "code": 13001, "message": "API Version >>> number was not sent, forward compatibility not guaranteed. Assuming >>> server's API version, 2.156", "name": "VersionMissing", >>> "type": "warning" >>> } >>> ], "summary": "IPA server version 4.2.3. API version 2.156" >>> }, "version": "4.2.3" >>> } >>> ipa: INFO: Forwarding 'config_show/1' to json server >>> 'https://id.vda.li/ipa/json' >>> ipa: INFO: Request: { >>> "id": 0, "method": "config_show/1", "params": [ >>> [], { >>> "version": "2.210" >>> } >>> ] >>> } >>> ipa: INFO: Response: { >>> "error": { >>> "code": 905, "message": "unknown command 'config_show/1'", >>> "name": "CommandError" >>> }, "id": 0, "principal": "admin at VDA.LI", "result": null, >>> "version": "4.2.3" >>> } >>> ipa: ERROR: unknown command 'config_show/1' >> >> Works fine for me: >> >> $ rpm -q freeipa-client >> freeipa-client-4.4.0.201607180602GITa2891af3-0.fc24.x86_64 >> >> $ ipa ping >> ------------------------------------------- >> IPA server version 4.2.3. API version 2.156 >> ------------------------------------------- >> >> $ ipa config-show >> Maximum username length: 32 >> Home directory base: /home >> Default shell: /bin/sh >> Default users group: ipausers >> Default e-mail domain: abc.idm.lab.eng.brq.redhat.com >> Search time limit: -1 >> Search size limit: -1 >> User search fields: uid,givenname,sn,telephonenumber,ou,title >> Group search fields: cn,description >> Enable migration mode: FALSE >> Certificate Subject base: O=ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >> Password Expiration Notification (days): 4 >> Password plugin features: AllowNThash >> SELinux user map order: >> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 >> >> Default SELinux user: unconfined_u:s0-s0:c0.c1023 >> Default PAC types: nfs:NONE, MS-PAC >> >> >> Try removing ~/.cache/ipa/servers/ - if you >> reinstalled the server in the last hour (the default cache TTL), it >> should help. > Yes, this did help, thanks. I didn't reinstall the server at all but I > ran ipa command before adding CA cert of that install to my client's NSS > database. I guess it was the cache from that attempt that broke it. Hmm, that does not sound right. If there was no CA cert for the server, then it wasn't possible to talk to it, so there should not have been any information cached for it. I will investigate further, but it might be a bug in caching. > > Coming back to trustconfig-show, older server response's 'value' field > is ignored. I guess we can actually remove the value completely because > it is of no use anywhere. That's even a better fix :-) > > As to other commands without primary key and returning value, may be you > can revive your patch? I think Martin already did that in the other thread: -- Jan Cholasta From pvoborni at redhat.com Tue Jul 19 10:56:56 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 19 Jul 2016 12:56:56 +0200 Subject: [Freeipa-devel] [PATCH] 0011 server uninstall fails to remove krb principals In-Reply-To: References: Message-ID: <0365c57c-b6df-ac35-3d45-be0fe2100b0b@redhat.com> On 07/11/2016 09:52 AM, Florence Blanc-Renaud wrote: > Hi, > > please find a patch for the 3rd issue of ticket 6012. > > https://fedorahosted.org/freeipa/ticket/6012 > > bump for review -- Petr Vobornik From abokovoy at redhat.com Tue Jul 19 11:13:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 19 Jul 2016 14:13:50 +0300 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: References: <20160716104655.crbov36a63cq7dcj@redhat.com> <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> Message-ID: <20160719111349.rxrqotars2agqkxm@redhat.com> On Mon, 18 Jul 2016, Martin Babinsky wrote: > On 07/18/2016 12:29 PM, Martin Babinsky wrote: > > On 07/18/2016 10:01 AM, Jan Cholasta wrote: > > > Hi, > > > > > > On 16.7.2016 12:46, Alexander Bokovoy wrote: > > > > Hi, > > > > > > > > I had some time and was blocked by these bugs to do my tickets so I > > > > actually fixed these three problems that are assigned to Martin > > > > Babinsky. Hopefully, Martin wouldn't be offended by that. :) > > > > > > > > ------ > > > > > > > > Output entry elements may have multiple types allowed. We need to check > > > > all of them to properly validate the output. Right now, thin client > > > > receives type specifications for elements as tuples of types, so > > > > what is seen as 'None' on the server side becomes (type(None),) tuple > > > > on the thin client side. > > > > > > > > Change validation to account this by processing each separate type > > > > of the element and account for both None and type(None). Raise type > > > > error only if all of the type checks failed. > > > > > > > > https://fedorahosted.org/freeipa/ticket/6061 > > > > > > NACK, this only hides the real issue, which is that trustconfig-show > > > (and automember-set-default in #6037) claims to return the primary key > > > of the object in the 'value' output field, but the object does not have > > > a primary key, so the client rightfully expects None. > > > > > > A proper fix would be to set "has_output = output.simple_value" for > > > these commands (all of automember_default_group_{set,remove,show}, > > > trustconfig_{mod,show}). > > > > > > Honza > > > > > > > The problem is that these commands do not return a simple boolean in > > 'result' but a full entry dict, so 'simple_value' won't do the trick in > > this case. > > > > But I agree, we should rather fix misbehaving commands rather than bend > > the framework to accomodate their idiosyncracies, we have enough of that > > already. > > > I am attaching a patch that adds a custom shim for misbehaving commands so > that they work as before. There is also a big fat warning added to > discourage implementation of such commands. Let's go by this patch. I originally thought changing trust.py to simply not supply 'value' field at all but this fix is simpler. -- / Alexander Bokovoy From ppicka at redhat.com Tue Jul 19 11:16:03 2016 From: ppicka at redhat.com (Pavel Picka) Date: Tue, 19 Jul 2016 07:16:03 -0400 (EDT) Subject: [Freeipa-devel] Location mechanism RFE In-Reply-To: <964845441.22283781.1468926799029.JavaMail.zimbra@redhat.com> Message-ID: <814858448.22284915.1468926963838.JavaMail.zimbra@redhat.com> Hello, can you please check if TCs for basic test looks good for http://www.freeipa.org/page/V4/DNS_Location_Mechanism TC 1 - default values (50:50) - ipa-server-install + replica - add two location - mod SRV record (ipa server-mod) to master - location1 | replica - location2 - check by 'dig' (dig @$FIRST_IPA_DNS_SERVER _kerberos._udp.$PRIMARYDNSDOMAIN SRV) output: both servers/location listed TC 2 - set up service weight - another replica in location1 - ipa server-mod server1 --service-weight=75 location1 - ipa server-mod server2 --service-weight=25 location1 - check traffic output: trafic divided into 1:4 TC 3 - used location server go offline - ipactl stop on location1 output : switch to another location TC 4 (negative) - try to add non-existant server to location :: can't be added - wrong dns setup :: non location in dig output -- Pavel Picka Red Hat Brno From ldoudova at redhat.com Tue Jul 19 11:19:13 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 19 Jul 2016 13:19:13 +0200 Subject: [Freeipa-devel] [PATCH 0024][Tests] Fix integration tests not to produce incorrect /etc/hosts file In-Reply-To: References: <1c1eeea2-19f9-b4e6-bc56-204fdb888b18@redhat.com> <5773F9CC.9070902@redhat.com> Message-ID: On 06/29/2016 06:49 PM, Petr Spacek wrote: > On 29.6.2016 18:39, Oleg Fayans wrote: >> In fact, I believe /etc/hosts file should not be touched at all. >> Hostname resolution is usually governed by the DNS system of the lab in >> which tests are running. We do not modify it when perform tests >> manually, so I'd rather remove this method at all. > +1, it should not be need. Let me know if it is needed for some reason and I > will have a look. > > Petr^2 Spacek Hi, providing new (and renamed) patch as was suggested in the discussion above - removing manipulation with /etc/hosts file from the tests. The "fix_etc_hosts" function was completely removed from the tasks file. Verification that nothing is broken by this change was done by running some random integration test (trust tests), and also on Milan's suggestion by running a test requiring two replicas (replica promotion tests). Lenka >> On 06/29/2016 06:27 PM, Lenka Doudova wrote: >>> Hi all, >>> >>> a function 'fix_etc_hosts' in ipatests/test_integration/tasks.py >>> produces incorrect /etc/hosts file (solitary IPv6 address), and >>> currently parser is not able to resolve the issue, causing >>> ipa-server-install to fail with 'list index out of range' error. >>> >>> Hence I'm attaching patch to fix this issue before parser is fixed >>> (related ticket to it #6014). The fix is just change of regexs >>> responsible for creating incorrect file so that all the lines containing >>> defined hostname are removed, not just specific IP/hostname/shortname >>> strings. >>> >>> >>> Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0024.2-Tests-Removing-manipulation-with-etc-hosts-file-from.patch Type: text/x-patch Size: 1850 bytes Desc: not available URL: From mbasti at redhat.com Tue Jul 19 11:19:35 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 13:19:35 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Bug in the ipapwd plugin In-Reply-To: <1468923715.21393.3.camel@redhat.com> References: <57865530.3000602@redhat.com> <20160713200257.GA13575@10.4.128.1> <578DE217.70502@redhat.com> <1468923715.21393.3.camel@redhat.com> Message-ID: <8f25e8d0-51b1-3d47-adf6-ef98575bd6f3@redhat.com> On 19.07.2016 12:21, Simo Sorce wrote: > On Tue, 2016-07-19 at 10:17 +0200, thierry bordaz wrote: >> >> On 07/13/2016 10:02 PM, Lukas Slebodnik wrote: >>> On (13/07/16 16:50), thierry bordaz wrote: >>>> https://fedorahosted.org/freeipa/ticket/6030 >>>> >From 4efedc5e674db92f9f7c160429df543422ed8afb Mon Sep 17 00:00:00 >> 2001 >>>> From: Thierry Bordaz >>>> Date: Wed, 13 Jul 2016 15:34:20 +0200 >>>> Subject: [PATCH] Ticket 6030 Bug in the ipapwd plugin >>>> >>>> ipapwd_encrypt_encode_key allocates 'kset' on the heap but >>>> with num_keys and keys not being initialized. >>>> Then ipa_krb5_generate_key_data initializes them with the >>>> generated keys. >>>> If ipa_krb5_generate_key_data fails (here EINVAL meaning no >>>> principal->realm.data), num_keys and keys are left uninitialized. >>>> Upon failure, ipapwd_keyset_free is called to free 'kset' >>>> that contains random num_keys and keys. >>>> >>>> allocates kset with calloc so that kset->num_keys==0 and >>>> kset->keys==NULL >>>> >>>> https://fedorahosted.org/freeipa/ticket/6030 >>>> --- >>>> daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >> b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >>>> index 5ca155d..46bf79a 100644 >>>> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >>>> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c >>>> @@ -148,7 +148,7 @@ Slapi_Value **ipapwd_encrypt_encode_key(struct >> ipapwd_krbcfg *krbcfg, >>>> pwd.length = strlen(data->password); >>>> } >>>> >>>> - kset = malloc(sizeof(struct ipapwd_keyset)); >>>> + kset = calloc(sizeof(struct ipapwd_keyset)); >>> I though that calloc need two arguments >>> >>> man malloc says: >>> void *malloc(size_t size); >>> void *calloc(size_t nmemb, size_t size); >>> >>> LS >> Oppss, sorry for this dummy patch. Here is the right one > ACK, > Simo. > Pushed to master: b04f617803c430b13f8796e911f78bd65f6cf55f From mbabinsk at redhat.com Tue Jul 19 11:25:08 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 Jul 2016 13:25:08 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <20160719111349.rxrqotars2agqkxm@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> <20160719111349.rxrqotars2agqkxm@redhat.com> Message-ID: <6f29f6b1-0c83-86dc-1b63-e76407bd5e07@redhat.com> On 07/19/2016 01:13 PM, Alexander Bokovoy wrote: > On Mon, 18 Jul 2016, Martin Babinsky wrote: >> On 07/18/2016 12:29 PM, Martin Babinsky wrote: >> > On 07/18/2016 10:01 AM, Jan Cholasta wrote: >> > > Hi, >> > > > > On 16.7.2016 12:46, Alexander Bokovoy wrote: >> > > > Hi, >> > > > > > > I had some time and was blocked by these bugs to do my >> tickets so I >> > > > actually fixed these three problems that are assigned to Martin >> > > > Babinsky. Hopefully, Martin wouldn't be offended by that. :) >> > > > > > > ------ >> > > > > > > Output entry elements may have multiple types allowed. We >> need to check >> > > > all of them to properly validate the output. Right now, thin client >> > > > receives type specifications for elements as tuples of types, so >> > > > what is seen as 'None' on the server side becomes (type(None),) >> tuple >> > > > on the thin client side. >> > > > > > > Change validation to account this by processing each >> separate type >> > > > of the element and account for both None and type(None). Raise type >> > > > error only if all of the type checks failed. >> > > > > > > https://fedorahosted.org/freeipa/ticket/6061 >> > > > > NACK, this only hides the real issue, which is that >> trustconfig-show >> > > (and automember-set-default in #6037) claims to return the primary >> key >> > > of the object in the 'value' output field, but the object does not >> have >> > > a primary key, so the client rightfully expects None. >> > > > > A proper fix would be to set "has_output = >> output.simple_value" for >> > > these commands (all of automember_default_group_{set,remove,show}, >> > > trustconfig_{mod,show}). >> > > > > Honza >> > > > > The problem is that these commands do not return a simple >> boolean in >> > 'result' but a full entry dict, so 'simple_value' won't do the trick in >> > this case. >> > > But I agree, we should rather fix misbehaving commands rather than >> bend >> > the framework to accomodate their idiosyncracies, we have enough of >> that >> > already. >> > I am attaching a patch that adds a custom shim for misbehaving >> commands so that they work as before. There is also a big fat warning >> added to discourage implementation of such commands. > Let's go by this patch. I originally thought changing trust.py to simply > not supply 'value' field at all but this fix is simpler. > We found out that we still would need to handle automember-default-group-{set,remove} commands which use the value to print out summary, so it seems that we cannot win without some more extensive fixing. -- Martin^3 Babinsky From mbasti at redhat.com Tue Jul 19 11:31:12 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 13:31:12 +0200 Subject: [Freeipa-devel] [PATCH 0025][Tests] RFE: External trust In-Reply-To: References: <22e9385b-24f3-5d00-be28-8087218e84ec@redhat.com> <4c9efae4-853d-05ae-3d37-9006ddafd38f@redhat.com> <7cea5284-b23d-9f95-2be8-a477274ff98f@redhat.com> <91683398-3c15-e5ac-6fef-f48c8a5e6a5a@redhat.com> <46c489d2-a9d5-0d6b-bfd2-3e789484a77e@redhat.com> Message-ID: <29fd74d4-58b9-1d28-acef-e483b7c9904c@redhat.com> On 18.07.2016 18:07, Martin Babinsky wrote: > On 07/18/2016 04:59 PM, Lenka Doudova wrote: >> >> >> On 07/18/2016 04:55 PM, Martin Babinsky wrote: >>> On 07/14/2016 11:42 AM, Lenka Doudova wrote: >>>> >>>> >>>> On 07/13/2016 05:40 PM, Martin Babinsky wrote: >>>>> On 07/01/2016 04:15 PM, Lenka Doudova wrote: >>>>>> >>>>>> >>>>>> On 07/01/2016 02:38 PM, Martin Babinsky wrote: >>>>>>> On 07/01/2016 06:36 AM, Lenka Doudova wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 06/30/2016 05:01 PM, Martin Babinsky wrote: >>>>>>>>> On 06/30/2016 03:47 PM, Lenka Doudova wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> attaching patch with some basic coverage for external trust >>>>>>>>>> feature. Bit >>>>>>>>>> more detailed info in commit message. >>>>>>>>>> >>>>>>>>>> Since the feature requires me to run commands previously used >>>>>>>>>> only for >>>>>>>>>> forest root domains even for subdomains, I made some changes in >>>>>>>>>> ipatests/test_integration/tasks.py file, so that it would enable >>>>>>>>>> me to >>>>>>>>>> reuse existing function without copy-pasting them for one >>>>>>>>>> variable >>>>>>>>>> change. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Lenka >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Lenka, >>>>>>>>> >>>>>>>>> I have a few comments: >>>>>>>>> >>>>>>>>> 1.) >>>>>>>>> >>>>>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>>>>> +def establish_trust_with_ad(master, ad, extra_args=(), >>>>>>>>> subdomain=False): >>>>>>>>> >>>>>>>>> This modification seems extremely kludgy to me. >>>>>>>>> >>>>>>>>> I would rather change the function signature to: >>>>>>>>> >>>>>>>>> -def establish_trust_with_ad(master, ad, extra_args=()): >>>>>>>>> +def establish_trust_with_ad(master, ad_domain, extra_args=()): >>>>>>>>> >>>>>>>>> and pass the domain name itself to the function instead of doing >>>>>>>>> magic >>>>>>>>> inside. The same goes with `remove trust_with_ad`. You may >>>>>>>>> want to >>>>>>>>> fix >>>>>>>>> the calls to them in existing code so that the domain is passed >>>>>>>>> instead of the whole trust object. >>>>>>>>> >>>>>>>>> 2.) >>>>>>>>> >>>>>>>>> +def sync_time_hostname(host, srv_hostname): >>>>>>>>> + """ >>>>>>>>> + Syncs time with the remote server given by its hostname. >>>>>>>>> + Please note that this function leaves ntpd stopped. >>>>>>>>> + """ >>>>>>>>> + host.run_command(['systemctl', 'stop', 'ntpd']) >>>>>>>>> + host.run_command(['ntpdate', srv_hostname]) >>>>>>>>> + >>>>>>>>> + >>>>>>>>> >>>>>>>>> this looks like a duplicate of the function above it, why is it >>>>>>>>> even >>>>>>>>> needed? >>>>>>>>> >>>>>>>>> 3.) >>>>>>>>> +class TestExternalTrustWithSubdomain(ADTrustBase): >>>>>>>>> + """ >>>>>>>>> + Test establishing external trust with subdomain >>>>>>>>> + """ >>>>>>>>> + >>>>>>>>> + @classmethod >>>>>>>>> + def install(cls, mh): >>>>>>>>> + super(ADTrustBase, cls).install(mh) >>>>>>>>> + cls.ad = cls.ad_domains[0].ads[0] >>>>>>>>> + cls.install_adtrust() >>>>>>>>> + cls.check_sid_generation() >>>>>>>>> + >>>>>>>>> + # Determine whether the subdomain AD is available >>>>>>>>> + try: >>>>>>>>> + child_ad = >>>>>>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>>>>>> + cls.ad_subdomain = >>>>>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>>>>> + except LookupError: >>>>>>>>> + cls.ad_subdomain = None >>>>>>>>> + >>>>>>>>> + cls.configure_dns_and_time() >>>>>>>>> >>>>>>>>> Please use proper OOP practices when overriding the behavior >>>>>>>>> of the >>>>>>>>> base test class. >>>>>>>>> >>>>>>>>> For starters you could rewrite the install method like this: >>>>>>>>> >>>>>>>>> + @classmethod >>>>>>>>> + def install(cls, mh): >>>>>>>>> + # Determine whether the subdomain AD is available >>>>>>>>> + try: >>>>>>>>> + cls.child_ad = >>>>>>>>> cls.host_by_role(cls.optional_extra_roles[0]) >>>>>>>>> + cls.ad_subdomain = >>>>>>>>> '.'.join(child_ad.hostname.split('.')[1:]) >>>>>>>>> + cls.ad_subdomain_hostname = child_ad.hostname >>>>>>>>> + except LookupError: >>>>>>>>> + raise nose.SkipTest("AFAIK this will skip the whole >>>>>>>>> test >>>>>>>>> class") >>>>>>>>> + super(ADTrustBase, cls).install(mh) >>>>>>>>> >>>>>>>>> with child_ad stored as class attribute, you can override >>>>>>>>> `configure_dns_and_time`: >>>>>>>>> + def configure_dns_and_time(cls): >>>>>>>>> + tasks.configure_dns_for_trust(cls.master, >>>>>>>>> cls.ad_subdomain) >>>>>>>>> # no need to re-implement the function just to get to the >>>>>>>>> child >>>>>>>>> AD DC hostname now >>>>>>>>> + tasks.sync_time(cls.master, cls.child_ad.hostname) >>>>>>>>> >>>>>>>>> You can then use this class as an intermediary in the >>>>>>>>> hierarchy and >>>>>>>>> inherit the other external/non-external trust test classes >>>>>>>>> from it, >>>>>>>>> since most setup method in them are just copy-pasted from this >>>>>>>>> one. >>>>>>>>> >>>>>>>> Hi, >>>>>>>> thanks for review, fixed patch attached. >>>>>>>> >>>>>>>> Lenka >>>>>>> >>>>>>> Hi Lenka, >>>>>>> >>>>>>> I am still not happy about the patch underutilizing the >>>>>>> potential for >>>>>>> a proper inheritance hierarchy and instead relying on a staggering >>>>>>> amounts of copy-pasting for implementation. >>>>>>> >>>>>>> I am attaching a quick untested patch illustrating how the >>>>>>> implementation should look like. >>>>>>> >>>>>>> Also you have some leftovers from previous revision, please fix >>>>>>> them: >>>>>>> >>>>>>> Pylint is running, please wait ... >>>>>>> ************* Module ipatests.test_integration.test_trust >>>>>>> ipatests/test_integration/test_trust.py:236: [E1101(no-member), >>>>>>> TestExternalTrustWithSubdomain.configure_dns_and_time] Module >>>>>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' >>>>>>> member) >>>>>>> ipatests/test_integration/test_trust.py:243: >>>>>>> [E1123(unexpected-keyword-arg), >>>>>>> TestExternalTrustWithSubdomain.test_establish_trust] Unexpected >>>>>>> keyword argument 'subdomain' in function call) >>>>>>> ipatests/test_integration/test_trust.py:279: >>>>>>> [E1123(unexpected-keyword-arg), >>>>>>> TestExternalTrustWithSubdomain.test_remove_nonposix_trust] >>>>>>> Unexpected >>>>>>> keyword argument 'subdomain' in function call) >>>>>>> ipatests/test_integration/test_trust.py:330: [E1101(no-member), >>>>>>> TestNonexternalTrustWithSubdomain.configure_dns_and_time] Module >>>>>>> 'ipatests.test_integration.tasks' has no 'sync_time_hostname' >>>>>>> member) >>>>>>> Makefile:137: recipe for target 'lint' failed >>>>>>> make: *** [lint] Error 1 >>>>>>> sending incremental file list >>>>>>> >>>>>>> (this is before I started meddling with it) >>>>>>> >>>>>>> >>>>>> Thank you very much for the example, fixed patch attached. >>>>>> Lenka >>>>> >>>>> Hi Lenka, >>>>> >>>>> 'TestExternalTrustWithSubdomain' and >>>>> 'TestExternalTrustWithRootDomain' >>>>> suites fail due to incorrectly used '--external' option in the >>>>> trust-add command. This option is Boolean, not Flag so it should be >>>>> '--external=True'. >>>>> >>>> Hi, >>>> that must have changes since I sent the patch, it was fine before. >>>> Anyway, fixed patch attached. >>>> >>>> Lenka >>> >>> Hi Lenka, >>> >>> one of the tests keep failing on non-posix user UID/GID resolution. Is >>> it a bug of the test or incorrect setup of AD machines? >>> >>> https://paste.fedoraproject.org/392195/68853561/ >>> >> Hi, >> >> this is due to incorrect setup of AD machines - some attributes are >> missing for AD users. Same issue should arise in any trust test that >> includes this method, i.e. also in the tests from patch 0026. >> >> Lenka > > Ok, ACK then. > New ticket created for tests https://fedorahosted.org/freeipa/ticket/6093 Pushed to master: f487233df002bf73dd48d5c87a146b90542bd034 From mbasti at redhat.com Tue Jul 19 11:31:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 13:31:55 +0200 Subject: [Freeipa-devel] [PATCH 0026][Tests] RFE: Support UPN for trusted domains In-Reply-To: <58bc6fec-8652-c9ec-36c3-c313ae7c8ccb@redhat.com> References: <32d4e85c-55ee-fa12-5792-fb14eb00d6ea@redhat.com> <4f1dbc48-726e-16e8-78a3-3cf821656402@redhat.com> <84d6fa1f-265c-9408-3ecd-65c640da1793@redhat.com> <76514b4d-63fe-f6e1-31a5-b1aff62b728a@redhat.com> <42931f20-6a19-f506-6982-c3c7be722553@redhat.com> <58bc6fec-8652-c9ec-36c3-c313ae7c8ccb@redhat.com> Message-ID: On 18.07.2016 18:09, Martin Babinsky wrote: > On 07/14/2016 03:39 PM, Lenka Doudova wrote: >> >> >> On 07/13/2016 06:04 PM, Martin Babinsky wrote: >>> On 07/01/2016 04:45 PM, Lenka Doudova wrote: >>>> >>>> >>>> On 07/01/2016 03:04 PM, Martin Babinsky wrote: >>>>> On 07/01/2016 11:13 AM, Lenka Doudova wrote: >>>>>> And, of course, a patch file :) >>>>>> >>>>>> >>>>>> On 07/01/2016 11:09 AM, Lenka Doudova wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> here's patch with basic test suite for support of UPN. >>>>>>> >>>>>>> Note: it needs to be applied on top of my patch 0025.2 (or >>>>>>> later, if >>>>>>> there's will be more fixes to that patch). >>>>>>> >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Hi Lenka, >>>>> >>>>> test data such as usernames, etc. should be stored either in separate >>>>> resource files or at least as class attributes like this: >>>>> >>>>> diff --git a/ipatests/test_integration/test_trust.py >>>>> b/ipatests/test_integration/test_trust.py >>>>> index e8fdc6b..86ba7cc 100644 >>>>> --- a/ipatests/test_integration/test_trust.py >>>>> +++ b/ipatests/test_integration/test_trust.py >>>>> @@ -394,28 +394,33 @@ class TestTrustWithUPN(ADTrustBase): >>>>> """ >>>>> Test support of UPN for trusted domains >>>>> """ >>>>> + upn_suffix = 'UPNsuffix.com' >>>>> + upn_username = 'upnuser' >>>>> + upn_princ = '{}@{}'.format(upn_username, upn_suffix) >>>>> + upn_password = 'Secret123456' >>>>> + >>>>> def test_upn_in_nonposix_trust(self): >>>>> """ Check that UPN is listed as trust attribute """ >>>>> result = self.master.run_command(['ipa', 'trust-show', >>>>> self.ad_domain, >>>>> '--all', '--raw']) >>>>> >>>>> - assert "ipantadditionalsuffixes: UPNsuffix.com" in >>>>> result.stdout_text >>>>> + assert ("ipantadditionalsuffixes: >>>>> {}".format(self.upn_suffix) in >>>>> + result.stdout_text) >>>>> >>>>> def test_upn_user_resolution_in_nonposix_trust(self): >>>>> """ Check that user with UPN can be resolved """ >>>>> - upnuser = 'upnuser at UPNsuffix.com' >>>>> - result = self.master.run_command(['getent', 'passwd', >>>>> upnuser]) >>>>> + result = self.master.run_command(['getent', 'passwd', >>>>> self.upn_princ]) >>>>> >>>>> # result will contain AD domain, not UPN >>>>> - upnuser_regex = "^upnuser@{0}:\*:(\d+):(\d+):UPN >>>>> User:/:$".format( >>>>> - self.ad_domain) >>>>> + upnuser_regex = "^{}@{}:\*:(\d+):(\d+):UPN User:/:$".format( >>>>> + self.upn_username, self.ad_domain) >>>>> assert re.search(upnuser_regex, result.stdout_text) >>>>> >>>>> def test_upn_user_authentication(self): >>>>> """ Check that AD user with UPN can authenticate in IPA """ >>>>> self.master.run_command(['systemctl', 'restart', 'krb5kdc']) >>>>> - self.master.run_command(['kinit', '-C', '-E', >>>>> 'upnuser at UPNsuffix.com'], >>>>> - stdin_text='Secret123456') >>>>> + self.master.run_command(['kinit', '-C', '-E', >>>>> self.upn_princ], >>>>> + stdin_text=self.upn_password) >>>>> >>>>> otherwise LGTM. >>>>> >>>> Thanks for review, fixed patch attached. >>>> >>>> Few notes: >>>> 1. mbabinsky's suggestion to store testdata as class attributes or >>>> separate resource file: I decided to use the class attribute approach. >>>> The separate resource file is a nice idea, which I have already put on >>>> my "to do" list - there's a lot of hardcoded stuff in the trust tests, >>>> even in the original ones (before my patches), so when there's time >>>> I'll >>>> work on a way how to dynamically provide this data as test >>>> configuration >>>> 2. previous discussion about getent vs. pwd.getpwnam(): I'll leave the >>>> getent command, since according to mbasti the alternative would not >>>> work >>>> in CI. >>>> >>>> Lenka >>> >>> Hi Lenka, >>> >>> I am not sure 'test_all_trustdomains_found' should be run as a part of >>> this test suite. Maybe yes, I'm not sure. >>> >>> Also I would add a 60 second sleep after KDC restart in >>> 'test_upn_user_authentication' so that MS-PAC cache gets refreshed >>> before trying to kinit as enterprise principal. >>> >>> Two of the tests fail on my setup but that is probably due to >>> https://fedorahosted.org/freeipa/ticket/6082 . >>> >> Hi, >> >> the "test_all_trustdomains_found" method is inherited from parent class, >> and I believe it cannot hurt to have it there. >> I added the sleep as you requested. >> I also tried to run the tests with two way trust and since everything >> was fine then, the failures you experienced are really most likely due >> to the oddjob issue you linked. Of course the patch still contains tests >> with one way trusts, so until the oddjob issue is solved, the tests will >> probably fail, and should be fine once the fix is provided. >> >> Fixed patch attached. >> Lenka > > Yes I think that the failing tests are due to bugs in trust, not the > test code. ACK. > New ticket created for tests https://fedorahosted.org/freeipa/ticket/6094 Pushed to master: 6a072f3c5c114747c190d0c309a8d53dd8e46394 From mbasti at redhat.com Tue Jul 19 12:12:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 14:12:57 +0200 Subject: [Freeipa-devel] [PATCH 0187] Use server API in com.redhat.idm.trust-fetch-domains oddjob helper In-Reply-To: <20160718085301.daefz4po5ptvsjzs@redhat.com> References: <94057997-9ae9-892b-c518-b8ef7a2b2b53@redhat.com> <20160718085301.daefz4po5ptvsjzs@redhat.com> Message-ID: <21af7d8e-9876-7061-d6bb-eb513da09274@redhat.com> On 18.07.2016 10:53, Alexander Bokovoy wrote: > On Mon, 18 Jul 2016, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6082 >> >> -- >> Martin^3 Babinsky > >> From 990f29cbfb457c6179ffc0bed452dc358ba30d21 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Thu, 14 Jul 2016 09:31:22 +0200 >> Subject: [PATCH] Use server API in com.redhat.idm.trust-fetch-domains >> oddjob >> helper >> >> https://fedorahosted.org/freeipa/ticket/6082 >> --- >> install/oddjob/com.redhat.idm.trust-fetch-domains | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains >> b/install/oddjob/com.redhat.idm.trust-fetch-domains >> index >> a6b87cde917cfa5bfedf28442a6d1b2b512706f9..7c948fd53bd54bf3638ef3cc4407576b9011f4fb >> 100755 >> --- a/install/oddjob/com.redhat.idm.trust-fetch-domains >> +++ b/install/oddjob/com.redhat.idm.trust-fetch-domains >> @@ -76,7 +76,7 @@ env._bootstrap(debug=options.debug, log=None) >> env._finalize_core(**dict(DEFAULT_CONFIG)) >> >> # Initialize the API with the proper debug level >> -api.bootstrap(debug=env.debug, log=None) >> +api.bootstrap(in_server=True, debug=env.debug, log=None) >> api.finalize() >> >> # Only import trust plugin after api is initialized or internal imports > ACK. Pushed to master: b144bf527db76573590255d4ac80e9dfd813ba3d From mbasti at redhat.com Tue Jul 19 12:21:05 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 14:21:05 +0200 Subject: [Freeipa-devel] [PATCH] 0046 Create server certs with DNS altname In-Reply-To: References: <20151207052611.GG23644@dhcp-40-8.bne.redhat.com> <5665813B.90406@redhat.com> <20151207224639.GL23644@dhcp-40-8.bne.redhat.com> <56660D1D.6000109@redhat.com> <20151208090638.GQ23644@dhcp-40-8.bne.redhat.com> <20160120040409.GN31821@dhcp-40-8.bne.redhat.com> Message-ID: <82d7ad96-9b63-67a6-3070-99dd86d40641@redhat.com> On 01.07.2016 13:26, Petr Spacek wrote: > On 20.1.2016 05:04, Fraser Tweedale wrote: >> On Tue, Dec 08, 2015 at 07:06:39PM +1000, Fraser Tweedale wrote: >>> On Mon, Dec 07, 2015 at 05:50:05PM -0500, Rob Crittenden wrote: >>>> Fraser Tweedale wrote: >>>>> On Mon, Dec 07, 2015 at 01:53:15PM +0100, Martin Kosek wrote: >>>>>> On 12/07/2015 06:26 AM, Fraser Tweedale wrote: >>>>>>> The attached patch fixes >>>>>>> https://fedorahosted.org/freeipa/ticket/4970. >>>>>>> >>>>>>> Note that the problem is addressed by adding the appropriate request >>>>>>> extension to the CSR; the fix does not involve changing the default >>>>>>> profile behaviour, which is complicated (see ticket for details). >>>>>> Thanks for the patch! This is something we should really fix, I already get >>>>>> warnings in my Python scripts when I hit sites protected by such HTTPS cert: >>>>>> >>>>>> /usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:264: >>>>>> SubjectAltNameWarning: Certificate for projects.engineering.redhat.com has no >>>>>> `subjectAltName`, falling back to check for a `commonName` for now. This >>>>>> feature is being removed by major browsers and deprecated by RFC 2818. (See >>>>>> https://github.com/shazow/urllib3/issues/497 for details.) >>>>>> >>>>>> Should we split ticket 4970, for the FreeIPA server part and then for cert >>>>>> profile part? As it looks like the FreeIPA server will be fixed even in FreeIPA >>>>>> 4.3.x and the other part later. >>>>>> >>>>>> How difficult do you see the general FreeIPA Certificate Profile part of this >>>>>> request? Is it a too big task to handle in 4.4 time frame? >>>>>> >>>>> I will split the ticket and would suggest 4.4 Backlog - it might be >>>>> doable but is a lower priority than e.g. Sub-CAs. >>>> If you are going to defer the profile part then you should probably >>>> update the client to also include a SAN if --request-cert is provided. >>>> >>>> rob >>>> >>> Yes, good idea. Updated patch attached. >>> >>> Cheers, >>> Fraser >> Bump, with rebased patch. > Hi, > > this seems to work for Apache on IPA server & client cert. ACK. Pushed to master: b12db924143cd6828c596c0b8a261325f3f589f3 > > Interestingly enough I found out that Dogtag cert used on port 8443 does not > have any SAN. > > Is it in scope of this ticket? I will leave the ticket open until this is answered. Martin^2 > From mbasti at redhat.com Tue Jul 19 14:18:35 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 16:18:35 +0200 Subject: [Freeipa-devel] [PATCH 0553] CI tests: improve log collecting in tests Message-ID: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0553-CI-tests-improve-log-collecting.patch Type: text/x-patch Size: 4873 bytes Desc: not available URL: From mbasti at redhat.com Tue Jul 19 15:03:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 17:03:01 +0200 Subject: [Freeipa-devel] [PATCH 0032] Secure permission and cleanup Custodia server.keys In-Reply-To: References: Message-ID: On 12.07.2016 16:45, Christian Heimes wrote: > Custodia's server.keys file contain the private RSA keys for encrypting > and signing Custodia messages. The file was created with permission 644 > and is only secured by permission 700 of the directory > /etc/ipa/custodia. The installer and upgrader ensure that the file > has 600. > > The server.keys file and all keys are now removed when during > uninstallation of a server, too. > > https://bugzilla.redhat.com/show_bug.cgi?id=1353936 > https://fedorahosted.org/freeipa/ticket/6015 > https://fedorahosted.org/freeipa/ticket/6056 > > NACK ipa-server-install --uninstall doesn't work 2016-07-19T15:00:34Z INFO Remove Custodia keys 2016-07-19T15:00:34Z 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 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, 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 1367, in main uninstall(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 1075, in uninstall custodiainstance.CustodiaInstance().uninstall() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 88, in uninstall self.__remove_keys() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 74, in __remove_keys keystore.remove_server_keys() File "/usr/lib/python2.7/site-packages/ipapython/secrets/kem.py", line 224, in remove_server_keys self.remove_keys('host') File "/usr/lib/python2.7/site-packages/ipapython/secrets/kem.py", line 231, in remove_keys ldapconn.remove_key(KEY_USAGE_SIG, principal) File "/usr/lib/python2.7/site-packages/ipapython/secrets/kem.py", line 145, in remove_key conn = self.connect() File "/usr/lib/python2.7/site-packages/ipapython/secrets/common.py", line 38, in connect conn.sasl_interactive_bind_s('', auth_tokens) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 244, in sasl_interactive_bind_s return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in _ldap_call result = func(*args,**kwargs) SERVER_DOWN: {'desc': "Can't contact LDAP server"} -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Jul 19 15:05:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Jul 2016 17:05:36 +0200 Subject: [Freeipa-devel] [PATCH 0553] CI tests: improve log collecting in tests In-Reply-To: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> References: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> Message-ID: <21a9655a-3943-67ac-3a8f-0a81dae37de3@redhat.com> On 19.07.2016 16:18, Martin Basti wrote: > Patch attached. > > > self-NACK, my assumptions were wrong, this doesn't work if any of log files do not exist -------------- next part -------------- An HTML attachment was scrubbed... URL: From gkaihoro at redhat.com Tue Jul 19 15:45:43 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Tue, 19 Jul 2016 11:45:43 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0001][Tests] Fix for dns_plugin tests In-Reply-To: <1246406437.22523321.1468942454879.JavaMail.zimbra@redhat.com> Message-ID: <1640445260.22535316.1468943143859.JavaMail.zimbra@redhat.com> Greetings! Fix for ipatests/test_xmlrpc/test_dns_plugin.py (test_forwardzone_delegation_warnings.test) You can't have a DNS zone with the authoritative nameserver that does not have a A or AAAA record in the local DNS. Since in some test environments primary hostname of the master is managed by an external DNS, this hostname can not be used as a NS-record for IPA-managed zones. Therefore another existing fqdn corresponding to the master's ip and managed by IPA DNS was used. Best regards, Ganna Kaihorodova Associate Software Quality Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-gkaihoro-0001-ipatest-dns-plugin-bugfix.patch Type: text/x-patch Size: 4094 bytes Desc: not available URL: From blipton at redhat.com Tue Jul 19 20:20:40 2016 From: blipton at redhat.com (Ben Lipton) Date: Tue, 19 Jul 2016 16:20:40 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 Message-ID: Hi, I have updated the design page http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules with my plan for implementing user-configurable rules for mapping IPA data into certificate requests. In brief: we will use Jinja2 for templating. Data rules (which map individual data items) and syntax rules (which group them into certificate fields) will both be snippets of Jinja2 markup. The formatting process will be as follows: 1. Syntax rules will be rendered using Jinja2. Data rules (rule text, not rendered) will be passed as the datarules attribute. 2. Rendered syntax rules will be processed by the Formatter class for the selected CSR generation helper (e.g. openssl or certutil). The formatter combines these partial rules into a full template for the config. 3. The template will be rendered using Jinja2. Relevant data from the IPA database will be available in the context for this rendering. 4. The final rendered template will be returned to the caller, labeled with its function (e.g. a command line or a config file). Are there any comments or objections to this approach? Here's an example to show what it might look like in practice. Example data rules: email={{subject.email}} O={{config.ipacertificatesubjectbase}}\nCN={{subject.username}} Example syntax rule: subjectAltName=@{% section %}{{datarules|join('\n')}}{% endsection %} Example composed config template: [ req ] prompt = no encrypt_key = no distinguished_name = {% section %}O={{config.ipacertificatesubjectbase}} CN={{subject.username}}{% endsection %} req_extensions = exts [ exts ] subjectAltName=@{% section %}email={{subject.email}}{% endsection %} There's a lot more information about the thinking behind this at http://blog.benjaminlipton.com/2016/07/19/csr-generation-templating.html if you're interested, as well. Thanks, Ben From ftweedal at redhat.com Wed Jul 20 00:32:50 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 20 Jul 2016 10:32:50 +1000 Subject: [Freeipa-devel] [PATCH] 0046 Create server certs with DNS altname In-Reply-To: <82d7ad96-9b63-67a6-3070-99dd86d40641@redhat.com> References: <20151207052611.GG23644@dhcp-40-8.bne.redhat.com> <5665813B.90406@redhat.com> <20151207224639.GL23644@dhcp-40-8.bne.redhat.com> <56660D1D.6000109@redhat.com> <20151208090638.GQ23644@dhcp-40-8.bne.redhat.com> <20160120040409.GN31821@dhcp-40-8.bne.redhat.com> <82d7ad96-9b63-67a6-3070-99dd86d40641@redhat.com> Message-ID: <20160720003250.GY10771@dhcp-40-8.bne.redhat.com> On Tue, Jul 19, 2016 at 02:21:05PM +0200, Martin Basti wrote: > > > On 01.07.2016 13:26, Petr Spacek wrote: > > On 20.1.2016 05:04, Fraser Tweedale wrote: > > > On Tue, Dec 08, 2015 at 07:06:39PM +1000, Fraser Tweedale wrote: > > > > On Mon, Dec 07, 2015 at 05:50:05PM -0500, Rob Crittenden wrote: > > > > > Fraser Tweedale wrote: > > > > > > On Mon, Dec 07, 2015 at 01:53:15PM +0100, Martin Kosek wrote: > > > > > > > On 12/07/2015 06:26 AM, Fraser Tweedale wrote: > > > > > > > > The attached patch fixes > > > > > > > > https://fedorahosted.org/freeipa/ticket/4970. > > > > > > > > > > > > > > > > Note that the problem is addressed by adding the appropriate request > > > > > > > > extension to the CSR; the fix does not involve changing the default > > > > > > > > profile behaviour, which is complicated (see ticket for details). > > > > > > > Thanks for the patch! This is something we should really fix, I already get > > > > > > > warnings in my Python scripts when I hit sites protected by such HTTPS cert: > > > > > > > > > > > > > > /usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:264: > > > > > > > SubjectAltNameWarning: Certificate for projects.engineering.redhat.com has no > > > > > > > `subjectAltName`, falling back to check for a `commonName` for now. This > > > > > > > feature is being removed by major browsers and deprecated by RFC 2818. (See > > > > > > > https://github.com/shazow/urllib3/issues/497 for details.) > > > > > > > > > > > > > > Should we split ticket 4970, for the FreeIPA server part and then for cert > > > > > > > profile part? As it looks like the FreeIPA server will be fixed even in FreeIPA > > > > > > > 4.3.x and the other part later. > > > > > > > > > > > > > > How difficult do you see the general FreeIPA Certificate Profile part of this > > > > > > > request? Is it a too big task to handle in 4.4 time frame? > > > > > > > > > > > > > I will split the ticket and would suggest 4.4 Backlog - it might be > > > > > > doable but is a lower priority than e.g. Sub-CAs. > > > > > If you are going to defer the profile part then you should probably > > > > > update the client to also include a SAN if --request-cert is provided. > > > > > > > > > > rob > > > > > > > > > Yes, good idea. Updated patch attached. > > > > > > > > Cheers, > > > > Fraser > > > Bump, with rebased patch. > > Hi, > > > > this seems to work for Apache on IPA server & client cert. ACK. > Pushed to master: b12db924143cd6828c596c0b8a261325f3f589f3 > > > > > Interestingly enough I found out that Dogtag cert used on port 8443 does not > > have any SAN. > > > > Is it in scope of this ticket? > I will leave the ticket open until this is answered. > It's in scope. Also in scope is to make default profile automatically add SAN dNSName if none is supplied. Thanks, Fraser > 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 jcholast at redhat.com Wed Jul 20 08:20:52 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 Jul 2016 10:20:52 +0200 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: References: Message-ID: Hi, On 17.6.2016 00:06, Ben Lipton wrote: > On 06/14/2016 08:27 AM, Ben Lipton wrote: >> Hello all, >> >> I have written up a design proposal for making certificate requests >> easier to generate when using alternate certificate profiles: >> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >> The use case for this is described in >> https://fedorahosted.org/freeipa/ticket/4899. I will be working on >> implementing this design over the next couple of months. If you have >> the time and interest, please take a look and share any comments or >> concerns that you have. >> >> Thanks! >> >> Ben >> > Just a quick update to say that I've created a new document that covers > the proposed schema additions in a more descriptive way (with diagrams!) > I'm very new to developing with LDAP, so some more experienced eyes on > the proposal would be very helpful, even if you don't have time to > absorb the full design. Please take a look at > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema > if you have a chance. I finally had a chance to take a look at this, here are some comments: 1) I don't like how transformation rules are tied to a particular helper and have to be duplicated for each of them. They should be generic and work with any helper, as helpers are just an implementation detail and their resulting data is the same. In fact, I think I would prefer if the CSR was generated using python-cryptography's CertificateSigningRequestBuilder [1] rather than openssl or certutil or any other command line tool. 2) The schema seems unnecessarily complex. I think all we need is a single new multi-value attribute in certprofile. For your S/MIME example, it could be something like: attr: subjectname=CN={subject.cn},{subject_base} attr: san_rfc822name={subject.email} attr: san_directoryname={subject.dn} Honza [1] -- Jan Cholasta From flo at redhat.com Wed Jul 20 08:26:08 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 20 Jul 2016 10:26:08 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: <70117590-1a61-8284-7680-c922fba8f7cc@redhat.com> References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> <296df9f1-1f62-b3aa-d395-13411c95d9e0@redhat.com> <70117590-1a61-8284-7680-c922fba8f7cc@redhat.com> Message-ID: On 07/18/2016 02:52 PM, Florence Blanc-Renaud wrote: > On 07/18/2016 08:20 AM, Jan Cholasta wrote: >> Hi, >> >> On 7.7.2016 16:40, Florence Blanc-Renaud wrote: >>> On 07/07/2016 01:23 PM, Petr Vobornik wrote: >>>> On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >>>>> Hi, >>>>> >>>>> the output of ipa selinuxusermap-add-hostgroup and >>>>> selinuxusermap-add-user does not display any more the host/host >>>>> group or >>>>> user/group that could not be added. This patch fixes this >>>>> regression by >>>>> adding the labels host/hostgroup/user/group to the list of >>>>> _failed_member_output_params of the class ClientMethod. >>>>> >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6026 >>>>> >>>> >>>> I've a feeling that this issue is more general and multiple commands >>>> regressed. Would be good to check other member options, e.g. also in >>>> user plugin. >>>> >>> Hi Petr, >>> >>> you are right, a lot of other commands regressed. So far I checked only >>> user and sudocmd but it is likely to be a long task. Are there >>> regression tests that could help me make sure that the fix is >>> exhaustive? >>> >>> Flo >> >> See attachment for a patch with an universal fix. >> >> Honza >> > Hi Honza, > > the patch fixes most of the issues. I still see some CLI that do not > print everything (while they used to before the regression): > ipa servicedelegationrule-add-member > ipa servicedelegationrule-remove-member > ipa servicedelegationtarget-add-member > ipa servicedelegationtarget-remove-member > > And the following CLI do not print the failed members (but they never did): > ipa automember-add-condition > ipa automember-remove-condition > ipa sudorule-add-allow-command > ipa sudorule-remove-allow-command > ipa sudorule-add-deny-command > ipa sudorule-remove-deny-command > > It is probably ok to commit this patch and investigate in another ticket > the remaining issues, > Flo. > Hi, please find a new version of the patch, thanks to Jan's help. This version also fixes servicedelegation commands. Flo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0010-2-Show-full-error-message-for-selinuxusermap-add-hostg.patch Type: text/x-patch Size: 6138 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 20 08:50:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 Jul 2016 10:50:07 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> <296df9f1-1f62-b3aa-d395-13411c95d9e0@redhat.com> <70117590-1a61-8284-7680-c922fba8f7cc@redhat.com> Message-ID: On 20.7.2016 10:26, Florence Blanc-Renaud wrote: > On 07/18/2016 02:52 PM, Florence Blanc-Renaud wrote: >> On 07/18/2016 08:20 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 7.7.2016 16:40, Florence Blanc-Renaud wrote: >>>> On 07/07/2016 01:23 PM, Petr Vobornik wrote: >>>>> On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >>>>>> Hi, >>>>>> >>>>>> the output of ipa selinuxusermap-add-hostgroup and >>>>>> selinuxusermap-add-user does not display any more the host/host >>>>>> group or >>>>>> user/group that could not be added. This patch fixes this >>>>>> regression by >>>>>> adding the labels host/hostgroup/user/group to the list of >>>>>> _failed_member_output_params of the class ClientMethod. >>>>>> >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6026 >>>>>> >>>>> >>>>> I've a feeling that this issue is more general and multiple commands >>>>> regressed. Would be good to check other member options, e.g. also in >>>>> user plugin. >>>>> >>>> Hi Petr, >>>> >>>> you are right, a lot of other commands regressed. So far I checked only >>>> user and sudocmd but it is likely to be a long task. Are there >>>> regression tests that could help me make sure that the fix is >>>> exhaustive? >>>> >>>> Flo >>> >>> See attachment for a patch with an universal fix. >>> >>> Honza >>> >> Hi Honza, >> >> the patch fixes most of the issues. I still see some CLI that do not >> print everything (while they used to before the regression): >> ipa servicedelegationrule-add-member >> ipa servicedelegationrule-remove-member >> ipa servicedelegationtarget-add-member >> ipa servicedelegationtarget-remove-member >> >> And the following CLI do not print the failed members (but they never >> did): >> ipa automember-add-condition >> ipa automember-remove-condition >> ipa sudorule-add-allow-command >> ipa sudorule-remove-allow-command >> ipa sudorule-add-deny-command >> ipa sudorule-remove-deny-command >> >> It is probably ok to commit this patch and investigate in another ticket >> the remaining issues, >> Flo. >> > > Hi, > please find a new version of the patch, thanks to Jan's help. This > version also fixes servicedelegation commands. I would rather keep the patches separate, as the fixes are different. Otherwise LGTM. -- Jan Cholasta From flo at redhat.com Wed Jul 20 09:46:31 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 20 Jul 2016 11:46:31 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> <296df9f1-1f62-b3aa-d395-13411c95d9e0@redhat.com> <70117590-1a61-8284-7680-c922fba8f7cc@redhat.com> Message-ID: <0e298329-6dd0-eafb-7b0a-bcd9c9a69aa9@redhat.com> On 07/20/2016 10:50 AM, Jan Cholasta wrote: > On 20.7.2016 10:26, Florence Blanc-Renaud wrote: >> On 07/18/2016 02:52 PM, Florence Blanc-Renaud wrote: >>> On 07/18/2016 08:20 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 7.7.2016 16:40, Florence Blanc-Renaud wrote: >>>>> On 07/07/2016 01:23 PM, Petr Vobornik wrote: >>>>>> On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the output of ipa selinuxusermap-add-hostgroup and >>>>>>> selinuxusermap-add-user does not display any more the host/host >>>>>>> group or >>>>>>> user/group that could not be added. This patch fixes this >>>>>>> regression by >>>>>>> adding the labels host/hostgroup/user/group to the list of >>>>>>> _failed_member_output_params of the class ClientMethod. >>>>>>> >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6026 >>>>>>> >>>>>> >>>>>> I've a feeling that this issue is more general and multiple commands >>>>>> regressed. Would be good to check other member options, e.g. also in >>>>>> user plugin. >>>>>> >>>>> Hi Petr, >>>>> >>>>> you are right, a lot of other commands regressed. So far I checked >>>>> only >>>>> user and sudocmd but it is likely to be a long task. Are there >>>>> regression tests that could help me make sure that the fix is >>>>> exhaustive? >>>>> >>>>> Flo >>>> >>>> See attachment for a patch with an universal fix. >>>> >>>> Honza >>>> >>> Hi Honza, >>> >>> the patch fixes most of the issues. I still see some CLI that do not >>> print everything (while they used to before the regression): >>> ipa servicedelegationrule-add-member >>> ipa servicedelegationrule-remove-member >>> ipa servicedelegationtarget-add-member >>> ipa servicedelegationtarget-remove-member >>> >>> And the following CLI do not print the failed members (but they never >>> did): >>> ipa automember-add-condition >>> ipa automember-remove-condition >>> ipa sudorule-add-allow-command >>> ipa sudorule-remove-allow-command >>> ipa sudorule-add-deny-command >>> ipa sudorule-remove-deny-command >>> >>> It is probably ok to commit this patch and investigate in another ticket >>> the remaining issues, >>> Flo. >>> >> >> Hi, >> please find a new version of the patch, thanks to Jan's help. This >> version also fixes servicedelegation commands. > > I would rather keep the patches separate, as the fixes are different. > Otherwise LGTM. > Hi Honza, please find an updated version which handles only servicedelegation issue (I also attached your original patch for reference). For the reviewers: both have to be applied to completely fix the ticket. Flo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0010-3-Show-full-error-message-for-selinuxusermap-add-hostg.patch Type: text/x-patch Size: 5224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-677-frontend-copy-command-arguments-to-output-params-on-.patch Type: text/x-patch Size: 1374 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Jul 20 10:08:07 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 20 Jul 2016 12:08:07 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <6f29f6b1-0c83-86dc-1b63-e76407bd5e07@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> <20160719111349.rxrqotars2agqkxm@redhat.com> <6f29f6b1-0c83-86dc-1b63-e76407bd5e07@redhat.com> Message-ID: <862cb3d0-6320-9bd6-5c61-5f40f8e90c19@redhat.com> On 07/19/2016 01:25 PM, Martin Babinsky wrote: > On 07/19/2016 01:13 PM, Alexander Bokovoy wrote: >> On Mon, 18 Jul 2016, Martin Babinsky wrote: >>> On 07/18/2016 12:29 PM, Martin Babinsky wrote: >>> > On 07/18/2016 10:01 AM, Jan Cholasta wrote: >>> > > Hi, >>> > > > > On 16.7.2016 12:46, Alexander Bokovoy wrote: >>> > > > Hi, >>> > > > > > > I had some time and was blocked by these bugs to do my >>> tickets so I >>> > > > actually fixed these three problems that are assigned to Martin >>> > > > Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>> > > > > > > ------ >>> > > > > > > Output entry elements may have multiple types allowed. We >>> need to check >>> > > > all of them to properly validate the output. Right now, thin >>> client >>> > > > receives type specifications for elements as tuples of types, so >>> > > > what is seen as 'None' on the server side becomes (type(None),) >>> tuple >>> > > > on the thin client side. >>> > > > > > > Change validation to account this by processing each >>> separate type >>> > > > of the element and account for both None and type(None). Raise >>> type >>> > > > error only if all of the type checks failed. >>> > > > > > > https://fedorahosted.org/freeipa/ticket/6061 >>> > > > > NACK, this only hides the real issue, which is that >>> trustconfig-show >>> > > (and automember-set-default in #6037) claims to return the primary >>> key >>> > > of the object in the 'value' output field, but the object does not >>> have >>> > > a primary key, so the client rightfully expects None. >>> > > > > A proper fix would be to set "has_output = >>> output.simple_value" for >>> > > these commands (all of automember_default_group_{set,remove,show}, >>> > > trustconfig_{mod,show}). >>> > > > > Honza >>> > > > > The problem is that these commands do not return a simple >>> boolean in >>> > 'result' but a full entry dict, so 'simple_value' won't do the >>> trick in >>> > this case. >>> > > But I agree, we should rather fix misbehaving commands rather than >>> bend >>> > the framework to accomodate their idiosyncracies, we have enough of >>> that >>> > already. >>> > I am attaching a patch that adds a custom shim for misbehaving >>> commands so that they work as before. There is also a big fat warning >>> added to discourage implementation of such commands. >> Let's go by this patch. I originally thought changing trust.py to simply >> not supply 'value' field at all but this fix is simpler. >> > We found out that we still would need to handle > automember-default-group-{set,remove} commands which use the value to > print out summary, so it seems that we cannot win without some more > extensive fixing. > I have botched the wording in the comment, attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0189.1-allow-value-output-param-in-commands-without-primary.patch Type: text/x-patch Size: 5944 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Jul 20 10:10:49 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 20 Jul 2016 12:10:49 +0200 Subject: [Freeipa-devel] [PATCH 190] expose `--secret` option in radiusproxy-* commands In-Reply-To: <4619e944-47d6-e181-c42d-073f479d4f85@redhat.com> References: <4619e944-47d6-e181-c42d-073f479d4f85@redhat.com> Message-ID: <0fb7c740-d932-3e77-87fd-4a91dbef71f4@redhat.com> On 07/19/2016 12:32 PM, Jan Cholasta wrote: > Hi, > > On 18.7.2016 13:51, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6078 > > I don't think we want the secret searchable. Add a 'no_search' flag to > the param to fix that. > > Honza > 'no_search' flag breaks the API backwards compatibility, so I am sending another two patches which fix handling of deprecated options in the framework and deprecate `--secret` in radiusproxy-find command. I hope this solution is the best. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0190-expose-secret-option-in-radiusproxy-commands.patch Type: text/x-patch Size: 1147 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0192-raise-ValidationError-when-deprecated-param-is-passe.patch Type: text/x-patch Size: 1462 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0193-prevent-search-for-RADIUS-proxy-servers-by-secret.patch Type: text/x-patch Size: 2859 bytes Desc: not available URL: From simo at redhat.com Wed Jul 20 10:11:52 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 20 Jul 2016 06:11:52 -0400 Subject: [Freeipa-devel] PATCH: Improve on #2795 patches Message-ID: <1469009512.21393.44.camel@redhat.com> Attached patch introduces a helper function and avoids the questionable replace+delete operations where possible (still employed in the entry_to_mods function). Compiles and I am about to test it, but I'd like feedback on it if anyone wants to take a look. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Simplify-date-manipulation-in-pwd-plugin.patch Type: text/x-patch Size: 8068 bytes Desc: not available URL: From simo at redhat.com Wed Jul 20 10:27:42 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 20 Jul 2016 06:27:42 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: References: Message-ID: <1469010462.21393.47.camel@redhat.com> On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: > Hi, > > I have updated the design page? > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generati > on/Mapping_Rules? > with my plan for implementing user-configurable rules for mapping > IPA? > data into certificate requests. In brief: we will use Jinja2 for? > templating. Data rules (which map individual data items) and syntax? > rules (which group them into certificate fields) will both be > snippets? > of Jinja2 markup. The formatting process will be as follows: > 1. Syntax rules will be rendered using Jinja2. Data rules (rule > text,? > not rendered) will be passed as the datarules attribute. > 2. Rendered syntax rules will be processed by the Formatter class > for? > the selected CSR generation helper (e.g. openssl or certutil). The? > formatter combines these partial rules into a full template for the > config. > 3. The template will be rendered using Jinja2. Relevant data from > the? > IPA database will be available in the context for this rendering. > 4. The final rendered template will be returned to the caller, > labeled? > with its function (e.g. a command line or a config file). > > Are there any comments or objections to this approach? Here's an > example? > to show what it might look like in practice. > > Example data rules: > email={{subject.email}} > O={{config.ipacertificatesubjectbase}}\nCN={{subject.username}} > > Example syntax rule: > subjectAltName=@{% section %}{{datarules|join('\n')}}{% endsection %} > > Example composed config template: > [ req ] > prompt = no > encrypt_key = no > > distinguished_name = {% section > %}O={{config.ipacertificatesubjectbase}} > CN={{subject.username}}{% endsection %} > > req_extensions = exts > > [ exts ] > subjectAltName=@{% section %}email={{subject.email}}{% endsection %} > > There's a lot more information about the thinking behind this at? > http://blog.benjaminlipton.com/2016/07/19/csr-generation-templating.h > tml? > if you're interested, as well. Nice work Ben, it's been really nice to be able to follow your notes on the blog post, one question remains lingering in my head, why jinja2 ? I know that engine relatively well as I used it in ipsilon, so I am not questioning the choice just asking why specifically jinja2 and not something else, potentially language agnostic. Simo. From jcholast at redhat.com Wed Jul 20 11:13:24 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 Jul 2016 13:13:24 +0200 Subject: [Freeipa-devel] [PATCH] 0010 Show full error message for selinuxusermap-add-hostgroup In-Reply-To: <0e298329-6dd0-eafb-7b0a-bcd9c9a69aa9@redhat.com> References: <37713d39-7937-713a-6e6e-ffb185e9f070@redhat.com> <5df3ce78-d9ca-859d-614d-de32e1b62279@redhat.com> <296df9f1-1f62-b3aa-d395-13411c95d9e0@redhat.com> <70117590-1a61-8284-7680-c922fba8f7cc@redhat.com> <0e298329-6dd0-eafb-7b0a-bcd9c9a69aa9@redhat.com> Message-ID: On 20.7.2016 11:46, Florence Blanc-Renaud wrote: > On 07/20/2016 10:50 AM, Jan Cholasta wrote: >> On 20.7.2016 10:26, Florence Blanc-Renaud wrote: >>> On 07/18/2016 02:52 PM, Florence Blanc-Renaud wrote: >>>> On 07/18/2016 08:20 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 7.7.2016 16:40, Florence Blanc-Renaud wrote: >>>>>> On 07/07/2016 01:23 PM, Petr Vobornik wrote: >>>>>>> On 07/05/2016 02:38 PM, Florence Blanc-Renaud wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the output of ipa selinuxusermap-add-hostgroup and >>>>>>>> selinuxusermap-add-user does not display any more the host/host >>>>>>>> group or >>>>>>>> user/group that could not be added. This patch fixes this >>>>>>>> regression by >>>>>>>> adding the labels host/hostgroup/user/group to the list of >>>>>>>> _failed_member_output_params of the class ClientMethod. >>>>>>>> >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/6026 >>>>>>>> >>>>>>> >>>>>>> I've a feeling that this issue is more general and multiple commands >>>>>>> regressed. Would be good to check other member options, e.g. also in >>>>>>> user plugin. >>>>>>> >>>>>> Hi Petr, >>>>>> >>>>>> you are right, a lot of other commands regressed. So far I checked >>>>>> only >>>>>> user and sudocmd but it is likely to be a long task. Are there >>>>>> regression tests that could help me make sure that the fix is >>>>>> exhaustive? >>>>>> >>>>>> Flo >>>>> >>>>> See attachment for a patch with an universal fix. >>>>> >>>>> Honza >>>>> >>>> Hi Honza, >>>> >>>> the patch fixes most of the issues. I still see some CLI that do not >>>> print everything (while they used to before the regression): >>>> ipa servicedelegationrule-add-member >>>> ipa servicedelegationrule-remove-member >>>> ipa servicedelegationtarget-add-member >>>> ipa servicedelegationtarget-remove-member >>>> >>>> And the following CLI do not print the failed members (but they never >>>> did): >>>> ipa automember-add-condition >>>> ipa automember-remove-condition >>>> ipa sudorule-add-allow-command >>>> ipa sudorule-remove-allow-command >>>> ipa sudorule-add-deny-command >>>> ipa sudorule-remove-deny-command >>>> >>>> It is probably ok to commit this patch and investigate in another >>>> ticket >>>> the remaining issues, >>>> Flo. >>>> >>> >>> Hi, >>> please find a new version of the patch, thanks to Jan's help. This >>> version also fixes servicedelegation commands. >> >> I would rather keep the patches separate, as the fixes are different. >> Otherwise LGTM. >> > Hi Honza, > > please find an updated version which handles only servicedelegation > issue (I also attached your original patch for reference). > For the reviewers: both have to be applied to completely fix the ticket. > Flo. Thanks, ACK. Pushed to master: 90704df59dbe996ef1db58d7a11f826c008d08a3 -- Jan Cholasta From mbabinsk at redhat.com Wed Jul 20 11:15:47 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 20 Jul 2016 13:15:47 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: <862cb3d0-6320-9bd6-5c61-5f40f8e90c19@redhat.com> References: <20160716104655.crbov36a63cq7dcj@redhat.com> <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> <20160719111349.rxrqotars2agqkxm@redhat.com> <6f29f6b1-0c83-86dc-1b63-e76407bd5e07@redhat.com> <862cb3d0-6320-9bd6-5c61-5f40f8e90c19@redhat.com> Message-ID: On 07/20/2016 12:08 PM, Martin Babinsky wrote: > On 07/19/2016 01:25 PM, Martin Babinsky wrote: >> On 07/19/2016 01:13 PM, Alexander Bokovoy wrote: >>> On Mon, 18 Jul 2016, Martin Babinsky wrote: >>>> On 07/18/2016 12:29 PM, Martin Babinsky wrote: >>>> > On 07/18/2016 10:01 AM, Jan Cholasta wrote: >>>> > > Hi, >>>> > > > > On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>> > > > Hi, >>>> > > > > > > I had some time and was blocked by these bugs to do my >>>> tickets so I >>>> > > > actually fixed these three problems that are assigned to Martin >>>> > > > Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>> > > > > > > ------ >>>> > > > > > > Output entry elements may have multiple types allowed. We >>>> need to check >>>> > > > all of them to properly validate the output. Right now, thin >>>> client >>>> > > > receives type specifications for elements as tuples of types, so >>>> > > > what is seen as 'None' on the server side becomes (type(None),) >>>> tuple >>>> > > > on the thin client side. >>>> > > > > > > Change validation to account this by processing each >>>> separate type >>>> > > > of the element and account for both None and type(None). Raise >>>> type >>>> > > > error only if all of the type checks failed. >>>> > > > > > > https://fedorahosted.org/freeipa/ticket/6061 >>>> > > > > NACK, this only hides the real issue, which is that >>>> trustconfig-show >>>> > > (and automember-set-default in #6037) claims to return the primary >>>> key >>>> > > of the object in the 'value' output field, but the object does not >>>> have >>>> > > a primary key, so the client rightfully expects None. >>>> > > > > A proper fix would be to set "has_output = >>>> output.simple_value" for >>>> > > these commands (all of automember_default_group_{set,remove,show}, >>>> > > trustconfig_{mod,show}). >>>> > > > > Honza >>>> > > > > The problem is that these commands do not return a simple >>>> boolean in >>>> > 'result' but a full entry dict, so 'simple_value' won't do the >>>> trick in >>>> > this case. >>>> > > But I agree, we should rather fix misbehaving commands rather than >>>> bend >>>> > the framework to accomodate their idiosyncracies, we have enough of >>>> that >>>> > already. >>>> > I am attaching a patch that adds a custom shim for misbehaving >>>> commands so that they work as before. There is also a big fat warning >>>> added to discourage implementation of such commands. >>> Let's go by this patch. I originally thought changing trust.py to simply >>> not supply 'value' field at all but this fix is simpler. >>> >> We found out that we still would need to handle >> automember-default-group-{set,remove} commands which use the value to >> print out summary, so it seems that we cannot win without some more >> extensive fixing. >> > > I have botched the wording in the comment, attaching updated patch. > > > And I have missed adding the new output to `trustconfig-mod` so attaching another version. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0189.2-allow-value-output-param-in-commands-without-primary.patch Type: text/x-patch Size: 6725 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 20 11:57:32 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 Jul 2016 13:57:32 +0200 Subject: [Freeipa-devel] [PATCH] 0210 frontend: fix output validation for multiple type choices In-Reply-To: References: <20160716104655.crbov36a63cq7dcj@redhat.com> <56a6648c-7e44-2319-f2ba-06d5134031f8@redhat.com> <20160719111349.rxrqotars2agqkxm@redhat.com> <6f29f6b1-0c83-86dc-1b63-e76407bd5e07@redhat.com> <862cb3d0-6320-9bd6-5c61-5f40f8e90c19@redhat.com> Message-ID: On 20.7.2016 13:15, Martin Babinsky wrote: > On 07/20/2016 12:08 PM, Martin Babinsky wrote: >> On 07/19/2016 01:25 PM, Martin Babinsky wrote: >>> On 07/19/2016 01:13 PM, Alexander Bokovoy wrote: >>>> On Mon, 18 Jul 2016, Martin Babinsky wrote: >>>>> On 07/18/2016 12:29 PM, Martin Babinsky wrote: >>>>> > On 07/18/2016 10:01 AM, Jan Cholasta wrote: >>>>> > > Hi, >>>>> > > > > On 16.7.2016 12:46, Alexander Bokovoy wrote: >>>>> > > > Hi, >>>>> > > > > > > I had some time and was blocked by these bugs to do my >>>>> tickets so I >>>>> > > > actually fixed these three problems that are assigned to Martin >>>>> > > > Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>>> > > > > > > ------ >>>>> > > > > > > Output entry elements may have multiple types allowed. We >>>>> need to check >>>>> > > > all of them to properly validate the output. Right now, thin >>>>> client >>>>> > > > receives type specifications for elements as tuples of types, so >>>>> > > > what is seen as 'None' on the server side becomes (type(None),) >>>>> tuple >>>>> > > > on the thin client side. >>>>> > > > > > > Change validation to account this by processing each >>>>> separate type >>>>> > > > of the element and account for both None and type(None). Raise >>>>> type >>>>> > > > error only if all of the type checks failed. >>>>> > > > > > > https://fedorahosted.org/freeipa/ticket/6061 >>>>> > > > > NACK, this only hides the real issue, which is that >>>>> trustconfig-show >>>>> > > (and automember-set-default in #6037) claims to return the primary >>>>> key >>>>> > > of the object in the 'value' output field, but the object does not >>>>> have >>>>> > > a primary key, so the client rightfully expects None. >>>>> > > > > A proper fix would be to set "has_output = >>>>> output.simple_value" for >>>>> > > these commands (all of automember_default_group_{set,remove,show}, >>>>> > > trustconfig_{mod,show}). >>>>> > > > > Honza >>>>> > > > > The problem is that these commands do not return a simple >>>>> boolean in >>>>> > 'result' but a full entry dict, so 'simple_value' won't do the >>>>> trick in >>>>> > this case. >>>>> > > But I agree, we should rather fix misbehaving commands rather than >>>>> bend >>>>> > the framework to accomodate their idiosyncracies, we have enough of >>>>> that >>>>> > already. >>>>> > I am attaching a patch that adds a custom shim for misbehaving >>>>> commands so that they work as before. There is also a big fat warning >>>>> added to discourage implementation of such commands. >>>> Let's go by this patch. I originally thought changing trust.py to >>>> simply >>>> not supply 'value' field at all but this fix is simpler. >>>> >>> We found out that we still would need to handle >>> automember-default-group-{set,remove} commands which use the value to >>> print out summary, so it seems that we cannot win without some more >>> extensive fixing. >>> >> >> I have botched the wording in the comment, attaching updated patch. >> >> >> > And I have missed adding the new output to `trustconfig-mod` so > attaching another version. Works for me, ACK. Pushed to master: f0a61546f552d4df887617167f7dc1378cb95083 -- Jan Cholasta From mbabinsk at redhat.com Wed Jul 20 12:04:53 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 20 Jul 2016 14:04:53 +0200 Subject: [Freeipa-devel] [PATCH 0028][Tests] Fix failing user tests In-Reply-To: References: Message-ID: On 07/15/2016 06:10 PM, Lenka Doudova wrote: > Hi, > > here's patch with fix for failing user tests, specifically tests with > renaming users. > > Failures were caused by RFE Kerberos principal aliases. As part of the > fix, I had to rewrite few of the tests themselves, since they used > "--setattr" option rather than "--rename" option, which produces > different results. > > > Lenka > > > Hi Lenka, I get nice green *user tests with this patch, so functionally it seems ok. However, the commit message does not meet our project standards[1]: 1.) The message summary is very vague, I would rather see something more specific like: """ Tests: improve the handling of rename operations by user tracker """ 2.) The message itself should be wrapped at the maximum of 78 character width (IIRC) but your lines are way too long. A nice way to automate this in vim is to highlight the text, enter command mode and run 'gq', that should format the text for you. 3.) You did not add upstream ticket URL to the end of the message, please do so. There is also an extraneous whitespace here: """ else: if type(value) is list: self.attrs[key] = value else: self.attrs[key] = [value] + for key, value in expected_updates.items(): if value is None or value is '' or value is u'': del self.attrs[key] """ that has nothing to do with the scope of the patch. Please remove it. [1] http://www.freeipa.org/page/Contribute/Patch_Format -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Jul 20 12:28:18 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 20 Jul 2016 14:28:18 +0200 Subject: [Freeipa-devel] [PATCH 0029][Tests] Adding authentication test to trust test suite In-Reply-To: <2a1cdafa-b75e-7789-6834-a5197f159ea6@redhat.com> References: <2a1cdafa-b75e-7789-6834-a5197f159ea6@redhat.com> Message-ID: <070a504c-fe7f-60de-7798-74210d102d0a@redhat.com> On 07/19/2016 10:41 AM, Lenka Doudova wrote: > Hi, > > > this patch adds authentication test (specifically "kinit -E > ipauser at IPADOMAIN") to basic trust test suite, as requested by Sumit. > > Intended to be applied after my patches 25.4 and 26.3 (already waiting > to be pushed). > > > Lenka > > > Hi Lenka, Code review: 1.) You have several PEP8 transgressions in the patch, please fix them: """ $ git show -U0 | pep8 --diff ./ipatests/test_integration/test_trust.py:172:34: E127 continuation line over-indented for visual indent ./ipatests/test_integration/test_trust.py:176:35: E128 continuation line under-indented for visual indent ./ipatests/test_integration/test_trust.py:180:27: E231 missing whitespace after ',' """ 2.) + + +def unlock_principal_password(user, oldpw, newpw, master): + container_user = "cn=users,cn=accounts" + basedn = master.domain.basedn + + userdn = "uid={},{},{}".format(user, container_user, basedn) + + args = [paths.LDAPPASSWD, '-D', userdn, '-w', oldpw, '-a', oldpw, + '-s', newpw, '-x'] + return run(args) there is already a function with the same name in other module: """ git grep -ni 'def unlock_principal_password' ipatests ipatests/test_integration/util.py:82:def unlock_principal_password(user, oldpw, newpw, master): ipatests/util.py:676:def unlock_principal_password(user, oldpw, newpw): """ Having functions with the same names in different modules makes for poor coding practice IMHO. Please rename the function to something like "ldappasswd_user" or something like that so that we have a distinction. Also, you should call ldappasswd directly on master (since you pass it as an argument anyway) using "master.run_command(args)". You should *not* run any in-test code on the controller unless absolutely necessary. You can then remove the ipautil.run import from the beginning of the module. Commit message woes: 1.) vague summary is vague, I would rather see something like: """ test that IPA user can kinit using enterprise principal with IPA domain """ 2.) Commit message body is longer than 78 characters. 3.) there is no ticket URL, I think you can link https://fedorahosted.org/freeipa/ticket/6036 or create a new ticket for the change. -- Martin^3 Babinsky From dkupka at redhat.com Wed Jul 20 12:32:14 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 20 Jul 2016 14:32:14 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> Message-ID: On 15/07/16 12:53, David Kupka wrote: > Hello! > > After Honza introduced thin client that builds plugins and commands > dynamically from schema client became much slower. This is only logical, > instead of importing a module client now must fetch the schema from > server, parse it and instantiate the commands using the data. > > First step to speed it up was addition of schema cache to client. That > removed the RTT and download time of fetching schema every time. > > Now the most time consuming task became displaying help for lists of > topics and command and displaying individual topics. This is simply > because of the need to instantiate all the commands to find the > relations between topics and commands. > > All the necessary bits for server commands and topics are already in the > schema cache so we can skip this part and generate help from it, right? > Not so fast! > > There are client plugins with commands and topics. So we can generate > basic bits (list of all topics, list of all commands, list of commands > for each topic) from schema and store it in cache. Then we need to go > through all client plugins and get similar bits for client plugins. Then > we can merge and print. > > Still the client response is not as fast as before and I this it even > can't be. Also first time you display particular topic or list takes > longer because it must be freshly generated and stored in cache for next > use. And this is what the attached patches do. > > https://fedorahosted.org/freeipa/ticket/6048 Reimplemented so there is no need to distinguish client plugins and remote plugins. The main idea of this approach is to avoid creating instances of the commands just to get the information about topic, name and summary needed for displaying help. Instead class properties are used to access the information directly in schema. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0112.1-schema-Read-data-from-cache-only-once.patch Type: text/x-patch Size: 1313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0113.1-schema-Speed-up-cache-verification.patch Type: text/x-patch Size: 1945 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0114.1-schema-Generate-and-store-bits-for-help.patch Type: text/x-patch Size: 2669 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0115.1-schema-Introduce-format-versioning-for-api-schema-ca.patch Type: text/x-patch Size: 3718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0116.1-frontend-Change-summary-topic-and-NO_CLI-to-class-pr.patch Type: text/x-patch Size: 8322 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0117.1-help-Do-not-create-instances-to-get-information-abou.patch Type: text/x-patch Size: 2499 bytes Desc: not available URL: From jcholast at redhat.com Wed Jul 20 12:56:33 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 20 Jul 2016 14:56:33 +0200 Subject: [Freeipa-devel] [freeipa] #6002: Default CA can be used without an ACL In-Reply-To: <20160719070154.GS10771@dhcp-40-8.bne.redhat.com> References: <040.c455dd24c0d77033bb69ad9540d2e83b@fedorahosted.org> <055.a874b9e24d14ff50c7966339031dfb11@fedorahosted.org> <20160704070616.GA10771@dhcp-40-8.bne.redhat.com> <9fb35b8f-c4e7-7c24-6070-dd70b046dac4@redhat.com> <20160719070154.GS10771@dhcp-40-8.bne.redhat.com> Message-ID: On 19.7.2016 09:01, Fraser Tweedale wrote: > On Tue, Jul 19, 2016 at 08:26:22AM +0200, Jan Cholasta wrote: >> Hi, >> >> On 4.7.2016 09:06, Fraser Tweedale wrote: >>> On Tue, Jun 28, 2016 at 01:47:23PM -0000, freeipa wrote: >>>> #6002: Default CA can be used without an ACL >>>> >>>> Comment (by ftweedal): >>>> >>>> This is expected behaviour; if a CA ACL does not reference any CAs, >>>> and does not have cacat=all, then it is assumed to refer to the >>>> default CA. This is for backwards compatibility with existing >>>> CA ACLs, which do not reference any CAs but did (and still do) >>>> allow access to IPA CA. >>>> >>>> Leaving open for discussion about whether to break compatibility >>>> for a more consistent behaviour. >>>> >>> Didn't get any feedback in the ticket yet so raising on list for >>> visibility. If people agree with current behaviour I can add a >>> clarification to caacl plugin help text and close out this ticket. >> >> (Sorry for the late reply, I was on vacation the last 2 weeks.) >> >> I would very much prefer if this was consistent with (literally) every other >> member list+category attribute, that is, no member and no category means the >> rule never matches. >> >> While documenting this as an exception to the above rule is the easy way >> out, IMHO adhering to the rule is even better - anyone who touched HBAC or >> sudo in IPA would immediately know their way around CA ACLs without having >> to read the documentation at all, which is a win, because people don't >> generally read documentation until something goes wrong. The current >> behavior might surprise them, even if documented properly (it sure surprised >> me at first :-). >> >> BTW I think this can be done without breaking compatibility, e.g. by using a >> new objectclass to distinguish between "old" (CA is always implicitly the >> top-level CA) and "new" (CAs are specified using the member and category >> attributes) CA ACLs. >> >> Honza >> > Is there precedent of "varying behaviour based on objectclass" in > IPA? Yes, for example in the permission plugin. > > Would it go along the lines of... > > 1. subtype 'ipaCaAcl' object class (let us call it 'ipaCaAclWithCa' > for sake of discussion). (Note that moving the 'ipaCa' attribute > to be part of 'ipaCaAclWithCa' would not be backwards compatible > with v4.4 as currently released, so it would remain in 'ipaCaAcl' > objectclass.) > > 2. Upgrade script to take 'ipaCaAcl' objects that are NOT > 'ipaCaAclWithCa', and make them so, while adding the IPA CA. > > Is this what you have in mind? Yes, something like this, but we can't inherit the new object class from ipaCaAcl if we want "new" CA ACLs to be invisible on 4.3 servers. > > If so, I don't think there is actually a need to vary the behaviour > based on object class, other than during upgrade. The reason I was > not doing upgrades in the first place was because I could not in > distinguish between "old" CA ACLs, and "new" CA ACLs that don't have > any CAs defined. However, adding a new objectclass resolves this > ambiguity. I'm not sure if this can be handled properly during upgrade only. One could have a 4.3 server and 4.4 replica, add a CA ACL on the 4.3 server and then uninstall the server, which would leave the CA ACL not upgraded for indeterminate time. Also we should keep "old" CA ACLs working on 4.3 servers, otherwise we would break cert-request on them, and I don't think this can be done without changing the object class at runtime. > > Lmk what you think; I could be way off track :) > > Cheers, > Fraser > -- Jan Cholasta From dkupka at redhat.com Wed Jul 20 13:17:02 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 20 Jul 2016 15:17:02 +0200 Subject: [Freeipa-devel] PATCH: Improve on #2795 patches In-Reply-To: <1469009512.21393.44.camel@redhat.com> References: <1469009512.21393.44.camel@redhat.com> Message-ID: <882ecdca-3b06-ee93-f0be-7d7b6751aa08@redhat.com> On 20/07/16 12:11, Simo Sorce wrote: > Attached patch introduces a helper function and avoids the questionable > replace+delete operations where possible (still employed in the > entry_to_mods function). > Compiles and I am about to test it, but I'd like feedback on it if > anyone wants to take a look. > > Simo. > > > Looks and works good, ACK. -- David Kupka From blipton at redhat.com Wed Jul 20 14:05:16 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 20 Jul 2016 10:05:16 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: References: Message-ID: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> Hi, Thanks very much for the feedback! Some responses below; I hope you'll let me know what you think of my reasoning. On 07/20/2016 04:20 AM, Jan Cholasta wrote: > Hi, > > On 17.6.2016 00:06, Ben Lipton wrote: >> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>> Hello all, >>> >>> I have written up a design proposal for making certificate requests >>> easier to generate when using alternate certificate profiles: >>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>> >>> The use case for this is described in >>> https://fedorahosted.org/freeipa/ticket/4899. I will be working on >>> implementing this design over the next couple of months. If you have >>> the time and interest, please take a look and share any comments or >>> concerns that you have. >>> >>> Thanks! >>> >>> Ben >>> >> Just a quick update to say that I've created a new document that covers >> the proposed schema additions in a more descriptive way (with diagrams!) >> I'm very new to developing with LDAP, so some more experienced eyes on >> the proposal would be very helpful, even if you don't have time to >> absorb the full design. Please take a look at >> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >> >> if you have a chance. > > I finally had a chance to take a look at this, here are some comments: > > 1) I don't like how transformation rules are tied to a particular > helper and have to be duplicated for each of them. They should be > generic and work with any helper, as helpers are just an > implementation detail and their resulting data is the same. > > In fact, I think I would prefer if the CSR was generated using > python-cryptography's CertificateSigningRequestBuilder [1] rather than > openssl or certutil or any other command line tool. > There are lots of tools that users might want to use to manage their private keys, so I don't know if we can assume that whatever library we prefer will actually be able to access the private key to sign a CSR, which is why I thought it would be useful to support more than one. The purpose of the mapping rule is to tie together the transformation rules that produce the same data into an object that's implementation-agnostic, so that profiles referencing those rules are automatically compatible with all the helper options. I do agree that it would be preferable to target APIs rather than command-line tools. When looking at the openSSL and NSS APIs I came to the conclusion that they would be more difficult than the command-line tools to target, as a first implementation. However, I haven't really looked at python-cryptography, and maybe it would have been a good choice. > > 2) The schema seems unnecessarily complex. I think all we need is a > single new multi-value attribute in certprofile. For your S/MIME > example, it could be something like: > > attr: subjectname=CN={subject.cn},{subject_base} > attr: san_rfc822name={subject.email} > attr: san_directoryname={subject.dn} This is turning out to be a common (and, I think, reasonable) reaction to the proposal. It is rather complex, and I worry that it will be difficult to configure. On the other hand, there is some hidden complexity to enabling a simpler config format, as well. One of the goals of the project as it was presented to me was to allow the creation of profiles that add certificate extensions *that FreeIPA doesn't yet know about*. With the current proposal, one only has to add a rule generating text that the helper will understand. With your suggestion, if there's a mapping between "san_directoryname" and the corresponding API calls or configuration lines, we need some way for users to augment that mapping without changing the code. If there's no mapping, and it's just done with text processing, we need enough in the config format to be able to generate fairly complex structures: builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) builder = builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) and we need to do it without it being equivalent to calling eval() on the config attributes. I'm not sure how to achieve this (is it safe to call getattr(x509, extensiontype)(value) where extensiontype and value are user-specified?) and it definitely would have to be tied to a particular library/tool. Ben > > > Honza > > [1] > > From mbasti at redhat.com Wed Jul 20 14:11:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Jul 2016 16:11:08 +0200 Subject: [Freeipa-devel] [PATCH 0001][Tests] Fix for dns_plugin tests In-Reply-To: <1640445260.22535316.1468943143859.JavaMail.zimbra@redhat.com> References: <1640445260.22535316.1468943143859.JavaMail.zimbra@redhat.com> Message-ID: Hello, On 19.07.2016 17:45, Ganna Kaihorodova wrote: > Greetings! > > Fix for ipatests/test_xmlrpc/test_dns_plugin.py (test_forwardzone_delegation_warnings.test) > > You can't have a DNS zone with the authoritative nameserver that does not have a A or AAAA record in the local DNS. Not true > Since in some test environments primary hostname of the master is managed by an external DNS, this hostname can not be used as a NS-record for IPA-managed zones. Therefore another existing fqdn corresponding to the master's ip and managed by IPA DNS was used. I really don't like using 'ipa-ca.' domain name as server name, this is not right. I was digging deeper today to find what is the root case why it doesn't work, and it looks that after some tests, named is not able to resolve hostname, even if global forwarder is specified. So this looks like bug on named/bind-dyndb-ldap side, because when I restarted named-pkcs11 before the first test that is failing and all forwardzone tests passed. So I think this patch just hides the real issue and we should discard it. I and pspacek will be continue investigating this tomorrow. Notes to the patch format: Please split that huge text in commit message to: short summary (max 72 chars) empty line longer description empty line [ticket (if available)] regars Martin^2 > > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldoudova at redhat.com Wed Jul 20 14:11:44 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 20 Jul 2016 16:11:44 +0200 Subject: [Freeipa-devel] [PATCH 0028][Tests] Fix failing user tests In-Reply-To: References: Message-ID: <35bf9edb-a9ec-8e2f-2285-e12417053e84@redhat.com> On 07/20/2016 02:04 PM, Martin Babinsky wrote: > On 07/15/2016 06:10 PM, Lenka Doudova wrote: >> Hi, >> >> here's patch with fix for failing user tests, specifically tests with >> renaming users. >> >> Failures were caused by RFE Kerberos principal aliases. As part of the >> fix, I had to rewrite few of the tests themselves, since they used >> "--setattr" option rather than "--rename" option, which produces >> different results. >> >> >> Lenka >> >> >> > > Hi Lenka, > > I get nice green *user tests with this patch, so functionally it seems > ok. > > However, the commit message does not meet our project standards[1]: > > 1.) The message summary is very vague, I would rather see something > more specific like: > > """ > Tests: improve the handling of rename operations by user tracker > """ > > 2.) The message itself should be wrapped at the maximum of 78 > character width (IIRC) but your lines are way too long. > > A nice way to automate this in vim is to highlight the text, enter > command mode and run 'gq', that should format the text for you. > > 3.) You did not add upstream ticket URL to the end of the message, > please do so. > > There is also an extraneous whitespace here: > """ > else: > if type(value) is list: > self.attrs[key] = value > else: > self.attrs[key] = [value] > + > for key, value in expected_updates.items(): > if value is None or value is '' or value is u'': > del self.attrs[key] > """ > > that has nothing to do with the scope of the patch. Please remove it. > > [1] http://www.freeipa.org/page/Contribute/Patch_Format > Hi, thanks for review, fixed patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0028.2-Tests-Improve-handling-of-rename-operation-by-user-t.patch Type: text/x-patch Size: 4470 bytes Desc: not available URL: From blipton at redhat.com Wed Jul 20 14:17:20 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 20 Jul 2016 10:17:20 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: <1469010462.21393.47.camel@redhat.com> References: <1469010462.21393.47.camel@redhat.com> Message-ID: On 07/20/2016 06:27 AM, Simo Sorce wrote: > On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: >> Hi, >> >> I have updated the design page >> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generati >> on/Mapping_Rules >> with my plan for implementing user-configurable rules for mapping >> IPA >> data into certificate requests. In brief: we will use Jinja2 for >> templating. Data rules (which map individual data items) and syntax >> rules (which group them into certificate fields) will both be >> snippets >> of Jinja2 markup. The formatting process will be as follows: >> 1. Syntax rules will be rendered using Jinja2. Data rules (rule >> text, >> not rendered) will be passed as the datarules attribute. >> 2. Rendered syntax rules will be processed by the Formatter class >> for >> the selected CSR generation helper (e.g. openssl or certutil). The >> formatter combines these partial rules into a full template for the >> config. >> 3. The template will be rendered using Jinja2. Relevant data from >> the >> IPA database will be available in the context for this rendering. >> 4. The final rendered template will be returned to the caller, >> labeled >> with its function (e.g. a command line or a config file). >> >> Are there any comments or objections to this approach? Here's an >> example >> to show what it might look like in practice. >> >> Example data rules: >> email={{subject.email}} >> O={{config.ipacertificatesubjectbase}}\nCN={{subject.username}} >> >> Example syntax rule: >> subjectAltName=@{% section %}{{datarules|join('\n')}}{% endsection %} >> >> Example composed config template: >> [ req ] >> prompt = no >> encrypt_key = no >> >> distinguished_name = {% section >> %}O={{config.ipacertificatesubjectbase}} >> CN={{subject.username}}{% endsection %} >> >> req_extensions = exts >> >> [ exts ] >> subjectAltName=@{% section %}email={{subject.email}}{% endsection %} >> >> There's a lot more information about the thinking behind this at >> http://blog.benjaminlipton.com/2016/07/19/csr-generation-templating.h >> tml >> if you're interested, as well. > Nice work Ben, > it's been really nice to be able to follow your notes on the blog post, > one question remains lingering in my head, why jinja2 ? > I know that engine relatively well as I used it in ipsilon, so I am not > questioning the choice just asking why specifically jinja2 and not > something else, potentially language agnostic. > > Simo. Honestly, my reasoning didn't go very far beyond that it seems to be widely used and is compatible with python, which is the language where the implementation is taking place (in the IPA RPC server). I thought about using the built-in python format strings or creating a simple domain-specific language, but the likelihood of wanting the built-in text processing features (join, replace, maybe even for loops) seemed high, and I didn't want to reimplement those features. Will the additional package dependency be a problem? Ben From mbasti at redhat.com Wed Jul 20 14:34:26 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Jul 2016 16:34:26 +0200 Subject: [Freeipa-devel] [PATCH 0180] allow multiple dashes in the components of server hostname In-Reply-To: <38e18ae9-f2d9-60f0-1c97-1951652f94fd@redhat.com> References: <38e18ae9-f2d9-60f0-1c97-1951652f94fd@redhat.com> Message-ID: <5fc3c0f8-83d4-8418-6691-a777bb0036b1@redhat.com> On 04.07.2016 12:54, Martin Babinsky wrote: > The PKI bug preventing use of multiple dashes in hostnames [1] was > already fixed. We may now relax our own syntax constraints. > > https://fedorahosted.org/freeipa/ticket/4710 > > [1] https://fedorahosted.org/pki/ticket/1260 > > > ACK Pushed to master: 15cfd0ee20fd05735473d3677b6f9f349339197e -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Jul 20 14:37:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Jul 2016 16:37:02 +0200 Subject: [Freeipa-devel] [PATCH] 0011 server uninstall fails to remove krb principals In-Reply-To: <0365c57c-b6df-ac35-3d45-be0fe2100b0b@redhat.com> References: <0365c57c-b6df-ac35-3d45-be0fe2100b0b@redhat.com> Message-ID: <290b00b7-bc94-1d68-2c49-118522b30371@redhat.com> On 19.07.2016 12:56, Petr Vobornik wrote: > On 07/11/2016 09:52 AM, Florence Blanc-Renaud wrote: >> Hi, >> >> please find a patch for the 3rd issue of ticket 6012. >> >> https://fedorahosted.org/freeipa/ticket/6012 >> >> > bump for review > ACK Pushed to master: a0d90263d62f48f0c04b8b9e7da3aaa10201c3a0 From simo at redhat.com Wed Jul 20 14:37:07 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 20 Jul 2016 10:37:07 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: References: <1469010462.21393.47.camel@redhat.com> Message-ID: <1469025427.21393.51.camel@redhat.com> On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: > On 07/20/2016 06:27 AM, Simo Sorce wrote: > > > > On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: > > > > > > Hi, > > > > > > I have updated the design page > > > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Gene > > > rati > > > on/Mapping_Rules > > > with my plan for implementing user-configurable rules for mapping > > > IPA > > > data into certificate requests. In brief: we will use Jinja2 for > > > templating. Data rules (which map individual data items) and > > > syntax > > > rules (which group them into certificate fields) will both be > > > snippets > > > of Jinja2 markup. The formatting process will be as follows: > > > 1. Syntax rules will be rendered using Jinja2. Data rules (rule > > > text, > > > not rendered) will be passed as the datarules attribute. > > > 2. Rendered syntax rules will be processed by the Formatter class > > > for > > > the selected CSR generation helper (e.g. openssl or certutil). > > > The > > > formatter combines these partial rules into a full template for > > > the > > > config. > > > 3. The template will be rendered using Jinja2. Relevant data from > > > the > > > IPA database will be available in the context for this rendering. > > > 4. The final rendered template will be returned to the caller, > > > labeled > > > with its function (e.g. a command line or a config file). > > > > > > Are there any comments or objections to this approach? Here's an > > > example > > > to show what it might look like in practice. > > > > > > Example data rules: > > > email={{subject.email}} > > > O={{config.ipacertificatesubjectbase}}\nCN={{subject.username}} > > > > > > Example syntax rule: > > > subjectAltName=@{% section %}{{datarules|join('\n')}}{% > > > endsection %} > > > > > > Example composed config template: > > > [ req ] > > > prompt = no > > > encrypt_key = no > > > > > > distinguished_name = {% section > > > %}O={{config.ipacertificatesubjectbase}} > > > CN={{subject.username}}{% endsection %} > > > > > > req_extensions = exts > > > > > > [ exts ] > > > subjectAltName=@{% section %}email={{subject.email}}{% endsection > > > %} > > > > > > There's a lot more information about the thinking behind this at > > > http://blog.benjaminlipton.com/2016/07/19/csr-generation-templati > > > ng.h > > > tml > > > if you're interested, as well. > > Nice work Ben, > > it's been really nice to be able to follow your notes on the blog > > post, > > one question remains lingering in my head, why jinja2 ? > > I know that engine relatively well as I used it in ipsilon, so I am > > not > > questioning the choice just asking why specifically jinja2 and not > > something else, potentially language agnostic. > > > > Simo. > Honestly, my reasoning didn't go very far beyond that it seems to be? > widely used and is compatible with python, which is the language > where? > the implementation is taking place (in the IPA RPC server). I > thought? > about using the built-in python format strings or creating a simple? > domain-specific language, but the likelihood of wanting the built-in? > text processing features (join, replace, maybe even for loops) > seemed? > high, and I didn't want to reimplement those features. > > Will the additional package dependency be a problem? I am more concerned a out the ability to process the data (which I guess is stored in LDAP) by another client, or in the CLI. Other than that the dependency does not concern me too much provided jinja2 templating is stable and has some guarantee that it will be supportable long term. If that is not guaranteed it is a problem, we cannot easily swap out one language for another once data is stored and used by the server. So the most important consideration for me is whether we are locking ourselves into something that will be hard to deal with later or not. Should the jinja2 project fail by the wayside next year would we be able to easily replace it with another engine without changing the templates as stored ? Simo. From pvomacka at redhat.com Wed Jul 20 14:43:46 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 20 Jul 2016 16:43:46 +0200 Subject: [Freeipa-devel] [PATCH] webui test: bunch of patches which fix webui patches In-Reply-To: <91f807de-949c-bac2-8028-35e57a929081@redhat.com> References: <91f807de-949c-bac2-8028-35e57a929081@redhat.com> Message-ID: <31a0668d-0f0e-062f-39b9-ac50fc623bf9@redhat.com> On 07/11/2016 06:33 PM, Pavel Vomacka wrote: > Hello, > > please review these patches. First four of them fixes patches and the > last one fixes small bug in WebUI which causes that some tests fail. > > https://fedorahosted.org/freeipa/ticket/6050 > > https://fedorahosted.org/freeipa/ticket/6052 > > https://fedorahosted.org/freeipa/ticket/6053 > > https://fedorahosted.org/freeipa/ticket/6054 > > > > 4 patches have incorrect information about user who makes the patch. Sending new patches which correct it. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0074-2-Remove-navigation-using-breadcrumb-menus.patch Type: text/x-patch Size: 1443 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0075-2-Fix-test_navigation-tests.patch Type: text/x-patch Size: 1757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0076-2-Fix-test-which-checks-removing-of-user.patch Type: text/x-patch Size: 1041 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0077-2-Set-default-delete-action-name-to-delete.patch Type: text/x-patch Size: 1442 bytes Desc: not available URL: From pvomacka at redhat.com Wed Jul 20 14:51:00 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 20 Jul 2016 16:51:00 +0200 Subject: [Freeipa-devel] [PATCH] 0078-82: webui tests: tests for new certificate widget Message-ID: <3e447bbe-fade-c5e5-2415-15ed7ae0b2ea@redhat.com> Please review attached patches, which add tests for new certificate widget in WebUI. https://fedorahosted.org/freeipa/ticket/6064 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0078-Add-possibility-to-choose-parent-element-by-css.patch Type: text/x-patch Size: 3966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0079-Add-function-which-check-whether-the-field-is-empty.patch Type: text/x-patch Size: 1214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0080-TEST-managing-user-certificates.patch Type: text/x-patch Size: 4961 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0081-TEST-managing-host-certificates.patch Type: text/x-patch Size: 8197 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0082-TEST-managing-service-certificates.patch Type: text/x-patch Size: 8645 bytes Desc: not available URL: From gkaihoro at redhat.com Wed Jul 20 15:02:03 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Wed, 20 Jul 2016 11:02:03 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests In-Reply-To: <865052616.23181284.1469026816515.JavaMail.zimbra@redhat.com> Message-ID: <1812744576.23182071.1469026923069.JavaMail.zimbra@redhat.com> Greetings! Fix for ipatests/test_xmlrpc/test_dns_plugin.py Fix conflict between ?got? and ?expected? values when testing "dnsconfig_mod: Update global DNS settings" Best regards, Ganna Kaihorodova Associate Software Quality Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-gkaihoro-0002-Fix-conflict-between-got-and-expected-values.patch Type: text/x-patch Size: 1436 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 20 15:04:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Jul 2016 17:04:47 +0200 Subject: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests In-Reply-To: <1812744576.23182071.1469026923069.JavaMail.zimbra@redhat.com> References: <1812744576.23182071.1469026923069.JavaMail.zimbra@redhat.com> Message-ID: On 20.07.2016 17:02, Ganna Kaihorodova wrote: > Greetings! > > Fix for ipatests/test_xmlrpc/test_dns_plugin.py > > Fix conflict between ?got? and ?expected? values when testing "dnsconfig_mod: Update global DNS settings" > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > > LGTM, but can you fix commit message? This looks very suspicious Subject: [PATCH 2/2] =?UTF-8?q?Fix=20conflict=20between=20=E2=80=9Cgot?= =?UTF-8?q?=E2=80=9D=20and=20=E2=80=9Cexpected=E2=80=9D=20values=20when=20?= =?UTF-8?q?testing=20"dnsconfig=5Fmod:=20Update=20global=20DNS=20settings"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit regards, Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From placko at redhat.com Wed Jul 20 15:31:00 2016 From: placko at redhat.com (Peter Lacko) Date: Wed, 20 Jul 2016 11:31:00 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 0002 New User Role Tests In-Reply-To: <8b36b91f-b93d-c1d8-0bab-7022b7f29949@redhat.com> References: <1698677244.50966760.1462789150686.JavaMail.zimbra@redhat.com> <19bc3a86-8e60-f023-6bab-b807a3d03364@redhat.com> <651798515.57202911.1464860977307.JavaMail.zimbra@redhat.com> <479389298.57290567.1464876990869.JavaMail.zimbra@redhat.com> <8b36b91f-b93d-c1d8-0bab-7022b7f29949@redhat.com> Message-ID: <1797731925.7831984.1469028660649.JavaMail.zimbra@redhat.com> Sorry for late reply, I was waiting how the discussion with tracker improvement will end, but since there's no progress and I'm leaving soon, I'm attaching new patch. I also created mapping between old and new tests [1], to make life of reviewer easier. Number in first column denotes line number in original file, followed by line number in new tests file and its name. Tests that are not mentioned in there extend previous coverage. Regards, Peter [1] http://etherpad.corp.redhat.com/Vk3tRLaPSK ----- Original Message ----- From: "Martin Basti" To: "Peter Lacko" Cc: freeipa-devel at redhat.com Sent: Monday, June 6, 2016 12:29:29 PM Subject: Re: [Freeipa-devel] [PATCH] 0002 New User Role Tests On 02.06.2016 16:16, Peter Lacko wrote: > Rebased with updated tests. > > Peter > > ----- Original Message ----- > From: "Martin Basti" > To: "Peter Lacko" > Cc: freeipa-devel at redhat.com > Sent: Thursday, June 2, 2016 1:50:06 PM > Subject: Re: [Freeipa-devel] [PATCH] 0002 New User Role Tests > > Your patch doesn't apply anymore on master, there were changes in role > test and patch have to be updated and rebased > > Please look at this for new changes in test_role_plugin.py > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=5f42b42bd4557a669ab5cfcf1af6596f1a2535f1 > > Martin^2 > > > On 02.06.2016 11:49, Peter Lacko wrote: >> Sorry for late response, I wasn't working these days. >> Fixed patch is in attachment. >> >> Peter >> >> >> ----- Original Message ----- >> From: "Martin Basti" >> To: "Peter Lacko" , freeipa-devel at redhat.com >> Sent: Monday, May 9, 2016 1:06:08 PM >> Subject: Re: [Freeipa-devel] [PATCH] 0002 New User Role Tests >> >> >> >> On 09.05.2016 13:04, Martin Basti wrote: >>> On 09.05.2016 12:19, Peter Lacko wrote: >>>> +# pylint: disable=unicode-builtin >>> I'm not doing complete review, just the line above hit my eyes. >>> >>> unicode() is not in Py3 because all strings there are unicode, thus >>> you cannot use it directly, you need something like >>> >>> if six.PY2: >>> str = unicode >>> >>> and use str() everywhere and remove that #pylint line >>> >>> FYI all enabled pylint checks are there for a good reason, be careful >>> with disabling it (mainly disabling it for a whole module) rather ask >>> before if you are not sure. >>> >>> Martin^2 >>> >> Nope, sorry, I temporarily forgot how to python >> >> instead of pylint disable use this >> >> if six.PY3: >> unicode =str >> >> and keep unicode there. Sorry >> >> Martin^2 Hi, I don't have time to continue with full review, maybe somebody else can continue instead of me, but anyway NACK, because using str(unicode()) or unicode(str()) is bad in both ways, it should be just unicode() in case of strings (with correct mapping unicode=str in Py3). I just I noticed this by reading code, but I didn't do deeper review, so there might be more mistakes. Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-placko-0002-4-New-User-Role-Tests.patch Type: text/x-patch Size: 75002 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 20 15:41:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Jul 2016 17:41:49 +0200 Subject: [Freeipa-devel] [PATCH 0553] CI tests: improve log collecting in tests In-Reply-To: <21a9655a-3943-67ac-3a8f-0a81dae37de3@redhat.com> References: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> <21a9655a-3943-67ac-3a8f-0a81dae37de3@redhat.com> Message-ID: <2dc7f75b-c0c4-e656-0cff-359696e2d05c@redhat.com> On 19.07.2016 17:05, Martin Basti wrote: > > > > On 19.07.2016 16:18, Martin Basti wrote: >> Patch attached. >> >> >> > self-NACK, my assumptions were wrong, this doesn't work if any of log > files do not exist > > updated patches attached Please note, that in case that any logfile does not exist tar returns exit code 2, but provides correct output anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0553.2-CI-tests-improve-log-collecting.patch Type: text/x-patch Size: 4872 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0554.2-CI-tests-fix-SSSD-log-collecting.patch Type: text/x-patch Size: 1064 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Jul 20 16:11:19 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 20 Jul 2016 18:11:19 +0200 Subject: [Freeipa-devel] [PATCH 0028][Tests] Fix failing user tests In-Reply-To: <35bf9edb-a9ec-8e2f-2285-e12417053e84@redhat.com> References: <35bf9edb-a9ec-8e2f-2285-e12417053e84@redhat.com> Message-ID: On 07/20/2016 04:11 PM, Lenka Doudova wrote: > > > On 07/20/2016 02:04 PM, Martin Babinsky wrote: >> On 07/15/2016 06:10 PM, Lenka Doudova wrote: >>> Hi, >>> >>> here's patch with fix for failing user tests, specifically tests with >>> renaming users. >>> >>> Failures were caused by RFE Kerberos principal aliases. As part of the >>> fix, I had to rewrite few of the tests themselves, since they used >>> "--setattr" option rather than "--rename" option, which produces >>> different results. >>> >>> >>> Lenka >>> >>> >>> >> >> Hi Lenka, >> >> I get nice green *user tests with this patch, so functionally it seems >> ok. >> >> However, the commit message does not meet our project standards[1]: >> >> 1.) The message summary is very vague, I would rather see something >> more specific like: >> >> """ >> Tests: improve the handling of rename operations by user tracker >> """ >> >> 2.) The message itself should be wrapped at the maximum of 78 >> character width (IIRC) but your lines are way too long. >> >> A nice way to automate this in vim is to highlight the text, enter >> command mode and run 'gq', that should format the text for you. >> >> 3.) You did not add upstream ticket URL to the end of the message, >> please do so. >> >> There is also an extraneous whitespace here: >> """ >> else: >> if type(value) is list: >> self.attrs[key] = value >> else: >> self.attrs[key] = [value] >> + >> for key, value in expected_updates.items(): >> if value is None or value is '' or value is u'': >> del self.attrs[key] >> """ >> >> that has nothing to do with the scope of the patch. Please remove it. >> >> [1] http://www.freeipa.org/page/Contribute/Patch_Format >> > Hi, > > thanks for review, fixed patch attached. > > Lenka Thanks, ACK. Pushed to master: 9093647f867e49bffc9042185b1765b48fe7400a -- Martin^3 Babinsky From blipton at redhat.com Wed Jul 20 16:14:03 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 20 Jul 2016 12:14:03 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: <1469025427.21393.51.camel@redhat.com> References: <1469010462.21393.47.camel@redhat.com> <1469025427.21393.51.camel@redhat.com> Message-ID: <514956a4-14f7-5816-23cd-d1ce1e3d28fa@redhat.com> On 07/20/2016 10:37 AM, Simo Sorce wrote: > On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: >> On 07/20/2016 06:27 AM, Simo Sorce wrote: >>> On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: >>>> Hi, >>>> >>>> I have updated the design page >>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Gene >>>> rati >>>> on/Mapping_Rules >>>> with my plan for implementing user-configurable rules for mapping >>>> IPA >>>> data into certificate requests. In brief: we will use Jinja2 for >>>> templating. Data rules (which map individual data items) and >>>> syntax >>>> rules (which group them into certificate fields) will both be >>>> snippets >>>> of Jinja2 markup. The formatting process will be as follows: >>>> 1. Syntax rules will be rendered using Jinja2. Data rules (rule >>>> text, >>>> not rendered) will be passed as the datarules attribute. >>>> 2. Rendered syntax rules will be processed by the Formatter class >>>> for >>>> the selected CSR generation helper (e.g. openssl or certutil). >>>> The >>>> formatter combines these partial rules into a full template for >>>> the >>>> config. >>>> 3. The template will be rendered using Jinja2. Relevant data from >>>> the >>>> IPA database will be available in the context for this rendering. >>>> 4. The final rendered template will be returned to the caller, >>>> labeled >>>> with its function (e.g. a command line or a config file). >>>> >>>> Are there any comments or objections to this approach? Here's an >>>> example >>>> to show what it might look like in practice. >>>> >>>> Example data rules: >>>> email={{subject.email}} >>>> O={{config.ipacertificatesubjectbase}}\nCN={{subject.username}} >>>> >>>> Example syntax rule: >>>> subjectAltName=@{% section %}{{datarules|join('\n')}}{% >>>> endsection %} >>>> >>>> Example composed config template: >>>> [ req ] >>>> prompt = no >>>> encrypt_key = no >>>> >>>> distinguished_name = {% section >>>> %}O={{config.ipacertificatesubjectbase}} >>>> CN={{subject.username}}{% endsection %} >>>> >>>> req_extensions = exts >>>> >>>> [ exts ] >>>> subjectAltName=@{% section %}email={{subject.email}}{% endsection >>>> %} >>>> >>>> There's a lot more information about the thinking behind this at >>>> http://blog.benjaminlipton.com/2016/07/19/csr-generation-templati >>>> ng.h >>>> tml >>>> if you're interested, as well. >>> Nice work Ben, >>> it's been really nice to be able to follow your notes on the blog >>> post, >>> one question remains lingering in my head, why jinja2 ? >>> I know that engine relatively well as I used it in ipsilon, so I am >>> not >>> questioning the choice just asking why specifically jinja2 and not >>> something else, potentially language agnostic. >>> >>> Simo. >> Honestly, my reasoning didn't go very far beyond that it seems to be >> widely used and is compatible with python, which is the language >> where >> the implementation is taking place (in the IPA RPC server). I >> thought >> about using the built-in python format strings or creating a simple >> domain-specific language, but the likelihood of wanting the built-in >> text processing features (join, replace, maybe even for loops) >> seemed >> high, and I didn't want to reimplement those features. >> >> Will the additional package dependency be a problem? > I am more concerned a out the ability to process the data (which I > guess is stored in LDAP) by another client, or in the CLI. > Other than that the dependency does not concern me too much provided > jinja2 templating is stable and has some guarantee that it will be > supportable long term. > > If that is not guaranteed it is a problem, we cannot easily swap out > one language for another once data is stored and used by the server. > So the most important consideration for me is whether we are locking > ourselves into something that will be hard to deal with later or not. > > Should the jinja2 project fail by the wayside next year would we be > able to easily replace it with another engine without changing the > templates as stored ? > > Simo. > Ah, ok, I understand the concern. For now, the plan is that the server will do all the text processing, so I don't really forsee a need for any other client to read the mapping rules from LDAP. However, it's true that templates written in jinja2 would probably need at least minor changes to be compatible with another templating engine. (Same goes for any other choice - a lot of these engines seem to have very similar, but not exactly compatible, syntax). I don't really know how to judge the long-term viability of the jinja2 project, though it seems to be recognized by lots of projects (ansible[1], openstack[2], flask[3], even django[4] which has its own templating engine). In any case, if the team prefers it, I'd be comfortable going with a more minimal DSL that only has the features we know we need. It might slightly limit the types of certs that can be generated, but that can be iterated on. But it would be another thing to design, build and maintain. Let me know what you think. Ben [1] http://docs.ansible.com/ansible/playbooks_variables.html#using-variables-about-jinja2 [2] http://lists.openstack.org/pipermail/openstack-dev/2013-July/012016.html [3] http://flask.pocoo.org/docs/0.11/templating/ [4] https://docs.djangoproject.com/en/1.9/topics/templates/#django.template.backends.jinja2.Jinja2 From gkaihoro at redhat.com Wed Jul 20 16:17:39 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Wed, 20 Jul 2016 12:17:39 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests In-Reply-To: References: <1812744576.23182071.1469026923069.JavaMail.zimbra@redhat.com> Message-ID: <536349855.23231759.1469031459952.JavaMail.zimbra@redhat.com> Hello! Thank you for review. I attached patch with fixed commit message Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Martin Basti" To: "Ganna Kaihorodova" , freeipa-devel at redhat.com Sent: Wednesday, July 20, 2016 5:04:47 PM Subject: Re: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests On 20.07.2016 17:02, Ganna Kaihorodova wrote: > Greetings! > > Fix for ipatests/test_xmlrpc/test_dns_plugin.py > > Fix conflict between ?got? and ?expected? values when testing "dnsconfig_mod: Update global DNS settings" > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > > LGTM, but can you fix commit message? This looks very suspicious Subject: [PATCH 2/2] =?UTF-8?q?Fix=20conflict=20between=20=E2=80=9Cgot?= =?UTF-8?q?=E2=80=9D=20and=20=E2=80=9Cexpected=E2=80=9D=20values=20when=20?= =?UTF-8?q?testing=20"dnsconfig=5Fmod:=20Update=20global=20DNS=20settings"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit regards, Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-gkaihoro-0002-Fix-conflict-between-got-and-expected-values.patch Type: text/x-patch Size: 1312 bytes Desc: not available URL: From simo at redhat.com Wed Jul 20 16:21:36 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 20 Jul 2016 12:21:36 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: <514956a4-14f7-5816-23cd-d1ce1e3d28fa@redhat.com> References: <1469010462.21393.47.camel@redhat.com> <1469025427.21393.51.camel@redhat.com> <514956a4-14f7-5816-23cd-d1ce1e3d28fa@redhat.com> Message-ID: <1469031696.21393.55.camel@redhat.com> On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote: > On 07/20/2016 10:37 AM, Simo Sorce wrote: > > > > On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: > > > > > > On 07/20/2016 06:27 AM, Simo Sorce wrote: > > > > > > > > On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: > > > > > > > > > > Hi, > > > > > > > > > > I have updated the design page > > > > > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_ > > > > > Gene > > > > > rati > > > > > on/Mapping_Rules > > > > > with my plan for implementing user-configurable rules for > > > > > mapping > > > > > IPA > > > > > data into certificate requests. In brief: we will use Jinja2 > > > > > for > > > > > templating. Data rules (which map individual data items) and > > > > > syntax > > > > > rules (which group them into certificate fields) will both be > > > > > snippets > > > > > of Jinja2 markup. The formatting process will be as follows: > > > > > 1. Syntax rules will be rendered using Jinja2. Data rules > > > > > (rule > > > > > text, > > > > > not rendered) will be passed as the datarules attribute. > > > > > 2. Rendered syntax rules will be processed by the Formatter > > > > > class > > > > > for > > > > > the selected CSR generation helper (e.g. openssl or > > > > > certutil). > > > > > The > > > > > formatter combines these partial rules into a full template > > > > > for > > > > > the > > > > > config. > > > > > 3. The template will be rendered using Jinja2. Relevant data > > > > > from > > > > > the > > > > > IPA database will be available in the context for this > > > > > rendering. > > > > > 4. The final rendered template will be returned to the > > > > > caller, > > > > > labeled > > > > > with its function (e.g. a command line or a config file). > > > > > > > > > > Are there any comments or objections to this approach? Here's > > > > > an > > > > > example > > > > > to show what it might look like in practice. > > > > > > > > > > Example data rules: > > > > > email={{subject.email}} > > > > > O={{config.ipacertificatesubjectbase}}\nCN={{subject.username > > > > > }} > > > > > > > > > > Example syntax rule: > > > > > subjectAltName=@{% section %}{{datarules|join('\n')}}{% > > > > > endsection %} > > > > > > > > > > Example composed config template: > > > > > [ req ] > > > > > prompt = no > > > > > encrypt_key = no > > > > > > > > > > distinguished_name = {% section > > > > > %}O={{config.ipacertificatesubjectbase}} > > > > > CN={{subject.username}}{% endsection %} > > > > > > > > > > req_extensions = exts > > > > > > > > > > [ exts ] > > > > > subjectAltName=@{% section %}email={{subject.email}}{% > > > > > endsection > > > > > %} > > > > > > > > > > There's a lot more information about the thinking behind this > > > > > at > > > > > http://blog.benjaminlipton.com/2016/07/19/csr-generation-temp > > > > > lati > > > > > ng.h > > > > > tml > > > > > if you're interested, as well. > > > > Nice work Ben, > > > > it's been really nice to be able to follow your notes on the > > > > blog > > > > post, > > > > one question remains lingering in my head, why jinja2 ? > > > > I know that engine relatively well as I used it in ipsilon, so > > > > I am > > > > not > > > > questioning the choice just asking why specifically jinja2 and > > > > not > > > > something else, potentially language agnostic. > > > > > > > > Simo. > > > Honestly, my reasoning didn't go very far beyond that it seems to > > > be > > > widely used and is compatible with python, which is the language > > > where > > > the implementation is taking place (in the IPA RPC server). I > > > thought > > > about using the built-in python format strings or creating a > > > simple > > > domain-specific language, but the likelihood of wanting the > > > built-in > > > text processing features (join, replace, maybe even for loops) > > > seemed > > > high, and I didn't want to reimplement those features. > > > > > > Will the additional package dependency be a problem? > > I am more concerned a out the ability to process the data (which I > > guess is stored in LDAP) by another client, or in the CLI. > > Other than that the dependency does not concern me too much > > provided > > jinja2 templating is stable and has some guarantee that it will be > > supportable long term. > > > > If that is not guaranteed it is a problem, we cannot easily swap > > out > > one language for another once data is stored and used by the > > server. > > So the most important consideration for me is whether we are > > locking > > ourselves into something that will be hard to deal with later or > > not. > > > > Should the jinja2 project fail by the wayside next year would we be > > able to easily replace it with another engine without changing the > > templates as stored ? > > > > Simo. > > > Ah, ok, I understand the concern. For now, the plan is that the > server? > will do all the text processing, so I don't really forsee a need for > any? > other client to read the mapping rules from LDAP. However, it's true? > that templates written in jinja2 would probably need at least minor? > changes to be compatible with another templating engine. (Same goes > for? > any other choice - a lot of these engines seem to have very similar, > but? > not exactly compatible, syntax). I don't really know how to judge > the? > long-term viability of the jinja2 project, though it seems to be? > recognized by lots of projects (ansible[1], openstack[2], flask[3], > even? > django[4] which has its own templating engine). > > In any case, if the team prefers it, I'd be comfortable going with a? > more minimal DSL that only has the features we know we need. It > might? > slightly limit the types of certs that can be generated, but that can > be? > iterated on. But it would be another thing to design, build and? > maintain. Let me know what you think. I am ok using jinja2 as long as we realize we may be on the hook for maintaining it ourselves in the long term. It's probably easier to do that than to write our own anyway. Simo. > Ben > > [1]? > http://docs.ansible.com/ansible/playbooks_variables.html#using-variab > les-about-jinja2 > [2] http://lists.openstack.org/pipermail/openstack-dev/2013-July/0120 > 16.html > [3] http://flask.pocoo.org/docs/0.11/templating/ > [4]? > https://docs.djangoproject.com/en/1.9/topics/templates/#django.templa > te.backends.jinja2.Jinja2 From blipton at redhat.com Wed Jul 20 17:25:15 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 20 Jul 2016 13:25:15 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: <1469031696.21393.55.camel@redhat.com> References: <1469010462.21393.47.camel@redhat.com> <1469025427.21393.51.camel@redhat.com> <514956a4-14f7-5816-23cd-d1ce1e3d28fa@redhat.com> <1469031696.21393.55.camel@redhat.com> Message-ID: On 07/20/2016 12:21 PM, Simo Sorce wrote: > On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote: >> On 07/20/2016 10:37 AM, Simo Sorce wrote: >>> On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: >>>> On 07/20/2016 06:27 AM, Simo Sorce wrote: >>>>> On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: >>>>>> Hi, >>>>>> >>>>>> I have updated the design page >>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_ >>>>>> Gene >>>>>> rati >>>>>> on/Mapping_Rules >>>>>> with my plan for implementing user-configurable rules for >>>>>> mapping >>>>>> IPA >>>>>> data into certificate requests. In brief: we will use Jinja2 >>>>>> for >>>>>> templating. Data rules (which map individual data items) and >>>>>> syntax >>>>>> rules (which group them into certificate fields) will both be >>>>>> snippets >>>>>> of Jinja2 markup. The formatting process will be as follows: >>>>>> 1. Syntax rules will be rendered using Jinja2. Data rules >>>>>> (rule >>>>>> text, >>>>>> not rendered) will be passed as the datarules attribute. >>>>>> 2. Rendered syntax rules will be processed by the Formatter >>>>>> class >>>>>> for >>>>>> the selected CSR generation helper (e.g. openssl or >>>>>> certutil). >>>>>> The >>>>>> formatter combines these partial rules into a full template >>>>>> for >>>>>> the >>>>>> config. >>>>>> 3. The template will be rendered using Jinja2. Relevant data >>>>>> from >>>>>> the >>>>>> IPA database will be available in the context for this >>>>>> rendering. >>>>>> 4. The final rendered template will be returned to the >>>>>> caller, >>>>>> labeled >>>>>> with its function (e.g. a command line or a config file). >>>>>> >>>>>> Are there any comments or objections to this approach? Here's >>>>>> an >>>>>> example >>>>>> to show what it might look like in practice. >>>>>> >>>>>> Example data rules: >>>>>> email={{subject.email}} >>>>>> O={{config.ipacertificatesubjectbase}}\nCN={{subject.username >>>>>> }} >>>>>> >>>>>> Example syntax rule: >>>>>> subjectAltName=@{% section %}{{datarules|join('\n')}}{% >>>>>> endsection %} >>>>>> >>>>>> Example composed config template: >>>>>> [ req ] >>>>>> prompt = no >>>>>> encrypt_key = no >>>>>> >>>>>> distinguished_name = {% section >>>>>> %}O={{config.ipacertificatesubjectbase}} >>>>>> CN={{subject.username}}{% endsection %} >>>>>> >>>>>> req_extensions = exts >>>>>> >>>>>> [ exts ] >>>>>> subjectAltName=@{% section %}email={{subject.email}}{% >>>>>> endsection >>>>>> %} >>>>>> >>>>>> There's a lot more information about the thinking behind this >>>>>> at >>>>>> http://blog.benjaminlipton.com/2016/07/19/csr-generation-temp >>>>>> lati >>>>>> ng.h >>>>>> tml >>>>>> if you're interested, as well. >>>>> Nice work Ben, >>>>> it's been really nice to be able to follow your notes on the >>>>> blog >>>>> post, >>>>> one question remains lingering in my head, why jinja2 ? >>>>> I know that engine relatively well as I used it in ipsilon, so >>>>> I am >>>>> not >>>>> questioning the choice just asking why specifically jinja2 and >>>>> not >>>>> something else, potentially language agnostic. >>>>> >>>>> Simo. >>>> Honestly, my reasoning didn't go very far beyond that it seems to >>>> be >>>> widely used and is compatible with python, which is the language >>>> where >>>> the implementation is taking place (in the IPA RPC server). I >>>> thought >>>> about using the built-in python format strings or creating a >>>> simple >>>> domain-specific language, but the likelihood of wanting the >>>> built-in >>>> text processing features (join, replace, maybe even for loops) >>>> seemed >>>> high, and I didn't want to reimplement those features. >>>> >>>> Will the additional package dependency be a problem? >>> I am more concerned a out the ability to process the data (which I >>> guess is stored in LDAP) by another client, or in the CLI. >>> Other than that the dependency does not concern me too much >>> provided >>> jinja2 templating is stable and has some guarantee that it will be >>> supportable long term. >>> >>> If that is not guaranteed it is a problem, we cannot easily swap >>> out >>> one language for another once data is stored and used by the >>> server. >>> So the most important consideration for me is whether we are >>> locking >>> ourselves into something that will be hard to deal with later or >>> not. >>> >>> Should the jinja2 project fail by the wayside next year would we be >>> able to easily replace it with another engine without changing the >>> templates as stored ? >>> >>> Simo. >>> >> Ah, ok, I understand the concern. For now, the plan is that the >> server >> will do all the text processing, so I don't really forsee a need for >> any >> other client to read the mapping rules from LDAP. However, it's true >> that templates written in jinja2 would probably need at least minor >> changes to be compatible with another templating engine. (Same goes >> for >> any other choice - a lot of these engines seem to have very similar, >> but >> not exactly compatible, syntax). I don't really know how to judge >> the >> long-term viability of the jinja2 project, though it seems to be >> recognized by lots of projects (ansible[1], openstack[2], flask[3], >> even >> django[4] which has its own templating engine). >> >> In any case, if the team prefers it, I'd be comfortable going with a >> more minimal DSL that only has the features we know we need. It >> might >> slightly limit the types of certs that can be generated, but that can >> be >> iterated on. But it would be another thing to design, build and >> maintain. Let me know what you think. > I am ok using jinja2 as long as we realize we may be on the hook for > maintaining it ourselves in the long term. It's probably easier to do > that than to write our own anyway. > > Simo. It might also be worth pointing out that although the examples in the document are based on jinja2, the overall approach should be pretty compatible with other (existing or custom) template languages. So we're not locked into jinja2 in that way, it's just the rules in deployed databases that would be tough to convert. Thanks for reading and commenting! Ben From jcholast at redhat.com Thu Jul 21 08:12:31 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Jul 2016 10:12:31 +0200 Subject: [Freeipa-devel] [PATCH 0112-7] Speeding up cli help In-Reply-To: References: <2f8df4f1-bf3e-d6fe-96d4-dbacdc9045bb@redhat.com> Message-ID: <01ff40a4-b964-4f78-33dd-f1c92c490fdd@redhat.com> Hi, On 20.7.2016 14:32, David Kupka wrote: > On 15/07/16 12:53, David Kupka wrote: >> Hello! >> >> After Honza introduced thin client that builds plugins and commands >> dynamically from schema client became much slower. This is only logical, >> instead of importing a module client now must fetch the schema from >> server, parse it and instantiate the commands using the data. >> >> First step to speed it up was addition of schema cache to client. That >> removed the RTT and download time of fetching schema every time. >> >> Now the most time consuming task became displaying help for lists of >> topics and command and displaying individual topics. This is simply >> because of the need to instantiate all the commands to find the >> relations between topics and commands. >> >> All the necessary bits for server commands and topics are already in the >> schema cache so we can skip this part and generate help from it, right? >> Not so fast! >> >> There are client plugins with commands and topics. So we can generate >> basic bits (list of all topics, list of all commands, list of commands >> for each topic) from schema and store it in cache. Then we need to go >> through all client plugins and get similar bits for client plugins. Then >> we can merge and print. >> >> Still the client response is not as fast as before and I this it even >> can't be. Also first time you display particular topic or list takes >> longer because it must be freshly generated and stored in cache for next >> use. And this is what the attached patches do. >> >> https://fedorahosted.org/freeipa/ticket/6048 > > Reimplemented so there is no need to distinguish client plugins and > remote plugins. > The main idea of this approach is to avoid creating instances of the > commands just to get the information about topic, name and summary > needed for displaying help. Instead class properties are used to access > the information directly in schema. Patch 0112: I think this would better be done in Schema.read_namespace_member, because Schema is where all the state is. (BTW does _SchemaNameSpace.__getitem__ raise KeyError for non-existent keys? It looks like it doesn't.) Patch 0113: How about setting _schema_cached to False in Schema.__init__() rather that getattr()-ing it in _ensure_cached()? Patch 0116: ClientCommand.doc should be a class property as well, otherwise .summary won't work on it correctly. _SchemaCommand.doc should not be a property, as it's not needed for .summary to work on it correctly. Otherwise works fine for me. Honza -- Jan Cholasta From mbabinsk at redhat.com Thu Jul 21 08:13:35 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Jul 2016 10:13:35 +0200 Subject: [Freeipa-devel] [PATCH 190] expose `--secret` option in radiusproxy-* commands In-Reply-To: <0fb7c740-d932-3e77-87fd-4a91dbef71f4@redhat.com> References: <4619e944-47d6-e181-c42d-073f479d4f85@redhat.com> <0fb7c740-d932-3e77-87fd-4a91dbef71f4@redhat.com> Message-ID: On 07/20/2016 12:10 PM, Martin Babinsky wrote: > On 07/19/2016 12:32 PM, Jan Cholasta wrote: >> Hi, >> >> On 18.7.2016 13:51, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/6078 >> >> I don't think we want the secret searchable. Add a 'no_search' flag to >> the param to fix that. >> >> Honza >> > > 'no_search' flag breaks the API backwards compatibility, so I am sending > another two patches which fix handling of deprecated options in the > framework and deprecate `--secret` in radiusproxy-find command. > > I hope this solution is the best. > > > After discussion with Jan we realized that it is enough to hide the '--secret' option from CLI, not deprecate it. Re-sending patch 190 and updated 193.1. Patch 192 will be send in separate thread since the actual issue it fixes is orthogonal to this one and requires a separate ticket. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0190-expose-secret-option-in-radiusproxy-commands.patch Type: text/x-patch Size: 1147 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0193.1-prevent-search-for-RADIUS-proxy-servers-by-secret.patch Type: text/x-patch Size: 1256 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 21 08:50:14 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Jul 2016 10:50:14 +0200 Subject: [Freeipa-devel] [PATCH 190] expose `--secret` option in radiusproxy-* commands In-Reply-To: References: <4619e944-47d6-e181-c42d-073f479d4f85@redhat.com> <0fb7c740-d932-3e77-87fd-4a91dbef71f4@redhat.com> Message-ID: On 21.7.2016 10:13, Martin Babinsky wrote: > On 07/20/2016 12:10 PM, Martin Babinsky wrote: >> On 07/19/2016 12:32 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.7.2016 13:51, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/6078 >>> >>> I don't think we want the secret searchable. Add a 'no_search' flag to >>> the param to fix that. >>> >>> Honza >>> >> >> 'no_search' flag breaks the API backwards compatibility, so I am sending >> another two patches which fix handling of deprecated options in the >> framework and deprecate `--secret` in radiusproxy-find command. >> >> I hope this solution is the best. >> >> >> > After discussion with Jan we realized that it is enough to hide the > '--secret' option from CLI, not deprecate it. > > Re-sending patch 190 and updated 193.1. Thanks, ACK. Pushed to master: 66da08445370f7024a6a529a6659714c33b7525e > Patch 192 will be send in > separate thread since the actual issue it fixes is orthogonal to this > one and requires a separate ticket. Right. ATM this only affects --srchostcat in hbacrule-find. -- Jan Cholasta From gkaihoro at redhat.com Thu Jul 21 10:24:57 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Thu, 21 Jul 2016 06:24:57 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0001][Tests] Fix for dns_plugin tests In-Reply-To: References: <1640445260.22535316.1468943143859.JavaMail.zimbra@redhat.com> Message-ID: <53278270.23711779.1469096697232.JavaMail.zimbra@redhat.com> Hello! Thank you for review and notes about patch format. I will keep it in mind. I agree that this is not the best way to fix it and I was about to bring up topic of strange behavior of named/bind-dyndb-ldap. Because without restart named service I have one number of failing tests and after restart different number. This is happening for me randomly, I never know when I need to restart service. > I really don't like using 'ipa-ca.' domain name as server name, this is not right. Can you please, explain me why? So if it's not too much trouble for you, maybe you can give me some advice's how to investigate such kind of issues, at least some basic stuff, like what to check, where to look and etc. It can be a letter or in a format of 1 hour meeting or presentation (I think it will be good to all members of our team to understand better how our dns plugin works and how to troubleshoot it) And it seems like I will spend some time with tests for our dns-plugin, and It will be really great to know more about it. Thank you and have a nice day! Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Martin Basti" To: "Ganna Kaihorodova" , freeipa-devel at redhat.com Sent: Wednesday, July 20, 2016 4:11:08 PM Subject: Re: [Freeipa-devel] [PATCH 0001][Tests] Fix for dns_plugin tests Hello, On 19.07.2016 17:45, Ganna Kaihorodova wrote: > Greetings! > > Fix for ipatests/test_xmlrpc/test_dns_plugin.py (test_forwardzone_delegation_warnings.test) > > You can't have a DNS zone with the authoritative nameserver that does not have a A or AAAA record in the local DNS. Not true > Since in some test environments primary hostname of the master is managed by an external DNS, this hostname can not be used as a NS-record for IPA-managed zones. Therefore another existing fqdn corresponding to the master's ip and managed by IPA DNS was used. I really don't like using 'ipa-ca.' domain name as server name, this is not right. I was digging deeper today to find what is the root case why it doesn't work, and it looks that after some tests, named is not able to resolve hostname, even if global forwarder is specified. So this looks like bug on named/bind-dyndb-ldap side, because when I restarted named-pkcs11 before the first test that is failing and all forwardzone tests passed. So I think this patch just hides the real issue and we should discard it. I and pspacek will be continue investigating this tomorrow. Notes to the patch format: Please split that huge text in commit message to: short summary (max 72 chars) empty line longer description empty line [ticket (if available)] regars Martin^2 > > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > > From mbabinsk at redhat.com Thu Jul 21 10:56:01 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Jul 2016 12:56:01 +0200 Subject: [Freeipa-devel] [PATCH 0194] harden the check for trust namespace overlap in new principals Message-ID: <0919a23d-3c7b-8314-6b5e-0d9f7eff92c2@redhat.com> '*-add-principal' would crash with error if the trusted domains did not have any UPN suffixes or NETBIOS name associated with them. This patch fixes that. Big thanks to Milan who found and reported the issue during writing tests for the feature. https://fedorahosted.org/freeipa/ticket/6099 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0194-harden-the-check-for-trust-namespace-overlap-in-new-.patch Type: text/x-patch Size: 1446 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 21 11:01:45 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Jul 2016 13:01:45 +0200 Subject: [Freeipa-devel] [PATCH] 0211-0212 Make sure --raw option works for trust-add In-Reply-To: <20160719093204.n44lfk66thkhlfjc@redhat.com> References: <20160716105005.3nbpdxd2bsr2o2op@redhat.com> <0183c16f-21a2-59ab-25cc-b4964a2111a4@redhat.com> <214270d7-2930-3977-33ff-d0ef2bd2c454@redhat.com> <20160719093204.n44lfk66thkhlfjc@redhat.com> Message-ID: <4f21c020-c108-8b1a-a366-082b7b61e678@redhat.com> On 19.7.2016 11:32, Alexander Bokovoy wrote: > On Tue, 19 Jul 2016, Jan Cholasta wrote: >> On 18.7.2016 12:06, Martin Babinsky wrote: >>> On 07/16/2016 12:50 PM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> >>>> I had some time and was blocked by these bugs to do my tickets so I >>>> actually fixed these three problems that are assigned to Martin >>>> Babinsky. Hopefully, Martin wouldn't be offended by that. :) >>>> >>>> Note that this fix (patch 0211) has potential for a break but also >>>> introduces a correct behavior in my view as we should not really have >>>> non-lower cased keys in LDAP dictionaries in entry_to_dict() for both >>>> normal and --raw modes. >>>> >>>> ----- 0211 >>>> >>>> Since commit a8dd7aa337f25abd938a582d0fcba51d3b356410 if IPA command >>>> is called with --raw option, a retrieved LDAP entry's attribute >>>> names aren't normalized to lower case when converting the entry >>>> to a dictionary. This breaks overall assumption that dictionary >>>> keys are in lower case. >>>> >>>> Partially fixes 'ipa trust-add --raw' issues. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6059 >>>> >>>> ----- 0212 >>>> >>>> Make sure we display raw values for 'trust-add --raw' case. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6059 >>>> >>>> >>>> >>>> >>> >>> Hi Alexander, >>> >>> I am CC'ing Jan since I hope he knows why >>> a8dd7aa337f25abd938a582d0fcba51d3b356410 was implemented in this way. I >>> think there was a reason behind this decision and we should not revert >>> it without further discussion. >> >> I think it was just because with --raw, the raw LDAP entry should be >> returned, letter case and all. I don't really care if the names are >> lowercased or not, but you should never assume anything about raw >> results in your code anyway, so I think the revert would be pointless. >> There were a few bugs with --raw unrelated to letter case in the past >> and most of the offending code was fixed, the same should be done here >> IMO. > This is not about LDAP entry, this is about Python dictionary from > entry_to_dict(). LDAP attribute name is case-insensitive. > > We call entry_to_dict() in multiple places and we expect that > dictionary keys are lowcased in Python code. I don't think it is fair to > have this assumption broken when --raw is used -- after all, we are > dealing with Python dictionary and LDAP attributes are case insensitive. We don't expect anything about raw results anywhere in our code base, except for buggy code, which needs be fixed anyway. Martin's patch fixes the issue without any intrusive changes, so ACK. We can talk bigger changes later for 4.5. Pushed to master: 2234a774416309a44aecb84f27e6cf4c6a1a990f -- Jan Cholasta From mbasti at redhat.com Thu Jul 21 13:04:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Jul 2016 15:04:08 +0200 Subject: [Freeipa-devel] [PATCH 0001][Tests] Fix for dns_plugin tests In-Reply-To: <53278270.23711779.1469096697232.JavaMail.zimbra@redhat.com> References: <1640445260.22535316.1468943143859.JavaMail.zimbra@redhat.com> <53278270.23711779.1469096697232.JavaMail.zimbra@redhat.com> Message-ID: <39b25b8e-3037-d5ef-34c3-6aabedc83c11@redhat.com> On 21.07.2016 12:24, Ganna Kaihorodova wrote: > Hello! > > Thank you for review and notes about patch format. I will keep it in mind. > > I agree that this is not the best way to fix it and I was about to bring up topic of strange behavior of named/bind-dyndb-ldap. > Because without restart named service I have one number of failing tests and after restart different number. This is happening for me randomly, I never know when I need to restart service. > > >> I really don't like using 'ipa-ca.' domain name as server name, this is not right. > Can you please, explain me why? ipa-ca contains A records of IPA servers that are installed with CA subsystem. There is no guarantee that server is installed with CA, so ipa-ca record may not be there at all. Also it does not look nice, because it is unrelated to CA. > > > So if it's not too much trouble for you, maybe you can give me some advice's how to investigate such kind of issues, at least some basic stuff, like what to check, where to look and etc. > It can be a letter or in a format of 1 hour meeting or presentation (I think it will be good to all members of our team to understand better how our dns plugin works and how to troubleshoot it) > And it seems like I will spend some time with tests for our dns-plugin, and It will be really great to know more about it. > > Thank you and have a nice day! It depends from case to case, I don't have any 'works for everything' solution. Usually, I run tests with --pdb option, that pause testing after each fail and I connect to machine and I try to find why. Feel free to ask if you need help with something particular. Martin^2 > > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Martin Basti" > To: "Ganna Kaihorodova" , freeipa-devel at redhat.com > Sent: Wednesday, July 20, 2016 4:11:08 PM > Subject: Re: [Freeipa-devel] [PATCH 0001][Tests] Fix for dns_plugin tests > > Hello, > > > On 19.07.2016 17:45, Ganna Kaihorodova wrote: >> Greetings! >> >> Fix for ipatests/test_xmlrpc/test_dns_plugin.py (test_forwardzone_delegation_warnings.test) >> >> You can't have a DNS zone with the authoritative nameserver that does not have a A or AAAA record in the local DNS. > Not true > >> Since in some test environments primary hostname of the master is managed by an external DNS, this hostname can not be used as a NS-record for IPA-managed zones. Therefore another existing fqdn corresponding to the master's ip and managed by IPA DNS was used. > I really don't like using 'ipa-ca.' domain name as server > name, this is not right. > > I was digging deeper today to find what is the root case why it doesn't > work, and it looks that after some tests, named is not able to resolve > hostname, even if global forwarder is specified. > So this looks like bug on named/bind-dyndb-ldap side, because when I > restarted named-pkcs11 before the first test that is failing and all > forwardzone tests passed. > > So I think this patch just hides the real issue and we should discard > it. I and pspacek will be continue investigating this tomorrow. > > Notes to the patch format: > > Please split that huge text in commit message to: > > short summary (max 72 chars) > empty line > longer description > empty line > [ticket (if available)] > > regars > Martin^2 >> >> Best regards, >> Ganna Kaihorodova >> Associate Software Quality Engineer >> >> >> >> From pvoborni at redhat.com Thu Jul 21 15:22:52 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Jul 2016 17:22:52 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> Message-ID: <3d6a2e6f-5e55-bf2c-7a0e-2a4d62e34e12@redhat.com> On 07/19/2016 09:27 AM, Petr Vobornik wrote: > On 07/19/2016 08:01 AM, Jan Cholasta wrote: >> Hi, >> >> On 18.7.2016 18:50, Florence Blanc-Renaud wrote: >>> On 07/15/2016 04:29 PM, Petr Vobornik wrote: >>>> ipa-ca-install said that it used >>>> /var/log/ipareplica-ca-install.log >>>> but in fact it used >>>> /var/log/ipaserver-ca-install.log >>>> >>>> This patch unites it to ipaserver-ca-install.log >>>> >>>> It was chosen because ipa-ca-install can be also used on >>>> master on CA-less -> CA conversion. >>>> >>>> Term "server" is valid for both master and replica. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6088 >>>> >>>> >>>> >>> >>> Looks good to me. >>> Ack >> >> Does not look so good to me, "ipareplica-ca-install.log" is in fact the >> original file name used since ipa-ca-install was introduced (in commit >> 8a32bb3746802a29b2655e4ad2cbbba8481e1eaf), so why the switch to >> "ipaserver-ca-install.log"? >> >> Honza >> > > Ideally it would be ipa-ca-install.log but for backwards compatibility, > let's stick with one which we have. AFAIK the framework(run_script > method? doesn't support switching the log name which is printed in error > message depending on usage. Therefore the universal was chosen - > ipaserver-ca-install.log. It was introduced by your commit > d27e77adc56f5a04f3bdd1aaed5440a89ed3acad > > And I see, that I used wrong ticket number in the commit. Correct is > https://fedorahosted.org/freeipa/ticket/6086 > > Proper solution might be to rework main and __main__ function in > ipa-ca-install but IMO we spent too much time on this already. > Updated patch attach - it uses the other log. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0963-1-unite-log-file-name-of-ipa-ca-install.patch Type: text/x-patch Size: 2190 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 21 15:43:55 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Jul 2016 17:43:55 +0200 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: References: <1469010462.21393.47.camel@redhat.com> <1469025427.21393.51.camel@redhat.com> <514956a4-14f7-5816-23cd-d1ce1e3d28fa@redhat.com> <1469031696.21393.55.camel@redhat.com> Message-ID: <60f90568-e517-8516-7c93-491d9bd20758@redhat.com> On 20.7.2016 19:25, Ben Lipton wrote: > On 07/20/2016 12:21 PM, Simo Sorce wrote: >> On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote: >>> On 07/20/2016 10:37 AM, Simo Sorce wrote: >>>> On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: >>>>> On 07/20/2016 06:27 AM, Simo Sorce wrote: >>>>>> On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have updated the design page >>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_ >>>>>>> Gene >>>>>>> rati >>>>>>> on/Mapping_Rules >>>>>>> with my plan for implementing user-configurable rules for >>>>>>> mapping >>>>>>> IPA >>>>>>> data into certificate requests. In brief: we will use Jinja2 >>>>>>> for >>>>>>> templating. Data rules (which map individual data items) and >>>>>>> syntax >>>>>>> rules (which group them into certificate fields) will both be >>>>>>> snippets >>>>>>> of Jinja2 markup. The formatting process will be as follows: I've finally found some time to read the sub-page Mapping_Rules and for me it is kind of hard to follow. It would not be understandable without this e-mail and the blog posts (BTW the blog articles are among best I have seen!). Most importantly, the explanations in brackets above ["Data rules (which map individual data items) and (which group them into certificate fields)"] are missing in the wiki page itself :-) Could you fold relevant parts of the e-mails and blogs back into the wiki page so it is self-contained? Besides this nit, http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation sounds reasonable. I like how it prevents bad data from template-injection. Regarding http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A , I prefer Option A with separate object for each helper. It is somehow cleaner and it might be useful to use distinct object classes for each helper etc. API for ipa cert-get-requestdata sounds good. API for ipa cert-request makes sense to me as well. In any case I would recommend you to consult API design with Jan Cholasta - he is our API custodian. BTW I very much like "Alternatives considered" sections, we should have this for each design! Good work, I really like the dutiful analysis! >>>>>>> 1. Syntax rules will be rendered using Jinja2. Data rules >>>>>>> (rule >>>>>>> text, >>>>>>> not rendered) will be passed as the datarules attribute. >>>>>>> 2. Rendered syntax rules will be processed by the Formatter >>>>>>> class >>>>>>> for >>>>>>> the selected CSR generation helper (e.g. openssl or >>>>>>> certutil). >>>>>>> The >>>>>>> formatter combines these partial rules into a full template >>>>>>> for >>>>>>> the >>>>>>> config. >>>>>>> 3. The template will be rendered using Jinja2. Relevant data >>>>>>> from >>>>>>> the >>>>>>> IPA database will be available in the context for this >>>>>>> rendering. >>>>>>> 4. The final rendered template will be returned to the >>>>>>> caller, >>>>>>> labeled >>>>>>> with its function (e.g. a command line or a config file). >>>>>>> >>>>>>> Are there any comments or objections to this approach? Here's >>>>>>> an >>>>>>> example >>>>>>> to show what it might look like in practice. >>>>>>> >>>>>>> Example data rules: >>>>>>> email={{subject.email}} >>>>>>> O={{config.ipacertificatesubjectbase}}\nCN={{subject.username >>>>>>> }} >>>>>>> >>>>>>> Example syntax rule: >>>>>>> subjectAltName=@{% section %}{{datarules|join('\n')}}{% >>>>>>> endsection %} >>>>>>> >>>>>>> Example composed config template: >>>>>>> [ req ] >>>>>>> prompt = no >>>>>>> encrypt_key = no >>>>>>> >>>>>>> distinguished_name = {% section >>>>>>> %}O={{config.ipacertificatesubjectbase}} >>>>>>> CN={{subject.username}}{% endsection %} >>>>>>> >>>>>>> req_extensions = exts >>>>>>> >>>>>>> [ exts ] >>>>>>> subjectAltName=@{% section %}email={{subject.email}}{% >>>>>>> endsection >>>>>>> %} >>>>>>> >>>>>>> There's a lot more information about the thinking behind this >>>>>>> at >>>>>>> http://blog.benjaminlipton.com/2016/07/19/csr-generation-temp >>>>>>> lati >>>>>>> ng.h >>>>>>> tml >>>>>>> if you're interested, as well. >>>>>> Nice work Ben, >>>>>> it's been really nice to be able to follow your notes on the >>>>>> blog >>>>>> post, >>>>>> one question remains lingering in my head, why jinja2 ? >>>>>> I know that engine relatively well as I used it in ipsilon, so >>>>>> I am >>>>>> not >>>>>> questioning the choice just asking why specifically jinja2 and >>>>>> not >>>>>> something else, potentially language agnostic. >>>>>> >>>>>> Simo. >>>>> Honestly, my reasoning didn't go very far beyond that it seems to >>>>> be >>>>> widely used and is compatible with python, which is the language >>>>> where >>>>> the implementation is taking place (in the IPA RPC server). I >>>>> thought >>>>> about using the built-in python format strings or creating a >>>>> simple >>>>> domain-specific language, but the likelihood of wanting the >>>>> built-in >>>>> text processing features (join, replace, maybe even for loops) >>>>> seemed >>>>> high, and I didn't want to reimplement those features. >>>>> >>>>> Will the additional package dependency be a problem? >>>> I am more concerned a out the ability to process the data (which I >>>> guess is stored in LDAP) by another client, or in the CLI. >>>> Other than that the dependency does not concern me too much >>>> provided >>>> jinja2 templating is stable and has some guarantee that it will be >>>> supportable long term. >>>> >>>> If that is not guaranteed it is a problem, we cannot easily swap >>>> out >>>> one language for another once data is stored and used by the >>>> server. >>>> So the most important consideration for me is whether we are >>>> locking >>>> ourselves into something that will be hard to deal with later or >>>> not. >>>> >>>> Should the jinja2 project fail by the wayside next year would we be >>>> able to easily replace it with another engine without changing the >>>> templates as stored ? >>>> >>>> Simo. >>>> >>> Ah, ok, I understand the concern. For now, the plan is that the >>> server >>> will do all the text processing, so I don't really forsee a need for >>> any >>> other client to read the mapping rules from LDAP. However, it's true >>> that templates written in jinja2 would probably need at least minor >>> changes to be compatible with another templating engine. (Same goes >>> for >>> any other choice - a lot of these engines seem to have very similar, >>> but >>> not exactly compatible, syntax). I don't really know how to judge >>> the >>> long-term viability of the jinja2 project, though it seems to be >>> recognized by lots of projects (ansible[1], openstack[2], flask[3], >>> even >>> django[4] which has its own templating engine). Other big users are exactly the reason why I consider Jinja2 to be a good choice. After all, if Jinja2 dies upstream we will not be alone :-) Petr^2 Spacek >>> In any case, if the team prefers it, I'd be comfortable going with a >>> more minimal DSL that only has the features we know we need. It >>> might >>> slightly limit the types of certs that can be generated, but that can >>> be >>> iterated on. But it would be another thing to design, build and >>> maintain. Let me know what you think. >> I am ok using jinja2 as long as we realize we may be on the hook for >> maintaining it ourselves in the long term. It's probably easier to do >> that than to write our own anyway. >> >> Simo. > It might also be worth pointing out that although the examples in the document > are based on jinja2, the overall approach should be pretty compatible with > other (existing or custom) template languages. So we're not locked into jinja2 > in that way, it's just the rules in deployed databases that would be tough to > convert. -- Petr^2 Spacek From mbabinsk at redhat.com Thu Jul 21 15:47:08 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Jul 2016 17:47:08 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: <3d6a2e6f-5e55-bf2c-7a0e-2a4d62e34e12@redhat.com> References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> <3d6a2e6f-5e55-bf2c-7a0e-2a4d62e34e12@redhat.com> Message-ID: <3f8b3810-63de-4e2d-668f-bbca5d1dcd1d@redhat.com> On 07/21/2016 05:22 PM, Petr Vobornik wrote: > On 07/19/2016 09:27 AM, Petr Vobornik wrote: >> On 07/19/2016 08:01 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 18.7.2016 18:50, Florence Blanc-Renaud wrote: >>>> On 07/15/2016 04:29 PM, Petr Vobornik wrote: >>>>> ipa-ca-install said that it used >>>>> /var/log/ipareplica-ca-install.log >>>>> but in fact it used >>>>> /var/log/ipaserver-ca-install.log >>>>> >>>>> This patch unites it to ipaserver-ca-install.log >>>>> >>>>> It was chosen because ipa-ca-install can be also used on >>>>> master on CA-less -> CA conversion. >>>>> >>>>> Term "server" is valid for both master and replica. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6088 >>>>> >>>>> >>>>> >>>> >>>> Looks good to me. >>>> Ack >>> >>> Does not look so good to me, "ipareplica-ca-install.log" is in fact the >>> original file name used since ipa-ca-install was introduced (in commit >>> 8a32bb3746802a29b2655e4ad2cbbba8481e1eaf), so why the switch to >>> "ipaserver-ca-install.log"? >>> >>> Honza >>> >> >> Ideally it would be ipa-ca-install.log but for backwards compatibility, >> let's stick with one which we have. AFAIK the framework(run_script >> method? doesn't support switching the log name which is printed in error >> message depending on usage. Therefore the universal was chosen - >> ipaserver-ca-install.log. It was introduced by your commit >> d27e77adc56f5a04f3bdd1aaed5440a89ed3acad >> >> And I see, that I used wrong ticket number in the commit. Correct is >> https://fedorahosted.org/freeipa/ticket/6086 >> >> Proper solution might be to rework main and __main__ function in >> ipa-ca-install but IMO we spent too much time on this already. >> > > Updated patch attach - it uses the other log. > > > Correct me if I'm wrong but the ticket URL should be https://fedorahosted.org/freeipa/ticket/6086 -- Martin^3 Babinsky From pvoborni at redhat.com Thu Jul 21 15:49:16 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Jul 2016 17:49:16 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: <3f8b3810-63de-4e2d-668f-bbca5d1dcd1d@redhat.com> References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> <3d6a2e6f-5e55-bf2c-7a0e-2a4d62e34e12@redhat.com> <3f8b3810-63de-4e2d-668f-bbca5d1dcd1d@redhat.com> Message-ID: On 07/21/2016 05:47 PM, Martin Babinsky wrote: > On 07/21/2016 05:22 PM, Petr Vobornik wrote: >> On 07/19/2016 09:27 AM, Petr Vobornik wrote: >>> On 07/19/2016 08:01 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 18.7.2016 18:50, Florence Blanc-Renaud wrote: >>>>> On 07/15/2016 04:29 PM, Petr Vobornik wrote: >>>>>> ipa-ca-install said that it used >>>>>> /var/log/ipareplica-ca-install.log >>>>>> but in fact it used >>>>>> /var/log/ipaserver-ca-install.log >>>>>> >>>>>> This patch unites it to ipaserver-ca-install.log >>>>>> >>>>>> It was chosen because ipa-ca-install can be also used on >>>>>> master on CA-less -> CA conversion. >>>>>> >>>>>> Term "server" is valid for both master and replica. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/6088 >>>>>> >>>>>> >>>>>> >>>>> >>>>> Looks good to me. >>>>> Ack >>>> >>>> Does not look so good to me, "ipareplica-ca-install.log" is in fact the >>>> original file name used since ipa-ca-install was introduced (in commit >>>> 8a32bb3746802a29b2655e4ad2cbbba8481e1eaf), so why the switch to >>>> "ipaserver-ca-install.log"? >>>> >>>> Honza >>>> >>> >>> Ideally it would be ipa-ca-install.log but for backwards compatibility, >>> let's stick with one which we have. AFAIK the framework(run_script >>> method? doesn't support switching the log name which is printed in error >>> message depending on usage. Therefore the universal was chosen - >>> ipaserver-ca-install.log. It was introduced by your commit >>> d27e77adc56f5a04f3bdd1aaed5440a89ed3acad >>> >>> And I see, that I used wrong ticket number in the commit. Correct is >>> https://fedorahosted.org/freeipa/ticket/6086 >>> >>> Proper solution might be to rework main and __main__ function in >>> ipa-ca-install but IMO we spent too much time on this already. >>> >> >> Updated patch attach - it uses the other log. >> >> >> > > Correct me if I'm wrong but the ticket URL should be > https://fedorahosted.org/freeipa/ticket/6086 > you are absolutely right. Fixed. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0963-2-unite-log-file-name-of-ipa-ca-install.patch Type: text/x-patch Size: 2190 bytes Desc: not available URL: From pvomacka at redhat.com Thu Jul 21 15:51:02 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 21 Jul 2016 17:51:02 +0200 Subject: [Freeipa-devel] [PATCH] 0083: webui: remove full name column from user to user group adder dialog Message-ID: <505f8376-d7ec-1652-285d-87a5afeaeeb3@redhat.com> Remove full name from adding user to user group dialog As the 'cn' is not in the response of user-show there is empty column in adder dialog. Therefore the column was removed. https://fedorahosted.org/freeipa/ticket/6055 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0083-Remove-full-name-from-adding-user-to-user-group-dial.patch Type: text/x-patch Size: 1148 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Jul 21 16:37:40 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Jul 2016 18:37:40 +0200 Subject: [Freeipa-devel] [PATCH] 963 unite log file name of ipa-ca-install In-Reply-To: References: <53e6660a-c354-21d0-0752-7da09ee23652@redhat.com> <2e2de886-9d85-f804-522c-2f54b5604f2f@redhat.com> <3d6a2e6f-5e55-bf2c-7a0e-2a4d62e34e12@redhat.com> <3f8b3810-63de-4e2d-668f-bbca5d1dcd1d@redhat.com> Message-ID: <4a15260e-6d16-346c-474c-eea9c8ea158c@redhat.com> On 07/21/2016 05:49 PM, Petr Vobornik wrote: > On 07/21/2016 05:47 PM, Martin Babinsky wrote: >> On 07/21/2016 05:22 PM, Petr Vobornik wrote: >>> On 07/19/2016 09:27 AM, Petr Vobornik wrote: >>>> On 07/19/2016 08:01 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 18.7.2016 18:50, Florence Blanc-Renaud wrote: >>>>>> On 07/15/2016 04:29 PM, Petr Vobornik wrote: >>>>>>> ipa-ca-install said that it used >>>>>>> /var/log/ipareplica-ca-install.log >>>>>>> but in fact it used >>>>>>> /var/log/ipaserver-ca-install.log >>>>>>> >>>>>>> This patch unites it to ipaserver-ca-install.log >>>>>>> >>>>>>> It was chosen because ipa-ca-install can be also used on >>>>>>> master on CA-less -> CA conversion. >>>>>>> >>>>>>> Term "server" is valid for both master and replica. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/6088 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Looks good to me. >>>>>> Ack >>>>> >>>>> Does not look so good to me, "ipareplica-ca-install.log" is in fact the >>>>> original file name used since ipa-ca-install was introduced (in commit >>>>> 8a32bb3746802a29b2655e4ad2cbbba8481e1eaf), so why the switch to >>>>> "ipaserver-ca-install.log"? >>>>> >>>>> Honza >>>>> >>>> >>>> Ideally it would be ipa-ca-install.log but for backwards compatibility, >>>> let's stick with one which we have. AFAIK the framework(run_script >>>> method? doesn't support switching the log name which is printed in error >>>> message depending on usage. Therefore the universal was chosen - >>>> ipaserver-ca-install.log. It was introduced by your commit >>>> d27e77adc56f5a04f3bdd1aaed5440a89ed3acad >>>> >>>> And I see, that I used wrong ticket number in the commit. Correct is >>>> https://fedorahosted.org/freeipa/ticket/6086 >>>> >>>> Proper solution might be to rework main and __main__ function in >>>> ipa-ca-install but IMO we spent too much time on this already. >>>> >>> >>> Updated patch attach - it uses the other log. >>> >>> >>> >> >> Correct me if I'm wrong but the ticket URL should be >> https://fedorahosted.org/freeipa/ticket/6086 >> > > you are absolutely right. Fixed. > ACK Pushed to master: 1b8a36d134dd320896e05809cc6b49f725eadda7 -- Martin^3 Babinsky From pvoborni at redhat.com Thu Jul 21 16:51:27 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Jul 2016 18:51:27 +0200 Subject: [Freeipa-devel] [DRAFT] FreeIPA 4.3.2 release notes Message-ID: <2a519b82-b7fa-174a-7ba9-35f5737823fb@redhat.com> Hi all, this is a draft of release notes for upcoming 4.3.2 release - http://www.freeipa.org/page/Releases/4.3.2 Comments/updates welcome! Regards, -- Petr Vobornik From mbasti at redhat.com Thu Jul 21 17:49:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Jul 2016 19:49:04 +0200 Subject: [Freeipa-devel] [PATCH 0555] AVC: use copy during instalation to keep SELinux context valid Message-ID: <1aa08b94-cdbd-8f1f-b607-24e2e2366c4a@redhat.com> https://fedorahosted.org/freeipa/ticket/6111 I was able to reproduce this locally with vagrant, but I haven't been able to reproduce this in LAB, I don't know where differences are (cloud vs desktop fedora?) Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0555-Use-copy-when-replacing-files-to-keep-SELinux-contex.patch Type: text/x-patch Size: 1068 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 21 18:01:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Jul 2016 20:01:00 +0200 Subject: [Freeipa-devel] [PATCH 0556] host-del: fix behavior of --updatedns and PTR records Message-ID: https://fedorahosted.org/freeipa/ticket/6060 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0556-Host-del-fix-behavior-of-updatedns-and-PTR-records.patch Type: text/x-patch Size: 3612 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 21 18:03:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Jul 2016 20:03:53 +0200 Subject: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests In-Reply-To: <536349855.23231759.1469031459952.JavaMail.zimbra@redhat.com> References: <1812744576.23182071.1469026923069.JavaMail.zimbra@redhat.com> <536349855.23231759.1469031459952.JavaMail.zimbra@redhat.com> Message-ID: <7cac1261-820e-e120-8899-b41c8490e902@redhat.com> On 20.07.2016 18:17, Ganna Kaihorodova wrote: > Hello! > > Thank you for review. > I attached patch with fixed commit message > > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Martin Basti" > To: "Ganna Kaihorodova" , freeipa-devel at redhat.com > Sent: Wednesday, July 20, 2016 5:04:47 PM > Subject: Re: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests > > > > On 20.07.2016 17:02, Ganna Kaihorodova wrote: >> Greetings! >> >> Fix for ipatests/test_xmlrpc/test_dns_plugin.py >> >> Fix conflict between ?got? and ?expected? values when testing "dnsconfig_mod: Update global DNS settings" >> >> Best regards, >> Ganna Kaihorodova >> Associate Software Quality Engineer >> >> >> >> > LGTM, but can you fix commit message? > > This looks very suspicious > > Subject: [PATCH 2/2] =?UTF-8?q?Fix=20conflict=20between=20=E2=80=9Cgot?= > =?UTF-8?q?=E2=80=9D=20and=20=E2=80=9Cexpected=E2=80=9D=20values=20when=20?= > =?UTF-8?q?testing=20"dnsconfig=5Fmod:=20Update=20global=20DNS=20settings"?= > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > > regards, > Martin^2 ACK I just replaced some fancy unicode quotation marks with ASCII in commit message before push Pushed to master: 359cfeb7c6798038f5638f9d0977dda351f21431 From ftweedal at redhat.com Fri Jul 22 05:13:27 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 22 Jul 2016 15:13:27 +1000 Subject: [Freeipa-devel] [PATCH] 0090, 0092..0094 cert-show: show subject alternative names In-Reply-To: References: <20160714114315.GB10771@dhcp-40-8.bne.redhat.com> Message-ID: <20160722051327.GI10771@dhcp-40-8.bne.redhat.com> On Tue, Jul 19, 2016 at 08:50:34AM +0200, Jan Cholasta wrote: > Hi, > > On 14.7.2016 13:44, Fraser Tweedale wrote: > > Hi all, > > > > The attached patch includes SANs in cert-show output. If you have > > certs with esoteric altnames (especially any that are more than just > > ASN.1 string types), please test with those certs. > > > > https://fedorahosted.org/freeipa/ticket/6022 > > I think it would be better to have a separate attribute for each supported > SAN type rather than cramming everything into subject_alt_name. That way if > you care only about a single specific type you won't have to go through all > the values and parse them. Also it would allow you to use param types > appropriate to the SAN types (DNSNameParam for DNS names, Principal for > principal names, etc.) > > Nitpick: please don't mix moving existing stuff and adding new stuff in a > single patch. > Updated patches attached. Patches 0092..0094 are refactors and bugfixes. Patch 0090-2 is the main feature (depends on 0092..0094). Thanks, Fraser -------------- next part -------------- From 0f85eba4efdd9281725c54268e8d213c412edebf Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 21 Jul 2016 16:27:49 +1000 Subject: [PATCH 92/94] Move GeneralName parsing code to ipalib.x509 GeneralName parsing code is primarily relevant to X.509. An upcoming change will add SAN parsing to the cert-show command, so first move the GeneralName parsing code from ipalib.pkcs10 to ipalib.x509. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/pkcs10.py | 93 ++----------------------------------- ipalib/x509.py | 114 +++++++++++++++++++++++++++++++++++++++++++++- ipaserver/plugins/cert.py | 8 ++-- 3 files changed, 120 insertions(+), 95 deletions(-) diff --git a/ipalib/pkcs10.py b/ipalib/pkcs10.py index e340c1a2005ad781542a32a0a76753e80364dacf..158ebb3a25be2bd292f3883545fe8afe49b7be8c 100644 --- a/ipalib/pkcs10.py +++ b/ipalib/pkcs10.py @@ -22,9 +22,10 @@ from __future__ import print_function import sys import base64 import nss.nss as nss -from pyasn1.type import univ, char, namedtype, tag +from pyasn1.type import univ, namedtype, tag from pyasn1.codec.der import decoder import six +from ipalib import x509 if six.PY3: unicode = str @@ -32,11 +33,6 @@ if six.PY3: PEM = 0 DER = 1 -SAN_DNSNAME = 'DNS name' -SAN_RFC822NAME = 'RFC822 Name' -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' - def get_subject(csr, datatype=PEM): """ Given a CSR return the subject value. @@ -72,78 +68,6 @@ def get_extensions(csr, datatype=PEM): return tuple(get_prefixed_oid_str(ext)[4:] for ext in request.extensions) -class _PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('name-type', univ.Integer().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -class _KRB5PrincipalName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('realm', char.GeneralString().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('principalName', _PrincipalName().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - ) - -def _decode_krb5principalname(data): - principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] - realm = (str(principal['realm']).replace('\\', '\\\\') - .replace('@', '\\@')) - name = principal['principalName']['name-string'] - name = '/'.join(str(n).replace('\\', '\\\\') - .replace('/', '\\/') - .replace('@', '\\@') for n in name) - name = '%s@%s' % (name, realm) - return name - -class _AnotherName(univ.Sequence): - componentType = namedtype.NamedTypes( - namedtype.NamedType('type-id', univ.ObjectIdentifier()), - namedtype.NamedType('value', univ.Any().subtype( - explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - ) - -class _GeneralName(univ.Choice): - componentType = namedtype.NamedTypes( - namedtype.NamedType('otherName', _AnotherName().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) - ), - namedtype.NamedType('rfc822Name', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) - ), - namedtype.NamedType('dNSName', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) - ), - namedtype.NamedType('x400Address', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) - ), - namedtype.NamedType('directoryName', univ.Choice().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) - ), - namedtype.NamedType('ediPartyName', univ.Sequence().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) - ), - namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) - ), - namedtype.NamedType('iPAddress', univ.OctetString().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) - ), - namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( - implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) - ), - ) - -class _SubjectAltName(univ.SequenceOf): - componentType = _GeneralName() def get_subjectaltname(csr, datatype=PEM): """ @@ -159,19 +83,8 @@ def get_subjectaltname(csr, datatype=PEM): return None del request - nss_names = nss.x509_alt_name(extension.value, nss.AsObject) - asn1_names = decoder.decode(extension.value.data, - asn1Spec=_SubjectAltName())[0] - names = [] - for nss_name, asn1_name in zip(nss_names, asn1_names): - name_type = nss_name.type_string - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: - name = _decode_krb5principalname(asn1_name['otherName']['value']) - else: - name = nss_name.name - names.append((name_type, name)) + return x509.decode_generalnames(extension.value) - return tuple(names) # Unfortunately, NSS can only parse the extension request attribute, so # we have to parse friendly name ourselves (see RFC 2986) diff --git a/ipalib/x509.py b/ipalib/x509.py index 82194922d151a1b0f2df03df3578ad45b43b71c9..15168de08240a84794efef409d022eaa983291c9 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -40,7 +40,7 @@ import re import nss.nss as nss from nss.error import NSPRError -from pyasn1.type import univ, namedtype, tag +from pyasn1.type import univ, char, namedtype, tag from pyasn1.codec.der import decoder, encoder import six @@ -63,6 +63,11 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' EKU_ANY = '2.5.29.37.0' EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' +SAN_DNSNAME = 'DNS name' +SAN_RFC822NAME = 'RFC822 Name' +SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' +SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' + _subject_base = None def subject_base(): @@ -374,6 +379,113 @@ def encode_ext_key_usage(ext_key_usage): eku = encoder.encode(eku) return _encode_extension('2.5.29.37', EKU_ANY not in ext_key_usage, eku) + +class _AnotherName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('type-id', univ.ObjectIdentifier()), + namedtype.NamedType('value', univ.Any().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + ) + + +class _GeneralName(univ.Choice): + componentType = namedtype.NamedTypes( + namedtype.NamedType('otherName', _AnotherName().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('rfc822Name', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + namedtype.NamedType('dNSName', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)) + ), + namedtype.NamedType('x400Address', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) + ), + namedtype.NamedType('directoryName', univ.Choice().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) + ), + namedtype.NamedType('ediPartyName', univ.Sequence().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 5)) + ), + namedtype.NamedType('uniformResourceIdentifier', char.IA5String().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 6)) + ), + namedtype.NamedType('iPAddress', univ.OctetString().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 7)) + ), + namedtype.NamedType('registeredID', univ.ObjectIdentifier().subtype( + implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 8)) + ), + ) + + +class _SubjectAltName(univ.SequenceOf): + componentType = _GeneralName() + + +class _PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('name-type', univ.Integer().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('name-string', univ.SequenceOf(char.GeneralString()).subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +class _KRB5PrincipalName(univ.Sequence): + componentType = namedtype.NamedTypes( + namedtype.NamedType('realm', char.GeneralString().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)) + ), + namedtype.NamedType('principalName', _PrincipalName().subtype( + explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 1)) + ), + ) + + +def _decode_krb5principalname(data): + principal = decoder.decode(data, asn1Spec=_KRB5PrincipalName())[0] + realm = (str(principal['realm']).replace('\\', '\\\\') + .replace('@', '\\@')) + name = principal['principalName']['name-string'] + name = '/'.join(str(n).replace('\\', '\\\\') + .replace('/', '\\/') + .replace('@', '\\@') for n in name) + name = '%s@%s' % (name, realm) + return name + + +def decode_generalnames(secitem): + """ + Decode a GeneralNames object (this the data for the Subject + Alt Name and Issuer Alt Name extensions, among others). + + ``secitem`` + The input is the DER-encoded extension data, without the + OCTET STRING header, as an nss SecItem object. + + Return a list of tuples of name types (as string, suitable for + presentation) and names (as string, suitable for presentation). + + """ + nss_names = nss.x509_alt_name(secitem, repr_kind=nss.AsObject) + asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] + names = [] + for nss_name, asn1_name in zip(nss_names, asn1_names): + name_type = nss_name.type_string + if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: + name = _decode_krb5principalname(asn1_name['otherName']['value']) + else: + name = nss_name.name + names.append((name_type, name)) + + return names + + if __name__ == '__main__': # this can be run with: # python ipalib/x509.py < /etc/ipa/ca.crt diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 06041d3083565e8d093b610473d6083111d406d2..85be2cf4daeb282b2c2ba866017c8e5745abda6d 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -535,7 +535,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): # Validate the subject alt name, if any for name_type, name in subjectaltname: - if name_type == pkcs10.SAN_DNSNAME: + if name_type == x509.SAN_DNSNAME: name = unicode(name) alt_principal_obj = None alt_principal_string = unicode(principal) @@ -566,13 +566,13 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "with subject alt name '%s'.") % name) if alt_principal_string is not None and not bypass_caacl: caacl_check(principal_type, principal, ca, profile_id) - elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, - pkcs10.SAN_OTHERNAME_UPN): + elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, + x509.SAN_OTHERNAME_UPN): if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) - elif name_type == pkcs10.SAN_RFC822NAME: + elif name_type == x509.SAN_RFC822NAME: if principal_type == USER: if name not in principal_obj.get('mail', []): raise errors.ValidationError( -- 2.5.5 -------------- next part -------------- From e9af4c5cd0bbc488f0a65c576286b0dc4452110b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 22 Jul 2016 12:05:13 +1000 Subject: [PATCH 93/94] x509: fix SAN directoryName parsing The subjectAltName extension parsing code in ipalib.x509 fails on directoryName values because the Choice structure is not endowed with an inner type. Implement the Name structure, whose inner type is a CHOICE { SEQUENCE OF RelativeDistinguishedName }, to resolve. Note that the structure still does not get fully parsed; only enough to recognise the SequenceOf tag and not fail. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 15168de08240a84794efef409d022eaa983291c9..2dc67441c92686826dd24f00a5ad30566cd032da 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -196,6 +196,12 @@ def is_self_signed(certificate, datatype=PEM, dbdir=None): del nsscert return self_signed +class _Name(univ.Choice): + componentType = namedtype.NamedTypes( + namedtype.NamedType('rdnSequence', + univ.SequenceOf()), + ) + class _TBSCertificate(univ.Sequence): componentType = namedtype.NamedTypes( namedtype.NamedType( @@ -204,9 +210,9 @@ class _TBSCertificate(univ.Sequence): tag.tagClassContext, tag.tagFormatSimple, 0))), namedtype.NamedType('serialNumber', univ.Integer()), namedtype.NamedType('signature', univ.Sequence()), - namedtype.NamedType('issuer', univ.Sequence()), + namedtype.NamedType('issuer', _Name()), namedtype.NamedType('validity', univ.Sequence()), - namedtype.NamedType('subject', univ.Sequence()), + namedtype.NamedType('subject', _Name()), namedtype.NamedType('subjectPublicKeyInfo', univ.Sequence()), namedtype.OptionalNamedType( 'issuerUniquedID', @@ -403,7 +409,7 @@ class _GeneralName(univ.Choice): namedtype.NamedType('x400Address', univ.Sequence().subtype( implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 3)) ), - namedtype.NamedType('directoryName', univ.Choice().subtype( + namedtype.NamedType('directoryName', _Name().subtype( implicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 4)) ), namedtype.NamedType('ediPartyName', univ.Sequence().subtype( -- 2.5.5 -------------- next part -------------- From 26b24435264f76fdfa5ec02cc4aac52b40511c13 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 22 Jul 2016 12:11:59 +1000 Subject: [PATCH 94/94] x509: use NSS enums and OIDs to identify SAN types GeneralName parsing currently relies heavily on strings from NSS. Make the code hopefully less brittle by identifying GeneralName types by NSS enums and, for otherName, the name-type OID also. Part of: https://fedorahosted.org/freeipa/ticket/6022 --- ipalib/x509.py | 30 +++++++++++++++++++++++------- ipaserver/plugins/cert.py | 19 ++++++++++--------- 2 files changed, 33 insertions(+), 16 deletions(-) diff --git a/ipalib/x509.py b/ipalib/x509.py index 2dc67441c92686826dd24f00a5ad30566cd032da..541609fbc1a53a73eafcff2327e53a292c2d9a3c 100644 --- a/ipalib/x509.py +++ b/ipalib/x509.py @@ -33,6 +33,7 @@ from __future__ import print_function +import collections import os import sys import base64 @@ -63,10 +64,8 @@ EKU_EMAIL_PROTECTION = '1.3.6.1.5.5.7.3.4' EKU_ANY = '2.5.29.37.0' EKU_PLACEHOLDER = '1.3.6.1.4.1.3319.6.10.16' -SAN_DNSNAME = 'DNS name' -SAN_RFC822NAME = 'RFC822 Name' -SAN_OTHERNAME_UPN = 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)' -SAN_OTHERNAME_KRB5PRINCIPALNAME = 'Other Name (OID.1.3.6.1.5.2.2)' +SAN_UPN = '1.3.6.1.4.1.311.20.2.3' +SAN_KRB5PRINCIPALNAME = '1.3.6.1.5.2.2' _subject_base = None @@ -465,6 +464,10 @@ def _decode_krb5principalname(data): return name +GeneralNameInfo = collections.namedtuple( + 'GeneralNameInfo', ('type', 'desc', 'value')) + + def decode_generalnames(secitem): """ Decode a GeneralNames object (this the data for the Subject @@ -482,12 +485,25 @@ def decode_generalnames(secitem): asn1_names = decoder.decode(secitem.data, asn1Spec=_SubjectAltName())[0] names = [] for nss_name, asn1_name in zip(nss_names, asn1_names): - name_type = nss_name.type_string - if name_type == SAN_OTHERNAME_KRB5PRINCIPALNAME: + # NOTE: we use the NSS enum to identify the name type. + # (For otherName we also tuple it up with the type-id OID). + # The enum does not correspond exactly to the ASN.1 tags. + # If we ever want to switch to using the true tag numbers, + # the expression to get the tag is: + # + # asn1_name.getComponent().getTagSet()[0].asTuple()[2] + # + if nss_name.type_enum == nss.certOtherName: + oid = str(asn1_name['otherName']['type-id']) + nametype = (nss_name.type_enum, oid) + else: + nametype = nss_name.type_enum + + if nametype == (nss.certOtherName, SAN_KRB5PRINCIPALNAME): name = _decode_krb5principalname(asn1_name['otherName']['value']) else: name = nss_name.name - names.append((name_type, name)) + names.append(GeneralNameInfo(nametype, nss_name.type_string, name)) return names diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 85be2cf4daeb282b2c2ba866017c8e5745abda6d..207f6964645254ebc417cab80634a68911ae0a08 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -534,8 +534,8 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "to the 'userCertificate' attribute of entry '%s'.") % dn) # Validate the subject alt name, if any - for name_type, name in subjectaltname: - if name_type == x509.SAN_DNSNAME: + for name_type, desc, name in subjectaltname: + if name_type == nss.certDNSName: name = unicode(name) alt_principal_obj = None alt_principal_string = unicode(principal) @@ -549,7 +549,7 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): raise errors.ValidationError( name='csr', error=_("subject alt name type %s is forbidden " - "for user principals") % name_type + "for user principals") % desc ) except errors.NotFound: # We don't want to issue any certificates referencing @@ -566,13 +566,15 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): "with subject alt name '%s'.") % name) if alt_principal_string is not None and not bypass_caacl: caacl_check(principal_type, principal, ca, profile_id) - elif name_type in (x509.SAN_OTHERNAME_KRB5PRINCIPALNAME, - x509.SAN_OTHERNAME_UPN): + elif name_type in [ + (nss.certOtherName, x509.SAN_UPN), + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME), + ]: if name != principal_string: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) - elif name_type == x509.SAN_RFC822NAME: + elif name_type == nss.certRFC822Name: if principal_type == USER: if name not in principal_obj.get('mail', []): raise errors.ValidationError( @@ -585,12 +587,11 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): raise errors.ValidationError( name='csr', error=_("subject alt name type %s is forbidden " - "for non-user principals") % name_type + "for non-user principals") % desc ) else: raise errors.ACIError( - info=_("Subject alt name type %s is forbidden") % - name_type) + info=_("Subject alt name type %s is forbidden") % desc) # Request the certificate result = self.Backend.ra.request_certificate( -- 2.5.5 -------------- next part -------------- From 9991e76716312f5cd15bfb71e69ec95466872c9f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 14 Jul 2016 21:36:33 +1000 Subject: [PATCH] cert-show: show subject alternative names Enhance the cert-show command to return subject alternative name values. Fixes: https://fedorahosted.org/freeipa/ticket/6022 --- ipaserver/plugins/cert.py | 80 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 79 insertions(+), 1 deletion(-) diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 207f6964645254ebc417cab80634a68911ae0a08..606d6cdbc28d30892ab60ad4aeb41ecbbd646589 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -38,7 +38,7 @@ from ipalib import ngettext from ipalib.constants import IPA_CA_CN from ipalib.crud import Create, PKQuery, Retrieve, Search from ipalib.frontend import Method, Object -from ipalib.parameters import Bytes, DateTime, DNParam, Principal +from ipalib.parameters import Bytes, DateTime, DNParam, DNSNameParam, Principal from ipalib.plugable import Registry from .virtual import VirtualCommand from .baseldap import pkey_to_value @@ -293,6 +293,61 @@ class BaseCertObject(Object): label=_('Serial number (hex)'), flags={'no_create', 'no_update', 'no_search'}, ), + Str( + 'san_rfc822name*', + label=_('Subject Alternative Name (Email)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + DNSNameParam( + 'san_dnsname*', + label=_('Subject Alternative Name (DNS)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_x400address*', + label=_('Subject Alternative Name (X.400 address)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_directoryname*', + label=_('Subject Alternative Name (Directory name)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_edipartyname*', + label=_('Subject Alternative Name (EDI Party name)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_uri*', + label=_('Subject Alternative Name (URI)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_ipaddress*', + label=_('Subject Alternative Name (IP Address)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_oid*', + label=_('Subject Alternative Name (OID)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Principal( + 'san_other_upn*', + label=_('Subject Alternative Name (UPN)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Principal( + 'san_other_kpn*', + label=_('Subject Alternative Name (Kerberos Principal)'), + flags={'no_create', 'no_update', 'no_search'}, + ), + Str( + 'san_other*', + label=_('Subject Alternative Name (Other Name)'), + flags={'no_create', 'no_update', 'no_search'}, + ), ) def _parse(self, obj): @@ -308,6 +363,29 @@ class BaseCertObject(Object): obj['serial_number'] = cert.serial_number obj['serial_number_hex'] = u'0x%X' % cert.serial_number + attr_name_map = { + nss.certRFC822Name: 'san_rfc822name', + nss.certDNSName: 'san_dnsname', + nss.certX400Address: 'san_x400address', + nss.certDirectoryName: 'san_directoryname', + nss.certEDIPartyName: 'san_edipartyname', + nss.certURI: 'san_uri', + nss.certIPAddress: 'san_ipaddress', + nss.certRegisterID: 'san_oid', + (nss.certOtherName, x509.SAN_UPN): 'san_other_upn', + (nss.certOtherName, x509.SAN_KRB5PRINCIPALNAME): 'san_other_kpn', + } + + try: + ext_san = cert.get_extension(nss.SEC_OID_X509_SUBJECT_ALT_NAME) + general_names = x509.decode_generalnames(ext_san.value) + except KeyError: + general_names = [] + + for name_type, desc, name in general_names: + attr_name = attr_name_map.get(name_type, 'san_other') + obj.setdefault(attr_name, []).append(unicode(name)) + class BaseCertMethod(Method): def get_options(self): -- 2.5.5 From ftweedal at redhat.com Fri Jul 22 05:18:07 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 22 Jul 2016 15:18:07 +1000 Subject: [Freeipa-devel] [PATCH] 0095 cert-request: allow directoryName in SAN extension Message-ID: <20160722051807.GJ10771@dhcp-40-8.bne.redhat.com> While I was poking around SAN-processing code, I decided to implement a small enhancement: allowing the subject principal's DN to appear in SAN. https://fedorahosted.org/freeipa/ticket/6112 Patch depends on my other patches 0090, 0092, 0093, 0094. Thanks, Fraser -------------- next part -------------- From 6a2ab7165c0ae600402c1c2794f2b10c9e38da05 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 22 Jul 2016 13:07:09 +1000 Subject: [PATCH] cert-request: allow directoryName in SAN extension Allow directoryName in SAN extension if the value matches the subject principal's DN in the IPA directory. Fixes: https://fedorahosted.org/freeipa/ticket/6112 --- ipaserver/plugins/cert.py | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ipaserver/plugins/cert.py b/ipaserver/plugins/cert.py index 606d6cdbc28d30892ab60ad4aeb41ecbbd646589..605fd321f00304f69347aae633f935dde8e59bdc 100644 --- a/ipaserver/plugins/cert.py +++ b/ipaserver/plugins/cert.py @@ -667,6 +667,12 @@ class cert_request(Create, BaseCertMethod, VirtualCommand): error=_("subject alt name type %s is forbidden " "for non-user principals") % desc ) + elif name_type == nss.certDirectoryName: + if DN(name) != principal_obj['dn']: + raise errors.ValidationError( + name='csr', + error=_("Directory Name does not match principal's DN") + ) else: raise errors.ACIError( info=_("Subject alt name type %s is forbidden") % desc) -- 2.5.5 From flo at redhat.com Fri Jul 22 08:08:23 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 22 Jul 2016 10:08:23 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix session cookies Message-ID: <8dae46a6-7c4f-c1c5-0e84-294f8fc59667@redhat.com> Hi, please find attached a patch related to session cookies used by IPA API. https://fedorahosted.org/freeipa/ticket/5984 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-frenaud-0012-Fix-session-cookies.patch Type: text/x-patch Size: 4540 bytes Desc: not available URL: From ldoudova at redhat.com Fri Jul 22 09:20:14 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 22 Jul 2016 11:20:14 +0200 Subject: [Freeipa-devel] [PATCH 0029][Tests] Adding authentication test to trust test suite In-Reply-To: <070a504c-fe7f-60de-7798-74210d102d0a@redhat.com> References: <2a1cdafa-b75e-7789-6834-a5197f159ea6@redhat.com> <070a504c-fe7f-60de-7798-74210d102d0a@redhat.com> Message-ID: <01508756-20fb-4b9b-90fd-55ada7d1e386@redhat.com> On 07/20/2016 02:28 PM, Martin Babinsky wrote: > On 07/19/2016 10:41 AM, Lenka Doudova wrote: >> Hi, >> >> >> this patch adds authentication test (specifically "kinit -E >> ipauser at IPADOMAIN") to basic trust test suite, as requested by Sumit. >> >> Intended to be applied after my patches 25.4 and 26.3 (already waiting >> to be pushed). >> >> >> Lenka >> >> >> > > Hi Lenka, > > Code review: > > 1.) You have several PEP8 transgressions in the patch, please fix them: > """ > $ git show -U0 | pep8 --diff > ./ipatests/test_integration/test_trust.py:172:34: E127 continuation > line over-indented for visual indent > ./ipatests/test_integration/test_trust.py:176:35: E128 continuation > line under-indented for visual indent > ./ipatests/test_integration/test_trust.py:180:27: E231 missing > whitespace after ',' > """ > > 2.) > + > + > +def unlock_principal_password(user, oldpw, newpw, master): > + container_user = "cn=users,cn=accounts" > + basedn = master.domain.basedn > + > + userdn = "uid={},{},{}".format(user, container_user, basedn) > + > + args = [paths.LDAPPASSWD, '-D', userdn, '-w', oldpw, '-a', oldpw, > + '-s', newpw, '-x'] > + return run(args) > > there is already a function with the same name in other module: > > """ > git grep -ni 'def unlock_principal_password' ipatests > ipatests/test_integration/util.py:82:def > unlock_principal_password(user, oldpw, newpw, master): > ipatests/util.py:676:def unlock_principal_password(user, oldpw, newpw): > """ > > Having functions with the same names in different modules makes for > poor coding practice IMHO. Please rename the function to something > like "ldappasswd_user" or something like that so that we have a > distinction. > > Also, you should call ldappasswd directly on master (since you pass it > as an argument anyway) using "master.run_command(args)". You should > *not* run any in-test code on the controller unless absolutely necessary. > > You can then remove the ipautil.run import from the beginning of the > module. > > Commit message woes: > > 1.) vague summary is vague, I would rather see something like: > > """ > test that IPA user can kinit using enterprise principal with IPA domain > """ > > 2.) Commit message body is longer than 78 characters. > > 3.) there is no ticket URL, I think you can link > https://fedorahosted.org/freeipa/ticket/6036 or create a new ticket > for the change. > Hi, thanks for review, fixed (and renamed) patch attached. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0029.2-Tests-IPA-user-can-kinit-using-enterprise-principal.patch Type: text/x-patch Size: 2914 bytes Desc: not available URL: From gkaihoro at redhat.com Fri Jul 22 10:11:33 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Fri, 22 Jul 2016 06:11:33 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests In-Reply-To: <7cac1261-820e-e120-8899-b41c8490e902@redhat.com> References: <1812744576.23182071.1469026923069.JavaMail.zimbra@redhat.com> <536349855.23231759.1469031459952.JavaMail.zimbra@redhat.com> <7cac1261-820e-e120-8899-b41c8490e902@redhat.com> Message-ID: <1268526445.28746430.1469182293442.JavaMail.zimbra@redhat.com> Hello! Thank you! Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Martin Basti" To: "Ganna Kaihorodova" Cc: freeipa-devel at redhat.com Sent: Thursday, July 21, 2016 8:03:53 PM Subject: Re: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests On 20.07.2016 18:17, Ganna Kaihorodova wrote: > Hello! > > Thank you for review. > I attached patch with fixed commit message > > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Martin Basti" > To: "Ganna Kaihorodova" , freeipa-devel at redhat.com > Sent: Wednesday, July 20, 2016 5:04:47 PM > Subject: Re: [Freeipa-devel] [PATCH 0002][Tests] Small fix for dns_plugin tests > > > > On 20.07.2016 17:02, Ganna Kaihorodova wrote: >> Greetings! >> >> Fix for ipatests/test_xmlrpc/test_dns_plugin.py >> >> Fix conflict between ?got? and ?expected? values when testing "dnsconfig_mod: Update global DNS settings" >> >> Best regards, >> Ganna Kaihorodova >> Associate Software Quality Engineer >> >> >> >> > LGTM, but can you fix commit message? > > This looks very suspicious > > Subject: [PATCH 2/2] =?UTF-8?q?Fix=20conflict=20between=20=E2=80=9Cgot?= > =?UTF-8?q?=E2=80=9D=20and=20=E2=80=9Cexpected=E2=80=9D=20values=20when=20?= > =?UTF-8?q?testing=20"dnsconfig=5Fmod:=20Update=20global=20DNS=20settings"?= > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > > regards, > Martin^2 ACK I just replaced some fancy unicode quotation marks with ASCII in commit message before push Pushed to master: 359cfeb7c6798038f5638f9d0977dda351f21431 From pspacek at redhat.com Fri Jul 22 11:07:13 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Jul 2016 13:07:13 +0200 Subject: [Freeipa-devel] [PATCH 0149] help: Add dnsserver commands to help topic 'dns' In-Reply-To: <8bf3db75-5639-5f2e-09a0-54457ab5f204@redhat.com> References: <8ba68b2a-af2f-ff4c-9621-05d207d71cdb@redhat.com> <8bf3db75-5639-5f2e-09a0-54457ab5f204@redhat.com> Message-ID: <93157272-25bc-dea9-9cd8-91fe88a3951b@redhat.com> On 15.7.2016 12:05, David Kupka wrote: > On 12/07/16 12:54, Petr Spacek wrote: >> Hello, >> >> help: Add dnsserver commands to help topic 'dns' >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1353888 >> > Hi! > > Your patch turns dnsserver topic to a subtopic of dns topic. I'm sorry I gave > you wrong advice. Attached patch makes dnsserver-* commands appear in dns topic. ACK, it works for me. -- Petr^2 Spacek From pspacek at redhat.com Fri Jul 22 11:24:13 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Jul 2016 13:24:13 +0200 Subject: [Freeipa-devel] [PATCH 0556] host-del: fix behavior of --updatedns and PTR records In-Reply-To: References: Message-ID: <0806aa1e-f866-ca6e-c480-f0516e6c6b06@redhat.com> On 21.7.2016 20:01, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/6060 > > > Patch attached. ACK -- Petr^2 Spacek From mbabinsk at redhat.com Fri Jul 22 11:27:27 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 22 Jul 2016 13:27:27 +0200 Subject: [Freeipa-devel] [PATCH 0195] Create indexes for krbCanonicalName attribute Message-ID: <283402fb-6f03-1e0a-8ed7-cdd9db8d7af0@redhat.com> https://fedorahosted.org/freeipa/ticket/6100 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0195-Create-indexes-for-krbCanonicalName-attribute.patch Type: text/x-patch Size: 1881 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 22 11:39:35 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Jul 2016 13:39:35 +0200 Subject: [Freeipa-devel] [PATCH 0557] DNS: fix update-system-records unpacking error Message-ID: https://fedorahosted.org/freeipa/ticket/6117 Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0557-DNS-Locations-fix-update-system-records-unpacking-er.patch Type: text/x-patch Size: 1461 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 22 11:41:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Jul 2016 13:41:54 +0200 Subject: [Freeipa-devel] [PATCH 0556] host-del: fix behavior of --updatedns and PTR records In-Reply-To: <0806aa1e-f866-ca6e-c480-f0516e6c6b06@redhat.com> References: <0806aa1e-f866-ca6e-c480-f0516e6c6b06@redhat.com> Message-ID: <1790c000-be06-2a10-1d7d-71ba175faf3a@redhat.com> On 22.07.2016 13:24, Petr Spacek wrote: > On 21.7.2016 20:01, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6060 >> >> >> Patch attached. > ACK > Pushed to master: 8aba4f63439853d524e8b394b7919159c86d2a08 From mbasti at redhat.com Fri Jul 22 11:53:50 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Jul 2016 13:53:50 +0200 Subject: [Freeipa-devel] [PATCH 0149] help: Add dnsserver commands to help topic 'dns' In-Reply-To: <93157272-25bc-dea9-9cd8-91fe88a3951b@redhat.com> References: <8ba68b2a-af2f-ff4c-9621-05d207d71cdb@redhat.com> <8bf3db75-5639-5f2e-09a0-54457ab5f204@redhat.com> <93157272-25bc-dea9-9cd8-91fe88a3951b@redhat.com> Message-ID: <54948f23-54b8-a714-946d-50c4a977578f@redhat.com> On 22.07.2016 13:07, Petr Spacek wrote: > On 15.7.2016 12:05, David Kupka wrote: >> On 12/07/16 12:54, Petr Spacek wrote: >>> Hello, >>> >>> help: Add dnsserver commands to help topic 'dns' >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1353888 >>> >> Hi! >> >> Your patch turns dnsserver topic to a subtopic of dns topic. I'm sorry I gave >> you wrong advice. Attached patch makes dnsserver-* commands appear in dns topic. > ACK, it works for me. > I replaced BZ with trac ticket in commit message Pushed to master: 34767ba25936700ba331fc5b7791ecd151083501 From tbordaz at redhat.com Fri Jul 22 12:37:14 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 22 Jul 2016 14:37:14 +0200 Subject: [Freeipa-devel] [PATCH 0195] Create indexes for krbCanonicalName attribute In-Reply-To: <283402fb-6f03-1e0a-8ed7-cdd9db8d7af0@redhat.com> References: <283402fb-6f03-1e0a-8ed7-cdd9db8d7af0@redhat.com> Message-ID: <5792137A.3050407@redhat.com> Hi Martin, The patch looks good. Just a question krbPrincipalName is caseExactIA5Match but is also indexed caseIgnoreIA5Match. Do you think it would be need for krbCanonicalName as well ? thanks thierry On 07/22/2016 01:27 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/6100 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndehadra at redhat.com Fri Jul 22 13:12:23 2016 From: ndehadra at redhat.com (Nikhil Dehadrai) Date: Fri, 22 Jul 2016 18:42:23 +0530 Subject: [Freeipa-devel] [PATCH 0557] DNS: fix update-system-records unpacking error In-Reply-To: References: Message-ID: <57921BB7.9090202@redhat.com> ACK. On 07/22/2016 05:09 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/6117 > > Patch attached > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Jul 22 13:17:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Jul 2016 15:17:43 +0200 Subject: [Freeipa-devel] [PATCH 0557] DNS: fix update-system-records unpacking error In-Reply-To: <57921BB7.9090202@redhat.com> References: <57921BB7.9090202@redhat.com> Message-ID: On 22.07.2016 15:12, Nikhil Dehadrai wrote: > ACK. > > On 07/22/2016 05:09 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6117 >> >> Patch attached >> >> >> > Thanks Pushed to master: 524719f420fa331b3a1d53d5d8bebdfee39c8371 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Fri Jul 22 13:43:03 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 22 Jul 2016 15:43:03 +0200 Subject: [Freeipa-devel] [PATCH 0195] Create indexes for krbCanonicalName attribute In-Reply-To: <5792137A.3050407@redhat.com> References: <283402fb-6f03-1e0a-8ed7-cdd9db8d7af0@redhat.com> <5792137A.3050407@redhat.com> Message-ID: <628e47fc-7790-a908-d759-28db52a4ee35@redhat.com> On 07/22/2016 02:37 PM, thierry bordaz wrote: > Hi Martin, > > The patch looks good. Just a question krbPrincipalName is > caseExactIA5Match but is also indexed caseIgnoreIA5Match. > Do you think it would be need for krbCanonicalName as well ? > > thanks > thierry > > > On 07/22/2016 01:27 PM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/6100 >> >> >> > krbPrincipalName is indexed with caseIgnoreIA5Match because it should be searched for case-insensitively when canonicalization is requested. krbCanonicalName is always searched for case-sensitively to retrieve correctly-cased canonical principal name. -- Martin^3 Babinsky From pspacek at redhat.com Fri Jul 22 13:47:10 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Jul 2016 15:47:10 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix session cookies In-Reply-To: <8dae46a6-7c4f-c1c5-0e84-294f8fc59667@redhat.com> References: <8dae46a6-7c4f-c1c5-0e84-294f8fc59667@redhat.com> Message-ID: <3fd8af5c-4047-b941-639a-0352a0a7ac47@redhat.com> On 22.7.2016 10:08, Florence Blanc-Renaud wrote: > Hi, > > please find attached a patch related to session cookies used by IPA API. > > https://fedorahosted.org/freeipa/ticket/5984 ACK -- Petr^2 Spacek From pspacek at redhat.com Fri Jul 22 13:49:31 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Jul 2016 15:49:31 +0200 Subject: [Freeipa-devel] [PATCH 0555] AVC: use copy during instalation to keep SELinux context valid In-Reply-To: <1aa08b94-cdbd-8f1f-b607-24e2e2366c4a@redhat.com> References: <1aa08b94-cdbd-8f1f-b607-24e2e2366c4a@redhat.com> Message-ID: <211a2468-3424-7bc4-6937-6a8096887883@redhat.com> On 21.7.2016 19:49, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/6111 > > I was able to reproduce this locally with vagrant, but I haven't been able to > reproduce this in LAB, I don't know where differences are (cloud vs desktop > fedora?) > > > Patch attached. ACK -- Petr^2 Spacek From mbabinsk at redhat.com Fri Jul 22 14:31:01 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 22 Jul 2016 16:31:01 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix session cookies In-Reply-To: <3fd8af5c-4047-b941-639a-0352a0a7ac47@redhat.com> References: <8dae46a6-7c4f-c1c5-0e84-294f8fc59667@redhat.com> <3fd8af5c-4047-b941-639a-0352a0a7ac47@redhat.com> Message-ID: <3774dcac-1cd2-e2b2-064f-c53a4960cca4@redhat.com> On 07/22/2016 03:47 PM, Petr Spacek wrote: > On 22.7.2016 10:08, Florence Blanc-Renaud wrote: >> Hi, >> >> please find attached a patch related to session cookies used by IPA API. >> >> https://fedorahosted.org/freeipa/ticket/5984 > > ACK > Pushed to: master: bc7eb99a2959980c1abf31f77610cec2f098744b ipa-4-3: 268d835556e677c80501349fc96a531ccd63f3f6 -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Jul 22 14:38:18 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 22 Jul 2016 16:38:18 +0200 Subject: [Freeipa-devel] [PATCH 0555] AVC: use copy during instalation to keep SELinux context valid In-Reply-To: <211a2468-3424-7bc4-6937-6a8096887883@redhat.com> References: <1aa08b94-cdbd-8f1f-b607-24e2e2366c4a@redhat.com> <211a2468-3424-7bc4-6937-6a8096887883@redhat.com> Message-ID: <8e300565-f41a-fbce-f9a3-7806f5237c2b@redhat.com> On 07/22/2016 03:49 PM, Petr Spacek wrote: > On 21.7.2016 19:49, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6111 >> >> I was able to reproduce this locally with vagrant, but I haven't been able to >> reproduce this in LAB, I don't know where differences are (cloud vs desktop >> fedora?) >> >> >> Patch attached. > > ACK > Patch needs a rebase for ipa-4-3. -- Martin^3 Babinsky From mbasti at redhat.com Fri Jul 22 14:45:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Jul 2016 16:45:49 +0200 Subject: [Freeipa-devel] [PATCH 0555] AVC: use copy during instalation to keep SELinux context valid In-Reply-To: <8e300565-f41a-fbce-f9a3-7806f5237c2b@redhat.com> References: <1aa08b94-cdbd-8f1f-b607-24e2e2366c4a@redhat.com> <211a2468-3424-7bc4-6937-6a8096887883@redhat.com> <8e300565-f41a-fbce-f9a3-7806f5237c2b@redhat.com> Message-ID: <493c4147-0937-861c-5a36-68e4ed00058a@redhat.com> On 22.07.2016 16:38, Martin Babinsky wrote: > On 07/22/2016 03:49 PM, Petr Spacek wrote: >> On 21.7.2016 19:49, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/6111 >>> >>> I was able to reproduce this locally with vagrant, but I haven't >>> been able to >>> reproduce this in LAB, I don't know where differences are (cloud vs >>> desktop >>> fedora?) >>> >>> >>> Patch attached. >> >> ACK >> > Patch needs a rebase for ipa-4-3. > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.3-mbasti-0555-Use-copy-when-replacing-files-to-keep-SELinux-contex.patch Type: text/x-patch Size: 1058 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0555-Use-copy-when-replacing-files-to-keep-SELinux-contex.patch Type: text/x-patch Size: 1068 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Jul 22 14:48:24 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 22 Jul 2016 16:48:24 +0200 Subject: [Freeipa-devel] [PATCH 0555] AVC: use copy during instalation to keep SELinux context valid In-Reply-To: <493c4147-0937-861c-5a36-68e4ed00058a@redhat.com> References: <1aa08b94-cdbd-8f1f-b607-24e2e2366c4a@redhat.com> <211a2468-3424-7bc4-6937-6a8096887883@redhat.com> <8e300565-f41a-fbce-f9a3-7806f5237c2b@redhat.com> <493c4147-0937-861c-5a36-68e4ed00058a@redhat.com> Message-ID: <069b55bf-c1b1-6803-beb6-95943c6f19da@redhat.com> On 07/22/2016 04:45 PM, Martin Basti wrote: > > > On 22.07.2016 16:38, Martin Babinsky wrote: >> On 07/22/2016 03:49 PM, Petr Spacek wrote: >>> On 21.7.2016 19:49, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/6111 >>>> >>>> I was able to reproduce this locally with vagrant, but I haven't >>>> been able to >>>> reproduce this in LAB, I don't know where differences are (cloud vs >>>> desktop >>>> fedora?) >>>> >>>> >>>> Patch attached. >>> >>> ACK >>> >> Patch needs a rebase for ipa-4-3. >> > Pushed to: master: f8bf8a62402a4385a7cc2f73b37b654b47713d60 ipa-4-3: 64bbbb52a20200025017d0b29c9fa2dcdd7ad83d -- Martin^3 Babinsky From pspacek at redhat.com Fri Jul 22 14:50:08 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Jul 2016 16:50:08 +0200 Subject: [Freeipa-devel] [PATCH 0432] Prevent crash while reloading an invalid DNS zone Message-ID: Hello, Prevent crash while reloading an invalid DNS zone. The crash happened under these circumstances: - create a DNS zone (test.) with NS record relative to this zone (ns.test.) - make sure that name pointed to by NS record does not have any A/AAAA records - restart BIND - add missing A/AAAA record to ns.test. -> CRASH! https://fedorahosted.org/bind-dyndb-ldap/ticket/166 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0432-Prevent-crash-while-reloading-an-invalid-DNS-zone.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 22 16:13:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Jul 2016 18:13:09 +0200 Subject: [Freeipa-devel] [PATCH 0553] CI tests: improve log collecting in tests In-Reply-To: <2dc7f75b-c0c4-e656-0cff-359696e2d05c@redhat.com> References: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> <21a9655a-3943-67ac-3a8f-0a81dae37de3@redhat.com> <2dc7f75b-c0c4-e656-0cff-359696e2d05c@redhat.com> Message-ID: On 20.07.2016 17:41, Martin Basti wrote: > > > > On 19.07.2016 17:05, Martin Basti wrote: >> >> >> >> On 19.07.2016 16:18, Martin Basti wrote: >>> Patch attached. >>> >>> >>> >> self-NACK, my assumptions were wrong, this doesn't work if any of log >> files do not exist >> >> > updated patches attached > > Please note, that in case that any logfile does not exist tar returns > exit code 2, but provides correct output anyway. > > Updated patches attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0554.3-CI-tests-fix-SSSD-log-collecting.patch Type: text/x-patch Size: 2013 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0553.3-CI-tests-improve-log-collecting.patch Type: text/x-patch Size: 4872 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 22 17:07:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Jul 2016 19:07:34 +0200 Subject: [Freeipa-devel] [PATCH 0432] Prevent crash while reloading an invalid DNS zone In-Reply-To: References: Message-ID: <991bf60a-e82b-c2d6-4641-b4d15a848d86@redhat.com> On 22.07.2016 16:50, Petr Spacek wrote: > Hello, > > Prevent crash while reloading an invalid DNS zone. > > The crash happened under these circumstances: > - create a DNS zone (test.) with NS record relative to this zone (ns.test.) > - make sure that name pointed to by NS record does not have any A/AAAA records > - restart BIND > - add missing A/AAAA record to ns.test. > -> CRASH! > > https://fedorahosted.org/bind-dyndb-ldap/ticket/166 > ACK From pvoborni at redhat.com Sun Jul 24 09:10:04 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Sun, 24 Jul 2016 11:10:04 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.3.2 Message-ID: <6ce714d0-3b69-33f0-e8df-386b6a044e55@redhat.com> The FreeIPA team would like to announce FreeIPA v4.3.2 bug fixing release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora 24 and rawhide. Experimental builds for CentOS 7 will be available in the official FreeIPA CentOS7 COPR repository This announcement is also available on http://www.freeipa.org/page/Releases/4.3.2 Fedora 24 update: https://bodhi.fedoraproject.org/updates/freeipa-4.3.2-1.fc24 == Highlights in 4.3.2 == === Enhancements === * added possibility to list/clean dangling RUV records for o=ipaca suffix https://fedorahosted.org/freeipa/ticket/4987 * --domain-level of `ipa-server-install` was deprecated https://fedorahosted.org/freeipa/ticket/5907 === Bug fixes === * fixed upgrade bug on servers without CA https://fedorahosted.org/freeipa/ticket/5958 * fixed installation of server with DNS if A record didn't exist https://fedorahosted.org/freeipa/ticket/5962 * fixed issue where A/AAAA DNS records were not created for CA https://fedorahosted.org/freeipa/ticket/5966 * fixed installation of CA less replica on domain level 1 https://fedorahosted.org/freeipa/ticket/5721 * fixed forward zone conflicts with automatic empty zones from BIND https://fedorahosted.org/freeipa/ticket/5710 * fixed race condition with multiple simultaneous request from the same principal https://fedorahosted.org/freeipa/ticket/5653 == 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.3.2 == === Abhijeet Kasurde (2) === * Added description related to 'status' in ipactl man page * Updated ipa command man page === Alexander Bokovoy (1) === * otptoken: support Python 3 for the qr code === David Kupka (3) === * man: Decribe ipa-client-install workaround for broken D-Bus enviroment. * installer: positional_arguments must be tuple or list of strings * installer: index() raises ValueError === Florence Blanc-Renaud (2) === * Do not allow installation in FIPS mode * Fix session cookies === Fraser Tweedale (5) === * caacl: correctly handle full user principal name * Prevent replica install from overwriting cert profiles * Detect and repair incorrect caIPAserviceCert config * upgrade: do not try to start CA if not configured * Move normalize_hostname to where it is expected === Jan Cholasta (4) === * spec file: bump minimum required pki-core version * build: fix client-only build * makeapi: use the same formatting for `int` and `long` values * replica install: do not set CA renewal master flag === Lenka Doudova (2) === * WebUI: Test creating user without private group * Test fix: Cleanup for host certificate === Martin Babinsky (1) === * replica-prepare: do not add PTR records if there is no IPA managed reverse zone === Martin Ba?ti (18) === * Add missing pre_common_callback to stageuser_add * Revert "ipatests: extend permission plugin test with new expected output" * make: fail when ACI.txt or API.txt differs from values in source code * Upgrade: always start CA * Set proper zanata project-version * Translations: remove deprecated locale configuration * Test: fix failing host_test * Fix: exceptions in DNS tests should not have data attribute * Translations: update translations for IPA 4.3.x * Fix resolve_rrsets: RRSet is not hashable * Translations: update ipa-4-3 translations * Revert "Switch /usr/bin/ipa to Python 3" * Use python2 for ipa cli * Replica promotion: use the correct IPA domain for replica * CA replica promotion: add proper CA DNS records * CA replica promotion: fix forgotten import * Fix replica install with CA * Use copy when replacing files to keep SELinux context === Milan Kub?k (3) === * ipatests: fix for change_principal context manager * ipatests: Add test case for requesting a certificate with full principal. * spec: Add python-sssdconfig dependency for python-ipatests package === Oleg Fayans (9) === * Added a kdestroy call to clean ccache at master/client uninstallation * Added 5 more tests to Replica Promotion testsuite * Fixed a failure in legacy_client tests * Add test if replica is working after domain upgrade * Improve reporting of failed tests in topology test suite * Bugfixes in managed topology tests * A workaround for ticket N 5348 * Increased certmonger timeout * Test for incorrect client domain === Pavel Vomacka (3) === * Add X-Frame-Options and frame-ancestors options * Add 'skip overlap check' checkbox into add zone dialog * Add 'skip overlap check' checkbox to the add dns forward zone dialog === Petr Viktorin (23) === * dns plugin: Fix zone normalization under Python 3 * sysrestore: Iterate over a list of dict keys * test_xmlrpc: Use absolute imports * xmlrpc_test: Rename exception instance before working with it * radiusproxy plugin: Use str(error) rather than error.message * xmlrpc_test: Expect bytes rather than strings for binary attributes * ipalib.rpc: Send base64-encoded data as string under Python 3 * range plugin tests: Use bytes with MockLDAP under Python 3 * radiusproxy plugin tests: Expect bytes, not text, for ipatokenradiussecret * certprofile plugin: Use binary mode for file with binary data * test_add_remove_cert_cmd: Use bytes for base64.b64encode() * Switch /usr/bin/ipa to Python 3 * Fix remaining relative import and enable Pylint check * ipalib.cli: Improve reporting of binary values in the CLI * test_cert_plugin: Encode 'certificate' for comparison with 'usercertificate' * ipaldap: Keep attribute names as text, not bytes * ipapython.secrets.kem: Use ConfigParser from six.moves * test_topology_plugin: Don't rely on order of an attribute's values * test_rpcserver: Expect updated error message under Python 3 * ipaplatform.redhat: Use bytestrings when calling rpm.so for version comparison * test_ipaserver.test_ldap: Use bytestrings for raw LDAP values * ipaldap: Convert dict items to list before iterating * test_ipaserver.test_ldap: Adjust tests to Python 3's KeyView === Petr Voborn?k (2) === * mod_auth_gssapi: enable unique credential caches names * Become IPA 4.3.2 === Petr ?pa?ek (30) === * Remove function ipapython.ipautil.host_exists() * Extend installers with --forward-policy option * Move automatic empty zone list into ipapython.dnsutil and make it reusable * Add assert_absolute_dnsname() helper to ipapython.dnsutil * Move function is_auto_empty_zone() into ipapython.dnsutil * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * Add function ipapython.dnsutil.inside_auto_empty_zone() * Auto-detect default value for --forward-policy option in installers * DNS: Fix upgrade - master to forward zone transformation * DNS installer: accept --auto-forwarders option in unattended mode * Batch command: avoid accessing potentially undefined context.principal * Move check_zone_overlap() from ipapython.ipautil to ipapython.dnsutil * Use root_logger for verify_host_resolvable() * Move IP address resolution from ipaserver.install.installutils to ipapython.dnsutil * Turn verify_host_resolvable() into a wrapper around ipapython.dnsutil * Add ipaDNSVersion option to dnsconfig* commands and use new attribute * DNS upgrade: separate backup logic to make it reusable * Add function ipapython.dnsutil.related_to_auto_empty_zone() * DNS upgrade: change forwarding policy to = only for conflicting forward zones * DNS upgrade: change global forwarding policy in LDAP to "only" if private IPs are used * DNS upgrade: change global forwarding policy in named.conf to "only" if private IPs are used * DNS: Warn if forwarding policy conflicts with automatic empty zones * DNS: Fix realm domains integration with DNS zone add. * client: Share validator and domain name normalization with server install * DNS: Fix tests for realm domains integration with DNS zone add * client-install: do not fail if DNS times out during DNS update generation * Use NSS for name->resolution in IPA installer * DNS: Remove unnecessary DNS check from installer * Remove unused is_local(), interface, and defaultnet from CheckedIPAddress * Fix internal errors in host-add and other commands caused by DNS resolution === Stanislav Laznicka (9) === * replica-manage: fail nicely when DM psswd required * ipa-replica-manage refactoring * abort-clean/list/clean-ruv now work for both suffixes * Moved password check from clean_dangling_ruv * Fix to clean-dangling-ruv for single CA topologies * Added pyusb as a dependency * Deprecated the domain-level option in ipa-server-install * fixes premature sys.exit in ipa-replica-manage del * Remove dangling RUVs even if replicas are offline === Thierry Bordaz (1) === * Make sure ipapwd_extop takes precedence over passwd_modify_extop -- Petr Vobornik From jcholast at redhat.com Mon Jul 25 08:50:24 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Jul 2016 10:50:24 +0200 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> Message-ID: <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> On 20.7.2016 16:05, Ben Lipton wrote: > Hi, > > Thanks very much for the feedback! Some responses below; I hope you'll > let me know what you think of my reasoning. > > > On 07/20/2016 04:20 AM, Jan Cholasta wrote: >> Hi, >> >> On 17.6.2016 00:06, Ben Lipton wrote: >>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>> Hello all, >>>> >>>> I have written up a design proposal for making certificate requests >>>> easier to generate when using alternate certificate profiles: >>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>> >>>> The use case for this is described in >>>> https://fedorahosted.org/freeipa/ticket/4899. I will be working on >>>> implementing this design over the next couple of months. If you have >>>> the time and interest, please take a look and share any comments or >>>> concerns that you have. >>>> >>>> Thanks! >>>> >>>> Ben >>>> >>> Just a quick update to say that I've created a new document that covers >>> the proposed schema additions in a more descriptive way (with diagrams!) >>> I'm very new to developing with LDAP, so some more experienced eyes on >>> the proposal would be very helpful, even if you don't have time to >>> absorb the full design. Please take a look at >>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>> >>> if you have a chance. >> >> I finally had a chance to take a look at this, here are some comments: >> >> 1) I don't like how transformation rules are tied to a particular >> helper and have to be duplicated for each of them. They should be >> generic and work with any helper, as helpers are just an >> implementation detail and their resulting data is the same. >> >> In fact, I think I would prefer if the CSR was generated using >> python-cryptography's CertificateSigningRequestBuilder [1] rather than >> openssl or certutil or any other command line tool. >> > There are lots of tools that users might want to use to manage their > private keys, so I don't know if we can assume that whatever library we > prefer will actually be able to access the private key to sign a CSR, > which is why I thought it would be useful to support more than one. python-cryptography has the notion of backends, which allow it to support multiple crypto implementations. Upstream it currently supports only OpenSSL [2], but some work has been done on PKCS#11 backend [3], which provides support for HSMs and soft-tokens (like NSS databases). Alternatively, for NSS databases (and other "simple" cases), you can generate the private key with python-cryptography using the default backend, export it to a file and import the file to the target database, so you don't actually need the PKCS#11 backend for them. So, the only thing that's currently lacking is HSM support, but given that we don't support HSMs in IPA nor in certmonger, I don't think it's an issue for now. > The > purpose of the mapping rule is to tie together the transformation rules > that produce the same data into an object that's > implementation-agnostic, so that profiles referencing those rules are > automatically compatible with all the helper options. They are implementation-agnostic, as long as you consider `openssl` and `certutil` the only implementations :-) But I don't think this solution scales well to other possible implementations. Anyway, my main grudge is that the transformation rules shouldn't really be stored on and processed by the server. The server should know the *what* (mapping rules), but not the *how* (transformation rules). The *how* is an implementation detail and does not change in time, so there's no benefit in handling it on the server. It should be handled exclusively on the client, which I believe would also make the whole thing more robust (it would not be possible for a bug on the server to break all the clients). > > I do agree that it would be preferable to target APIs rather than > command-line tools. When looking at the openSSL and NSS APIs I came to > the conclusion that they would be more difficult than the command-line > tools to target, as a first implementation. However, I haven't really > looked at python-cryptography, and maybe it would have been a good choice. The current trend is to port all crypto code to python-cryptography, so it is indeed a good choice :-) >> >> 2) The schema seems unnecessarily complex. I think all we need is a >> single new multi-value attribute in certprofile. For your S/MIME >> example, it could be something like: >> >> attr: subjectname=CN={subject.cn},{subject_base} >> attr: san_rfc822name={subject.email} >> attr: san_directoryname={subject.dn} > > This is turning out to be a common (and, I think, reasonable) reaction > to the proposal. It is rather complex, and I worry that it will be > difficult to configure. On the other hand, there is some hidden > complexity to enabling a simpler config format, as well. One of the > goals of the project as it was presented to me was to allow the creation > of profiles that add certificate extensions *that FreeIPA doesn't yet > know about*. With the current proposal, one only has to add a rule > generating text that the helper will understand. ... which will be possible only as long as the helper understands the extension. Which it might not, thus the current proposal works only for *some* extensions that FreeIPA doesn't yet support. > With your suggestion, > if there's a mapping between "san_directoryname" and the corresponding > API calls or configuration lines, we need some way for users to augment > that mapping without changing the code. If there's no mapping, and it's > just done with text processing, we need enough in the config format to > be able to generate fairly complex structures: > > builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) > builder = > builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), > x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) > > and we need to do it without it being equivalent to calling eval() on > the config attributes. I'm not sure how to achieve this (is it safe to > call getattr(x509, extensiontype)(value) where extensiontype and value > are user-specified?) and it definitely would have to be tied to a > particular library/tool. As I pointed out above, this needs to be figured out for the generic case for both the current proposal and my suggestion. OTOH, I think we could use GSER encoding of the extension value: { rfc822Name:"user at example.com", directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } > > Ben >> >> >> Honza >> >> [1] >> [2] [3] -- Jan Cholasta From jcholast at redhat.com Mon Jul 25 08:53:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Jul 2016 10:53:07 +0200 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: <60f90568-e517-8516-7c93-491d9bd20758@redhat.com> References: <1469010462.21393.47.camel@redhat.com> <1469025427.21393.51.camel@redhat.com> <514956a4-14f7-5816-23cd-d1ce1e3d28fa@redhat.com> <1469031696.21393.55.camel@redhat.com> <60f90568-e517-8516-7c93-491d9bd20758@redhat.com> Message-ID: <77d95052-ce19-f5db-0fc6-f2da17c64365@redhat.com> On 21.7.2016 17:43, Petr Spacek wrote: > On 20.7.2016 19:25, Ben Lipton wrote: >> On 07/20/2016 12:21 PM, Simo Sorce wrote: >>> On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote: >>>> On 07/20/2016 10:37 AM, Simo Sorce wrote: >>>>> On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: >>>>>> On 07/20/2016 06:27 AM, Simo Sorce wrote: >>>>>>> On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have updated the design page >>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_ >>>>>>>> Gene >>>>>>>> rati >>>>>>>> on/Mapping_Rules >>>>>>>> with my plan for implementing user-configurable rules for >>>>>>>> mapping >>>>>>>> IPA >>>>>>>> data into certificate requests. In brief: we will use Jinja2 >>>>>>>> for >>>>>>>> templating. Data rules (which map individual data items) and >>>>>>>> syntax >>>>>>>> rules (which group them into certificate fields) will both be >>>>>>>> snippets >>>>>>>> of Jinja2 markup. The formatting process will be as follows: > > I've finally found some time to read the sub-page Mapping_Rules and for me it > is kind of hard to follow. It would not be understandable without this e-mail > and the blog posts (BTW the blog articles are among best I have seen!). > > Most importantly, the explanations in brackets above ["Data rules (which map > individual data items) and (which group them into certificate fields)"] are > missing in the wiki page itself :-) > > Could you fold relevant parts of the e-mails and blogs back into the wiki page > so it is self-contained? > > Besides this nit, > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation > sounds reasonable. I like how it prevents bad data from template-injection. > > Regarding > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A > , I prefer Option A with separate object for each helper. It is somehow > cleaner and it might be useful to use distinct object classes for each helper etc. > > > API for ipa cert-get-requestdata sounds good. > API for ipa cert-request makes sense to me as well. > > In any case I would recommend you to consult API design with Jan Cholasta > - he is our API custodian. See the other thread for my comments: . > > > BTW I very much like "Alternatives considered" sections, we should have this > for each design! > > Good work, I really like the dutiful analysis! > > > >>>>>>>> 1. Syntax rules will be rendered using Jinja2. Data rules >>>>>>>> (rule >>>>>>>> text, >>>>>>>> not rendered) will be passed as the datarules attribute. >>>>>>>> 2. Rendered syntax rules will be processed by the Formatter >>>>>>>> class >>>>>>>> for >>>>>>>> the selected CSR generation helper (e.g. openssl or >>>>>>>> certutil). >>>>>>>> The >>>>>>>> formatter combines these partial rules into a full template >>>>>>>> for >>>>>>>> the >>>>>>>> config. >>>>>>>> 3. The template will be rendered using Jinja2. Relevant data >>>>>>>> from >>>>>>>> the >>>>>>>> IPA database will be available in the context for this >>>>>>>> rendering. >>>>>>>> 4. The final rendered template will be returned to the >>>>>>>> caller, >>>>>>>> labeled >>>>>>>> with its function (e.g. a command line or a config file). >>>>>>>> >>>>>>>> Are there any comments or objections to this approach? Here's >>>>>>>> an >>>>>>>> example >>>>>>>> to show what it might look like in practice. >>>>>>>> >>>>>>>> Example data rules: >>>>>>>> email={{subject.email}} >>>>>>>> O={{config.ipacertificatesubjectbase}}\nCN={{subject.username >>>>>>>> }} >>>>>>>> >>>>>>>> Example syntax rule: >>>>>>>> subjectAltName=@{% section %}{{datarules|join('\n')}}{% >>>>>>>> endsection %} >>>>>>>> >>>>>>>> Example composed config template: >>>>>>>> [ req ] >>>>>>>> prompt = no >>>>>>>> encrypt_key = no >>>>>>>> >>>>>>>> distinguished_name = {% section >>>>>>>> %}O={{config.ipacertificatesubjectbase}} >>>>>>>> CN={{subject.username}}{% endsection %} >>>>>>>> >>>>>>>> req_extensions = exts >>>>>>>> >>>>>>>> [ exts ] >>>>>>>> subjectAltName=@{% section %}email={{subject.email}}{% >>>>>>>> endsection >>>>>>>> %} >>>>>>>> >>>>>>>> There's a lot more information about the thinking behind this >>>>>>>> at >>>>>>>> http://blog.benjaminlipton.com/2016/07/19/csr-generation-temp >>>>>>>> lati >>>>>>>> ng.h >>>>>>>> tml >>>>>>>> if you're interested, as well. >>>>>>> Nice work Ben, >>>>>>> it's been really nice to be able to follow your notes on the >>>>>>> blog >>>>>>> post, >>>>>>> one question remains lingering in my head, why jinja2 ? >>>>>>> I know that engine relatively well as I used it in ipsilon, so >>>>>>> I am >>>>>>> not >>>>>>> questioning the choice just asking why specifically jinja2 and >>>>>>> not >>>>>>> something else, potentially language agnostic. >>>>>>> >>>>>>> Simo. >>>>>> Honestly, my reasoning didn't go very far beyond that it seems to >>>>>> be >>>>>> widely used and is compatible with python, which is the language >>>>>> where >>>>>> the implementation is taking place (in the IPA RPC server). I >>>>>> thought >>>>>> about using the built-in python format strings or creating a >>>>>> simple >>>>>> domain-specific language, but the likelihood of wanting the >>>>>> built-in >>>>>> text processing features (join, replace, maybe even for loops) >>>>>> seemed >>>>>> high, and I didn't want to reimplement those features. >>>>>> >>>>>> Will the additional package dependency be a problem? >>>>> I am more concerned a out the ability to process the data (which I >>>>> guess is stored in LDAP) by another client, or in the CLI. >>>>> Other than that the dependency does not concern me too much >>>>> provided >>>>> jinja2 templating is stable and has some guarantee that it will be >>>>> supportable long term. >>>>> >>>>> If that is not guaranteed it is a problem, we cannot easily swap >>>>> out >>>>> one language for another once data is stored and used by the >>>>> server. >>>>> So the most important consideration for me is whether we are >>>>> locking >>>>> ourselves into something that will be hard to deal with later or >>>>> not. >>>>> >>>>> Should the jinja2 project fail by the wayside next year would we be >>>>> able to easily replace it with another engine without changing the >>>>> templates as stored ? >>>>> >>>>> Simo. >>>>> >>>> Ah, ok, I understand the concern. For now, the plan is that the >>>> server >>>> will do all the text processing, so I don't really forsee a need for >>>> any >>>> other client to read the mapping rules from LDAP. However, it's true >>>> that templates written in jinja2 would probably need at least minor >>>> changes to be compatible with another templating engine. (Same goes >>>> for >>>> any other choice - a lot of these engines seem to have very similar, >>>> but >>>> not exactly compatible, syntax). I don't really know how to judge >>>> the >>>> long-term viability of the jinja2 project, though it seems to be >>>> recognized by lots of projects (ansible[1], openstack[2], flask[3], >>>> even >>>> django[4] which has its own templating engine). > > Other big users are exactly the reason why I consider Jinja2 to be a good > choice. After all, if Jinja2 dies upstream we will not be alone :-) > > Petr^2 Spacek > >>>> In any case, if the team prefers it, I'd be comfortable going with a >>>> more minimal DSL that only has the features we know we need. It >>>> might >>>> slightly limit the types of certs that can be generated, but that can >>>> be >>>> iterated on. But it would be another thing to design, build and >>>> maintain. Let me know what you think. >>> I am ok using jinja2 as long as we realize we may be on the hook for >>> maintaining it ourselves in the long term. It's probably easier to do >>> that than to write our own anyway. >>> >>> Simo. >> It might also be worth pointing out that although the examples in the document >> are based on jinja2, the overall approach should be pretty compatible with >> other (existing or custom) template languages. So we're not locked into jinja2 >> in that way, it's just the rules in deployed databases that would be tough to >> convert. -- Jan Cholasta From simo at redhat.com Mon Jul 25 09:07:50 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 05:07:50 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> Message-ID: <1469437670.18067.62.camel@redhat.com> On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > Anyway, my main grudge is that the transformation rules shouldn't > really > be stored on and processed by the server. The server should know the > *what* (mapping rules), but not the *how* (transformation rules). The > *how* is an implementation detail and does not change in time, so > there's no benefit in handling it on the server. It should be handled > exclusively on the client, which I believe would also make the whole > thing more robust (it would not be possible for a bug on the server > to > break all the clients). W/o entering in specific +1 as a general comment on this. If it can be done on the client, probably better be done there. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Jul 25 09:11:08 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 05:11:08 -0400 Subject: [Freeipa-devel] PATCH: Improve on #2795 patches In-Reply-To: <882ecdca-3b06-ee93-f0be-7d7b6751aa08@redhat.com> References: <1469009512.21393.44.camel@redhat.com> <882ecdca-3b06-ee93-f0be-7d7b6751aa08@redhat.com> Message-ID: <1469437868.18067.64.camel@redhat.com> On Wed, 2016-07-20 at 15:17 +0200, David Kupka wrote: > On 20/07/16 12:11, Simo Sorce wrote: > > Attached patch introduces a helper function and avoids the questionable > > replace+delete operations where possible (still employed in the > > entry_to_mods function). > > Compiles and I am about to test it, but I'd like feedback on it if > > anyone wants to take a look. > > > > Simo. > > > > > > > > Looks and works good, ACK. > Pushed to master: ab4fcb0fe25e313c93caae3b90f68b4010a9f2eb Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Jul 25 09:17:47 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Jul 2016 12:17:47 +0300 Subject: [Freeipa-devel] [PATCH] 0083: webui: remove full name column from user to user group adder dialog In-Reply-To: <505f8376-d7ec-1652-285d-87a5afeaeeb3@redhat.com> References: <505f8376-d7ec-1652-285d-87a5afeaeeb3@redhat.com> Message-ID: <20160725091747.3x3cijajnxb6yz4o@redhat.com> On Thu, 21 Jul 2016, Pavel Vomacka wrote: >Remove full name from adding user to user group dialog > >As the 'cn' is not in the response of user-show there is empty column >in adder dialog. >Therefore the column was removed. > >https://fedorahosted.org/freeipa/ticket/6055 ACK. -- / Alexander Bokovoy From simo at redhat.com Mon Jul 25 09:46:59 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 05:46:59 -0400 Subject: [Freeipa-devel] [PATCHES] Coverity fixes Message-ID: <1469440019.18067.66.camel@redhat.com> The attached patches fix some minor issues found by coverity, and pull in other fixes released by the asn1c project. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-567-1-Regenerate-asn1-code.patch Type: text/x-patch Size: 135687 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-568-1-Additional-coverity-fixes.patch Type: text/x-patch Size: 3324 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Jul 25 10:22:53 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 Jul 2016 12:22:53 +0200 Subject: [Freeipa-devel] [PATCH 0029][Tests] Adding authentication test to trust test suite In-Reply-To: <01508756-20fb-4b9b-90fd-55ada7d1e386@redhat.com> References: <2a1cdafa-b75e-7789-6834-a5197f159ea6@redhat.com> <070a504c-fe7f-60de-7798-74210d102d0a@redhat.com> <01508756-20fb-4b9b-90fd-55ada7d1e386@redhat.com> Message-ID: On 07/22/2016 11:20 AM, Lenka Doudova wrote: > > > On 07/20/2016 02:28 PM, Martin Babinsky wrote: >> On 07/19/2016 10:41 AM, Lenka Doudova wrote: >>> Hi, >>> >>> >>> this patch adds authentication test (specifically "kinit -E >>> ipauser at IPADOMAIN") to basic trust test suite, as requested by Sumit. >>> >>> Intended to be applied after my patches 25.4 and 26.3 (already waiting >>> to be pushed). >>> >>> >>> Lenka >>> >>> >>> >> >> Hi Lenka, >> >> Code review: >> >> 1.) You have several PEP8 transgressions in the patch, please fix them: >> """ >> $ git show -U0 | pep8 --diff >> ./ipatests/test_integration/test_trust.py:172:34: E127 continuation >> line over-indented for visual indent >> ./ipatests/test_integration/test_trust.py:176:35: E128 continuation >> line under-indented for visual indent >> ./ipatests/test_integration/test_trust.py:180:27: E231 missing >> whitespace after ',' >> """ >> >> 2.) >> + >> + >> +def unlock_principal_password(user, oldpw, newpw, master): >> + container_user = "cn=users,cn=accounts" >> + basedn = master.domain.basedn >> + >> + userdn = "uid={},{},{}".format(user, container_user, basedn) >> + >> + args = [paths.LDAPPASSWD, '-D', userdn, '-w', oldpw, '-a', oldpw, >> + '-s', newpw, '-x'] >> + return run(args) >> >> there is already a function with the same name in other module: >> >> """ >> git grep -ni 'def unlock_principal_password' ipatests >> ipatests/test_integration/util.py:82:def >> unlock_principal_password(user, oldpw, newpw, master): >> ipatests/util.py:676:def unlock_principal_password(user, oldpw, newpw): >> """ >> >> Having functions with the same names in different modules makes for >> poor coding practice IMHO. Please rename the function to something >> like "ldappasswd_user" or something like that so that we have a >> distinction. >> >> Also, you should call ldappasswd directly on master (since you pass it >> as an argument anyway) using "master.run_command(args)". You should >> *not* run any in-test code on the controller unless absolutely necessary. >> >> You can then remove the ipautil.run import from the beginning of the >> module. >> >> Commit message woes: >> >> 1.) vague summary is vague, I would rather see something like: >> >> """ >> test that IPA user can kinit using enterprise principal with IPA domain >> """ >> >> 2.) Commit message body is longer than 78 characters. >> >> 3.) there is no ticket URL, I think you can link >> https://fedorahosted.org/freeipa/ticket/6036 or create a new ticket >> for the change. >> > Hi, > > thanks for review, fixed (and renamed) patch attached. > > Lenka Thanks, ACK. Pushed to master: 648b5afa2f2d01d99c1cf2d1f4a87a5da4461246 -- Martin^3 Babinsky From abokovoy at redhat.com Mon Jul 25 11:11:23 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Jul 2016 14:11:23 +0300 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> Message-ID: <20160725111123.qthtarfgcsfbdnzk@redhat.com> On Mon, 25 Jul 2016, Jan Cholasta wrote: >On 20.7.2016 16:05, Ben Lipton wrote: >>Hi, >> >>Thanks very much for the feedback! Some responses below; I hope you'll >>let me know what you think of my reasoning. >> >> >>On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>Hi, >>> >>>On 17.6.2016 00:06, Ben Lipton wrote: >>>>On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>Hello all, >>>>> >>>>>I have written up a design proposal for making certificate requests >>>>>easier to generate when using alternate certificate profiles: >>>>>http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>> >>>>>The use case for this is described in >>>>>https://fedorahosted.org/freeipa/ticket/4899. I will be working on >>>>>implementing this design over the next couple of months. If you have >>>>>the time and interest, please take a look and share any comments or >>>>>concerns that you have. >>>>> >>>>>Thanks! >>>>> >>>>>Ben >>>>> >>>>Just a quick update to say that I've created a new document that covers >>>>the proposed schema additions in a more descriptive way (with diagrams!) >>>>I'm very new to developing with LDAP, so some more experienced eyes on >>>>the proposal would be very helpful, even if you don't have time to >>>>absorb the full design. Please take a look at >>>>http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>> >>>>if you have a chance. >>> >>>I finally had a chance to take a look at this, here are some comments: >>> >>>1) I don't like how transformation rules are tied to a particular >>>helper and have to be duplicated for each of them. They should be >>>generic and work with any helper, as helpers are just an >>>implementation detail and their resulting data is the same. >>> >>>In fact, I think I would prefer if the CSR was generated using >>>python-cryptography's CertificateSigningRequestBuilder [1] rather than >>>openssl or certutil or any other command line tool. >>> >>There are lots of tools that users might want to use to manage their >>private keys, so I don't know if we can assume that whatever library we >>prefer will actually be able to access the private key to sign a CSR, >>which is why I thought it would be useful to support more than one. > >python-cryptography has the notion of backends, which allow it to >support multiple crypto implementations. Upstream it currently >supports only OpenSSL [2], but some work has been done on PKCS#11 >backend [3], which provides support for HSMs and soft-tokens (like NSS >databases). > >Alternatively, for NSS databases (and other "simple" cases), you can >generate the private key with python-cryptography using the default >backend, export it to a file and import the file to the target >database, so you don't actually need the PKCS#11 backend for them. > >So, the only thing that's currently lacking is HSM support, but given >that we don't support HSMs in IPA nor in certmonger, I don't think >it's an issue for now. > >>The >>purpose of the mapping rule is to tie together the transformation rules >>that produce the same data into an object that's >>implementation-agnostic, so that profiles referencing those rules are >>automatically compatible with all the helper options. > >They are implementation-agnostic, as long as you consider `openssl` >and `certutil` the only implementations :-) But I don't think this >solution scales well to other possible implementations. > >Anyway, my main grudge is that the transformation rules shouldn't >really be stored on and processed by the server. The server should >know the *what* (mapping rules), but not the *how* (transformation >rules). The *how* is an implementation detail and does not change in >time, so there's no benefit in handling it on the server. It should be >handled exclusively on the client, which I believe would also make the >whole thing more robust (it would not be possible for a bug on the >server to break all the clients). This is a good point. However, for the scope of Ben's project can we limit it by openssl and certutil support? Otherwise Ben wouldn't be able to complete the project in time. >>This is turning out to be a common (and, I think, reasonable) reaction >>to the proposal. It is rather complex, and I worry that it will be >>difficult to configure. On the other hand, there is some hidden >>complexity to enabling a simpler config format, as well. One of the >>goals of the project as it was presented to me was to allow the creation >>of profiles that add certificate extensions *that FreeIPA doesn't yet >>know about*. With the current proposal, one only has to add a rule >>generating text that the helper will understand. > >... which will be possible only as long as the helper understands the >extension. Which it might not, thus the current proposal works only >for *some* extensions that FreeIPA doesn't yet support. We can go ad infinitum here but with any helper implementation, be it python-cryptography or anything else, you will need to have a support there as well. The idea with unknown extensions was to allow mapping their acceptance to a specific relationship between IPA objects (optionally) and an input from the CSR. A simplest example would be an identity rule that would copy an ASN.1 encoded content from the CSR to the certificate. That's on the mapping side, not on the CSR generation side, but it would go similarly for the CSR if you would be able to enter unknown but otherwise correct ASN.1 stream. There is no difference at which helper type we are talking about because all of them support inserting ASN.1 content. >>With your suggestion, >>if there's a mapping between "san_directoryname" and the corresponding >>API calls or configuration lines, we need some way for users to augment >>that mapping without changing the code. If there's no mapping, and it's >>just done with text processing, we need enough in the config format to >>be able to generate fairly complex structures: >> >>builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>builder = >>builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >> >>and we need to do it without it being equivalent to calling eval() on >>the config attributes. I'm not sure how to achieve this (is it safe to >>call getattr(x509, extensiontype)(value) where extensiontype and value >>are user-specified?) and it definitely would have to be tied to a >>particular library/tool. > >As I pointed out above, this needs to be figured out for the generic >case for both the current proposal and my suggestion. > >OTOH, I think we could use GSER encoding of the extension value: > > { rfc822Name:"user at example.com", >directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } GSER is not really used widely and does not have standardized encoding rules beyond its own definition. If you want to allow transformation rules in GSER that mention existing content in IPA objects, you would need to deal with templating anyway. At this point it becomes irrelevant what you are templating, though. -- / Alexander Bokovoy From jcholast at redhat.com Mon Jul 25 11:45:06 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Jul 2016 13:45:06 +0200 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <20160725111123.qthtarfgcsfbdnzk@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> Message-ID: <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> On 25.7.2016 13:11, Alexander Bokovoy wrote: > On Mon, 25 Jul 2016, Jan Cholasta wrote: >> On 20.7.2016 16:05, Ben Lipton wrote: >>> Hi, >>> >>> Thanks very much for the feedback! Some responses below; I hope you'll >>> let me know what you think of my reasoning. >>> >>> >>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>> Hello all, >>>>>> >>>>>> I have written up a design proposal for making certificate requests >>>>>> easier to generate when using alternate certificate profiles: >>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>> >>>>>> >>>>>> The use case for this is described in >>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be working on >>>>>> implementing this design over the next couple of months. If you have >>>>>> the time and interest, please take a look and share any comments or >>>>>> concerns that you have. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Ben >>>>>> >>>>> Just a quick update to say that I've created a new document that >>>>> covers >>>>> the proposed schema additions in a more descriptive way (with >>>>> diagrams!) >>>>> I'm very new to developing with LDAP, so some more experienced eyes on >>>>> the proposal would be very helpful, even if you don't have time to >>>>> absorb the full design. Please take a look at >>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>> >>>>> >>>>> if you have a chance. >>>> >>>> I finally had a chance to take a look at this, here are some comments: >>>> >>>> 1) I don't like how transformation rules are tied to a particular >>>> helper and have to be duplicated for each of them. They should be >>>> generic and work with any helper, as helpers are just an >>>> implementation detail and their resulting data is the same. >>>> >>>> In fact, I think I would prefer if the CSR was generated using >>>> python-cryptography's CertificateSigningRequestBuilder [1] rather than >>>> openssl or certutil or any other command line tool. >>>> >>> There are lots of tools that users might want to use to manage their >>> private keys, so I don't know if we can assume that whatever library we >>> prefer will actually be able to access the private key to sign a CSR, >>> which is why I thought it would be useful to support more than one. >> >> python-cryptography has the notion of backends, which allow it to >> support multiple crypto implementations. Upstream it currently >> supports only OpenSSL [2], but some work has been done on PKCS#11 >> backend [3], which provides support for HSMs and soft-tokens (like NSS >> databases). >> >> Alternatively, for NSS databases (and other "simple" cases), you can >> generate the private key with python-cryptography using the default >> backend, export it to a file and import the file to the target >> database, so you don't actually need the PKCS#11 backend for them. >> >> So, the only thing that's currently lacking is HSM support, but given >> that we don't support HSMs in IPA nor in certmonger, I don't think >> it's an issue for now. >> >>> The >>> purpose of the mapping rule is to tie together the transformation rules >>> that produce the same data into an object that's >>> implementation-agnostic, so that profiles referencing those rules are >>> automatically compatible with all the helper options. >> >> They are implementation-agnostic, as long as you consider `openssl` >> and `certutil` the only implementations :-) But I don't think this >> solution scales well to other possible implementations. >> >> Anyway, my main grudge is that the transformation rules shouldn't >> really be stored on and processed by the server. The server should >> know the *what* (mapping rules), but not the *how* (transformation >> rules). The *how* is an implementation detail and does not change in >> time, so there's no benefit in handling it on the server. It should be >> handled exclusively on the client, which I believe would also make the >> whole thing more robust (it would not be possible for a bug on the >> server to break all the clients). > This is a good point. However, for the scope of Ben's project can we > limit it by openssl and certutil support? Otherwise Ben wouldn't be able > to complete the project in time. I'm fine with that, but I don't think it's up to me :-) > >>> This is turning out to be a common (and, I think, reasonable) reaction >>> to the proposal. It is rather complex, and I worry that it will be >>> difficult to configure. On the other hand, there is some hidden >>> complexity to enabling a simpler config format, as well. One of the >>> goals of the project as it was presented to me was to allow the creation >>> of profiles that add certificate extensions *that FreeIPA doesn't yet >>> know about*. With the current proposal, one only has to add a rule >>> generating text that the helper will understand. >> >> ... which will be possible only as long as the helper understands the >> extension. Which it might not, thus the current proposal works only >> for *some* extensions that FreeIPA doesn't yet support. > We can go ad infinitum here but with any helper implementation, be it > python-cryptography or anything else, you will need to have a support > there as well. My point was that the current proposal is not any better than my proposal in this regard, as neither of them allows one to use an arbitrary extension. > The idea with unknown extensions was to allow mapping > their acceptance to a specific relationship between IPA objects > (optionally) and an input from the CSR. A simplest example would be an > identity rule that would copy an ASN.1 encoded content from the CSR to > the certificate. > > That's on the mapping side, not on the CSR generation side, but it would > go similarly for the CSR if you would be able to enter unknown but > otherwise correct ASN.1 stream. There is no difference at which helper > type we are talking about because all of them support inserting ASN.1 > content. > >>> With your suggestion, >>> if there's a mapping between "san_directoryname" and the corresponding >>> API calls or configuration lines, we need some way for users to augment >>> that mapping without changing the code. If there's no mapping, and it's >>> just done with text processing, we need enough in the config format to >>> be able to generate fairly complex structures: >>> >>> builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>> builder = >>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>> >>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>> >>> and we need to do it without it being equivalent to calling eval() on >>> the config attributes. I'm not sure how to achieve this (is it safe to >>> call getattr(x509, extensiontype)(value) where extensiontype and value >>> are user-specified?) and it definitely would have to be tied to a >>> particular library/tool. >> >> As I pointed out above, this needs to be figured out for the generic >> case for both the current proposal and my suggestion. >> >> OTOH, I think we could use GSER encoding of the extension value: >> >> { rfc822Name:"user at example.com", >> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } > GSER is not really used widely and does not have standardized encoding > rules beyond its own definition. If you want to allow transformation > rules in GSER that mention existing content in IPA objects, you would > need to deal with templating anyway. At this point it becomes irrelevant > what you are templating, though. True, but the goal here is not to avoid templating, but rather to avoid implementation-specific bits on the server, and GSER is the only thing that is textual, implementation-neutral and, as a bonus, standardized. -- Jan Cholasta From mkubik at redhat.com Mon Jul 25 11:53:56 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 25 Jul 2016 13:53:56 +0200 Subject: [Freeipa-devel] [PATCH 42-47][tests] RFE: Allow users to authenticate with alternative names Message-ID: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> Hi, I'm sending the tests for kerberos principal aliases rfe. The tests are implemented according to test plan [1] sent earlier. Some of the patches implement modifications and extensions to previous code to allow implement the tests themselves. The patches can be cloned also from github [2]. [1]: http://www.freeipa.org/page/V4/Kerberos_principal_aliases/Test_Plan [2]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test Cheers, -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0042-ipatests-Add-tracker-class-for-kerberos-principal-al.patch Type: text/x-patch Size: 10449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0043-ipatests-Extend-the-MockLDAP-utility-class.patch Type: text/x-patch Size: 1340 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0044-ipatests-Provide-a-context-manager-for-mocking-a-tru.patch Type: text/x-patch Size: 2778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0045-ipapython-Extend-kinit_password-to-support-principal.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0046-ipatests-Allow-change_principal-context-manager-to-u.patch Type: text/x-patch Size: 1434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0047-ipatests-Add-kerberos-principal-alias-tests.patch Type: text/x-patch Size: 10191 bytes Desc: not available URL: From mkubik at redhat.com Mon Jul 25 12:05:00 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 25 Jul 2016 14:05:00 +0200 Subject: [Freeipa-devel] [PATCH 42-47][tests] RFE: Allow users to authenticate with alternative names In-Reply-To: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> References: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> Message-ID: On 07/25/2016 01:53 PM, Milan Kub?k wrote: > Hi, > > I'm sending the tests for kerberos principal aliases rfe. The tests > are implemented according to test plan [1] sent earlier. > Some of the patches implement modifications and extensions to previous > code to allow implement the tests themselves. > > The patches can be cloned also from github [2]. > > [1]: http://www.freeipa.org/page/V4/Kerberos_principal_aliases/Test_Plan > [2]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test > > Cheers, > > > Self nack for 0047, the ldapconn fixture is not needed. New patch attached. Git repo updated (force-push). -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0047-1-ipatests-Add-kerberos-principal-alias-tests.patch Type: text/x-patch Size: 10119 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jul 25 12:12:17 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Jul 2016 15:12:17 +0300 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> Message-ID: <20160725121217.6orssupq3u5lhvl4@redhat.com> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>This is turning out to be a common (and, I think, reasonable) reaction >>>>to the proposal. It is rather complex, and I worry that it will be >>>>difficult to configure. On the other hand, there is some hidden >>>>complexity to enabling a simpler config format, as well. One of the >>>>goals of the project as it was presented to me was to allow the creation >>>>of profiles that add certificate extensions *that FreeIPA doesn't yet >>>>know about*. With the current proposal, one only has to add a rule >>>>generating text that the helper will understand. >>> >>>... which will be possible only as long as the helper understands the >>>extension. Which it might not, thus the current proposal works only >>>for *some* extensions that FreeIPA doesn't yet support. >>We can go ad infinitum here but with any helper implementation, be it >>python-cryptography or anything else, you will need to have a support >>there as well. > >My point was that the current proposal is not any better than my >proposal in this regard, as neither of them allows one to use an >arbitrary extension. That's true. One of arguments for supporting openssl format was to allow people to generate CSRs themselves later. E.g. it would be a stepping stone to some automation around certificates to those who need it. Turning everything into python-cryptography has less benefit in this context. >>The idea with unknown extensions was to allow mapping >>their acceptance to a specific relationship between IPA objects >>(optionally) and an input from the CSR. A simplest example would be an >>identity rule that would copy an ASN.1 encoded content from the CSR to >>the certificate. >> >>That's on the mapping side, not on the CSR generation side, but it would >>go similarly for the CSR if you would be able to enter unknown but >>otherwise correct ASN.1 stream. There is no difference at which helper >>type we are talking about because all of them support inserting ASN.1 >>content. >> >>>>With your suggestion, >>>>if there's a mapping between "san_directoryname" and the corresponding >>>>API calls or configuration lines, we need some way for users to augment >>>>that mapping without changing the code. If there's no mapping, and it's >>>>just done with text processing, we need enough in the config format to >>>>be able to generate fairly complex structures: >>>> >>>>builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>builder = >>>>builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>> >>>>x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>>> >>>>and we need to do it without it being equivalent to calling eval() on >>>>the config attributes. I'm not sure how to achieve this (is it safe to >>>>call getattr(x509, extensiontype)(value) where extensiontype and value >>>>are user-specified?) and it definitely would have to be tied to a >>>>particular library/tool. >>> >>>As I pointed out above, this needs to be figured out for the generic >>>case for both the current proposal and my suggestion. >>> >>>OTOH, I think we could use GSER encoding of the extension value: >>> >>> { rfc822Name:"user at example.com", >>>directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>GSER is not really used widely and does not have standardized encoding >>rules beyond its own definition. If you want to allow transformation >>rules in GSER that mention existing content in IPA objects, you would >>need to deal with templating anyway. At this point it becomes irrelevant >>what you are templating, though. > >True, but the goal here is not to avoid templating, but rather to >avoid implementation-specific bits on the server, and GSER is the only >thing that is textual, implementation-neutral and, as a bonus, >standardized. If we move these bits to the client, the only thing server will need to deal with is CSR. The client then would definitely need to have ability to provide alternative CSR sources (e.g. openssl text format) to aid API users that don't utilize IPA tools directly. At this point GSER use is irrelevant either. -- / Alexander Bokovoy From simo at redhat.com Mon Jul 25 12:40:05 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 08:40:05 -0400 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation Message-ID: <1469450405.18067.69.camel@redhat.com> As described in #232 start restricting the use of the setkeytab operation to just the computers objects. I haven't tested this with older RHEL/CentOS machines that actully use the setkeytab operation as I do not have such an old VM handy right now. Meanwhile I'd like to know if ppl agree with this approach. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-569-1-Restrict-the-old-setkeytab-operation.patch Type: text/x-patch Size: 3961 bytes Desc: not available URL: From jcholast at redhat.com Mon Jul 25 12:47:56 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Jul 2016 14:47:56 +0200 Subject: [Freeipa-devel] [PATCHES 678-679] client: fix hiding of commands which lack server support Message-ID: <571ec045-f4b9-8755-42a7-9abfee6bfd9d@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-678-Revert-Enable-vault-commands-on-client.patch Type: text/x-patch Size: 1723 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-679-client-fix-hiding-of-commands-which-lack-server-supp.patch Type: text/x-patch Size: 3494 bytes Desc: not available URL: From pspacek at redhat.com Mon Jul 25 13:55:59 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Jul 2016 15:55:59 +0200 Subject: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain Message-ID: <74ee6686-c8de-d80f-3e2f-3fca3bfb4f8d@redhat.com> Hello, replica-install: Fix --domain Replica installation must not check existence of --domain - the domain must (logically) exist. https://fedorahosted.org/freeipa/ticket/6130 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0150-replica-install-Fix-domain.patch Type: text/x-patch Size: 2446 bytes Desc: not available URL: From jcholast at redhat.com Mon Jul 25 14:16:37 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Jul 2016 16:16:37 +0200 Subject: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain In-Reply-To: <74ee6686-c8de-d80f-3e2f-3fca3bfb4f8d@redhat.com> References: <74ee6686-c8de-d80f-3e2f-3fca3bfb4f8d@redhat.com> Message-ID: On 25.7.2016 15:55, Petr Spacek wrote: > Hello, > > replica-install: Fix --domain > > Replica installation must not check existence of --domain - the domain > must (logically) exist. > > https://fedorahosted.org/freeipa/ticket/6130 Note that Server.domain_name is already defined on line 1204 in ipaserver/install/server/install.py. -- Jan Cholasta From blipton at redhat.com Mon Jul 25 14:19:30 2016 From: blipton at redhat.com (Ben Lipton) Date: Mon, 25 Jul 2016 10:19:30 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <20160725121217.6orssupq3u5lhvl4@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <20160725121217.6orssupq3u5lhvl4@redhat.com> Message-ID: <43b1f608-0a89-9484-d3c5-98f5676d71f2@redhat.com> On 07/25/2016 08:12 AM, Alexander Bokovoy wrote: > On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>> This is turning out to be a common (and, I think, reasonable) >>>>> reaction >>>>> to the proposal. It is rather complex, and I worry that it will be >>>>> difficult to configure. On the other hand, there is some hidden >>>>> complexity to enabling a simpler config format, as well. One of the >>>>> goals of the project as it was presented to me was to allow the >>>>> creation >>>>> of profiles that add certificate extensions *that FreeIPA doesn't yet >>>>> know about*. With the current proposal, one only has to add a rule >>>>> generating text that the helper will understand. >>>> >>>> ... which will be possible only as long as the helper understands the >>>> extension. Which it might not, thus the current proposal works only >>>> for *some* extensions that FreeIPA doesn't yet support. >>> We can go ad infinitum here but with any helper implementation, be it >>> python-cryptography or anything else, you will need to have a support >>> there as well. >> >> My point was that the current proposal is not any better than my >> proposal in this regard, as neither of them allows one to use an >> arbitrary extension. > That's true. One of arguments for supporting openssl format was to allow > people to generate CSRs themselves later. E.g. it would be a stepping > stone to some automation around certificates to those who need it. > Turning everything into python-cryptography has less benefit in this > context. > >>> The idea with unknown extensions was to allow mapping >>> their acceptance to a specific relationship between IPA objects >>> (optionally) and an input from the CSR. A simplest example would be an >>> identity rule that would copy an ASN.1 encoded content from the CSR to >>> the certificate. >>> >>> That's on the mapping side, not on the CSR generation side, but it >>> would >>> go similarly for the CSR if you would be able to enter unknown but >>> otherwise correct ASN.1 stream. There is no difference at which helper >>> type we are talking about because all of them support inserting ASN.1 >>> content. Along similar lines, on the CSR generation side, certutil has an --extGeneric flag, and openssl also has an "ARBITRARY EXTENSIONS" feature described in x509v3_config(5). I'm guessing that generating those configs automatically would be a bit beyond the current feature set of jinja2, but when we allow the requester to specify contents for some of the data fields it should be possible to build ok automation around that. >>> >>>>> With your suggestion, >>>>> if there's a mapping between "san_directoryname" and the >>>>> corresponding >>>>> API calls or configuration lines, we need some way for users to >>>>> augment >>>>> that mapping without changing the code. If there's no mapping, and >>>>> it's >>>>> just done with text processing, we need enough in the config >>>>> format to >>>>> be able to generate fairly complex structures: >>>>> >>>>> builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>> builder = >>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>> >>>>> >>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False) >>>>> >>>>> and we need to do it without it being equivalent to calling eval() on >>>>> the config attributes. I'm not sure how to achieve this (is it >>>>> safe to >>>>> call getattr(x509, extensiontype)(value) where extensiontype and >>>>> value >>>>> are user-specified?) and it definitely would have to be tied to a >>>>> particular library/tool. >>>> >>>> As I pointed out above, this needs to be figured out for the generic >>>> case for both the current proposal and my suggestion. >>>> >>>> OTOH, I think we could use GSER encoding of the extension value: >>>> >>>> { rfc822Name:"user at example.com", >>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>> GSER is not really used widely and does not have standardized encoding >>> rules beyond its own definition. If you want to allow transformation >>> rules in GSER that mention existing content in IPA objects, you would >>> need to deal with templating anyway. At this point it becomes >>> irrelevant >>> what you are templating, though. >> >> True, but the goal here is not to avoid templating, but rather to >> avoid implementation-specific bits on the server, and GSER is the >> only thing that is textual, implementation-neutral and, as a bonus, >> standardized. > If we move these bits to the client, the only thing server will need to > deal with is CSR. The client then would definitely need to have ability > to provide alternative CSR sources (e.g. openssl text format) to aid > API users that don't utilize IPA tools directly. At this point GSER use > is irrelevant either. The GSER format is new to me, but I don't see any particular reason the existing design would not be able to produce this format. But: is there an existing library that allows creating a CSR from a GSER description? If our goal is to provide an easy way to create certificates according to a particular profile, and the CSR is still our main way to provide that data to the IPA cert-request feature, we need to be able to build that CSR. If we have a client that accepts GSER and has at least the CSR generation features we need, then maybe we don't need support for generating the other formats anymore. From pspacek at redhat.com Mon Jul 25 14:36:11 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Jul 2016 16:36:11 +0200 Subject: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain In-Reply-To: References: <74ee6686-c8de-d80f-3e2f-3fca3bfb4f8d@redhat.com> Message-ID: On 25.7.2016 16:16, Jan Cholasta wrote: > On 25.7.2016 15:55, Petr Spacek wrote: >> Hello, >> >> replica-install: Fix --domain >> >> Replica installation must not check existence of --domain - the domain >> must (logically) exist. >> >> https://fedorahosted.org/freeipa/ticket/6130 > > Note that Server.domain_name is already defined on line 1204 in > ipaserver/install/server/install.py. My bad, here is updated patch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0150-2-replica-install-Fix-domain.patch Type: text/x-patch Size: 2522 bytes Desc: not available URL: From blipton at redhat.com Mon Jul 25 14:51:09 2016 From: blipton at redhat.com (Ben Lipton) Date: Mon, 25 Jul 2016 10:51:09 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <1469437670.18067.62.camel@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> Message-ID: <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> On 07/25/2016 05:07 AM, Simo Sorce wrote: > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: >> Anyway, my main grudge is that the transformation rules shouldn't >> really >> be stored on and processed by the server. The server should know the >> *what* (mapping rules), but not the *how* (transformation rules). The >> *how* is an implementation detail and does not change in time, so >> there's no benefit in handling it on the server. It should be handled >> exclusively on the client, which I believe would also make the whole >> thing more robust (it would not be possible for a bug on the server >> to >> break all the clients). > W/o entering in specific +1 as a general comment on this. > If it can be done on the client, probably better be done there. > > Simo. > My thinking was that while the CSR generation must be done on the client, the retrieval and formatting of the data for the CSR should be done on the server, so that the functionality is available to all consumers of the API (ipa command-line, certmonger, Web UI, something else?). I imagine it would be relatively easy to move the formatting stuff into the ipa CLI, but all the other clients would then need an implementation of their own, and so we'd need to worry about interpreting the templates and generating CSRs in multiple different languages. It's true that as it stands a bug on the server could break all the clients, but on the other hand there's only one implementation to maintain, rather than a different one in each client. But maybe I'm not seeing the proper priorities here. Perhaps it's more of a problem because clients are easier to update with bugfixes than the server? Or maybe the preference for the client is for scalability reasons? Could you tell me more about why you prefer a client implementation? (And yeah, everything here carries a disclaimer of "I probably can't make any large changes in the remaining 3 weeks of my internship," but I think it's still good to know and document what the limitations of the current implementation are.) Thanks, Ben From rcritten at redhat.com Mon Jul 25 14:55:36 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Jul 2016 10:55:36 -0400 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <1469450405.18067.69.camel@redhat.com> References: <1469450405.18067.69.camel@redhat.com> Message-ID: <57962868.8090904@redhat.com> Simo Sorce wrote: > As described in #232 start restricting the use of the setkeytab > operation to just the computers objects. > > I haven't tested this with older RHEL/CentOS machines that actully use > the setkeytab operation as I do not have such an old VM handy right now. > > Meanwhile I'd like to know if ppl agree with this approach. What about services? rob From blipton at redhat.com Mon Jul 25 15:00:56 2016 From: blipton at redhat.com (Ben Lipton) Date: Mon, 25 Jul 2016 11:00:56 -0400 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos In-Reply-To: <20160718205457.GA13618@10.4.128.1> References: <20160714080910.xmcnbqgqvi7evfds@redhat.com> <20160718205457.GA13618@10.4.128.1> Message-ID: On 07/18/2016 04:54 PM, Lukas Slebodnik wrote: > On (18/07/16 16:38), Petr Spacek wrote: >> On 14.7.2016 16:11, Ben Lipton wrote: >>> On 07/14/2016 04:09 AM, Alexander Bokovoy wrote: >>>> On Wed, 13 Jul 2016, Ben Lipton wrote: >>>>> Nothing too exciting, just fixes a few typos I've noticed in comments. >>>> ACK. However, please file a ticket and mention it in the commit message. >> Is it worth the bureaucracy? I do not think so. We will certainly not backport >> typo fixes in comments to older branches so I would say that ticket is useless. >> >> Just my two cents. >> > +1 > > LS > Necessary or not, as the ticket is created now, any objection to pushing the patch? Ben From simo at redhat.com Mon Jul 25 15:01:30 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 11:01:30 -0400 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <57962868.8090904@redhat.com> References: <1469450405.18067.69.camel@redhat.com> <57962868.8090904@redhat.com> Message-ID: <1469458890.18067.72.camel@redhat.com> On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > As described in #232 start restricting the use of the setkeytab > > operation to just the computers objects. > > > > I haven't tested this with older RHEL/CentOS machines that actully use > > the setkeytab operation as I do not have such an old VM handy right now. > > > > Meanwhile I'd like to know if ppl agree with this approach. > > What about services? Do we automatically acquire keytab for services in the old clients ? Are you thinking about scripted ipa-getkytab callouts ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Jul 25 15:04:34 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 11:04:34 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> Message-ID: <1469459074.18067.75.camel@redhat.com> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: > On 07/25/2016 05:07 AM, Simo Sorce wrote: > > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > >> Anyway, my main grudge is that the transformation rules shouldn't > >> really > >> be stored on and processed by the server. The server should know the > >> *what* (mapping rules), but not the *how* (transformation rules). The > >> *how* is an implementation detail and does not change in time, so > >> there's no benefit in handling it on the server. It should be handled > >> exclusively on the client, which I believe would also make the whole > >> thing more robust (it would not be possible for a bug on the server > >> to > >> break all the clients). > > W/o entering in specific +1 as a general comment on this. > > If it can be done on the client, probably better be done there. > > > > Simo. > > > My thinking was that while the CSR generation must be done on the > client, the retrieval and formatting of the data for the CSR should be > done on the server, so that the functionality is available to all > consumers of the API (ipa command-line, certmonger, Web UI, something > else?). I imagine it would be relatively easy to move the formatting > stuff into the ipa CLI, but all the other clients would then need an > implementation of their own, and so we'd need to worry about > interpreting the templates and generating CSRs in multiple different > languages. It's true that as it stands a bug on the server could break > all the clients, but on the other hand there's only one implementation > to maintain, rather than a different one in each client. > > But maybe I'm not seeing the proper priorities here. Perhaps it's more > of a problem because clients are easier to update with bugfixes than the > server? Or maybe the preference for the client is for scalability > reasons? Could you tell me more about why you prefer a client > implementation? > > (And yeah, everything here carries a disclaimer of "I probably can't > make any large changes in the remaining 3 weeks of my internship," but I > think it's still good to know and document what the limitations of the > current implementation are.) > > Thanks, > Ben You do not want to have to upgrade the server because tool foobarx became suddenly the most used. Client tools may change over the time as well, so if you try to generate stuff on the server you may end up having to support multiple version with little way of knowing which version that is. It is true that multiple client would have to implement "something", but that something could be a python library+binary that other tools/script can call or pipe through as needed. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Jul 25 15:05:20 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Jul 2016 18:05:20 +0300 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> Message-ID: <20160725150520.baxtfleeadh3i4q6@redhat.com> On Mon, 25 Jul 2016, Ben Lipton wrote: >On 07/25/2016 05:07 AM, Simo Sorce wrote: >>On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: >>>Anyway, my main grudge is that the transformation rules shouldn't >>>really >>>be stored on and processed by the server. The server should know the >>>*what* (mapping rules), but not the *how* (transformation rules). The >>>*how* is an implementation detail and does not change in time, so >>>there's no benefit in handling it on the server. It should be handled >>>exclusively on the client, which I believe would also make the whole >>>thing more robust (it would not be possible for a bug on the server >>>to >>>break all the clients). >>W/o entering in specific +1 as a general comment on this. >>If it can be done on the client, probably better be done there. >> >>Simo. >> >My thinking was that while the CSR generation must be done on the >client, the retrieval and formatting of the data for the CSR should be >done on the server, so that the functionality is available to all >consumers of the API (ipa command-line, certmonger, Web UI, something >else?). I imagine it would be relatively easy to move the formatting >stuff into the ipa CLI, but all the other clients would then need an >implementation of their own, and so we'd need to worry about >interpreting the templates and generating CSRs in multiple different >languages. It's true that as it stands a bug on the server could break >all the clients, but on the other hand there's only one implementation >to maintain, rather than a different one in each client. For other clients we would need to worry about CSR, not generating them. For them we *could* make use of the fact that IPA server is IPA client as well and provide some API to create CSR based on a pre-defined request type (e.g. don't support all CSR backends, just one, like python-cryptography). That wouldn't be too flexible but for flexibility we already accept CSRs generated by someone else. >But maybe I'm not seeing the proper priorities here. Perhaps it's more >of a problem because clients are easier to update with bugfixes than >the server? Or maybe the preference for the client is for scalability >reasons? Could you tell me more about why you prefer a client >implementation? Making client responsible for generating the certificate signing request serves several purposes where privacy is one of main benefits: access to private key stays at the client side. >(And yeah, everything here carries a disclaimer of "I probably can't >make any large changes in the remaining 3 weeks of my internship," but >I think it's still good to know and document what the limitations of >the current implementation are.) Agreed. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 25 15:06:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Jul 2016 18:06:50 +0300 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <1469458890.18067.72.camel@redhat.com> References: <1469450405.18067.69.camel@redhat.com> <57962868.8090904@redhat.com> <1469458890.18067.72.camel@redhat.com> Message-ID: <20160725150650.5kt3k5uafby63v25@redhat.com> On Mon, 25 Jul 2016, Simo Sorce wrote: >On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >> > As described in #232 start restricting the use of the setkeytab >> > operation to just the computers objects. >> > >> > I haven't tested this with older RHEL/CentOS machines that actully use >> > the setkeytab operation as I do not have such an old VM handy right now. >> > >> > Meanwhile I'd like to know if ppl agree with this approach. >> >> What about services? > >Do we automatically acquire keytab for services in the old clients ? > >Are you thinking about scripted ipa-getkytab callouts ? There are people still using ipa 3.0 clients and scripting around it, both with RHEL 6.x and CentOS 6.x. I wouldn't break those on purpose. -- / Alexander Bokovoy From simo at redhat.com Mon Jul 25 15:07:13 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 11:07:13 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <1469459074.18067.75.camel@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <1469459074.18067.75.camel@redhat.com> Message-ID: <1469459233.18067.77.camel@redhat.com> On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: > On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: > > On 07/25/2016 05:07 AM, Simo Sorce wrote: > > > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > > >> Anyway, my main grudge is that the transformation rules shouldn't > > >> really > > >> be stored on and processed by the server. The server should know the > > >> *what* (mapping rules), but not the *how* (transformation rules). The > > >> *how* is an implementation detail and does not change in time, so > > >> there's no benefit in handling it on the server. It should be handled > > >> exclusively on the client, which I believe would also make the whole > > >> thing more robust (it would not be possible for a bug on the server > > >> to > > >> break all the clients). > > > W/o entering in specific +1 as a general comment on this. > > > If it can be done on the client, probably better be done there. > > > > > > Simo. > > > > > My thinking was that while the CSR generation must be done on the > > client, the retrieval and formatting of the data for the CSR should be > > done on the server, so that the functionality is available to all > > consumers of the API (ipa command-line, certmonger, Web UI, something > > else?). I imagine it would be relatively easy to move the formatting > > stuff into the ipa CLI, but all the other clients would then need an > > implementation of their own, and so we'd need to worry about > > interpreting the templates and generating CSRs in multiple different > > languages. It's true that as it stands a bug on the server could break > > all the clients, but on the other hand there's only one implementation > > to maintain, rather than a different one in each client. > > > > But maybe I'm not seeing the proper priorities here. Perhaps it's more > > of a problem because clients are easier to update with bugfixes than the > > server? Or maybe the preference for the client is for scalability > > reasons? Could you tell me more about why you prefer a client > > implementation? > > > > (And yeah, everything here carries a disclaimer of "I probably can't > > make any large changes in the remaining 3 weeks of my internship," but I > > think it's still good to know and document what the limitations of the > > current implementation are.) > > > > Thanks, > > Ben > > You do not want to have to upgrade the server because tool foobarx > became suddenly the most used. Client tools may change over the time as > well, so if you try to generate stuff on the server you may end up > having to support multiple version with little way of knowing which > version that is. > > It is true that multiple client would have to implement "something", but > that something could be a python library+binary that other tools/script > can call or pipe through as needed. Note, from my pov the code should be more or less the same except it would run on the client rather than the server. Templates would be delivered via the same package that delivers the tool/module and admins would have the option to add more locally, though I am not against sharing templates via the server if we think that is a good idea in general (but the same issue vs tools changing and rendering templates broken with one or another version remain). Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Jul 25 15:10:29 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Jul 2016 11:10:29 -0400 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <1469458890.18067.72.camel@redhat.com> References: <1469450405.18067.69.camel@redhat.com> <57962868.8090904@redhat.com> <1469458890.18067.72.camel@redhat.com> Message-ID: <57962BE5.60404@redhat.com> Simo Sorce wrote: > On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> As described in #232 start restricting the use of the setkeytab >>> operation to just the computers objects. >>> >>> I haven't tested this with older RHEL/CentOS machines that actully use >>> the setkeytab operation as I do not have such an old VM handy right now. >>> >>> Meanwhile I'd like to know if ppl agree with this approach. >> >> What about services? > > Do we automatically acquire keytab for services in the old clients ? > > Are you thinking about scripted ipa-getkytab callouts ? You are limiting access to host keytabs, what about service keytabs? Should they be or are they now similarly restricted? Installers for something like Foreman may try to generate a service keytab in its installer, probably using admin credentials. I am planning to do the same in Openstack. rob From simo at redhat.com Mon Jul 25 15:26:14 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 11:26:14 -0400 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <57962BE5.60404@redhat.com> References: <1469450405.18067.69.camel@redhat.com> <57962868.8090904@redhat.com> <1469458890.18067.72.camel@redhat.com> <57962BE5.60404@redhat.com> Message-ID: <1469460374.18067.79.camel@redhat.com> On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> As described in #232 start restricting the use of the setkeytab > >>> operation to just the computers objects. > >>> > >>> I haven't tested this with older RHEL/CentOS machines that actully use > >>> the setkeytab operation as I do not have such an old VM handy right now. > >>> > >>> Meanwhile I'd like to know if ppl agree with this approach. > >> > >> What about services? > > > > Do we automatically acquire keytab for services in the old clients ? > > > > Are you thinking about scripted ipa-getkytab callouts ? > > You are limiting access to host keytabs, what about service keytabs? > Should they be or are they now similarly restricted? > > Installers for something like Foreman may try to generate a service > keytab in its installer, probably using admin credentials. I am planning > to do the same in Openstack. Ok I'll amend the patch to allow service keytabs to still use the setkeytab control still, and restrict only users. However note that the idea of using this method is that admin can change this default on their own, so they can restrict more or less if they want, to that end I need to remember how to set a default that we do not override in the update file. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Mon Jul 25 16:02:22 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 Jul 2016 18:02:22 +0200 Subject: [Freeipa-devel] [PATCH 0553] CI tests: improve log collecting in tests In-Reply-To: References: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> <21a9655a-3943-67ac-3a8f-0a81dae37de3@redhat.com> <2dc7f75b-c0c4-e656-0cff-359696e2d05c@redhat.com> Message-ID: <028f109f-136a-ba8e-1054-534286ae23cf@redhat.com> On 07/22/2016 06:13 PM, Martin Basti wrote: > > > On 20.07.2016 17:41, Martin Basti wrote: >> >> >> >> On 19.07.2016 17:05, Martin Basti wrote: >>> >>> >>> >>> On 19.07.2016 16:18, Martin Basti wrote: >>>> Patch attached. >>>> >>>> >>>> >>> self-NACK, my assumptions were wrong, this doesn't work if any of log >>> files do not exist >>> >>> >> updated patches attached >> >> Please note, that in case that any logfile does not exist tar returns >> exit code 2, but provides correct output anyway. >> >> > Updated patches attached. > > NACK: ************* Module ipatests.test_integration.tasks ipatests/test_integration/tasks.py:68: [E1101(no-member), setup_server_logs_collecting] Instance of 'FedoraPathNamespace' has no 'IPASERVER_CA_INSTALL_LOG' member) Makefile:137: recipe for target 'lint' failed make: *** [lint] Error 1 -- Martin^3 Babinsky From simo at redhat.com Mon Jul 25 16:03:27 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 12:03:27 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <20160725150520.baxtfleeadh3i4q6@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <20160725150520.baxtfleeadh3i4q6@redhat.com> Message-ID: <1469462607.18067.81.camel@redhat.com> On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: > >But maybe I'm not seeing the proper priorities here. Perhaps it's > more > >of a problem because clients are easier to update with bugfixes than > >the server? Or maybe the preference for the client is for > scalability > >reasons? Could you tell me more about why you prefer a client > >implementation? > Making client responsible for generating the certificate signing > request serves several purposes where privacy is one of main benefits: > access to private key stays at the client side. I would definitely veto any scheme where the client must send the private key to the server. I thought the server would generate the CSR, but then it would be sent to the client for signing ? Simo. -- Simo Sorce * Red Hat, Inc * New York From blipton at redhat.com Mon Jul 25 16:09:49 2016 From: blipton at redhat.com (Ben Lipton) Date: Mon, 25 Jul 2016 12:09:49 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <1469462607.18067.81.camel@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <20160725150520.baxtfleeadh3i4q6@redhat.com> <1469462607.18067.81.camel@redhat.com> Message-ID: <32934772-ec8c-934c-9e5d-1a78d35a37a6@redhat.com> On 07/25/2016 12:03 PM, Simo Sorce wrote: > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: >>> But maybe I'm not seeing the proper priorities here. Perhaps it's >> more >>> of a problem because clients are easier to update with bugfixes than >>> the server? Or maybe the preference for the client is for >> scalability >>> reasons? Could you tell me more about why you prefer a client >>> implementation? >> Making client responsible for generating the certificate signing >> request serves several purposes where privacy is one of main benefits: >> access to private key stays at the client side. > I would definitely veto any scheme where the client must send the > private key to the server. I thought the server would generate the CSR, > but then it would be sent to the client for signing ? > > Simo. > The server generates the data and formats it for the helper tool. The helper runs on the client and generates the CSR, with signature. I don't think we were considering signing anything server-side; in this thread I was referring to whether the data should be requested and formatted on the server or client side. From blipton at redhat.com Mon Jul 25 16:13:17 2016 From: blipton at redhat.com (Ben Lipton) Date: Mon, 25 Jul 2016 12:13:17 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <1469459233.18067.77.camel@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <1469459074.18067.75.camel@redhat.com> <1469459233.18067.77.camel@redhat.com> Message-ID: On 07/25/2016 11:07 AM, Simo Sorce wrote: > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: >>> On 07/25/2016 05:07 AM, Simo Sorce wrote: >>>> On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: >>>>> Anyway, my main grudge is that the transformation rules shouldn't >>>>> really >>>>> be stored on and processed by the server. The server should know the >>>>> *what* (mapping rules), but not the *how* (transformation rules). The >>>>> *how* is an implementation detail and does not change in time, so >>>>> there's no benefit in handling it on the server. It should be handled >>>>> exclusively on the client, which I believe would also make the whole >>>>> thing more robust (it would not be possible for a bug on the server >>>>> to >>>>> break all the clients). >>>> W/o entering in specific +1 as a general comment on this. >>>> If it can be done on the client, probably better be done there. >>>> >>>> Simo. >>>> >>> My thinking was that while the CSR generation must be done on the >>> client, the retrieval and formatting of the data for the CSR should be >>> done on the server, so that the functionality is available to all >>> consumers of the API (ipa command-line, certmonger, Web UI, something >>> else?). I imagine it would be relatively easy to move the formatting >>> stuff into the ipa CLI, but all the other clients would then need an >>> implementation of their own, and so we'd need to worry about >>> interpreting the templates and generating CSRs in multiple different >>> languages. It's true that as it stands a bug on the server could break >>> all the clients, but on the other hand there's only one implementation >>> to maintain, rather than a different one in each client. >>> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more >>> of a problem because clients are easier to update with bugfixes than the >>> server? Or maybe the preference for the client is for scalability >>> reasons? Could you tell me more about why you prefer a client >>> implementation? >>> >>> (And yeah, everything here carries a disclaimer of "I probably can't >>> make any large changes in the remaining 3 weeks of my internship," but I >>> think it's still good to know and document what the limitations of the >>> current implementation are.) >>> >>> Thanks, >>> Ben >> You do not want to have to upgrade the server because tool foobarx >> became suddenly the most used. Client tools may change over the time as >> well, so if you try to generate stuff on the server you may end up >> having to support multiple version with little way of knowing which >> version that is. >> >> It is true that multiple client would have to implement "something", but >> that something could be a python library+binary that other tools/script >> can call or pipe through as needed. > Note, from my pov the code should be more or less the same except it > would run on the client rather than the server. Templates would be > delivered via the same package that delivers the tool/module and admins > would have the option to add more locally, though I am not against > sharing templates via the server if we think that is a good idea in > general (but the same issue vs tools changing and rendering templates > broken with one or another version remain). > > Simo. > Ok, I definitely see your point here about making it easier to support the shifting versions of the helper utilities. Pulling the formatting out into a standalone binary that could be used by different clients seems achievable. The Web UI wouldn't be able to use it, I guess, but as of now there's no web UI for this feature anyway. I'll make sure this is at least documented as a desirable modification. From simo at redhat.com Mon Jul 25 16:23:20 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 12:23:20 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <32934772-ec8c-934c-9e5d-1a78d35a37a6@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <20160725150520.baxtfleeadh3i4q6@redhat.com> <1469462607.18067.81.camel@redhat.com> <32934772-ec8c-934c-9e5d-1a78d35a37a6@redhat.com> Message-ID: <1469463800.18067.82.camel@redhat.com> On Mon, 2016-07-25 at 12:09 -0400, Ben Lipton wrote: > On 07/25/2016 12:03 PM, Simo Sorce wrote: > > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: > >>> But maybe I'm not seeing the proper priorities here. Perhaps it's > >> more > >>> of a problem because clients are easier to update with bugfixes than > >>> the server? Or maybe the preference for the client is for > >> scalability > >>> reasons? Could you tell me more about why you prefer a client > >>> implementation? > >> Making client responsible for generating the certificate signing > >> request serves several purposes where privacy is one of main benefits: > >> access to private key stays at the client side. > > I would definitely veto any scheme where the client must send the > > private key to the server. I thought the server would generate the CSR, > > but then it would be sent to the client for signing ? > > > > Simo. > > > The server generates the data and formats it for the helper tool. The > helper runs on the client and generates the CSR, with signature. I don't > think we were considering signing anything server-side; in this thread I > was referring to whether the data should be requested and formatted on > the server or client side. This was my understanding as well, but Alexander's comment startled me, thanks for confirming. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Jul 25 16:24:05 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 25 Jul 2016 12:24:05 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <1469459074.18067.75.camel@redhat.com> <1469459233.18067.77.camel@redhat.com> Message-ID: <1469463845.18067.83.camel@redhat.com> On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote: > On 07/25/2016 11:07 AM, Simo Sorce wrote: > > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: > >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: > >>> On 07/25/2016 05:07 AM, Simo Sorce wrote: > >>>> On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: > >>>>> Anyway, my main grudge is that the transformation rules shouldn't > >>>>> really > >>>>> be stored on and processed by the server. The server should know the > >>>>> *what* (mapping rules), but not the *how* (transformation rules). The > >>>>> *how* is an implementation detail and does not change in time, so > >>>>> there's no benefit in handling it on the server. It should be handled > >>>>> exclusively on the client, which I believe would also make the whole > >>>>> thing more robust (it would not be possible for a bug on the server > >>>>> to > >>>>> break all the clients). > >>>> W/o entering in specific +1 as a general comment on this. > >>>> If it can be done on the client, probably better be done there. > >>>> > >>>> Simo. > >>>> > >>> My thinking was that while the CSR generation must be done on the > >>> client, the retrieval and formatting of the data for the CSR should be > >>> done on the server, so that the functionality is available to all > >>> consumers of the API (ipa command-line, certmonger, Web UI, something > >>> else?). I imagine it would be relatively easy to move the formatting > >>> stuff into the ipa CLI, but all the other clients would then need an > >>> implementation of their own, and so we'd need to worry about > >>> interpreting the templates and generating CSRs in multiple different > >>> languages. It's true that as it stands a bug on the server could break > >>> all the clients, but on the other hand there's only one implementation > >>> to maintain, rather than a different one in each client. > >>> > >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more > >>> of a problem because clients are easier to update with bugfixes than the > >>> server? Or maybe the preference for the client is for scalability > >>> reasons? Could you tell me more about why you prefer a client > >>> implementation? > >>> > >>> (And yeah, everything here carries a disclaimer of "I probably can't > >>> make any large changes in the remaining 3 weeks of my internship," but I > >>> think it's still good to know and document what the limitations of the > >>> current implementation are.) > >>> > >>> Thanks, > >>> Ben > >> You do not want to have to upgrade the server because tool foobarx > >> became suddenly the most used. Client tools may change over the time as > >> well, so if you try to generate stuff on the server you may end up > >> having to support multiple version with little way of knowing which > >> version that is. > >> > >> It is true that multiple client would have to implement "something", but > >> that something could be a python library+binary that other tools/script > >> can call or pipe through as needed. > > Note, from my pov the code should be more or less the same except it > > would run on the client rather than the server. Templates would be > > delivered via the same package that delivers the tool/module and admins > > would have the option to add more locally, though I am not against > > sharing templates via the server if we think that is a good idea in > > general (but the same issue vs tools changing and rendering templates > > broken with one or another version remain). > > > > Simo. > > > Ok, I definitely see your point here about making it easier to support > the shifting versions of the helper utilities. Pulling the formatting > out into a standalone binary that could be used by different clients > seems achievable. The Web UI wouldn't be able to use it, I guess, but as > of now there's no web UI for this feature anyway. I'll make sure this is > at least documented as a desirable modification. Note, that the same tool *could* be used server side in the UI, should it be desirable. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Jul 25 16:24:48 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 25 Jul 2016 18:24:48 +0200 Subject: [Freeipa-devel] [PATCH 0553] CI tests: improve log collecting in tests In-Reply-To: <028f109f-136a-ba8e-1054-534286ae23cf@redhat.com> References: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> <21a9655a-3943-67ac-3a8f-0a81dae37de3@redhat.com> <2dc7f75b-c0c4-e656-0cff-359696e2d05c@redhat.com> <028f109f-136a-ba8e-1054-534286ae23cf@redhat.com> Message-ID: On 25.07.2016 18:02, Martin Babinsky wrote: > On 07/22/2016 06:13 PM, Martin Basti wrote: >> >> >> On 20.07.2016 17:41, Martin Basti wrote: >>> >>> >>> >>> On 19.07.2016 17:05, Martin Basti wrote: >>>> >>>> >>>> >>>> On 19.07.2016 16:18, Martin Basti wrote: >>>>> Patch attached. >>>>> >>>>> >>>>> >>>> self-NACK, my assumptions were wrong, this doesn't work if any of log >>>> files do not exist >>>> >>>> >>> updated patches attached >>> >>> Please note, that in case that any logfile does not exist tar returns >>> exit code 2, but provides correct output anyway. >>> >>> >> Updated patches attached. >> >> > NACK: > > ************* Module ipatests.test_integration.tasks > ipatests/test_integration/tasks.py:68: [E1101(no-member), > setup_server_logs_collecting] Instance of 'FedoraPathNamespace' has no > 'IPASERVER_CA_INSTALL_LOG' member) > Makefile:137: recipe for target 'lint' failed > make: *** [lint] Error 1 > Ooops, I forgot to merge fix Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0553.4-CI-tests-improve-log-collecting.patch Type: text/x-patch Size: 4818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0554.4-CI-tests-fix-SSSD-log-collecting.patch Type: text/x-patch Size: 2013 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jul 25 18:33:20 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Jul 2016 21:33:20 +0300 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <1469463800.18067.82.camel@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <20160725150520.baxtfleeadh3i4q6@redhat.com> <1469462607.18067.81.camel@redhat.com> <32934772-ec8c-934c-9e5d-1a78d35a37a6@redhat.com> <1469463800.18067.82.camel@redhat.com> Message-ID: <20160725183320.wiljes24eckytplh@redhat.com> On Mon, 25 Jul 2016, Simo Sorce wrote: >On Mon, 2016-07-25 at 12:09 -0400, Ben Lipton wrote: >> On 07/25/2016 12:03 PM, Simo Sorce wrote: >> > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: >> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's >> >> more >> >>> of a problem because clients are easier to update with bugfixes than >> >>> the server? Or maybe the preference for the client is for >> >> scalability >> >>> reasons? Could you tell me more about why you prefer a client >> >>> implementation? >> >> Making client responsible for generating the certificate signing >> >> request serves several purposes where privacy is one of main benefits: >> >> access to private key stays at the client side. >> > I would definitely veto any scheme where the client must send the >> > private key to the server. I thought the server would generate the CSR, >> > but then it would be sent to the client for signing ? >> > >> > Simo. >> > >> The server generates the data and formats it for the helper tool. The >> helper runs on the client and generates the CSR, with signature. I don't >> think we were considering signing anything server-side; in this thread I >> was referring to whether the data should be requested and formatted on >> the server or client side. > >This was my understanding as well, but Alexander's comment startled me, >thanks for confirming. Correct. I was commenting by also taking into account current Fedora situation where your certificate is generated on the server and that it needs to be provided as well if we want Fedora to use FreeIPA as a replacement for some of their infrastructure. However, this has nothing to do with CSR generation as that mode can be simulated on IPA server locally if really needed (again, because IPA server is own client, so it has access to all the client infra). -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jul 25 18:34:44 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Jul 2016 21:34:44 +0300 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <1469463845.18067.83.camel@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <1469459074.18067.75.camel@redhat.com> <1469459233.18067.77.camel@redhat.com> <1469463845.18067.83.camel@redhat.com> Message-ID: <20160725183444.rdmv23z6k47jdlg3@redhat.com> On Mon, 25 Jul 2016, Simo Sorce wrote: >On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote: >> On 07/25/2016 11:07 AM, Simo Sorce wrote: >> > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote: >> >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote: >> >>> On 07/25/2016 05:07 AM, Simo Sorce wrote: >> >>>> On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote: >> >>>>> Anyway, my main grudge is that the transformation rules shouldn't >> >>>>> really >> >>>>> be stored on and processed by the server. The server should know the >> >>>>> *what* (mapping rules), but not the *how* (transformation rules). The >> >>>>> *how* is an implementation detail and does not change in time, so >> >>>>> there's no benefit in handling it on the server. It should be handled >> >>>>> exclusively on the client, which I believe would also make the whole >> >>>>> thing more robust (it would not be possible for a bug on the server >> >>>>> to >> >>>>> break all the clients). >> >>>> W/o entering in specific +1 as a general comment on this. >> >>>> If it can be done on the client, probably better be done there. >> >>>> >> >>>> Simo. >> >>>> >> >>> My thinking was that while the CSR generation must be done on the >> >>> client, the retrieval and formatting of the data for the CSR should be >> >>> done on the server, so that the functionality is available to all >> >>> consumers of the API (ipa command-line, certmonger, Web UI, something >> >>> else?). I imagine it would be relatively easy to move the formatting >> >>> stuff into the ipa CLI, but all the other clients would then need an >> >>> implementation of their own, and so we'd need to worry about >> >>> interpreting the templates and generating CSRs in multiple different >> >>> languages. It's true that as it stands a bug on the server could break >> >>> all the clients, but on the other hand there's only one implementation >> >>> to maintain, rather than a different one in each client. >> >>> >> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more >> >>> of a problem because clients are easier to update with bugfixes than the >> >>> server? Or maybe the preference for the client is for scalability >> >>> reasons? Could you tell me more about why you prefer a client >> >>> implementation? >> >>> >> >>> (And yeah, everything here carries a disclaimer of "I probably can't >> >>> make any large changes in the remaining 3 weeks of my internship," but I >> >>> think it's still good to know and document what the limitations of the >> >>> current implementation are.) >> >>> >> >>> Thanks, >> >>> Ben >> >> You do not want to have to upgrade the server because tool foobarx >> >> became suddenly the most used. Client tools may change over the time as >> >> well, so if you try to generate stuff on the server you may end up >> >> having to support multiple version with little way of knowing which >> >> version that is. >> >> >> >> It is true that multiple client would have to implement "something", but >> >> that something could be a python library+binary that other tools/script >> >> can call or pipe through as needed. >> > Note, from my pov the code should be more or less the same except it >> > would run on the client rather than the server. Templates would be >> > delivered via the same package that delivers the tool/module and admins >> > would have the option to add more locally, though I am not against >> > sharing templates via the server if we think that is a good idea in >> > general (but the same issue vs tools changing and rendering templates >> > broken with one or another version remain). >> > >> > Simo. >> > >> Ok, I definitely see your point here about making it easier to support >> the shifting versions of the helper utilities. Pulling the formatting >> out into a standalone binary that could be used by different clients >> seems achievable. The Web UI wouldn't be able to use it, I guess, but as >> of now there's no web UI for this feature anyway. I'll make sure this is >> at least documented as a desirable modification. > >Note, that the same tool *could* be used server side in the UI, should >it be desirable. That was what I commented on -- IPA server is IPA client too, so it can make all the work locally and provide resulted bundle to download. -- / Alexander Bokovoy From rcritten at redhat.com Mon Jul 25 18:47:23 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Jul 2016 14:47:23 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <1469462607.18067.81.camel@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <1469437670.18067.62.camel@redhat.com> <47ccc9a5-0337-9e0f-1009-3b2b448444ee@redhat.com> <20160725150520.baxtfleeadh3i4q6@redhat.com> <1469462607.18067.81.camel@redhat.com> Message-ID: <57965EBB.3010503@redhat.com> Simo Sorce wrote: > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote: >>> But maybe I'm not seeing the proper priorities here. Perhaps it's >> more >>> of a problem because clients are easier to update with bugfixes than >>> the server? Or maybe the preference for the client is for >> scalability >>> reasons? Could you tell me more about why you prefer a client >>> implementation? >> Making client responsible for generating the certificate signing >> request serves several purposes where privacy is one of main benefits: >> access to private key stays at the client side. > > I would definitely veto any scheme where the client must send the > private key to the server. I thought the server would generate the CSR, > but then it would be sent to the client for signing ? I doubt any SSL library will let you disconnect CSR generation in this way (fairly certain not in NSS anyway). rob From pspacek at redhat.com Tue Jul 26 09:55:07 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Jul 2016 11:55:07 +0200 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos In-Reply-To: References: <20160714080910.xmcnbqgqvi7evfds@redhat.com> <20160718205457.GA13618@10.4.128.1> Message-ID: <5c28c534-c269-6ea9-6339-1f022746d716@redhat.com> On 25.7.2016 17:00, Ben Lipton wrote: > On 07/18/2016 04:54 PM, Lukas Slebodnik wrote: >> On (18/07/16 16:38), Petr Spacek wrote: >>> On 14.7.2016 16:11, Ben Lipton wrote: >>>> On 07/14/2016 04:09 AM, Alexander Bokovoy wrote: >>>>> On Wed, 13 Jul 2016, Ben Lipton wrote: >>>>>> Nothing too exciting, just fixes a few typos I've noticed in comments. >>>>> ACK. However, please file a ticket and mention it in the commit message. >>> Is it worth the bureaucracy? I do not think so. We will certainly not backport >>> typo fixes in comments to older branches so I would say that ticket is >>> useless. >>> >>> Just my two cents. >>> >> +1 >> >> LS >> > Necessary or not, as the ticket is created now, any objection to pushing the > patch? ACK -- Petr^2 Spacek From mbasti at redhat.com Tue Jul 26 10:04:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 26 Jul 2016 12:04:31 +0200 Subject: [Freeipa-devel] [PATCH 0003] Fix several small typos In-Reply-To: <5c28c534-c269-6ea9-6339-1f022746d716@redhat.com> References: <20160714080910.xmcnbqgqvi7evfds@redhat.com> <20160718205457.GA13618@10.4.128.1> <5c28c534-c269-6ea9-6339-1f022746d716@redhat.com> Message-ID: <4a496e84-5e98-ef2d-7583-7d3fdcbf5aff@redhat.com> On 26.07.2016 11:55, Petr Spacek wrote: > On 25.7.2016 17:00, Ben Lipton wrote: >> On 07/18/2016 04:54 PM, Lukas Slebodnik wrote: >>> On (18/07/16 16:38), Petr Spacek wrote: >>>> On 14.7.2016 16:11, Ben Lipton wrote: >>>>> On 07/14/2016 04:09 AM, Alexander Bokovoy wrote: >>>>>> On Wed, 13 Jul 2016, Ben Lipton wrote: >>>>>>> Nothing too exciting, just fixes a few typos I've noticed in comments. >>>>>> ACK. However, please file a ticket and mention it in the commit message. >>>> Is it worth the bureaucracy? I do not think so. We will certainly not backport >>>> typo fixes in comments to older branches so I would say that ticket is >>>> useless. >>>> >>>> Just my two cents. >>>> >>> +1 >>> >>> LS >>> >> Necessary or not, as the ticket is created now, any objection to pushing the >> patch? > ACK > Pushed to master: 99a702568d1bcaad2c0d1f83fdc2b485958b6e3d From ldoudova at redhat.com Tue Jul 26 10:17:11 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 26 Jul 2016 12:17:11 +0200 Subject: [Freeipa-devel] [PATCH 0022][Tests] Prevent trust test failures cause by adding duplicate DNS forward zone In-Reply-To: <7a38333f-5bbf-624f-1943-a39d23474898@redhat.com> References: <8f0b13cb-cc6e-1e0f-e56d-d16c26c8c9a3@redhat.com> <7e0d68b1-0c98-f22a-739a-9366fd39bcbb@redhat.com> <01fb470f-6a85-6805-fc36-2137fb4d7c51@redhat.com> <38d82175-0566-8b03-327f-ea3dd8b1860b@redhat.com> <8f38d8cb-052b-a09b-856e-e8817e9a7489@redhat.com> <1a20608c-4e17-b190-5cac-db39c71e2dba@redhat.com> <318770da-e34c-ee8e-d1b6-3b9e383243a9@redhat.com> <7a38333f-5bbf-624f-1943-a39d23474898@redhat.com> Message-ID: On 06/30/2016 01:14 PM, Martin Basti wrote: > > > On 30.06.2016 12:58, Lenka Doudova wrote: >> >> >> On 06/30/2016 12:51 PM, Petr Spacek wrote: >>> On 30.6.2016 12:32, Lenka Doudova wrote: >>>> >>>> On 06/29/2016 07:49 PM, Petr Spacek wrote: >>>>> On 29.6.2016 18:52, Lenka Doudova wrote: >>>>>> On 06/29/2016 06:51 PM, Petr Spacek wrote: >>>>>>> On 29.6.2016 18:48, Lenka Doudova wrote: >>>>>>>> On 06/27/2016 11:05 AM, Lenka Doudova wrote: >>>>>>>>> On 06/27/2016 10:33 AM, Martin Babinsky wrote: >>>>>>>>>> On 06/27/2016 10:28 AM, Petr Spacek wrote: >>>>>>>>>>> On 27.6.2016 10:26, Petr Spacek wrote: >>>>>>>>>>>> On 27.6.2016 10:18, Martin Babinsky wrote: >>>>>>>>>>>>> On 06/27/2016 10:04 AM, Petr Vobornik wrote: >>>>>>>>>>>>>> On 06/27/2016 09:42 AM, Lenka Doudova wrote: >>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With newly created AD machines in Brno lab, existing >>>>>>>>>>>>>>> trust tests >>>>>>>>>>>>>>> fail on >>>>>>>>>>>>>>> 'ipa dnsforwardzone-add' command claiming the zone is >>>>>>>>>>>>>>> already >>>>>>>>>>>>>>> present, >>>>>>>>>>>>>>> as new AD domain is dom-221.idm.lab.eng.brq.redhat.com. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To prevent these failures I prepared attached patch, >>>>>>>>>>>>>>> that will still >>>>>>>>>>>>>>> attempt to add the forward zone, but in case of non-zero >>>>>>>>>>>>>>> return code >>>>>>>>>>>>>>> will check the message if it says that the forward zone >>>>>>>>>>>>>>> is already >>>>>>>>>>>>>>> configured, and lets the tests continue, if it is so. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lenka >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Current approach expects that every error of ipa >>>>>>>>>>>>>> dnsforward-add here >>>>>>>>>>>>>> will mean that the zone exists. So it might hide other >>>>>>>>>>>>>> issues - not >>>>>>>>>>>>>> very >>>>>>>>>>>>>> good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On the other hand it is not very robust to parse error >>>>>>>>>>>>>> message. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Question for general audience: What do you think if IPA >>>>>>>>>>>>>> client's exit >>>>>>>>>>>>>> status would be the IPA error code instead of "1" for >>>>>>>>>>>>>> every error. >>>>>>>>>>>>>> E.g. >>>>>>>>>>>>>> in DuplicateEntry case it's 4002. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Btw, this is not a NACK. >>>>>>>>>>>>>> >>>>>>>>>>>>> Well AFAIK the exit status on POSIX systems is encoded >>>>>>>>>>>>> into a single >>>>>>>>>>>>> byte so >>>>>>>>>>>>> you cannot have the return value greater that 255. We >>>>>>>>>>>>> would have to >>>>>>>>>>>>> devise >>>>>>>>>>>>> some mapping between our XMLRPC status codes and >>>>>>>>>>>>> subprocess return >>>>>>>>>>>>> codes. >>>>>>>>>>>>> >>>>>>>>>>>>> Some of our exceptions have defined return values outside >>>>>>>>>>>>> plain '1', >>>>>>>>>>>>> e.g. >>>>>>>>>>>>> NotFound has return value of 2. It would be possible to >>>>>>>>>>>>> extend this >>>>>>>>>>>>> concept on >>>>>>>>>>>>> other common errors. >>>>>>>>>>>> Even more importantly, the forward zone is completely >>>>>>>>>>>> unnecessary >>>>>>>>>>>> because >>>>>>>>>>>> DNS >>>>>>>>>>>> when DNS is set up properly. I would simply remove the >>>>>>>>>>>> dnsforwardzone-add. >>>>>>>>>>>> >>>>>>>>>>> Grr, I meant this: >>>>>>>>>>> Even more importantly, the forward zone is completely >>>>>>>>>>> unnecessary when >>>>>>>>>>> DNS is >>>>>>>>>>> set up properly. I would simply remove the dnsforwardzone-add. >>>>>>>>>>> >>>>>>>>>> +1, our tests should not fiddle with the provisioned >>>>>>>>>> environment as >>>>>>>>>> much as >>>>>>>>>> they sometimes do. >>>>>>>>>> >>>>>>>>> Well, I have nothing against removing it completely, but left >>>>>>>>> it there just >>>>>>>>> because with previous AD machines with "wild" domains it was >>>>>>>>> necessary. >>>>>>>>> Looking at the code, your suggestion would probably mean to >>>>>>>>> entirely remove >>>>>>>>> method configure_dns_for_trust from >>>>>>>>> ipatests/test_integration/tasks.py, >>>>>>>>> right? I'll have to verify this won't break anything else. >>>>>>>>> >>>>>>>>> Lenka >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> to get back to this issue: do we really want to have the DNS >>>>>>>> configuration >>>>>>>> method removed? I mean, we no longer need it for our CI tests, >>>>>>>> with new >>>>>>>> AD VMs >>>>>>>> it works without it, but should somebody else with different >>>>>>>> setup run these >>>>>>>> tests, they could experience failures because their AD domain >>>>>>>> would not be >>>>>>>> configured in DNS by default and the test would no longer >>>>>>>> provide that >>>>>>>> configuration. It doesn't feel right to delete something we >>>>>>>> needed before >>>>>>>> but >>>>>>>> don't need anymore, in case somebody else is depending on the same >>>>>>>> configuration. But of course, I'll abide by your counsel. >>>>>>>> In case the call on DNS configuration method really is removed, >>>>>>>> should I >>>>>>>> remove even it's definition? It's not used anywhere else, so it >>>>>>>> would be >>>>>>>> quite >>>>>>>> logical. >>>>>>> Feel free to keep empty method around as a "hook" for other >>>>>>> people. The >>>>>>> important thing is that it should do nothing by default. >>>>>>> >>>>>> So leave the method call, but erase method contents and let it >>>>>> just pass? >>>>> Fine with me. (List re-added.) >>>>> >>>> Ah, sorry for doing the wrong reply. >>>> Anyway, fixed patch attached. I decided to do as you suggested - >>>> the original >>>> DNS configuring function is now empty, I modified the comment to >>>> explain >>>> significance of this strange thing. I also changed patch title to >>>> better >>>> reflect proposed changes. >>> ACK if it passes your tests. >>> >> Yes, I've had no problems running the tests since I started to use this. >> Thanks. >> > Pushed to master: 1d9e1521c59a5b43c2322892ce5cbe8cceff2790 > Hi, I just realized the same problem occurs in 4.3 branch, but the original patch was pushed to master only, hence I ask for second review. The originally pushed patch attached, should not need any modifications for ipa-4-3 branch. Ticket: https://fedorahosted.org/freeipa/ticket/6133 Thanks, Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0022.3-Tests-Remove-DNS-configuration-from-trust-tests.patch Type: text/x-patch Size: 2753 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Jul 26 10:24:26 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 Jul 2016 12:24:26 +0200 Subject: [Freeipa-devel] [PATCH 42-47][tests] RFE: Allow users to authenticate with alternative names In-Reply-To: References: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> Message-ID: <35385bd8-7bd3-255b-7b0d-e1d5efecd949@redhat.com> On 07/25/2016 02:05 PM, Milan Kub?k wrote: > On 07/25/2016 01:53 PM, Milan Kub?k wrote: >> Hi, >> >> I'm sending the tests for kerberos principal aliases rfe. The tests >> are implemented according to test plan [1] sent earlier. >> Some of the patches implement modifications and extensions to previous >> code to allow implement the tests themselves. >> >> The patches can be cloned also from github [2]. >> >> [1]: http://www.freeipa.org/page/V4/Kerberos_principal_aliases/Test_Plan >> [2]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test >> >> Cheers, >> >> >> > > Self nack for 0047, the ldapconn fixture is not needed. New patch attached. > Git repo updated (force-push). > > -- > Milan Kubik > > > Hi Milan, the tests seem to work as expected except `test_enterprise_principal_UPN_overlap_without_additional_suffix` which crashes on #6099. I have a few comments, however: Patch 42: 1.) +class KerberosAliasMixin: make sure the class inherits from 'object' so that it behaves like new-style class in Python 2. Also, I think that 'check_for_tracker' method is slightly redundant. If somebody would use the mixin directly, then he will still get "NotImplementedError" exceptions and see that he probably did something wrong. If you really really want to treat to prevent the instantiation of the class, then use ABC module to turn it into proper abstract class. But in this case it should IMHO be enough that you explained the class usage in the module docstring. 2.) + def _make_add_alias_cmd(self): + raise RuntimeError("The _make_add_alias_cmd method " + "is not implemented.") + + def _make_remove_alias_cmd(self): + raise RuntimeError("The _make_remove_alias_cmd method " + "is not implemented." Abstract methods should raise "NotImplementedError" exception. 3.) is the 'options=None' kwarg in {add,remove}_principals methods necessary? I didn't see it anywhere in the later commits so I guess you can safely remove it. Better yet, you can just replace it with '**options' since all it does is to pass options to the `*-add/remove-principal` commands. 4.) a nitpick but IIRC the mixin class should be listed before the actual hierarchy base so that MRO works as expected. So instead +class UserTracker(Tracker, KerberosAliasMixin): It should say +class UserTracker(KerberosAliasMixin, Tracker): PATCH 43: LGTM PATCH 44: Please do not create any more utility modules. Either put it to existing 'ipatests/util.py' or better yet, rename the module to something like 'mock_trust' since the scope of it is to provide mocked trust entries. PATCH 45: It would be nice if you could add '-E' option in the same way to indicate enterprise principal name resolution. PATCH 46: LGTM PATCH 47: 1.) +from ipatests.test_xmlrpc.test_range_plugin import ( + get_trust_dn, get_trusted_dom_dict, encode_mockldap_value) Since you already introduced a module grouping all trust-mocking machinery in patch 44, you could extract these functions and put it there to improve code reuse. 2.) I am not a big fan of duplicate code in 'trusted_domain' and 'trusted_domain_with_suffix' fixtures. Use some module-level mapping for common attributes and add more specific attributes per fixture. 3.) I would like to expand the test cases for AD realm namespace overlap checks. We should reject enterprise principals with suffixes coinciding with realm names, NETBIOS names, and UPN suffixes and I would like to test all three cases to get a full coverage. -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Jul 26 11:18:53 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 Jul 2016 13:18:53 +0200 Subject: [Freeipa-devel] [PATCH 0194] harden the check for trust namespace overlap in new principals In-Reply-To: <0919a23d-3c7b-8314-6b5e-0d9f7eff92c2@redhat.com> References: <0919a23d-3c7b-8314-6b5e-0d9f7eff92c2@redhat.com> Message-ID: On 07/21/2016 12:56 PM, Martin Babinsky wrote: > '*-add-principal' would crash with error if the trusted domains did not > have any UPN suffixes or NETBIOS name associated with them. This patch > fixes that. > > Big thanks to Milan who found and reported the issue during writing > tests for the feature. > > https://fedorahosted.org/freeipa/ticket/6099 > > > Bump for review. -- Martin^3 Babinsky From simo at redhat.com Tue Jul 26 11:38:25 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 26 Jul 2016 07:38:25 -0400 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <1469460374.18067.79.camel@redhat.com> References: <1469450405.18067.69.camel@redhat.com> <57962868.8090904@redhat.com> <1469458890.18067.72.camel@redhat.com> <57962BE5.60404@redhat.com> <1469460374.18067.79.camel@redhat.com> Message-ID: <1469533105.18067.89.camel@redhat.com> On Mon, 2016-07-25 at 11:26 -0400, Simo Sorce wrote: > On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: > > >> Simo Sorce wrote: > > >>> As described in #232 start restricting the use of the setkeytab > > >>> operation to just the computers objects. > > >>> > > >>> I haven't tested this with older RHEL/CentOS machines that actully use > > >>> the setkeytab operation as I do not have such an old VM handy right now. > > >>> > > >>> Meanwhile I'd like to know if ppl agree with this approach. > > >> > > >> What about services? > > > > > > Do we automatically acquire keytab for services in the old clients ? > > > > > > Are you thinking about scripted ipa-getkytab callouts ? > > > > You are limiting access to host keytabs, what about service keytabs? > > Should they be or are they now similarly restricted? > > > > Installers for something like Foreman may try to generate a service > > keytab in its installer, probably using admin credentials. I am planning > > to do the same in Openstack. > > Ok I'll amend the patch to allow service keytabs to still use the > setkeytab control still, and restrict only users. > However note that the idea of using this method is that admin can change > this default on their own, so they can restrict more or less if they > want, to that end I need to remember how to set a default that we do not > override in the update file. > > Simo. > Amended patch to allow services too. Only users are excluded. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-569-2-Restrict-the-old-setkeytab-operation.patch Type: text/x-patch Size: 4182 bytes Desc: not available URL: From mbasti at redhat.com Tue Jul 26 13:15:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 26 Jul 2016 15:15:04 +0200 Subject: [Freeipa-devel] [PATCH 0022][Tests] Prevent trust test failures cause by adding duplicate DNS forward zone In-Reply-To: References: <8f0b13cb-cc6e-1e0f-e56d-d16c26c8c9a3@redhat.com> <7e0d68b1-0c98-f22a-739a-9366fd39bcbb@redhat.com> <01fb470f-6a85-6805-fc36-2137fb4d7c51@redhat.com> <38d82175-0566-8b03-327f-ea3dd8b1860b@redhat.com> <8f38d8cb-052b-a09b-856e-e8817e9a7489@redhat.com> <1a20608c-4e17-b190-5cac-db39c71e2dba@redhat.com> <318770da-e34c-ee8e-d1b6-3b9e383243a9@redhat.com> <7a38333f-5bbf-624f-1943-a39d23474898@redhat.com> Message-ID: <61ca8c19-dd53-b40e-e433-a9ba516a06b4@redhat.com> On 26.07.2016 12:17, Lenka Doudova wrote: > > > On 06/30/2016 01:14 PM, Martin Basti wrote: >> >> >> On 30.06.2016 12:58, Lenka Doudova wrote: >>> >>> >>> On 06/30/2016 12:51 PM, Petr Spacek wrote: >>>> On 30.6.2016 12:32, Lenka Doudova wrote: >>>>> >>>>> On 06/29/2016 07:49 PM, Petr Spacek wrote: >>>>>> On 29.6.2016 18:52, Lenka Doudova wrote: >>>>>>> On 06/29/2016 06:51 PM, Petr Spacek wrote: >>>>>>>> On 29.6.2016 18:48, Lenka Doudova wrote: >>>>>>>>> On 06/27/2016 11:05 AM, Lenka Doudova wrote: >>>>>>>>>> On 06/27/2016 10:33 AM, Martin Babinsky wrote: >>>>>>>>>>> On 06/27/2016 10:28 AM, Petr Spacek wrote: >>>>>>>>>>>> On 27.6.2016 10:26, Petr Spacek wrote: >>>>>>>>>>>>> On 27.6.2016 10:18, Martin Babinsky wrote: >>>>>>>>>>>>>> On 06/27/2016 10:04 AM, Petr Vobornik wrote: >>>>>>>>>>>>>>> On 06/27/2016 09:42 AM, Lenka Doudova wrote: >>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> With newly created AD machines in Brno lab, existing >>>>>>>>>>>>>>>> trust tests >>>>>>>>>>>>>>>> fail on >>>>>>>>>>>>>>>> 'ipa dnsforwardzone-add' command claiming the zone is >>>>>>>>>>>>>>>> already >>>>>>>>>>>>>>>> present, >>>>>>>>>>>>>>>> as new AD domain is dom-221.idm.lab.eng.brq.redhat.com. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To prevent these failures I prepared attached patch, >>>>>>>>>>>>>>>> that will still >>>>>>>>>>>>>>>> attempt to add the forward zone, but in case of >>>>>>>>>>>>>>>> non-zero return code >>>>>>>>>>>>>>>> will check the message if it says that the forward zone >>>>>>>>>>>>>>>> is already >>>>>>>>>>>>>>>> configured, and lets the tests continue, if it is so. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Lenka >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Current approach expects that every error of ipa >>>>>>>>>>>>>>> dnsforward-add here >>>>>>>>>>>>>>> will mean that the zone exists. So it might hide other >>>>>>>>>>>>>>> issues - not >>>>>>>>>>>>>>> very >>>>>>>>>>>>>>> good. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On the other hand it is not very robust to parse error >>>>>>>>>>>>>>> message. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Question for general audience: What do you think if IPA >>>>>>>>>>>>>>> client's exit >>>>>>>>>>>>>>> status would be the IPA error code instead of "1" for >>>>>>>>>>>>>>> every error. >>>>>>>>>>>>>>> E.g. >>>>>>>>>>>>>>> in DuplicateEntry case it's 4002. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Btw, this is not a NACK. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Well AFAIK the exit status on POSIX systems is encoded >>>>>>>>>>>>>> into a single >>>>>>>>>>>>>> byte so >>>>>>>>>>>>>> you cannot have the return value greater that 255. We >>>>>>>>>>>>>> would have to >>>>>>>>>>>>>> devise >>>>>>>>>>>>>> some mapping between our XMLRPC status codes and >>>>>>>>>>>>>> subprocess return >>>>>>>>>>>>>> codes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some of our exceptions have defined return values outside >>>>>>>>>>>>>> plain '1', >>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>> NotFound has return value of 2. It would be possible to >>>>>>>>>>>>>> extend this >>>>>>>>>>>>>> concept on >>>>>>>>>>>>>> other common errors. >>>>>>>>>>>>> Even more importantly, the forward zone is completely >>>>>>>>>>>>> unnecessary >>>>>>>>>>>>> because >>>>>>>>>>>>> DNS >>>>>>>>>>>>> when DNS is set up properly. I would simply remove the >>>>>>>>>>>>> dnsforwardzone-add. >>>>>>>>>>>>> >>>>>>>>>>>> Grr, I meant this: >>>>>>>>>>>> Even more importantly, the forward zone is completely >>>>>>>>>>>> unnecessary when >>>>>>>>>>>> DNS is >>>>>>>>>>>> set up properly. I would simply remove the dnsforwardzone-add. >>>>>>>>>>>> >>>>>>>>>>> +1, our tests should not fiddle with the provisioned >>>>>>>>>>> environment as >>>>>>>>>>> much as >>>>>>>>>>> they sometimes do. >>>>>>>>>>> >>>>>>>>>> Well, I have nothing against removing it completely, but left >>>>>>>>>> it there just >>>>>>>>>> because with previous AD machines with "wild" domains it was >>>>>>>>>> necessary. >>>>>>>>>> Looking at the code, your suggestion would probably mean to >>>>>>>>>> entirely remove >>>>>>>>>> method configure_dns_for_trust from >>>>>>>>>> ipatests/test_integration/tasks.py, >>>>>>>>>> right? I'll have to verify this won't break anything else. >>>>>>>>>> >>>>>>>>>> Lenka >>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> to get back to this issue: do we really want to have the DNS >>>>>>>>> configuration >>>>>>>>> method removed? I mean, we no longer need it for our CI tests, >>>>>>>>> with new >>>>>>>>> AD VMs >>>>>>>>> it works without it, but should somebody else with different >>>>>>>>> setup run these >>>>>>>>> tests, they could experience failures because their AD domain >>>>>>>>> would not be >>>>>>>>> configured in DNS by default and the test would no longer >>>>>>>>> provide that >>>>>>>>> configuration. It doesn't feel right to delete something we >>>>>>>>> needed before >>>>>>>>> but >>>>>>>>> don't need anymore, in case somebody else is depending on the >>>>>>>>> same >>>>>>>>> configuration. But of course, I'll abide by your counsel. >>>>>>>>> In case the call on DNS configuration method really is >>>>>>>>> removed, should I >>>>>>>>> remove even it's definition? It's not used anywhere else, so >>>>>>>>> it would be >>>>>>>>> quite >>>>>>>>> logical. >>>>>>>> Feel free to keep empty method around as a "hook" for other >>>>>>>> people. The >>>>>>>> important thing is that it should do nothing by default. >>>>>>>> >>>>>>> So leave the method call, but erase method contents and let it >>>>>>> just pass? >>>>>> Fine with me. (List re-added.) >>>>>> >>>>> Ah, sorry for doing the wrong reply. >>>>> Anyway, fixed patch attached. I decided to do as you suggested - >>>>> the original >>>>> DNS configuring function is now empty, I modified the comment to >>>>> explain >>>>> significance of this strange thing. I also changed patch title to >>>>> better >>>>> reflect proposed changes. >>>> ACK if it passes your tests. >>>> >>> Yes, I've had no problems running the tests since I started to use >>> this. >>> Thanks. >>> >> Pushed to master: 1d9e1521c59a5b43c2322892ce5cbe8cceff2790 >> > Hi, > > I just realized the same problem occurs in 4.3 branch, but the > original patch was pushed to master only, hence I ask for second review. > The originally pushed patch attached, should not need any > modifications for ipa-4-3 branch. > > Ticket: https://fedorahosted.org/freeipa/ticket/6133 > > Thanks, > Lenka > > Pushed to ipa-4-3: 40b1459ad0299e95331699be9684682fca02a570 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ariel.o.barria at gmail.com Thu Jul 21 22:14:35 2016 From: ariel.o.barria at gmail.com (Ariel Barria) Date: Thu, 21 Jul 2016 17:14:35 -0500 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode Message-ID: Hello everyone. I send patch for review. Regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-arielb-0001-six.u-function-instead-of-the-de.patch Type: text/x-patch Size: 1255 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Jul 26 13:34:44 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 Jul 2016 15:34:44 +0200 Subject: [Freeipa-devel] [PATCH 0553] CI tests: improve log collecting in tests In-Reply-To: References: <188b0c67-928f-02b3-d77f-d87c84ef3466@redhat.com> <21a9655a-3943-67ac-3a8f-0a81dae37de3@redhat.com> <2dc7f75b-c0c4-e656-0cff-359696e2d05c@redhat.com> <028f109f-136a-ba8e-1054-534286ae23cf@redhat.com> Message-ID: <31d9ff1f-fb4d-86ba-3bcd-842ef55e160e@redhat.com> On 07/25/2016 06:24 PM, Martin Basti wrote: > > > On 25.07.2016 18:02, Martin Babinsky wrote: >> On 07/22/2016 06:13 PM, Martin Basti wrote: >>> >>> >>> On 20.07.2016 17:41, Martin Basti wrote: >>>> >>>> >>>> >>>> On 19.07.2016 17:05, Martin Basti wrote: >>>>> >>>>> >>>>> >>>>> On 19.07.2016 16:18, Martin Basti wrote: >>>>>> Patch attached. >>>>>> >>>>>> >>>>>> >>>>> self-NACK, my assumptions were wrong, this doesn't work if any of log >>>>> files do not exist >>>>> >>>>> >>>> updated patches attached >>>> >>>> Please note, that in case that any logfile does not exist tar returns >>>> exit code 2, but provides correct output anyway. >>>> >>>> >>> Updated patches attached. >>> >>> >> NACK: >> >> ************* Module ipatests.test_integration.tasks >> ipatests/test_integration/tasks.py:68: [E1101(no-member), >> setup_server_logs_collecting] Instance of 'FedoraPathNamespace' has no >> 'IPASERVER_CA_INSTALL_LOG' member) >> Makefile:137: recipe for target 'lint' failed >> make: *** [lint] Error 1 >> > Ooops, I forgot to merge fix > > Updated patch attached. ACK. Pushed to master: ae623864ee6e5dc2f6d254111c9cdd369fc144a8 -- Martin^3 Babinsky From ofayans at redhat.com Tue Jul 26 13:34:54 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 26 Jul 2016 15:34:54 +0200 Subject: [Freeipa-devel] [Test][patch-0053] Forced-client-reenrollment test fixed. In-Reply-To: References: <577ACC32.3030201@redhat.com> <577DF223.5010302@redhat.com> Message-ID: <579766FE.3000108@redhat.com> Hi Martin, The patch was updated according to your suggestions. A separate patch removing outdated tests is attached. On 07/08/2016 02:10 PM, Martin Basti wrote: > > > On 07.07.2016 08:09, Oleg Fayans wrote: >> Updated version of the patch is attached with the failing tests marked >> as xfailed (let's make the jenkins green). >> >> On 07/04/2016 10:50 PM, Oleg Fayans wrote: >>> 2 out of 7 tests currently fail due to a known issue [1], others pass. >>> >>> [1] https://fedorahosted.org/freeipa/ticket/6029 >>> >>> >>> >>> >> >> >> > This is wrong: > > 1) > you are not getting SSHFP records, just SSH public key (with your changes) > > 2) > you are using host-find without any arguments, so it will returns SSH > key for all hosts, the code before was getting SSHFP only for one host. > Would be better to use host-show? > > 3) > you actually found a bug, because host-find and host-show should print > only SSH fingerprints not SSH keys > https://fedorahosted.org/freeipa/ticket/6042 > https://fedorahosted.org/freeipa/ticket/6043 > > 4) > don't call it SSHFP records in code, because it is not DNS related, > probably you want to get SSH fingerprints instead of SSH keys > > 5) > It may contain multiple SSH keys, you always return only the first (the > original code returns all values) > > def get_sshfp_record(self): > - sshfp_record = '' > - client_host = self.clients[0].hostname.split('.')[0] > - > result = self.master.run_command( > - ['ipa', 'dnsrecord-show', self.master.domain.name, client_host] > + ['ipa', 'host-find'] > ) > - > - lines = result.stdout_text.splitlines() > - for line in lines: > - if 'SSHFP record:' in line: > - sshfp_record = line.replace('SSHFP record:', '').strip() > - > - assert sshfp_record, 'SSHFP record not found' > - > - sshfp_record = set(sshfp_record.split(', ')) > - self.log.debug("SSHFP record for host %s: %s", client_host, > str(sshfp_record)) > - > - return sshfp_record > + records = result.stdout_text.split('\n\n') > + sshkey_re = re.compile('.+SSH public key: ssh-\w+ (\S+?),.+') > + for hostrecord in records: > + if self.clients[0].hostname in hostrecord: > + sshfps = sshkey_re.findall(hostrecord) > + assert sshfps, 'SSHFP record not found' > + sshfp = sshfps[0] > + return sshfp > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0053-Removed-outdated-reenrollment-tests.patch Type: text/x-patch Size: 2731 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0054-Updated-forced_client_reenrollment-test.patch Type: text/x-patch Size: 6868 bytes Desc: not available URL: From ofayans at redhat.com Tue Jul 26 13:35:50 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 26 Jul 2016 15:35:50 +0200 Subject: [Freeipa-devel] [Test][patch-0053] Forced-client-reenrollment test fixed. In-Reply-To: <579766FE.3000108@redhat.com> References: <577ACC32.3030201@redhat.com> <577DF223.5010302@redhat.com> <579766FE.3000108@redhat.com> Message-ID: <57976736.90903@redhat.com> Here is the test output: https://paste.fedoraproject.org/395706/69538081/ On 07/26/2016 03:34 PM, Oleg Fayans wrote: > Hi Martin, > > The patch was updated according to your suggestions. A separate patch > removing outdated tests is attached. > > On 07/08/2016 02:10 PM, Martin Basti wrote: >> >> >> On 07.07.2016 08:09, Oleg Fayans wrote: >>> Updated version of the patch is attached with the failing tests marked >>> as xfailed (let's make the jenkins green). >>> >>> On 07/04/2016 10:50 PM, Oleg Fayans wrote: >>>> 2 out of 7 tests currently fail due to a known issue [1], others pass. >>>> >>>> [1] https://fedorahosted.org/freeipa/ticket/6029 >>>> >>>> >>>> >>>> >>> >>> >>> >> This is wrong: >> >> 1) >> you are not getting SSHFP records, just SSH public key (with your >> changes) >> >> 2) >> you are using host-find without any arguments, so it will returns SSH >> key for all hosts, the code before was getting SSHFP only for one host. >> Would be better to use host-show? >> >> 3) >> you actually found a bug, because host-find and host-show should print >> only SSH fingerprints not SSH keys >> https://fedorahosted.org/freeipa/ticket/6042 >> https://fedorahosted.org/freeipa/ticket/6043 >> >> 4) >> don't call it SSHFP records in code, because it is not DNS related, >> probably you want to get SSH fingerprints instead of SSH keys >> >> 5) >> It may contain multiple SSH keys, you always return only the first (the >> original code returns all values) >> >> def get_sshfp_record(self): >> - sshfp_record = '' >> - client_host = self.clients[0].hostname.split('.')[0] >> - >> result = self.master.run_command( >> - ['ipa', 'dnsrecord-show', self.master.domain.name, >> client_host] >> + ['ipa', 'host-find'] >> ) >> - >> - lines = result.stdout_text.splitlines() >> - for line in lines: >> - if 'SSHFP record:' in line: >> - sshfp_record = line.replace('SSHFP record:', '').strip() >> - >> - assert sshfp_record, 'SSHFP record not found' >> - >> - sshfp_record = set(sshfp_record.split(', ')) >> - self.log.debug("SSHFP record for host %s: %s", client_host, >> str(sshfp_record)) >> - >> - return sshfp_record >> + records = result.stdout_text.split('\n\n') >> + sshkey_re = re.compile('.+SSH public key: ssh-\w+ (\S+?),.+') >> + for hostrecord in records: >> + if self.clients[0].hostname in hostrecord: >> + sshfps = sshkey_re.findall(hostrecord) >> + assert sshfps, 'SSHFP record not found' >> + sshfp = sshfps[0] >> + return sshfp >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Tue Jul 26 14:09:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 26 Jul 2016 16:09:31 +0200 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode In-Reply-To: References: Message-ID: On 22.07.2016 00:14, Ariel Barria wrote: > Hello everyone. > > I send patch for review. > > Regards, > > Thank you, I will look on this, for some reason we received your e-mail just today (2016-07-26) Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Jul 26 14:28:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Jul 2016 16:28:07 +0200 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode In-Reply-To: References: Message-ID: <3afeae65-e827-70d2-948d-89eef71bbcd3@redhat.com> Hi, On 26.7.2016 16:09, Martin Basti wrote: > > > On 22.07.2016 00:14, Ariel Barria wrote: >> Hello everyone. >> >> I send patch for review. NACK, six.u() is supposed to be used on string literals *only* [1]. A proper fix would be something like: value = self.to_text() if not isinstance(value, unicode): value = value.decode('ascii') return value >> >> Regards, >> >> > > Thank you, > > I will look on this, for some reason we received your e-mail just today > (2016-07-26) Honza [1] -- Jan Cholasta From pspacek at redhat.com Tue Jul 26 14:39:21 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Jul 2016 16:39:21 +0200 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode In-Reply-To: <3afeae65-e827-70d2-948d-89eef71bbcd3@redhat.com> References: <3afeae65-e827-70d2-948d-89eef71bbcd3@redhat.com> Message-ID: <8e4e551f-3446-9d33-de19-1dc4996ff697@redhat.com> On 26.7.2016 16:28, Jan Cholasta wrote: > Hi, > > On 26.7.2016 16:09, Martin Basti wrote: >> >> >> On 22.07.2016 00:14, Ariel Barria wrote: >>> Hello everyone. >>> >>> I send patch for review. > > NACK, six.u() is supposed to be used on string literals *only* [1]. > > A proper fix would be something like: > > value = self.to_text() > if not isinstance(value, unicode): > value = value.decode('ascii') > return value Most importantly, we should fix/provide this method in python-dns and inherit this method from there. Petr^2 Spacek > >>> >>> Regards, >>> >>> >> >> Thank you, >> >> I will look on this, for some reason we received your e-mail just today >> (2016-07-26) > > Honza > > [1] From mbabinsk at redhat.com Tue Jul 26 14:42:03 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 Jul 2016 16:42:03 +0200 Subject: [Freeipa-devel] [PATCH 0196] baseldap: Fix MidairCollision instantiation during entry modification Message-ID: Fix for https://fedorahosted.org/freeipa/ticket/6097 Since this issue was found during investigation of other ticket[1], you can test it by performing steps to reproduce #6041, but instead of internal error you should see the MidairCollision raised as public error with the right error message. [1] https://fedorahosted.org/freeipa/ticket/6041 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0196-baseldap-Fix-MidairCollision-instantiation-during-en.patch Type: text/x-patch Size: 1443 bytes Desc: not available URL: From ariel.o.barria at gmail.com Tue Jul 26 15:01:02 2016 From: ariel.o.barria at gmail.com (Ariel Barria) Date: Tue, 26 Jul 2016 10:01:02 -0500 Subject: [Freeipa-devel] [PATCH] 0002 Add client install option to set ipa_backup_server Message-ID: Hello everyone. I send patch for review. Regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-arielb-0002-Add-client-install-option-to-set.patch Type: text/x-patch Size: 2514 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jul 26 15:22:19 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 26 Jul 2016 18:22:19 +0300 Subject: [Freeipa-devel] [PATCH 0196] baseldap: Fix MidairCollision instantiation during entry modification In-Reply-To: References: Message-ID: <20160726152219.u67pdvfxg4mwkogc@redhat.com> On Tue, 26 Jul 2016, Martin Babinsky wrote: >Fix for https://fedorahosted.org/freeipa/ticket/6097 > >Since this issue was found during investigation of other ticket[1], >you can test it by performing steps to reproduce #6041, but instead of >internal error you should see the MidairCollision raised as public >error with the right error message. > >[1] https://fedorahosted.org/freeipa/ticket/6041 I have a preliminary patch for slapi-nis to fix 6041 (attached). As for this fix -- ACK. > >-- >Martin^3 Babinsky >From 8f0d6dab08f61fe2fd1ad64a63f7ab91fc5227d4 Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Mon, 25 Jul 2016 14:05:08 +0200 >Subject: [PATCH] baseldap: Fix MidairCollision instantiation during entry > modification > >https://fedorahosted.org/freeipa/ticket/6097 >--- > ipaserver/plugins/baseldap.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/ipaserver/plugins/baseldap.py b/ipaserver/plugins/baseldap.py >index 6107e43a6ee17d9b9a63d9dc109664d8b232069f..f7844e3e7c59c259b9c8367d135b2dbefc3f0016 100644 >--- a/ipaserver/plugins/baseldap.py >+++ b/ipaserver/plugins/baseldap.py >@@ -1466,7 +1466,7 @@ class LDAPUpdate(LDAPQuery, crud.Update): > entry_attrs.dn, attrs_list) > except errors.NotFound: > raise errors.MidairCollision( >- format=_('the entry was deleted while being modified') >+ message=_('the entry was deleted while being modified') > ) > > self.obj.get_indirect_members(entry_attrs, attrs_list) >@@ -2344,7 +2344,7 @@ class BaseLDAPModAttribute(LDAPQuery): > entry_attrs.dn, attrs_list) > except errors.NotFound: > raise errors.MidairCollision( >- format=_('the entry was deleted while being modified') >+ message=_('the entry was deleted while being modified') > ) > > for callback in self.get_callbacks('post'): >-- >2.7.4 > >-- >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 -- / Alexander Bokovoy -------------- next part -------------- From 987472fbe8c3564c0bb70c0dd8eebbc430117e0a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 26 Jul 2016 18:11:53 +0300 Subject: [PATCH] back-sch: do not clobber target of the pblock for idview When extracting idview all we care is the DN of new target. We don't really use the rewritten target as a string anymore, so there is no need to rewrite the string in the pblock. This fixes a bug when running with 389-ds 1.3.5.10+ which is more strict about modification of the values in pblock. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1360245 --- src/back-sch.c | 43 ++++++++++++++++++++++--------------------- src/back-sch.h | 2 +- 2 files changed, 23 insertions(+), 22 deletions(-) diff --git a/src/back-sch.c b/src/back-sch.c index 0745329..e15988f 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -1652,6 +1652,8 @@ backend_search_cb(Slapi_PBlock *pb) struct backend_search_cbdata cbdata; struct backend_staged_search *staged, *next; int i, isroot, ret; + char *original_target = NULL; + char *target = NULL; if (wrap_get_call_level() > 0) { return 0; @@ -1676,7 +1678,7 @@ backend_search_cb(Slapi_PBlock *pb) return 0; } - slapi_pblock_get(pb, SLAPI_SEARCH_TARGET, &cbdata.target); + slapi_pblock_get(pb, SLAPI_SEARCH_TARGET, &original_target); slapi_pblock_get(pb, SLAPI_SEARCH_SCOPE, &cbdata.scope); slapi_pblock_get(pb, SLAPI_SEARCH_SIZELIMIT, &cbdata.sizelimit); slapi_pblock_get(pb, SLAPI_SEARCH_TIMELIMIT, &cbdata.timelimit); @@ -1697,15 +1699,15 @@ backend_search_cb(Slapi_PBlock *pb) /* Okay, we can search. */ slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, "searching from \"%s\" for \"%s\" with scope %d%s\n", - cbdata.target, cbdata.strfilter, cbdata.scope, + original_target, cbdata.strfilter, cbdata.scope, backend_sch_scope_as_string(cbdata.scope)); - cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); + cbdata.target_dn = slapi_sdn_new_dn_byval(original_target); /* Check if there's a backend handling this search. */ if (!slapi_be_exist(cbdata.target_dn)) { slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, "slapi_be_exists(\"%s\") = 0, " - "ignoring search\n", cbdata.target); + "ignoring search\n", original_target); slapi_sdn_free(&cbdata.target_dn); return 0; } @@ -1716,22 +1718,23 @@ backend_search_cb(Slapi_PBlock *pb) * detect the ID view use. Unless the ID view is within the set we control, don't consider the override */ map_data_foreach_domain(cbdata.state, backend_search_find_set_dn_cb, &cbdata); if (cbdata.answer == FALSE) { - idview_replace_target_dn(&cbdata.target, &cbdata.idview); + target = slapi_ch_strdup(original_target); + idview_replace_target_dn(&target, &cbdata.idview); if (cbdata.idview != NULL) { slapi_sdn_free(&cbdata.target_dn); /* Perform another check, now for rewritten DN */ - cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); + cbdata.target_dn = slapi_sdn_new_dn_byval(target); map_data_foreach_domain(cbdata.state, backend_search_find_set_dn_cb, &cbdata); /* Rewritten DN might still be outside of our trees */ if (cbdata.answer == TRUE) { slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, "Use of ID view '%s' is detected, searching from \"%s\" " "for \"%s\" with scope %d%s. Filter may get overridden later.\n", - cbdata.idview, cbdata.target, cbdata.strfilter, cbdata.scope, + cbdata.idview, target, cbdata.strfilter, cbdata.scope, backend_sch_scope_as_string(cbdata.scope)); } else { slapi_sdn_free(&cbdata.target_dn); - slapi_ch_free_string(&cbdata.target); + slapi_ch_free_string(&target); slapi_ch_free_string(&cbdata.idview); slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, @@ -1739,6 +1742,8 @@ backend_search_cb(Slapi_PBlock *pb) "ignoring search\n"); return 0; } + } else { + slapi_ch_free_string(&target); } } cbdata.answer = FALSE; @@ -1890,7 +1895,7 @@ backend_search_cb(Slapi_PBlock *pb) } slapi_sdn_free(&cbdata.target_dn); if (cbdata.idview != NULL) { - slapi_ch_free_string(&cbdata.target); + slapi_ch_free_string(&target); } slapi_ch_free_string(&cbdata.idview); #ifdef USE_IPA_IDVIEWS @@ -1904,7 +1909,6 @@ backend_search_cb(Slapi_PBlock *pb) /* Locate the entry for a given DN. */ struct backend_locate_cbdata { struct plugin_state *state; - char *target; Slapi_DN *target_dn; struct backend_entry_data *entry_data; @@ -1953,6 +1957,7 @@ static void backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char **group, const char**set) { struct backend_locate_cbdata cbdata; + char *original_target = NULL; slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &cbdata.state); if (cbdata.state->plugin_base == NULL) { @@ -1960,9 +1965,9 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** *data = NULL; return; } - slapi_pblock_get(pb, SLAPI_TARGET_DN, &cbdata.target); + slapi_pblock_get(pb, SLAPI_TARGET_DN, &original_target); - cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); + cbdata.target_dn = slapi_sdn_new_dn_byval(original_target); cbdata.entry_data = NULL; cbdata.entry_group = NULL; cbdata.entry_set = NULL; @@ -1972,12 +1977,9 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** * rebuild the target's RDN to use original attribute's value */ if (cbdata.entry_data == NULL) { char *idview = NULL; - char *target, *original_target; - target = original_target = slapi_ch_strdup(cbdata.target); + char *target = NULL; + target = slapi_ch_strdup(original_target); idview_replace_target_dn(&target, &idview); - if (target != original_target) { - slapi_ch_free_string(&original_target); - } if (idview != NULL) { char *rdnstr; char *val; @@ -1992,7 +1994,6 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** bval.bv_val = slapi_ch_strdup(val); memset(&scbdata, 0, sizeof(scbdata)); scbdata.idview = idview; - scbdata.target = target; scbdata.pb = pb; scbdata.state = cbdata.state; scbdata.target_dn = slapi_sdn_new_dn_byval(target); @@ -2025,7 +2026,6 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** * insufficient-access error. */ struct backend_group_check_scope_cbdata { struct plugin_state *state; - const char *target; Slapi_DN *target_dn; bool_t ours; }; @@ -2050,14 +2050,15 @@ static bool_t backend_check_scope_pb(Slapi_PBlock *pb) { struct backend_group_check_scope_cbdata cbdata; + char *original_target = NULL; slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &cbdata.state); if (cbdata.state->plugin_base == NULL) { /* The plugin was not actually started. */ return FALSE; } - slapi_pblock_get(pb, SLAPI_TARGET_DN, &cbdata.target); - cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); + slapi_pblock_get(pb, SLAPI_TARGET_DN, &original_target); + cbdata.target_dn = slapi_sdn_new_dn_byval(original_target); cbdata.ours = FALSE; map_data_foreach_domain(cbdata.state, backend_group_check_scope_cb, &cbdata); diff --git a/src/back-sch.h b/src/back-sch.h index 1258ae0..9a9abc7 100644 --- a/src/back-sch.h +++ b/src/back-sch.h @@ -88,7 +88,7 @@ struct entries_to_send { struct backend_search_cbdata { Slapi_PBlock *pb; struct plugin_state *state; - char *target, *strfilter, **attrs; + char *strfilter, **attrs; char *idview; Slapi_Entry **overrides; int scope, sizelimit, timelimit, attrsonly; -- 2.7.4 From abokovoy at redhat.com Tue Jul 26 15:50:04 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 26 Jul 2016 18:50:04 +0300 Subject: [Freeipa-devel] [PATCH 0196] baseldap: Fix MidairCollision instantiation during entry modification In-Reply-To: <20160726152219.u67pdvfxg4mwkogc@redhat.com> References: <20160726152219.u67pdvfxg4mwkogc@redhat.com> Message-ID: <20160726155004.bq3fjlbhd2ykzsb6@redhat.com> On Tue, 26 Jul 2016, Alexander Bokovoy wrote: > On Tue, 26 Jul 2016, Martin Babinsky wrote: > > Fix for https://fedorahosted.org/freeipa/ticket/6097 > > > > Since this issue was found during investigation of other ticket[1], you > > can test it by performing steps to reproduce #6041, but instead of > > internal error you should see the MidairCollision raised as public error > > with the right error message. > > > > [1] https://fedorahosted.org/freeipa/ticket/6041 > I have a preliminary patch for slapi-nis to fix 6041 (attached). Tested the slapi-nis patch: # kinit Administrator at AD.TEST Password for Administrator at AD.TEST: # ipa idoverrideuser-find 'default trust view' administrator at ad.test --raw --all -------------------------- 1 User ID override matched -------------------------- dn: ipaanchoruuid=:SID:S-1-5-21-2275361654-3393353068-3720134936-500,cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=ad,dc=test ipaanchoruuid: :SID:S-1-5-21-2275361654-3393353068-3720134936-500 loginshell: /bin/bash ipaoriginaluid: administrator at ad.test objectclass: ipaOverrideAnchor objectclass: top objectclass: ipaUserOverride objectclass: ipasshuser objectclass: ipaSshGroupOfPubKeys ---------------------------- Number of entries returned 1 ---------------------------- # ipa idoverrideuser-mod 'default trust view' administrator at ad.test --addattr='objectclass=nestedGroup' ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'objectClass' attribute of entry 'ipaanchoruuid=:sid:s-1-5-21-2275361654-3393353068-3720134936-500,cn=default trust view,cn=views,cn=accounts,dc=ipa,dc=ad,dc=test'. # klist -A Ticket cache: KEYRING:persistent:0:0 Default principal: Administrator at AD.TEST Valid starting Expires Service principal 07/26/2016 18:45:46 07/27/2016 04:45:30 HTTP/f24-master.ipa.ad.test at IPA.AD.TEST renew until 07/27/2016 18:45:27 07/26/2016 18:45:46 07/27/2016 04:45:30 krbtgt/IPA.AD.TEST at AD.TEST renew until 07/27/2016 18:45:27 07/26/2016 18:45:30 07/27/2016 04:45:30 krbtgt/AD.TEST at AD.TEST renew until 07/27/2016 18:45:27 # ipa idoverrideuser-mod 'default trust view' administrator at ad.test --desc='Administrator of a trusted domain' ---------------------------------------------------- Modified an User ID override "administrator at ad.test" ---------------------------------------------------- Anchor to override: administrator at ad.test Description: Administrator of a trusted domain Login shell: /bin/bash So no MidairCollision anymore and editing ID override as the AD user associated with the override works for those attributes that are allowed. -- / Alexander Bokovoy From mbabinsk at redhat.com Tue Jul 26 16:16:19 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 26 Jul 2016 18:16:19 +0200 Subject: [Freeipa-devel] [Test][patch-0053] Forced-client-reenrollment test fixed. In-Reply-To: <579766FE.3000108@redhat.com> References: <577ACC32.3030201@redhat.com> <577DF223.5010302@redhat.com> <579766FE.3000108@redhat.com> Message-ID: <2c21930a-efdb-b042-e2ff-36b10c685fe9@redhat.com> On 07/26/2016 03:34 PM, Oleg Fayans wrote: > Hi Martin, > > The patch was updated according to your suggestions. A separate patch > removing outdated tests is attached. > > On 07/08/2016 02:10 PM, Martin Basti wrote: >> >> >> On 07.07.2016 08:09, Oleg Fayans wrote: >>> Updated version of the patch is attached with the failing tests marked >>> as xfailed (let's make the jenkins green). >>> >>> On 07/04/2016 10:50 PM, Oleg Fayans wrote: >>>> 2 out of 7 tests currently fail due to a known issue [1], others pass. >>>> >>>> [1] https://fedorahosted.org/freeipa/ticket/6029 >>>> >>>> >>>> >>>> >>> >>> >>> >> This is wrong: >> >> 1) >> you are not getting SSHFP records, just SSH public key (with your >> changes) >> >> 2) >> you are using host-find without any arguments, so it will returns SSH >> key for all hosts, the code before was getting SSHFP only for one host. >> Would be better to use host-show? >> >> 3) >> you actually found a bug, because host-find and host-show should print >> only SSH fingerprints not SSH keys >> https://fedorahosted.org/freeipa/ticket/6042 >> https://fedorahosted.org/freeipa/ticket/6043 >> >> 4) >> don't call it SSHFP records in code, because it is not DNS related, >> probably you want to get SSH fingerprints instead of SSH keys >> >> 5) >> It may contain multiple SSH keys, you always return only the first (the >> original code returns all values) >> >> def get_sshfp_record(self): >> - sshfp_record = '' >> - client_host = self.clients[0].hostname.split('.')[0] >> - >> result = self.master.run_command( >> - ['ipa', 'dnsrecord-show', self.master.domain.name, >> client_host] >> + ['ipa', 'host-find'] >> ) >> - >> - lines = result.stdout_text.splitlines() >> - for line in lines: >> - if 'SSHFP record:' in line: >> - sshfp_record = line.replace('SSHFP record:', '').strip() >> - >> - assert sshfp_record, 'SSHFP record not found' >> - >> - sshfp_record = set(sshfp_record.split(', ')) >> - self.log.debug("SSHFP record for host %s: %s", client_host, >> str(sshfp_record)) >> - >> - return sshfp_record >> + records = result.stdout_text.split('\n\n') >> + sshkey_re = re.compile('.+SSH public key: ssh-\w+ (\S+?),.+') >> + for hostrecord in records: >> + if self.clients[0].hostname in hostrecord: >> + sshfps = sshkey_re.findall(hostrecord) >> + assert sshfps, 'SSHFP record not found' >> + sshfp = sshfps[0] >> + return sshfp >> >> > > > Oleg, the original forced client reenrollment suite passes for me: """ =========================================== 8 passed in 1859.52 seconds ============================================ """ I am not quite sure what are you trying to accomplish with these patches, since you are deleting valid test cases and then removing 'restore_client' method that simulates the use case of e.g. removing a client VM while keeping old keytab and host entry and then re-enrolling. The commit messages did not help very much, either. Please review the original design and test cases carefully and make sure you understand why is the test constructed the way it is: http://www.freeipa.org/page/V3/Forced_client_re-enrollment NACK until you clearly state the purpose of your patches. -- Martin^3 Babinsky From akasurde at redhat.com Wed Jul 27 03:47:36 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 27 Jul 2016 09:17:36 +0530 Subject: [Freeipa-devel] [PATCH 0018] Minor fix in ipa-replica-manage MAN page In-Reply-To: References: Message-ID: <23a7f7cd-8344-6ad1-9591-ea60be6f8ee4@redhat.com> Ping. On 07/13/2016 09:24 AM, Abhijeet Kasurde wrote: > > Hi All, > > Please review patch. > > Fixes: https://fedorahosted.org/freeipa/ticket/6058 > -- > Thanks, > Abhijeet Kasurde > > IRC: akasurde > http://akasurde.github.io > > > -- Thanks, Abhijeet Kasurde IRC: akasurde http://akasurde.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Jul 27 07:38:56 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 Jul 2016 09:38:56 +0200 Subject: [Freeipa-devel] documentation: Manually Configuring a Linux Client & host-add-managedby Message-ID: Hello list, question from users led me to reading about host-add-managedby. While doing so I found out procedure listed on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/#host-setup-proc and I wonder if it is correct or not. I think it needs update. - In step 3 "create a host entry for the client" I would omit --force option as this option should not be promoted at all. - More interestingly, step 4 "set the client host to be managed by the server" seems totally weird. Why managedby from client should be pointing to a server? I do not think it is necessary at all. Remove the step completely? - Steps 5 & 7: sssd.conf and krb5.conf should not be pointing to one IPA server but rather use server auto-discovery. - AFAIK step 11 "set up a host certificate for the host in IdM" is obsolete as we do not do this by default anymore. I would remove the step. Any opinions? As a side-note, help text for host-add-managedby is totally insufficient because it does not explain purpose of the command: > # ipa help host-add-managedby > Usage: ipa [global-options] host-add-managedby HOSTNAME [options] > > Add hosts that can manage this host. > Options: > --hosts=STR hosts to add Docs https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/#Delegating_Host_Management is a little bit more verbose but contains an invalid example. The delegation was done to client2 but keytab used in the example was for server... I would fix the example + add some explanation to the help command. With this I need help from someone because I'm not even sure what is the correct semantics. Should the 'manager' be able to retrieve keytab for host/ only? Or of any service running on that host? What about certificates? All this should be clarified somewhere in the help text. Thank you for your attention :-) -- Petr^2 Spacek From mkubik at redhat.com Wed Jul 27 09:54:16 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 27 Jul 2016 11:54:16 +0200 Subject: [Freeipa-devel] [PATCH 42-47][tests] RFE: Allow users to authenticate with alternative names In-Reply-To: <35385bd8-7bd3-255b-7b0d-e1d5efecd949@redhat.com> References: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> <35385bd8-7bd3-255b-7b0d-e1d5efecd949@redhat.com> Message-ID: <70cd2dfa-b457-74b8-8bcb-ce2a547e4cb9@redhat.com> >> >> > > Hi Milan, > > the tests seem to work as expected except > `test_enterprise_principal_UPN_overlap_without_additional_suffix` > which crashes on #6099. I have a few comments, however: This is a test that hits a known bug. I have added an expected fail marker for it. > > Patch 42: > > 1.) > +class KerberosAliasMixin: > > make sure the class inherits from 'object' so that it behaves like > new-style class in Python 2. > > Also, I think that 'check_for_tracker' method is slightly redundant. > If somebody would use the mixin directly, then he will still get > "NotImplementedError" exceptions and see that he probably did > something wrong. > > If you really really want to treat to prevent the instantiation of the > class, then use ABC module to turn it into proper abstract class. > > But in this case it should IMHO be enough that you explained the class > usage in the module docstring. Ok. Fixed the inheritance and removed the check for Tracker. The check for krbprincipalname attribute has been kept. > > 2.) > + def _make_add_alias_cmd(self): > + raise RuntimeError("The _make_add_alias_cmd method " > + "is not implemented.") > + > + def _make_remove_alias_cmd(self): > + raise RuntimeError("The _make_remove_alias_cmd method " > + "is not implemented." > > Abstract methods should raise "NotImplementedError" exception. > Fixed. > 3.) > is the 'options=None' kwarg in {add,remove}_principals methods > necessary? I didn't see it anywhere in the later commits so I guess > you can safely remove it. Better yet, you can just replace it with > '**options' since all it does is to pass options to the > `*-add/remove-principal` commands. > Fixed to **options. > 4.) > a nitpick but IIRC the mixin class should be listed before the actual > hierarchy base so that MRO works as expected. > > So instead > > +class UserTracker(Tracker, KerberosAliasMixin): > > It should say > +class UserTracker(KerberosAliasMixin, Tracker): Fixed in all three classes. > > PATCH 43: LGTM > > PATCH 44: > > Please do not create any more utility modules. Either put it to > existing 'ipatests/util.py' or better yet, rename the module to > something like 'mock_trust' since the scope of it is to provide mocked > trust entries. Moved the functions from test_range_plugin.py module to a new mock_trust module. The fix for the range plugin test introduced a new commit here. > > PATCH 45: > > It would be nice if you could add '-E' option in the same way to > indicate enterprise principal name resolution. Done. > > PATCH 46: LGTM > PATCH 47: > > 1.) > +from ipatests.test_xmlrpc.test_range_plugin import ( > + get_trust_dn, get_trusted_dom_dict, encode_mockldap_value) > > Since you already introduced a module grouping all trust-mocking > machinery in patch 44, you could extract these functions and put it > there to improve code reuse. Fixed. > > 2.) > I am not a big fan of duplicate code in 'trusted_domain' and > 'trusted_domain_with_suffix' fixtures. Use some module-level mapping > for common attributes and add more specific attributes per fixture. Fixed > > 3.) > I would like to expand the test cases for AD realm namespace overlap > checks. We should reject enterprise principals with suffixes > coinciding with realm names, NETBIOS names, and UPN suffixes and I > would like to test all three cases to get a full coverage. > Extended with explicit checks fot rhe AD realm and NETBIOS name by constructing the enterprise principal from corresponding LDAP attributes. The fixed and rebased version of the commits is in my repo [1]. [1]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test Regards -- Milan Kubik From mbabinsk at redhat.com Wed Jul 27 12:12:35 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 27 Jul 2016 14:12:35 +0200 Subject: [Freeipa-devel] [PATCH 0196] baseldap: Fix MidairCollision instantiation during entry modification In-Reply-To: <20160726152219.u67pdvfxg4mwkogc@redhat.com> References: <20160726152219.u67pdvfxg4mwkogc@redhat.com> Message-ID: <8b709a55-3ada-c7ba-ee1f-6d8622904d9c@redhat.com> On 07/26/2016 05:22 PM, Alexander Bokovoy wrote: > On Tue, 26 Jul 2016, Martin Babinsky wrote: >> Fix for https://fedorahosted.org/freeipa/ticket/6097 >> >> Since this issue was found during investigation of other ticket[1], >> you can test it by performing steps to reproduce #6041, but instead of >> internal error you should see the MidairCollision raised as public >> error with the right error message. >> >> [1] https://fedorahosted.org/freeipa/ticket/6041 > I have a preliminary patch for slapi-nis to fix 6041 (attached). > > As for this fix -- ACK. > Thanks. Pushed to master: dc62dd8c908b3c8a8c166006d2d4e71dde99883e >> >> -- >> Martin^3 Babinsky > >> From 8f0d6dab08f61fe2fd1ad64a63f7ab91fc5227d4 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Mon, 25 Jul 2016 14:05:08 +0200 >> Subject: [PATCH] baseldap: Fix MidairCollision instantiation during entry >> modification >> >> https://fedorahosted.org/freeipa/ticket/6097 >> --- >> ipaserver/plugins/baseldap.py | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/ipaserver/plugins/baseldap.py >> b/ipaserver/plugins/baseldap.py >> index >> 6107e43a6ee17d9b9a63d9dc109664d8b232069f..f7844e3e7c59c259b9c8367d135b2dbefc3f0016 >> 100644 >> --- a/ipaserver/plugins/baseldap.py >> +++ b/ipaserver/plugins/baseldap.py >> @@ -1466,7 +1466,7 @@ class LDAPUpdate(LDAPQuery, crud.Update): >> entry_attrs.dn, attrs_list) >> except errors.NotFound: >> raise errors.MidairCollision( >> - format=_('the entry was deleted while being modified') >> + message=_('the entry was deleted while being modified') >> ) >> >> self.obj.get_indirect_members(entry_attrs, attrs_list) >> @@ -2344,7 +2344,7 @@ class BaseLDAPModAttribute(LDAPQuery): >> entry_attrs.dn, attrs_list) >> except errors.NotFound: >> raise errors.MidairCollision( >> - format=_('the entry was deleted while being modified') >> + message=_('the entry was deleted while being modified') >> ) >> >> for callback in self.get_callbacks('post'): >> -- >> 2.7.4 >> > >> -- >> 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 > > -- Martin^3 Babinsky From ldoudova at redhat.com Wed Jul 27 13:00:15 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 27 Jul 2016 15:00:15 +0200 Subject: [Freeipa-devel] [PATCH] webui test: bunch of patches which fix webui patches In-Reply-To: <31a0668d-0f0e-062f-39b9-ac50fc623bf9@redhat.com> References: <91f807de-949c-bac2-8028-35e57a929081@redhat.com> <31a0668d-0f0e-062f-39b9-ac50fc623bf9@redhat.com> Message-ID: <7839f829-7e6d-a227-a441-e0a5df33734a@redhat.com> On 07/20/2016 04:43 PM, Pavel Vomacka wrote: > > > > On 07/11/2016 06:33 PM, Pavel Vomacka wrote: >> Hello, >> >> please review these patches. First four of them fixes patches and the >> last one fixes small bug in WebUI which causes that some tests fail. >> >> https://fedorahosted.org/freeipa/ticket/6050 >> >> https://fedorahosted.org/freeipa/ticket/6052 >> >> https://fedorahosted.org/freeipa/ticket/6053 >> >> https://fedorahosted.org/freeipa/ticket/6054 >> >> >> >> > 4 patches have incorrect information about user who makes the patch. > Sending new patches which correct it. > > -- > Pavel^3 Vomacka > > Hi, thanks for patches, ACK on all. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Jul 27 13:30:56 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 27 Jul 2016 15:30:56 +0200 Subject: [Freeipa-devel] [PATCH 0194] harden the check for trust namespace overlap in new principals In-Reply-To: References: <0919a23d-3c7b-8314-6b5e-0d9f7eff92c2@redhat.com> Message-ID: On 26/07/16 13:18, Martin Babinsky wrote: > On 07/21/2016 12:56 PM, Martin Babinsky wrote: >> '*-add-principal' would crash with error if the trusted domains did not >> have any UPN suffixes or NETBIOS name associated with them. This patch >> fixes that. >> >> Big thanks to Milan who found and reported the issue during writing >> tests for the feature. >> >> https://fedorahosted.org/freeipa/ticket/6099 >> >> >> > Bump for review. > Works for me, ACK. -- David Kupka From ldoudova at redhat.com Wed Jul 27 15:40:34 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 27 Jul 2016 17:40:34 +0200 Subject: [Freeipa-devel] [PATCH] webui test: bunch of patches which fix webui patches In-Reply-To: <7839f829-7e6d-a227-a441-e0a5df33734a@redhat.com> References: <91f807de-949c-bac2-8028-35e57a929081@redhat.com> <31a0668d-0f0e-062f-39b9-ac50fc623bf9@redhat.com> <7839f829-7e6d-a227-a441-e0a5df33734a@redhat.com> Message-ID: <888abc43-0606-4fb0-8dc7-a79d3c3e4eaf@redhat.com> On 07/27/2016 03:00 PM, Lenka Doudova wrote: > > > > On 07/20/2016 04:43 PM, Pavel Vomacka wrote: >> >> >> >> On 07/11/2016 06:33 PM, Pavel Vomacka wrote: >>> Hello, >>> >>> please review these patches. First four of them fixes patches and >>> the last one fixes small bug in WebUI which causes that some tests >>> fail. >>> >>> https://fedorahosted.org/freeipa/ticket/6050 >>> >>> https://fedorahosted.org/freeipa/ticket/6052 >>> >>> https://fedorahosted.org/freeipa/ticket/6053 >>> >>> https://fedorahosted.org/freeipa/ticket/6054 >>> >>> >>> >>> >> 4 patches have incorrect information about user who makes the patch. >> Sending new patches which correct it. >> >> -- >> Pavel^3 Vomacka >> >> > Hi, > thanks for patches, ACK on all. > > Lenka > > When pushing, please don't forget to push patch 0073 from the original email. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Wed Jul 27 16:26:43 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 27 Jul 2016 18:26:43 +0200 Subject: [Freeipa-devel] [PATCH 0195] Create indexes for krbCanonicalName attribute In-Reply-To: <628e47fc-7790-a908-d759-28db52a4ee35@redhat.com> References: <283402fb-6f03-1e0a-8ed7-cdd9db8d7af0@redhat.com> <5792137A.3050407@redhat.com> <628e47fc-7790-a908-d759-28db52a4ee35@redhat.com> Message-ID: <5798E0C3.6060906@redhat.com> On 07/22/2016 03:43 PM, Martin Babinsky wrote: > On 07/22/2016 02:37 PM, thierry bordaz wrote: >> Hi Martin, >> >> The patch looks good. Just a question krbPrincipalName is >> caseExactIA5Match but is also indexed caseIgnoreIA5Match. >> Do you think it would be need for krbCanonicalName as well ? >> >> thanks >> thierry >> >> >> On 07/22/2016 01:27 PM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/6100 >>> >>> >>> >> > krbPrincipalName is indexed with caseIgnoreIA5Match because it should > be searched for case-insensitively when canonicalization is requested. > > krbCanonicalName is always searched for case-sensitively to retrieve > correctly-cased canonical principal name. > Hi martin, The patch is working fine and user-add on top of 50K users gives a response time of 3.5s. the index is correctly updated. ACK thanks thierry From blipton at redhat.com Wed Jul 27 17:06:09 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 27 Jul 2016 13:06:09 -0400 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation Message-ID: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> Hi all, I think the automatic CSR generation feature (https://fedorahosted.org/freeipa/ticket/4899, http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) is stable enough to review now. The following are summaries of the attached patches: 0004: LDAP schema changes for the new feature 0005: Basic API for new objects and CSR generation 0006: Update install automation to create some default mapping rules 0007: Implement the lookups and text processing that generates the CSR config 0008 and 0009: Implement some actual transformation rules so that the feature is usable 0010: Add a new cert profile for user certs, with mappings 0011: Implement import/export of cert profiles with mappings 0012: Tests for profile import/export Generally speaking, later patches depend on earlier ones, but I don't anticipate any problems from committing earlier patches without later ones. If you prefer, you can also comment on the pull request version: https://github.com/LiptonB/freeipa/pull/4. Note that I may force push on this branch. Allocation of OIDs for schema change also needs review: https://code.engineering.redhat.com/gerrit/#/c/80061/ Known issues: - When the requested principal does not have some of the requested data, produces funny-looking configs with extra commas, empty sections, etc. They are still accepted by my copies of openssl and certutil, but they look ugly. - The new objects don't have any ACIs, so for the moment only admin can run the new commands. - Does not yet have support for prompting user for field values, so currently all data must come from the database. - All processing happens on the server side. As discussed in a previous thread, it would be desirable to break this out into a library so it could be used client-side. Very excited to hear your thoughts! Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0004-Add-schema-to-support-automatic-CSR-generation.patch Type: text/x-patch Size: 6055 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0005-Add-plugin-for-CSR-generation.patch Type: text/x-patch Size: 20581 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0006-Add-generation-rules-to-the-default-cert-profile.patch Type: text/x-patch Size: 8002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0007-Add-code-to-support-generating-configs-using-mapping.patch Type: text/x-patch Size: 10906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0008-Add-jinja2-templates-and-macros-to-support-generatin.patch Type: text/x-patch Size: 7032 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0009-Add-jinja2-transformation-rules-for-caIPAserviceCert.patch Type: text/x-patch Size: 6222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0010-Add-a-new-cert-profile-for-users.patch Type: text/x-patch Size: 9460 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0011-Add-ability-to-import-export-mappings-with-profile.patch Type: text/x-patch Size: 15515 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0012-Add-tests-for-mapping-rules-import-export.patch Type: text/x-patch Size: 18905 bytes Desc: not available URL: From mbasti at redhat.com Wed Jul 27 17:24:24 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 27 Jul 2016 19:24:24 +0200 Subject: [Freeipa-devel] [PATCH] webui test: bunch of patches which fix webui patches In-Reply-To: <888abc43-0606-4fb0-8dc7-a79d3c3e4eaf@redhat.com> References: <91f807de-949c-bac2-8028-35e57a929081@redhat.com> <31a0668d-0f0e-062f-39b9-ac50fc623bf9@redhat.com> <7839f829-7e6d-a227-a441-e0a5df33734a@redhat.com> <888abc43-0606-4fb0-8dc7-a79d3c3e4eaf@redhat.com> Message-ID: On 27.07.2016 17:40, Lenka Doudova wrote: > > > > On 07/27/2016 03:00 PM, Lenka Doudova wrote: >> >> >> >> On 07/20/2016 04:43 PM, Pavel Vomacka wrote: >>> >>> >>> >>> On 07/11/2016 06:33 PM, Pavel Vomacka wrote: >>>> Hello, >>>> >>>> please review these patches. First four of them fixes patches and >>>> the last one fixes small bug in WebUI which causes that some tests >>>> fail. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6050 >>>> >>>> https://fedorahosted.org/freeipa/ticket/6052 >>>> >>>> https://fedorahosted.org/freeipa/ticket/6053 >>>> >>>> https://fedorahosted.org/freeipa/ticket/6054 >>>> >>>> >>>> >>>> >>> 4 patches have incorrect information about user who makes the patch. >>> Sending new patches which correct it. >>> >>> -- >>> Pavel^3 Vomacka >>> >>> >> Hi, >> thanks for patches, ACK on all. >> >> Lenka >> >> > When pushing, please don't forget to push patch 0073 from the original > email. > Lenka > > master: * 3ba3080dfe8a69d8f9e4b2cafc309853e74da9b3 Close host adder dialog before showing 4304 dialog * 8c07568c0be0a2d6a54a39f868bc90b64c507f9f Remove navigation using breadcrumb menus * 9f94a5f7badcec412d695914f6405f74e5b353d7 Fix test_navigation tests * 73ef15ccb49671f0fd401018e68675e16f674bd3 Fix test which checks removing of user * 41ace68e0420fc731c0005ee01a839bc6a7fd995 Set default delete action name to 'delete' -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Jul 27 17:27:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 27 Jul 2016 19:27:47 +0200 Subject: [Freeipa-devel] [PATCH 0195] Create indexes for krbCanonicalName attribute In-Reply-To: <5798E0C3.6060906@redhat.com> References: <283402fb-6f03-1e0a-8ed7-cdd9db8d7af0@redhat.com> <5792137A.3050407@redhat.com> <628e47fc-7790-a908-d759-28db52a4ee35@redhat.com> <5798E0C3.6060906@redhat.com> Message-ID: On 27.07.2016 18:26, thierry bordaz wrote: > > > On 07/22/2016 03:43 PM, Martin Babinsky wrote: >> On 07/22/2016 02:37 PM, thierry bordaz wrote: >>> Hi Martin, >>> >>> The patch looks good. Just a question krbPrincipalName is >>> caseExactIA5Match but is also indexed caseIgnoreIA5Match. >>> Do you think it would be need for krbCanonicalName as well ? >>> >>> thanks >>> thierry >>> >>> >>> On 07/22/2016 01:27 PM, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/6100 >>>> >>>> >>>> >>> >> krbPrincipalName is indexed with caseIgnoreIA5Match because it should >> be searched for case-insensitively when canonicalization is requested. >> >> krbCanonicalName is always searched for case-sensitively to retrieve >> correctly-cased canonical principal name. >> > > Hi martin, > > The patch is working fine and user-add on top of 50K users gives a > response time of 3.5s. > the index is correctly updated. > > ACK > > thanks > thierry > Pushed to master: 807702c986976ade8005ec344fcd827f70b2ba2f From mbasti at redhat.com Wed Jul 27 18:03:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 27 Jul 2016 20:03:15 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Add client install option to set ipa_backup_server In-Reply-To: References: Message-ID: On 26.07.2016 17:01, Ariel Barria wrote: > Hello everyone. > > I send patch for review. > > Regards, > > Hello, thank you for the patch, but I have a few comments: 1) can you please use option --backup-server instead of --ipa-backup-server to be consistent with --server (as we don't have option --ipa-server) 2) values passed by --server option are validated if it is IPA server or not, this should happen for backup server(s) too. But looking to current ipa-client-install, it may be challenging to achieve this goal. I'm afraid that you might rather wait until we refactor the client code (next release hopefully). But in case you are brave enough, I can provide advises, but it will be hell. 3) There is a question, if the backup server should be used also for krb5.conf or other configs where multiple servers can be specified. Probably not. But at least this should be mentioned in manpage that this option is used only for SSSD (probably there should be check to prevent using --backup-server together with --no-sssd option) 4) 'man ipa-client-install' should be updated with the new option 5) ipa_backup_server allows to specify multiple servers, so the new option should be multivalued (and then joined to coma separated list into SSSD config) regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From blipton at redhat.com Wed Jul 27 18:42:46 2016 From: blipton at redhat.com (Ben Lipton) Date: Wed, 27 Jul 2016 14:42:46 -0400 Subject: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2 In-Reply-To: <60f90568-e517-8516-7c93-491d9bd20758@redhat.com> References: <1469010462.21393.47.camel@redhat.com> <1469025427.21393.51.camel@redhat.com> <514956a4-14f7-5816-23cd-d1ce1e3d28fa@redhat.com> <1469031696.21393.55.camel@redhat.com> <60f90568-e517-8516-7c93-491d9bd20758@redhat.com> Message-ID: <1fc2c544-9431-24e4-331d-5f73bf1aaa43@redhat.com> On 07/21/2016 11:43 AM, Petr Spacek wrote: > On 20.7.2016 19:25, Ben Lipton wrote: >> On 07/20/2016 12:21 PM, Simo Sorce wrote: >>> On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote: >>>> On 07/20/2016 10:37 AM, Simo Sorce wrote: >>>>> On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote: >>>>>> On 07/20/2016 06:27 AM, Simo Sorce wrote: >>>>>>> On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have updated the design page >>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_ >>>>>>>> Gene >>>>>>>> rati >>>>>>>> on/Mapping_Rules >>>>>>>> with my plan for implementing user-configurable rules for >>>>>>>> mapping >>>>>>>> IPA >>>>>>>> data into certificate requests. In brief: we will use Jinja2 >>>>>>>> for >>>>>>>> templating. Data rules (which map individual data items) and >>>>>>>> syntax >>>>>>>> rules (which group them into certificate fields) will both be >>>>>>>> snippets >>>>>>>> of Jinja2 markup. The formatting process will be as follows: > I've finally found some time to read the sub-page Mapping_Rules and for me it > is kind of hard to follow. It would not be understandable without this e-mail > and the blog posts (BTW the blog articles are among best I have seen!). > > Most importantly, the explanations in brackets above ["Data rules (which map > individual data items) and (which group them into certificate fields)"] are > missing in the wiki page itself :-) > > Could you fold relevant parts of the e-mails and blogs back into the wiki page > so it is self-contained? Very good point. I may have been assuming knowledge of the whole design when reading this document, which doesn't make sense. I did some cleanup, plus added some more detail about how things work in the implementation I just sent out for review. I hope that will clarify things somewhat. > Besides this nit, > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation > sounds reasonable. I like how it prevents bad data from template-injection. That's what I like about it, too. It does turn out to make things a little tricky when it comes to writing rules that won't render if the data they depend on is unavailable. (Because instead of rendering individual rules which we can drop if they're missing data, we build one big template that has to handle missing data correctly on its own.) I think it's probably still worth it, though. I added this to the "Alternatives considered" section of the above document. > Regarding > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A > , I prefer Option A with separate object for each helper. It is somehow > cleaner and it might be useful to use distinct object classes for each helper etc. +1, I think option B was a bit of premature optimization. > > > API for ipa cert-get-requestdata sounds good. > API for ipa cert-request makes sense to me as well. > > In any case I would recommend you to consult API design with Jan Cholasta > - he is our API custodian. > > > BTW I very much like "Alternatives considered" sections, we should have this > for each design! > > Good work, I really like the dutiful analysis! > > Thanks for the feedback, and the kind words! Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Jul 28 01:31:19 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 28 Jul 2016 11:31:19 +1000 Subject: [Freeipa-devel] [PATCH] 0096 caacl: fix regression in rule instantiation Message-ID: <20160728013118.GA10771@dhcp-40-8.bne.redhat.com> The attached patch fixes a kerberos.Principal-related regression. Thanks, Fraser -------------- next part -------------- From c3d4bee34f4a1aa6afafee07851e8b5557860331 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 28 Jul 2016 10:55:45 +1000 Subject: [PATCH] caacl: fix regression in rule instantiation The Principal refactor causes service collections ('memberservice_service' attribute) to return Principal objects where previously it returned strings, but the HBAC machinery used for CA ACL enforcement only handles strings. Update the code to stringify service Principal objects when adding them to HBAC rules. Part of: https://fedorahosted.org/freeipa/ticket/3864 --- ipaserver/plugins/caacl.py | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py index d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a..a7817c4cf64f070c74557f52e9f26c9013a4963c 100644 --- a/ipaserver/plugins/caacl.py +++ b/ipaserver/plugins/caacl.py @@ -132,16 +132,21 @@ def _acl_make_rule(principal_type, obj): rule.services.names = obj.get(attr, []) # add principals and principal's groups - m = {'user': 'group', 'host': 'hostgroup', 'service': None} category_attr = '{}category'.format(principal_type) if category_attr in obj and obj[category_attr][0].lower() == 'all': rule.users.category = {pyhbac.HBAC_CATEGORY_ALL} else: - principal_attr = 'member{}_{}'.format(principal_type, principal_type) - rule.users.names = obj.get(principal_attr, []) - if m[principal_type] is not None: - group_attr = 'member{}_{}'.format(principal_type, m[principal_type]) - rule.users.groups = obj.get(group_attr, []) + if principal_type == 'user': + rule.users.names = obj.get('memberuser_user', []) + rule.users.groups = obj.get('memberuser_group', []) + elif principal_type == 'host': + rule.users.names = obj.get('memberhost_host', []) + rule.users.groups = obj.get('memberhost_hostgroup', []) + elif principal_type == 'service': + rule.users.names = [ + unicode(principal) + for principal in obj.get('memberservice_service', []) + ] return rule -- 2.5.5 From ldoudova at redhat.com Thu Jul 28 06:16:52 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 28 Jul 2016 08:16:52 +0200 Subject: [Freeipa-devel] [PATCH] 0078-82: webui tests: tests for new certificate widget In-Reply-To: <3e447bbe-fade-c5e5-2415-15ed7ae0b2ea@redhat.com> References: <3e447bbe-fade-c5e5-2415-15ed7ae0b2ea@redhat.com> Message-ID: <7298654a-0ea9-8f42-dc24-f48f0dabeeb4@redhat.com> On 07/20/2016 04:51 PM, Pavel Vomacka wrote: > Please review attached patches, which add tests for new certificate > widget in WebUI. > > https://fedorahosted.org/freeipa/ticket/6064 > > > Hi, thanks for patches. Functionally ok, but you have lots of PEP8 errors in patches 78, 80, 81 and 82 -> NACK. Also in patch 82, method test_arbitrary_certificate, comment says user needs to have "arbitrary_cert" configured, but the property in config file is correctly "arbitrary_cert_path", so it's a bit misleading. Patch 79 is OK, ACK. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Jul 28 07:35:16 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 28 Jul 2016 09:35:16 +0200 Subject: [Freeipa-devel] [PATCH 0194] harden the check for trust namespace overlap in new principals In-Reply-To: References: <0919a23d-3c7b-8314-6b5e-0d9f7eff92c2@redhat.com> Message-ID: <9a207ca6-0e49-1975-6d59-35f7e108df9c@redhat.com> On 07/27/2016 03:30 PM, David Kupka wrote: > On 26/07/16 13:18, Martin Babinsky wrote: >> On 07/21/2016 12:56 PM, Martin Babinsky wrote: >>> '*-add-principal' would crash with error if the trusted domains did not >>> have any UPN suffixes or NETBIOS name associated with them. This patch >>> fixes that. >>> >>> Big thanks to Milan who found and reported the issue during writing >>> tests for the feature. >>> >>> https://fedorahosted.org/freeipa/ticket/6099 >>> >>> >>> >> Bump for review. >> > > Works for me, ACK. > Pushed to master: da2305ddb99ab982c757ab723acc95cda3d2f025 -- Martin^3 Babinsky From mbabinsk at redhat.com Thu Jul 28 07:56:30 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 28 Jul 2016 09:56:30 +0200 Subject: [Freeipa-devel] [PATCH] 0096 caacl: fix regression in rule instantiation In-Reply-To: <20160728013118.GA10771@dhcp-40-8.bne.redhat.com> References: <20160728013118.GA10771@dhcp-40-8.bne.redhat.com> Message-ID: <3131b303-a873-1575-9488-f764c7dd96be@redhat.com> On 07/28/2016 03:31 AM, Fraser Tweedale wrote: > The attached patch fixes a kerberos.Principal-related regression. > > Thanks, > Fraser > Hi Fraser, The ticket you linked in the commit message points to a closed milestone. You have to open a new ticket which needs to be triaged. Sorry, those are the processes. -- Martin^3 Babinsky From jcholast at redhat.com Thu Jul 28 08:11:24 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Jul 2016 10:11:24 +0200 Subject: [Freeipa-devel] [PATCH 680] compat: fix ping call Message-ID: Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-680-compat-fix-ping-call.patch Type: text/x-patch Size: 1067 bytes Desc: not available URL: From flo at redhat.com Thu Jul 28 08:16:14 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 28 Jul 2016 10:16:14 +0200 Subject: [Freeipa-devel] [PATCHES 678-679] client: fix hiding of commands which lack server support In-Reply-To: <571ec045-f4b9-8755-42a7-9abfee6bfd9d@redhat.com> References: <571ec045-f4b9-8755-42a7-9abfee6bfd9d@redhat.com> Message-ID: On 07/25/2016 02:47 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza > > > Hi, Tested with freeipa server 4.1.4-4.fc22 and patched client, correctly hides the commands. Tested with server 4.4 + patched client, correctly shows the commands. Ack, Flo. From mbasti at redhat.com Thu Jul 28 08:17:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Jul 2016 10:17:02 +0200 Subject: [Freeipa-devel] [PATCH] 0083: webui: remove full name column from user to user group adder dialog In-Reply-To: <20160725091747.3x3cijajnxb6yz4o@redhat.com> References: <505f8376-d7ec-1652-285d-87a5afeaeeb3@redhat.com> <20160725091747.3x3cijajnxb6yz4o@redhat.com> Message-ID: <7c35c2ff-2bfc-516b-1228-497875be55d3@redhat.com> On 25.07.2016 11:17, Alexander Bokovoy wrote: > On Thu, 21 Jul 2016, Pavel Vomacka wrote: >> Remove full name from adding user to user group dialog >> >> As the 'cn' is not in the response of user-show there is empty column >> in adder dialog. >> Therefore the column was removed. >> >> https://fedorahosted.org/freeipa/ticket/6055 > ACK. > Pushed to master: ffea8218c7d6db3abe4667a4d05817249a0e83bd From mbasti at redhat.com Thu Jul 28 08:20:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Jul 2016 10:20:11 +0200 Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember tests in 4.3 In-Reply-To: <4237887a-917f-4fb2-0a7c-1eeb79ee6996@redhat.com> References: <4237887a-917f-4fb2-0a7c-1eeb79ee6996@redhat.com> Message-ID: On 13.07.2016 15:21, Lenka Doudova wrote: > Hi, > > providing patch to fix two failing automember tests in 4.3 branch. The > reason of the failure was the output normalization (specifically > manager attribute for user). > > The patch is intended for ipa-4-3 branch only. > > > Lenka > > > Bump for review -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Jul 28 08:25:23 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Jul 2016 10:25:23 +0200 Subject: [Freeipa-devel] [PATCHES 678-679] client: fix hiding of commands which lack server support In-Reply-To: References: <571ec045-f4b9-8755-42a7-9abfee6bfd9d@redhat.com> Message-ID: <78389810-1a9f-219b-8413-7f04add9e847@redhat.com> On 28.7.2016 10:16, Florence Blanc-Renaud wrote: > On 07/25/2016 02:47 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Honza >> >> >> > Hi, > Tested with freeipa server 4.1.4-4.fc22 and patched client, correctly > hides the commands. > Tested with server 4.4 + patched client, correctly shows the commands. > > Ack, > Flo. Thanks. Pushed to master: f563d982f2331456feadb5f961b7883d28348211 -- Jan Cholasta From mbasti at redhat.com Thu Jul 28 08:27:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Jul 2016 10:27:25 +0200 Subject: [Freeipa-devel] [PATCH 0017] Added fix for correct IPA backup file name In-Reply-To: <577E53CA.5040205@redhat.com> References: <28e5999e-9dc8-f59d-28a6-1db882199880@redhat.com> <0d70dfbb-db6a-5df4-858b-1181404ef147@redhat.com> <577E53CA.5040205@redhat.com> Message-ID: On 07.07.2016 15:06, Rob Crittenden wrote: > Abhijeet Kasurde wrote: >> Hi Florence, >> >> >> On 07/07/2016 03:30 PM, Florence Blanc-Renaud wrote: >>> On 07/07/2016 10:58 AM, Abhijeet Kasurde wrote: >>>> Hi All, >>>> >>>> Please review the patch. >>>> >>>> Fixes : https://fedorahosted.org/freeipa/ticket/6031 >>>> >>>> -- >>>> Thanks, >>>> Abhijeet Kasurde >>>> >>>> IRC: akasurde >>>> http://akasurde.github.io >>>> >>>> >>>> >>> Hi Abhijeet, >>> >>> thanks for your patch. I have a comment though: if the filename is >>> modified in ipa-backup, then it should also be changed in ipa-restore, >>> to make sure that the backup can be restored. It may be a good idea to >>> define the file name as a constant and use this constant everywhere. >>> >> I will change ipa-restore as well. >>> As far as I can see, the tool ipa-restore checks that the backup >>> version and ipa-restore version are consistent, meaning that both >>> tools should use the same filename and that it will not break backward >>> compatibility, but other team members can confirm. >>> >> I will wait for other team members to comment on this. > > ipa-restore will probably need to look for both the ipa-full.tar and > ipa-full.tar.gz because the version check is optional. > > rob > I'm curious if this even worth to fix this. We are saying that after each upgrade users need to recreate backups (because with high probability old backup will stop working with new packages) but I'm sure that users are not doing that, so we have to check both in restore. Martin^2 From pspacek at redhat.com Thu Jul 28 08:30:48 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Jul 2016 10:30:48 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Add client install option to set ipa_backup_server In-Reply-To: References: Message-ID: <532242ea-0ebc-575b-eefd-974d84e4a474@redhat.com> On 27.7.2016 20:03, Martin Basti wrote: > > > On 26.07.2016 17:01, Ariel Barria wrote: >> Hello everyone. >> >> I send patch for review. >> >> Regards, >> >> > Hello, thank you for the patch, but I have a few comments: > > 1) > can you please use option --backup-server instead of --ipa-backup-server to be > consistent with --server (as we don't have option --ipa-server) > > 2) > values passed by --server option are validated if it is IPA server or not, > this should happen for backup server(s) too. > > But looking to current ipa-client-install, it may be challenging to achieve > this goal. I'm afraid that you might rather wait until we refactor the client > code (next release hopefully). But in case you are brave enough, I can provide > advises, but it will be hell. > > 3) > There is a question, if the backup server should be used also for krb5.conf or > other configs where multiple servers can be specified. Probably not. But at > least this should be mentioned in manpage that this option is used only for > SSSD (probably there should be check to prevent using --backup-server together > with --no-sssd option) I would use backup_servers even in krb5.conf. Quick testing indicates that krb5 lib respects order of KDCs in krb5.conf so simply list backup servers at the end of the list. That would remove mutual exclusivity of --no-sssd and --backup-server options. Petr^2 Spacek > > 4) > 'man ipa-client-install' should be updated with the new option > > 5) > ipa_backup_server allows to specify multiple servers, so the new option should > be multivalued (and then joined to coma separated list into SSSD config) > > regards, > Martin From mbabinsk at redhat.com Thu Jul 28 08:56:40 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 28 Jul 2016 10:56:40 +0200 Subject: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users Message-ID: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> Fixes https://fedorahosted.org/freeipa/ticket/6101 I have also noticed that the principal aliases are not preserved during migration from FreeIPA 4.4. That, however, requires more powerful runes to transform the realm of all values and warrants a separate ticket if we even want to support migration of user aliases. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0197-re-set-canonical-principal-name-on-migrated-users.patch Type: text/x-patch Size: 3569 bytes Desc: not available URL: From mbasti at redhat.com Thu Jul 28 08:57:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Jul 2016 10:57:07 +0200 Subject: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules In-Reply-To: <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> References: <91e234f8-554f-7efd-a399-d51db521a2fe@redhat.com> <9e9d6098-cbe2-3455-47c0-a21d1aea8ae5@redhat.com> <28420a22-04ad-b04c-4c25-bd9a71f9051f@redhat.com> <9171d38e-da4f-0693-1f53-767dc4dfe219@redhat.com> <5763ABED.9010102@redhat.com> <5763D892.20605@redhat.com> <3b048d9c-03c8-1675-0a3f-20e4b8e293c2@redhat.com> Message-ID: <92bbb69d-cba7-a820-8254-00b684cdbada@redhat.com> On 17.06.2016 13:56, Stanislav Laznicka wrote: > On 06/17/2016 01:01 PM, Petr Vobornik wrote: >> On 17.6.2016 12:12, Stanislav Laznicka wrote: >>> On 06/17/2016 09:51 AM, Petr Vobornik wrote: >>>> On 17.6.2016 09:24, Stanislav Laznicka wrote: >>>>> On 06/17/2016 08:48 AM, Petr Spacek wrote: >>>>>> On 17.6.2016 08:43, Stanislav Laznicka wrote: >>>>>>> On 06/17/2016 07:45 AM, Petr Spacek wrote: >>>>>>>> On 16.6.2016 17:33, Stanislav Laznicka wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> This patch removes most sys.exits() from installer modules and >>>>>>>>> scripts and >>>>>>>>> replaces them with ScriptError. I only left sys.exits at places >>>>>>>>> where the user >>>>>>>>> decides yes/no on continuation of the script. >>>>>>>> I wonder if yes/no should be replaced with KeyboardInterrupt or >>>>>>>> some >>>>>>>> other >>>>>>>> exception, too... >>>>>>>> >>>>>>> I'm not sure, it seems more clear to just really exit if the user >>>>>>> desires it >>>>>>> and it's what we say we'll do (with possible cleanup >>>>>>> beforehand). Do >>>>>>> you think >>>>>>> we could benefit somehow by raising an exception here? >>>>>> I'm just thinking out loud. >>>>>> >>>>>> It seemed to me that it is easier to share cleanup on one except >>>>>> block >>>>>> instead >>>>>> of having if (interrupt): cleanup; if (interrupt2): same_cleanup; >>>>>> >>>>>> etc. >>>>>> >>>>>> Again, just wondering out loud. >>>>>> >>>>> If the cleanup is the same, or similar it might be more beneficial to >>>>> have it in a function where you could pass what was set up already >>>>> and >>>>> therefore needs cleanup. But that's just an opinion coming from >>>>> thinking >>>>> out loud as well. I went through the code to see if there's much >>>>> cleanup >>>>> after these user actions and it seems that usually there's nothing >>>>> much >>>>> if anything. However, thinking in advance may save us much trouble in >>>>> the future, of course. >>>>> >>>> Btw the original scope of the ticket is to replace sys.exit calls ONLY >>>> in installer modules. Please don't waste time with debugging other use >>>> cases before 4.4 is out. >>>> >>> I might have gotten carried away a bit. Would you suggest keeping the >>> sys.exits replaced only in ipaserver/install/server/replicainstall.py, >>> ipaserver/install/server/install.py modules which are the installer >>> modules managed by AdminTool? I considered the modules in >>> ipaserver/install/ to also be installer modules as they are heavily >>> used >>> during installation and the sys.exits there mainly occur in functions >>> called from install()/install_check() methods. The *-install scripts >>> were perhaps really obviously over the scope. >> Yes, modules: >> ipaserver/install/bindinstance.py | 2 +- >> ipaserver/install/ca.py | 19 +++--- >> ipaserver/install/cainstance.py | 5 +- >> ipaserver/install/dns.py | 5 +- >> ipaserver/install/dsinstance.py | 3 +- >> ipaserver/install/installutils.py | 16 +++--- >> ipaserver/install/ipa_ldap_updater.py | 2 +- >> ipaserver/install/krainstance.py | 3 +- >> ipaserver/install/replication.py | 10 ++-- >> ipaserver/install/server/install.py | 64 +++++++++++---------- >> ipaserver/install/server/replicainstall.py | 92 >> >> not modules: >> install/tools/ipa-adtrust-install | 17 +++--- >> install/tools/ipa-ca-install | 23 ++++---- >> install/tools/ipa-compat-manage | 11 ++-- >> install/tools/ipa-dns-install | 3 +- >> >>> I'll keep the sys.exit replaces that won't make it here on the side, we >>> may want to do them later. >> I'm a bit worried that the patch might change some behavior. Maybe I'm >> wrong. >> > Attached is the patch with correct modules with sys.exits replaced. > > I double-checked the changes and I believe the behavior shouldn't > really change. > > > Hello, suprisingly, patch needs rebase :) 1) Is the script error the right Exception? 2) Can you use rather raise Exception(), instead of raise Exception 3) I really hate to print errors to STDOUT from modules and then just call exit(1) (duplicated evil), could you replace print('xxx') with raise AnException('xxx') Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Jul 28 10:51:28 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 28 Jul 2016 12:51:28 +0200 Subject: [Freeipa-devel] [PATCH 42-47][tests] RFE: Allow users to authenticate with alternative names In-Reply-To: <70cd2dfa-b457-74b8-8bcb-ce2a547e4cb9@redhat.com> References: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> <35385bd8-7bd3-255b-7b0d-e1d5efecd949@redhat.com> <70cd2dfa-b457-74b8-8bcb-ce2a547e4cb9@redhat.com> Message-ID: <1005f935-f761-1754-9d84-0e4fca33a7a6@redhat.com> On 07/27/2016 11:54 AM, Milan Kub?k wrote: > >>> >>> >> >> Hi Milan, >> >> the tests seem to work as expected except >> `test_enterprise_principal_UPN_overlap_without_additional_suffix` >> which crashes on #6099. I have a few comments, however: > This is a test that hits a known bug. I have added an expected fail > marker for it. >> >> Patch 42: >> >> 1.) >> +class KerberosAliasMixin: >> >> make sure the class inherits from 'object' so that it behaves like >> new-style class in Python 2. >> >> Also, I think that 'check_for_tracker' method is slightly redundant. >> If somebody would use the mixin directly, then he will still get >> "NotImplementedError" exceptions and see that he probably did >> something wrong. >> >> If you really really want to treat to prevent the instantiation of the >> class, then use ABC module to turn it into proper abstract class. >> >> But in this case it should IMHO be enough that you explained the class >> usage in the module docstring. > Ok. Fixed the inheritance and removed the check for Tracker. The check > for krbprincipalname attribute has been kept. >> >> 2.) >> + def _make_add_alias_cmd(self): >> + raise RuntimeError("The _make_add_alias_cmd method " >> + "is not implemented.") >> + >> + def _make_remove_alias_cmd(self): >> + raise RuntimeError("The _make_remove_alias_cmd method " >> + "is not implemented." >> >> Abstract methods should raise "NotImplementedError" exception. >> > Fixed. >> 3.) >> is the 'options=None' kwarg in {add,remove}_principals methods >> necessary? I didn't see it anywhere in the later commits so I guess >> you can safely remove it. Better yet, you can just replace it with >> '**options' since all it does is to pass options to the >> `*-add/remove-principal` commands. >> > Fixed to **options. >> 4.) >> a nitpick but IIRC the mixin class should be listed before the actual >> hierarchy base so that MRO works as expected. >> >> So instead >> >> +class UserTracker(Tracker, KerberosAliasMixin): >> >> It should say >> +class UserTracker(KerberosAliasMixin, Tracker): > Fixed in all three classes. >> >> PATCH 43: LGTM >> >> PATCH 44: >> >> Please do not create any more utility modules. Either put it to >> existing 'ipatests/util.py' or better yet, rename the module to >> something like 'mock_trust' since the scope of it is to provide mocked >> trust entries. > Moved the functions from test_range_plugin.py module to a new mock_trust > module. The fix for the range plugin test introduced a new commit here. >> >> PATCH 45: >> >> It would be nice if you could add '-E' option in the same way to >> indicate enterprise principal name resolution. > Done. >> >> PATCH 46: LGTM >> PATCH 47: >> >> 1.) >> +from ipatests.test_xmlrpc.test_range_plugin import ( >> + get_trust_dn, get_trusted_dom_dict, encode_mockldap_value) >> >> Since you already introduced a module grouping all trust-mocking >> machinery in patch 44, you could extract these functions and put it >> there to improve code reuse. > Fixed. >> >> 2.) >> I am not a big fan of duplicate code in 'trusted_domain' and >> 'trusted_domain_with_suffix' fixtures. Use some module-level mapping >> for common attributes and add more specific attributes per fixture. > Fixed >> >> 3.) >> I would like to expand the test cases for AD realm namespace overlap >> checks. We should reject enterprise principals with suffixes >> coinciding with realm names, NETBIOS names, and UPN suffixes and I >> would like to test all three cases to get a full coverage. >> > Extended with explicit checks fot rhe AD realm and NETBIOS name by > constructing the enterprise principal from corresponding LDAP attributes. > > The fixed and rebased version of the commits is in my repo [1]. > > [1]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test > > Regards > Tests works and code is ok, however you will need to create a separate ticket to your patches, since it is not allowed to add fixes to tickets in closed milestones. Sorry that I didn't notice it earlier. cond-ACK if you create ticket and remove the xfail from `test_enterprise_principal_overlap_with_AD_realm` test case as the fix for #6099 was pushed to master. -- Martin^3 Babinsky From mbasti at redhat.com Thu Jul 28 11:01:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Jul 2016 13:01:01 +0200 Subject: [Freeipa-devel] [PATCHES] Coverity fixes In-Reply-To: <1469440019.18067.66.camel@redhat.com> References: <1469440019.18067.66.camel@redhat.com> Message-ID: <6dcfcd32-05e3-d36c-484a-bb074373af4c@redhat.com> On 25.07.2016 11:46, Simo Sorce wrote: > The attached patches fix some minor issues found by coverity, and pull > in other fixes released by the asn1c project. > > Simo. > > > I cannot build RPMS with this patch, is there any missing build dependency? /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 -lk5crypto -lcom_err -llber -lldap -lsasl2 -lpopt -lini_config -lbasicobjects -lref_array -lcollection -lini_config -lini_config libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 -Wall -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers -Wl,-z -Wl,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab ipa-getkeytab.o ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a -lkrb5 -lk5crypto -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects -lref_array -lcollection -lini_config ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_decode_uper': /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:897: undefined reference to `uper_open_type_get' ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function `CHOICE_encode_uper': /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:982: undefined reference to `uper_open_type_put' ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function `SEQUENCE_handle_extensions': /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285: undefined reference to `uper_open_type_put' ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function `SEQUENCE_decode_uper': /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187: undefined reference to `uper_open_type_get' /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203: undefined reference to `uper_open_type_skip' collect2: error: ld returned 1 exit status Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Thu Jul 28 11:04:31 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 28 Jul 2016 13:04:31 +0200 Subject: [Freeipa-devel] [PATCH 0018] Minor fix in ipa-replica-manage MAN page In-Reply-To: <23a7f7cd-8344-6ad1-9591-ea60be6f8ee4@redhat.com> References: <23a7f7cd-8344-6ad1-9591-ea60be6f8ee4@redhat.com> Message-ID: <0832a15c-ac3f-272c-2a19-921f1ef080e7@redhat.com> On 07/27/2016 05:47 AM, Abhijeet Kasurde wrote: > Ping. > > > On 07/13/2016 09:24 AM, Abhijeet Kasurde wrote: >> >> Hi All, >> >> Please review patch. >> >> Fixes: https://fedorahosted.org/freeipa/ticket/6058 >> -- >> Thanks, >> Abhijeet Kasurde >> >> IRC: akasurde >> http://akasurde.github.io >> >> >> > > -- > Thanks, > Abhijeet Kasurde > > IRC: akasurde > http://akasurde.github.io > > > Hi, thanks for your patch! The man page now correctly reflects the output of ipa-replica-manage list [SERVER]. ACK Flo. From mbasti at redhat.com Thu Jul 28 11:06:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Jul 2016 13:06:03 +0200 Subject: [Freeipa-devel] [PATCH 0018] Minor fix in ipa-replica-manage MAN page In-Reply-To: <0832a15c-ac3f-272c-2a19-921f1ef080e7@redhat.com> References: <23a7f7cd-8344-6ad1-9591-ea60be6f8ee4@redhat.com> <0832a15c-ac3f-272c-2a19-921f1ef080e7@redhat.com> Message-ID: On 28.07.2016 13:04, Florence Blanc-Renaud wrote: > On 07/27/2016 05:47 AM, Abhijeet Kasurde wrote: >> Ping. >> >> >> On 07/13/2016 09:24 AM, Abhijeet Kasurde wrote: >>> >>> Hi All, >>> >>> Please review patch. >>> >>> Fixes: https://fedorahosted.org/freeipa/ticket/6058 >>> -- >>> Thanks, >>> Abhijeet Kasurde >>> >>> IRC: akasurde >>> http://akasurde.github.io >>> >>> >>> >> >> -- >> Thanks, >> Abhijeet Kasurde >> >> IRC: akasurde >> http://akasurde.github.io >> >> >> > Hi, > > thanks for your patch! The man page now correctly reflects the output > of ipa-replica-manage list [SERVER]. > ACK > > Flo. > Pushed to master: 0253f3d7319442150c37fe62e7c9f3f985406ccb From placko at redhat.com Thu Jul 28 11:30:03 2016 From: placko at redhat.com (Peter Lacko) Date: Thu, 28 Jul 2016 07:30:03 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: <553790169.9640957.1469705199335.JavaMail.zimbra@redhat.com> Message-ID: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> Attached you can find a patch adding test for URIs in generated certificate ipatests/test_xmlrpc/test_cert_plugin.py Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. Regards, Peter From ldoudova at redhat.com Thu Jul 28 11:32:25 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 28 Jul 2016 13:32:25 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> Message-ID: <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> Hi, I cannot find any attached patch :) Lenka On 07/28/2016 01:30 PM, Peter Lacko wrote: > Attached you can find a patch adding test for URIs in generated certificate > ipatests/test_xmlrpc/test_cert_plugin.py > Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. > > Regards, > > Peter > From placko at redhat.com Thu Jul 28 11:35:07 2016 From: placko at redhat.com (Peter Lacko) Date: Thu, 28 Jul 2016 07:35:07 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> Message-ID: <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> Hops, fixed. Peter ----- Original Message ----- From: "Lenka Doudova" To: freeipa-devel at redhat.com Sent: Thursday, July 28, 2016 1:32:25 PM Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate Hi, I cannot find any attached patch :) Lenka On 07/28/2016 01:30 PM, Peter Lacko wrote: > Attached you can find a patch adding test for URIs in generated certificate > ipatests/test_xmlrpc/test_cert_plugin.py > Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. > > Regards, > > Peter > -- 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: freeipa-placko-0003-1-Test-URIs-in-certificate.patch Type: text/x-patch Size: 4837 bytes Desc: not available URL: From mkubik at redhat.com Thu Jul 28 11:44:49 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 28 Jul 2016 13:44:49 +0200 Subject: [Freeipa-devel] [PATCH 42-44, 48-51][tests] RFE: Allow users to authenticate with alternative names In-Reply-To: <1005f935-f761-1754-9d84-0e4fca33a7a6@redhat.com> References: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> <35385bd8-7bd3-255b-7b0d-e1d5efecd949@redhat.com> <70cd2dfa-b457-74b8-8bcb-ce2a547e4cb9@redhat.com> <1005f935-f761-1754-9d84-0e4fca33a7a6@redhat.com> Message-ID: <07201acb-5154-d615-8859-f1c0851fb7cc@redhat.com> On 07/28/2016 12:51 PM, Martin Babinsky wrote: > On 07/27/2016 11:54 AM, Milan Kub?k wrote: >> >>>> >>>> >>> >>> Hi Milan, >>> >>> the tests seem to work as expected except >>> `test_enterprise_principal_UPN_overlap_without_additional_suffix` >>> which crashes on #6099. I have a few comments, however: >> This is a test that hits a known bug. I have added an expected fail >> marker for it. >>> >>> Patch 42: >>> >>> 1.) >>> +class KerberosAliasMixin: >>> >>> make sure the class inherits from 'object' so that it behaves like >>> new-style class in Python 2. >>> >>> Also, I think that 'check_for_tracker' method is slightly redundant. >>> If somebody would use the mixin directly, then he will still get >>> "NotImplementedError" exceptions and see that he probably did >>> something wrong. >>> >>> If you really really want to treat to prevent the instantiation of the >>> class, then use ABC module to turn it into proper abstract class. >>> >>> But in this case it should IMHO be enough that you explained the class >>> usage in the module docstring. >> Ok. Fixed the inheritance and removed the check for Tracker. The check >> for krbprincipalname attribute has been kept. >>> >>> 2.) >>> + def _make_add_alias_cmd(self): >>> + raise RuntimeError("The _make_add_alias_cmd method " >>> + "is not implemented.") >>> + >>> + def _make_remove_alias_cmd(self): >>> + raise RuntimeError("The _make_remove_alias_cmd method " >>> + "is not implemented." >>> >>> Abstract methods should raise "NotImplementedError" exception. >>> >> Fixed. >>> 3.) >>> is the 'options=None' kwarg in {add,remove}_principals methods >>> necessary? I didn't see it anywhere in the later commits so I guess >>> you can safely remove it. Better yet, you can just replace it with >>> '**options' since all it does is to pass options to the >>> `*-add/remove-principal` commands. >>> >> Fixed to **options. >>> 4.) >>> a nitpick but IIRC the mixin class should be listed before the actual >>> hierarchy base so that MRO works as expected. >>> >>> So instead >>> >>> +class UserTracker(Tracker, KerberosAliasMixin): >>> >>> It should say >>> +class UserTracker(KerberosAliasMixin, Tracker): >> Fixed in all three classes. >>> >>> PATCH 43: LGTM >>> >>> PATCH 44: >>> >>> Please do not create any more utility modules. Either put it to >>> existing 'ipatests/util.py' or better yet, rename the module to >>> something like 'mock_trust' since the scope of it is to provide mocked >>> trust entries. >> Moved the functions from test_range_plugin.py module to a new mock_trust >> module. The fix for the range plugin test introduced a new commit here. >>> >>> PATCH 45: >>> >>> It would be nice if you could add '-E' option in the same way to >>> indicate enterprise principal name resolution. >> Done. >>> >>> PATCH 46: LGTM >>> PATCH 47: >>> >>> 1.) >>> +from ipatests.test_xmlrpc.test_range_plugin import ( >>> + get_trust_dn, get_trusted_dom_dict, encode_mockldap_value) >>> >>> Since you already introduced a module grouping all trust-mocking >>> machinery in patch 44, you could extract these functions and put it >>> there to improve code reuse. >> Fixed. >>> >>> 2.) >>> I am not a big fan of duplicate code in 'trusted_domain' and >>> 'trusted_domain_with_suffix' fixtures. Use some module-level mapping >>> for common attributes and add more specific attributes per fixture. >> Fixed >>> >>> 3.) >>> I would like to expand the test cases for AD realm namespace overlap >>> checks. We should reject enterprise principals with suffixes >>> coinciding with realm names, NETBIOS names, and UPN suffixes and I >>> would like to test all three cases to get a full coverage. >>> >> Extended with explicit checks fot rhe AD realm and NETBIOS name by >> constructing the enterprise principal from corresponding LDAP >> attributes. >> >> The fixed and rebased version of the commits is in my repo [1]. >> >> [1]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test >> >> Regards >> > > Tests works and code is ok, however you will need to create a separate > ticket to your patches, since it is not allowed to add fixes to > tickets in closed milestones. Sorry that I didn't notice it earlier. > > cond-ACK if you create ticket and remove the xfail from > `test_enterprise_principal_overlap_with_AD_realm` test case as the fix > for #6099 was pushed to master. > Hi, thanks for the review. The xfail marker was removed. The commit messages now reffer to new ticket [1]. Since the changes during review introduced new commit in the sequence, I have abandoned the patches 45 to 47 and renumbered them (with the new one) from 48 onwards. [1]: https://fedorahosted.org/freeipa/ticket/6142 Regards -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0042-1-ipatests-Add-tracker-class-for-kerberos-principal-al.patch Type: text/x-patch Size: 10049 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0043-1-ipatests-Extend-the-MockLDAP-utility-class.patch Type: text/x-patch Size: 1340 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0044-1-ipatests-Provide-a-context-manager-for-mocking-a-tru.patch Type: text/x-patch Size: 2798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0048-ipatests-Move-trust-mock-helper-functions-to-a-separ.patch Type: text/x-patch Size: 5253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0049-ipapython-Extend-kinit_password-to-support-principal.patch Type: text/x-patch Size: 1836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0050-ipatests-Allow-change_principal-context-manager-to-u.patch Type: text/x-patch Size: 1587 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0051-ipatests-Add-kerberos-principal-alias-tests.patch Type: text/x-patch Size: 10839 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 28 12:10:35 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Jul 2016 14:10:35 +0200 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode In-Reply-To: References: <3afeae65-e827-70d2-948d-89eef71bbcd3@redhat.com> <8e4e551f-3446-9d33-de19-1dc4996ff697@redhat.com> Message-ID: On 27.7.2016 18:26, Ariel Barria wrote: > 2016-07-26 9:39 GMT-05:00 Petr Spacek : >> On 26.7.2016 16:28, Jan Cholasta wrote: >>> Hi, >>> >>> On 26.7.2016 16:09, Martin Basti wrote: >>>> >>>> >>>> On 22.07.2016 00:14, Ariel Barria wrote: >>>>> Hello everyone. >>>>> >>>>> I send patch for review. >>> >>> NACK, six.u() is supposed to be used on string literals *only* [1]. >>> >>> A proper fix would be something like: >>> >>> value = self.to_text() >>> if not isinstance(value, unicode): >>> value = value.decode('ascii') >>> return value > > thanks for the guidance and comments > >> >> Most importantly, we should fix/provide this method in python-dns and inherit >> this method from there. > > Well, I made a pr, but apparently travis ci test failed with other > versions of python, so it is possible that they do not approve, I will > be performing other tests to see what the downside. > > https://github.com/rthalley/dnspython/pull/195 Looking at the PR, there are functions dns.name.to_text() dns.name.to_unicode() What is missing in them? Petr^2 Spacek >>>> I will look on this, for some reason we received your e-mail just today >>>> (2016-07-26) > > welcome. > it was my mistake, I sent the patch to the list before being signed to the list > >>> >>> Honza >>> >>> [1] -- Petr^2 Spacek From jcholast at redhat.com Thu Jul 28 13:26:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Jul 2016 15:26:07 +0200 Subject: [Freeipa-devel] [PATCH 680] compat: fix ping call In-Reply-To: References: Message-ID: On 28.7.2016 10:11, Jan Cholasta wrote: > Hi, > > the attached patch fixes . Pushed to master under the one-liner rule: b8b7b9bf8e8a23d652c99c335219abf9de1a6fb7 > > Honza > > > -- Jan Cholasta From mbasti at redhat.com Thu Jul 28 14:11:26 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Jul 2016 16:11:26 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <577FAD77.7080504@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> Message-ID: <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> On 08.07.2016 15:41, Oleg Fayans wrote: > Hi Martin, > > Thanks for the review! > > On 07/08/2016 02:18 PM, Martin Basti wrote: >> >> >> On 27.06.2016 13:53, Oleg Fayans wrote: >>> Hi guys, >>> >>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed before >>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>> feature. >>> >>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>> One more test was added to the patch-0048 >>>> >>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>> Fixed a bug in the previous patch, automated 2 more testcases from >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>> >>>>> >>>>> >>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> IIUC, this will turn off the machine completely, how is cleanup done >> then. AFAIK our tests cannot turn on machine again and run cleanup, so >> you will not be able to run more tests on the same topology without >> manual cleanup and manual start. >> >> + replica = self.replicas[0] >> + replica.run_command(['poweroff']) >> >> IMO would be better to just call 'ipactl stop' instead of 'poweroff' > > Agreed! Fixed. > >> >> Martin^2 >> > > > *Automated ipa-replica-manage del tests* 1) + replica.run_command(['ipactl', 'stop']) + time.sleep(3) Why do you need sleep here? 2) + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) + replica_ruvs = ruvid_re.findall(result.stdout_text) + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', + '-p', master.config.dirman_password, + replica_ruvs[0]]) Because you are using re.findall(), without any match you will receive IndexError here replica_ruvs[0]. IMO it deserves assert before. 3) assert(replica.hostname in result1.stdout_text) I think that this is error prone. What if there is just error 'could not connect to replica ', or something similar. instead of listing/cleaning/whatever operation was executed. I think that it should be more specific regexp than just finding a replica name substring (Yes In IPA we dont always print error so stderr) I'm not sure, but probably there might be cases when non critical error happen and exist status is still 0 4) + replica.run_command(['poweroff']) + time.sleep(3) There should not be poweroff, probably sleep could be removed too. * Automated clean-ruv subcommand test* 1) PEP8, 2 new lines expected ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 blank lines, found 0 ./ipatests/test_integration/test_topology.py:182:80: E501 line too long (85 > 79 characters) 2) I dont like doing assert just with count of occurences of substring in STDOUT, would be possible to improve this somehow? 3) I'm not sure if clean-ruv is instant operations or there is some magic happening in background (we have abort-clean-ruv). Maybe some sleep should be there, but this needs investigation. + assert(replica.hostname in result2.stdout_text), ( + "The wrong RUV was deleted") + result3 = master.run_command(['ipa-replica-manage', 'list-ruv', + '-p', master.config.dirman_password]) + assert(result3.stdout_text.count(replica.hostname) == 1), ( + "CA RUV of the replica is still displayed") -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Jul 28 14:20:14 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Jul 2016 16:20:14 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value Message-ID: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> Hello, install: Call hostnamectl set-hostname only if --hostname option is used This commit also splits hostname backup and configuration into two separate functions. This allows us to backup hostname without setting it at the same time. https://fedorahosted.org/freeipa/ticket/6071 server-install: Fix --hostname option to always override api.env values Attempts to compare local hostname with user-provided values are error prone as we found out in #5794. This patch removes comparison and makes the env values deterministic. https://fedorahosted.org/freeipa/ticket/6071 Jan, this patch set should fix problems you have seen in containers. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0151-server-install-Fix-hostname-option-to-always-overrid.patch Type: text/x-patch Size: 1888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0152-install-Call-hostnamectl-set-hostname-only-if-hostna.patch Type: text/x-patch Size: 6031 bytes Desc: not available URL: From jcholast at redhat.com Thu Jul 28 14:35:56 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Jul 2016 16:35:56 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> Message-ID: <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> On 28.7.2016 16:20, Petr Spacek wrote: > Hello, > > install: Call hostnamectl set-hostname only if --hostname option is used > > This commit also splits hostname backup and configuration into two separate > functions. This allows us to backup hostname without setting it at the > same time. > > https://fedorahosted.org/freeipa/ticket/6071 Note that you can set ca_host in cfg unconditionally, the value is only valid during install and is not written anywhere. > > server-install: Fix --hostname option to always override api.env values > > Attempts to compare local hostname with user-provided values are error > prone as we found out in #5794. This patch removes comparison and makes > the env values deterministic. > > https://fedorahosted.org/freeipa/ticket/6071 > > > Jan, this patch set should fix problems you have seen in containers. > > > -- Jan Cholasta From jcholast at redhat.com Thu Jul 28 14:39:14 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Jul 2016 16:39:14 +0200 Subject: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain In-Reply-To: References: <74ee6686-c8de-d80f-3e2f-3fca3bfb4f8d@redhat.com> Message-ID: On 25.7.2016 16:36, Petr Spacek wrote: > On 25.7.2016 16:16, Jan Cholasta wrote: >> On 25.7.2016 15:55, Petr Spacek wrote: >>> Hello, >>> >>> replica-install: Fix --domain >>> >>> Replica installation must not check existence of --domain - the domain >>> must (logically) exist. >>> >>> https://fedorahosted.org/freeipa/ticket/6130 >> >> Note that Server.domain_name is already defined on line 1204 in >> ipaserver/install/server/install.py. > > My bad, here is updated patch. Please use the original domain_name definition in Server, the order of knobs in the class matters. -- Jan Cholasta From pspacek at redhat.com Thu Jul 28 14:37:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Jul 2016 16:37:06 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> Message-ID: <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> On 28.7.2016 16:35, Jan Cholasta wrote: > On 28.7.2016 16:20, Petr Spacek wrote: >> Hello, >> >> install: Call hostnamectl set-hostname only if --hostname option is used >> >> This commit also splits hostname backup and configuration into two separate >> functions. This allows us to backup hostname without setting it at the >> same time. >> >> https://fedorahosted.org/freeipa/ticket/6071 > > Note that you can set ca_host in cfg unconditionally, the value is only valid > during install and is not written anywhere. I prefer not to set it so the code blows up when we attempt to touch variables we should reference in particular setups. I.e. Take this as a first step towards api.env without invalid values :-) (In my stash I have a patch which removes nonsense defaults from ipalib.constants. To be pushed when we a new git branch for 4.4...) Petr^2 Spacek >> server-install: Fix --hostname option to always override api.env values >> >> Attempts to compare local hostname with user-provided values are error >> prone as we found out in #5794. This patch removes comparison and makes >> the env values deterministic. >> >> https://fedorahosted.org/freeipa/ticket/6071 >> >> >> Jan, this patch set should fix problems you have seen in containers. -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek From jcholast at redhat.com Thu Jul 28 14:44:58 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Jul 2016 16:44:58 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> Message-ID: <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> On 28.7.2016 16:37, Petr Spacek wrote: > On 28.7.2016 16:35, Jan Cholasta wrote: >> On 28.7.2016 16:20, Petr Spacek wrote: >>> Hello, >>> >>> install: Call hostnamectl set-hostname only if --hostname option is used >>> >>> This commit also splits hostname backup and configuration into two separate >>> functions. This allows us to backup hostname without setting it at the >>> same time. >>> >>> https://fedorahosted.org/freeipa/ticket/6071 >> >> Note that you can set ca_host in cfg unconditionally, the value is only valid >> during install and is not written anywhere. > > I prefer not to set it so the code blows up when we attempt to touch variables > we should reference in particular setups. I.e. Take this as a first step > towards api.env without invalid values :-) OK. Use the proper condition then ("if setup_ca:"). > > (In my stash I have a patch which removes nonsense defaults from > ipalib.constants. To be pushed when we a new git branch for 4.4...) > > Petr^2 Spacek > >>> server-install: Fix --hostname option to always override api.env values >>> >>> Attempts to compare local hostname with user-provided values are error >>> prone as we found out in #5794. This patch removes comparison and makes >>> the env values deterministic. >>> >>> https://fedorahosted.org/freeipa/ticket/6071 >>> >>> >>> Jan, this patch set should fix problems you have seen in containers. -- Jan Cholasta From pspacek at redhat.com Thu Jul 28 14:53:43 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Jul 2016 16:53:43 +0200 Subject: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain In-Reply-To: References: <74ee6686-c8de-d80f-3e2f-3fca3bfb4f8d@redhat.com> Message-ID: <2710813d-2aa0-d647-5bf4-6cb21e98428d@redhat.com> On 28.7.2016 16:39, Jan Cholasta wrote: > On 25.7.2016 16:36, Petr Spacek wrote: >> On 25.7.2016 16:16, Jan Cholasta wrote: >>> On 25.7.2016 15:55, Petr Spacek wrote: >>>> Hello, >>>> >>>> replica-install: Fix --domain >>>> >>>> Replica installation must not check existence of --domain - the domain >>>> must (logically) exist. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6130 >>> >>> Note that Server.domain_name is already defined on line 1204 in >>> ipaserver/install/server/install.py. >> >> My bad, here is updated patch. > > Please use the original domain_name definition in Server, the order of knobs > in the class matters. Ah, the order in class is re-used for ordering in --help. Given that --domain option depends on setup_dns which is defined before, I had to move realm option down so realm & domain are next to each other. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0150-3-replica-install-Fix-domain.patch Type: text/x-patch Size: 2573 bytes Desc: not available URL: From pspacek at redhat.com Thu Jul 28 14:55:16 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Jul 2016 16:55:16 +0200 Subject: [Freeipa-devel] [PATCH 0151-0152] install: Call hostnamectl set-hostname only if --hostname option is use server-install: Fix --hostname option to always override api.env value In-Reply-To: <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> References: <7b729ec0-619f-17d4-bf2f-dceca268a444@redhat.com> <5467c214-4555-0d07-520f-9a280da2f7c9@redhat.com> <31ceaafa-4f54-7bcb-e7d1-1452d3eb5f30@redhat.com> <809195d1-83f7-bf47-df6b-ad2cc1851e50@redhat.com> Message-ID: On 28.7.2016 16:44, Jan Cholasta wrote: > On 28.7.2016 16:37, Petr Spacek wrote: >> On 28.7.2016 16:35, Jan Cholasta wrote: >>> On 28.7.2016 16:20, Petr Spacek wrote: >>>> Hello, >>>> >>>> install: Call hostnamectl set-hostname only if --hostname option is used >>>> >>>> This commit also splits hostname backup and configuration into two separate >>>> functions. This allows us to backup hostname without setting it at the >>>> same time. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6071 >>> >>> Note that you can set ca_host in cfg unconditionally, the value is only valid >>> during install and is not written anywhere. >> >> I prefer not to set it so the code blows up when we attempt to touch variables >> we should reference in particular setups. I.e. Take this as a first step >> towards api.env without invalid values :-) > > OK. Use the proper condition then ("if setup_ca:"). Oh, I'm probably blind. Here is revised version. Petr^2 Spacek > >> >> (In my stash I have a patch which removes nonsense defaults from >> ipalib.constants. To be pushed when we a new git branch for 4.4...) >> >> Petr^2 Spacek >> >>>> server-install: Fix --hostname option to always override api.env values >>>> >>>> Attempts to compare local hostname with user-provided values are error >>>> prone as we found out in #5794. This patch removes comparison and makes >>>> the env values deterministic. >>>> >>>> https://fedorahosted.org/freeipa/ticket/6071 >>>> >>>> >>>> Jan, this patch set should fix problems you have seen in containers. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0151-2-server-install-Fix-hostname-option-to-always-overrid.patch Type: text/x-patch Size: 1842 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0152-2-install-Call-hostnamectl-set-hostname-only-if-hostna.patch Type: text/x-patch Size: 6031 bytes Desc: not available URL: From gkaihoro at redhat.com Thu Jul 28 16:08:14 2016 From: gkaihoro at redhat.com (Ganna Kaihorodova) Date: Thu, 28 Jul 2016 12:08:14 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember tests in 4.3 In-Reply-To: <4237887a-917f-4fb2-0a7c-1eeb79ee6996@redhat.com> References: <4237887a-917f-4fb2-0a7c-1eeb79ee6996@redhat.com> Message-ID: <267013028.45213877.1469722094808.JavaMail.zimbra@redhat.com> Greetings! ACK Best regards, Ganna Kaihorodova Associate Software Quality Engineer ----- Original Message ----- From: "Lenka Doudova" To: "freeipa-devel" Sent: Wednesday, July 13, 2016 3:21:25 PM Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember tests in 4.3 Hi, providing patch to fix two failing automember tests in 4.3 branch. The reason of the failure was the output normalization (specifically manager attribute for user). The patch is intended for ipa-4-3 branch only. Lenka -- 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 mbabinsk at redhat.com Thu Jul 28 16:10:35 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 28 Jul 2016 18:10:35 +0200 Subject: [Freeipa-devel] [PATCH 42-44, 48-51][tests] RFE: Allow users to authenticate with alternative names In-Reply-To: <07201acb-5154-d615-8859-f1c0851fb7cc@redhat.com> References: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> <35385bd8-7bd3-255b-7b0d-e1d5efecd949@redhat.com> <70cd2dfa-b457-74b8-8bcb-ce2a547e4cb9@redhat.com> <1005f935-f761-1754-9d84-0e4fca33a7a6@redhat.com> <07201acb-5154-d615-8859-f1c0851fb7cc@redhat.com> Message-ID: <280c27fc-1e82-0893-a3a2-3af281381629@redhat.com> On 07/28/2016 01:44 PM, Milan Kub?k wrote: > On 07/28/2016 12:51 PM, Martin Babinsky wrote: >> On 07/27/2016 11:54 AM, Milan Kub?k wrote: >>> >>>>> >>>>> >>>> >>>> Hi Milan, >>>> >>>> the tests seem to work as expected except >>>> `test_enterprise_principal_UPN_overlap_without_additional_suffix` >>>> which crashes on #6099. I have a few comments, however: >>> This is a test that hits a known bug. I have added an expected fail >>> marker for it. >>>> >>>> Patch 42: >>>> >>>> 1.) >>>> +class KerberosAliasMixin: >>>> >>>> make sure the class inherits from 'object' so that it behaves like >>>> new-style class in Python 2. >>>> >>>> Also, I think that 'check_for_tracker' method is slightly redundant. >>>> If somebody would use the mixin directly, then he will still get >>>> "NotImplementedError" exceptions and see that he probably did >>>> something wrong. >>>> >>>> If you really really want to treat to prevent the instantiation of the >>>> class, then use ABC module to turn it into proper abstract class. >>>> >>>> But in this case it should IMHO be enough that you explained the class >>>> usage in the module docstring. >>> Ok. Fixed the inheritance and removed the check for Tracker. The check >>> for krbprincipalname attribute has been kept. >>>> >>>> 2.) >>>> + def _make_add_alias_cmd(self): >>>> + raise RuntimeError("The _make_add_alias_cmd method " >>>> + "is not implemented.") >>>> + >>>> + def _make_remove_alias_cmd(self): >>>> + raise RuntimeError("The _make_remove_alias_cmd method " >>>> + "is not implemented." >>>> >>>> Abstract methods should raise "NotImplementedError" exception. >>>> >>> Fixed. >>>> 3.) >>>> is the 'options=None' kwarg in {add,remove}_principals methods >>>> necessary? I didn't see it anywhere in the later commits so I guess >>>> you can safely remove it. Better yet, you can just replace it with >>>> '**options' since all it does is to pass options to the >>>> `*-add/remove-principal` commands. >>>> >>> Fixed to **options. >>>> 4.) >>>> a nitpick but IIRC the mixin class should be listed before the actual >>>> hierarchy base so that MRO works as expected. >>>> >>>> So instead >>>> >>>> +class UserTracker(Tracker, KerberosAliasMixin): >>>> >>>> It should say >>>> +class UserTracker(KerberosAliasMixin, Tracker): >>> Fixed in all three classes. >>>> >>>> PATCH 43: LGTM >>>> >>>> PATCH 44: >>>> >>>> Please do not create any more utility modules. Either put it to >>>> existing 'ipatests/util.py' or better yet, rename the module to >>>> something like 'mock_trust' since the scope of it is to provide mocked >>>> trust entries. >>> Moved the functions from test_range_plugin.py module to a new mock_trust >>> module. The fix for the range plugin test introduced a new commit here. >>>> >>>> PATCH 45: >>>> >>>> It would be nice if you could add '-E' option in the same way to >>>> indicate enterprise principal name resolution. >>> Done. >>>> >>>> PATCH 46: LGTM >>>> PATCH 47: >>>> >>>> 1.) >>>> +from ipatests.test_xmlrpc.test_range_plugin import ( >>>> + get_trust_dn, get_trusted_dom_dict, encode_mockldap_value) >>>> >>>> Since you already introduced a module grouping all trust-mocking >>>> machinery in patch 44, you could extract these functions and put it >>>> there to improve code reuse. >>> Fixed. >>>> >>>> 2.) >>>> I am not a big fan of duplicate code in 'trusted_domain' and >>>> 'trusted_domain_with_suffix' fixtures. Use some module-level mapping >>>> for common attributes and add more specific attributes per fixture. >>> Fixed >>>> >>>> 3.) >>>> I would like to expand the test cases for AD realm namespace overlap >>>> checks. We should reject enterprise principals with suffixes >>>> coinciding with realm names, NETBIOS names, and UPN suffixes and I >>>> would like to test all three cases to get a full coverage. >>>> >>> Extended with explicit checks fot rhe AD realm and NETBIOS name by >>> constructing the enterprise principal from corresponding LDAP >>> attributes. >>> >>> The fixed and rebased version of the commits is in my repo [1]. >>> >>> [1]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test >>> >>> Regards >>> >> >> Tests works and code is ok, however you will need to create a separate >> ticket to your patches, since it is not allowed to add fixes to >> tickets in closed milestones. Sorry that I didn't notice it earlier. >> >> cond-ACK if you create ticket and remove the xfail from >> `test_enterprise_principal_overlap_with_AD_realm` test case as the fix >> for #6099 was pushed to master. >> > > Hi, > > thanks for the review. The xfail marker was removed. The commit messages > now reffer to new ticket [1]. > Since the changes during review introduced new commit in the sequence, I > have abandoned the patches 45 to 47 and renumbered them (with the new > one) from 48 onwards. > > [1]: https://fedorahosted.org/freeipa/ticket/6142 > > Regards > Thanks, ACK. -- Martin^3 Babinsky From ariel.o.barria at gmail.com Thu Jul 28 16:29:07 2016 From: ariel.o.barria at gmail.com (Ariel Barria) Date: Thu, 28 Jul 2016 11:29:07 -0500 Subject: [Freeipa-devel] [PATCH] 0001 six.u function instead of the decode In-Reply-To: References: <3afeae65-e827-70d2-948d-89eef71bbcd3@redhat.com> <8e4e551f-3446-9d33-de19-1dc4996ff697@redhat.com> Message-ID: 2016-07-28 7:10 GMT-05:00 Petr Spacek : > On 27.7.2016 18:26, Ariel Barria wrote: >> 2016-07-26 9:39 GMT-05:00 Petr Spacek : >>> On 26.7.2016 16:28, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 26.7.2016 16:09, Martin Basti wrote: >>>>> >>>>> >>>>> On 22.07.2016 00:14, Ariel Barria wrote: >>>>>> Hello everyone. >>>>>> >>>>>> I send patch for review. >>>> >>>> NACK, six.u() is supposed to be used on string literals *only* [1]. >>>> >>>> A proper fix would be something like: >>>> >>>> value = self.to_text() >>>> if not isinstance(value, unicode): >>>> value = value.decode('ascii') >>>> return value >> >> thanks for the guidance and comments >> >>> >>> Most importantly, we should fix/provide this method in python-dns and inherit >>> this method from there. >> >> Well, I made a pr, but apparently travis ci test failed with other >> versions of python, so it is possible that they do not approve, I will >> be performing other tests to see what the downside. >> >> https://github.com/rthalley/dnspython/pull/195 > > Looking at the PR, there are functions > dns.name.to_text() > dns.name.to_unicode() > > What is missing in them? > > Petr^2 Spacek > > >>>>> I will look on this, for some reason we received your e-mail just today >>>>> (2016-07-26) >> >> welcome. >> it was my mistake, I sent the patch to the list before being signed to the list >> >>>> >>>> Honza >>>> >>>> [1] > -- > Petr^2 Spacek Hi. I send the requested changes thanks for review. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-arielb-0001-0002-six.u-function-instead-of-t.patch Type: text/x-patch Size: 1288 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jul 29 04:21:04 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 29 Jul 2016 14:21:04 +1000 Subject: [Freeipa-devel] [PATCH] 0096 caacl: fix regression in rule instantiation In-Reply-To: <3131b303-a873-1575-9488-f764c7dd96be@redhat.com> References: <20160728013118.GA10771@dhcp-40-8.bne.redhat.com> <3131b303-a873-1575-9488-f764c7dd96be@redhat.com> Message-ID: <20160729042103.GK10771@dhcp-40-8.bne.redhat.com> On Thu, Jul 28, 2016 at 09:56:30AM +0200, Martin Babinsky wrote: > On 07/28/2016 03:31 AM, Fraser Tweedale wrote: > > The attached patch fixes a kerberos.Principal-related regression. > > > > Thanks, > > Fraser > > > Hi Fraser, > > The ticket you linked in the commit message points to a closed milestone. > You have to open a new ticket which needs to be triaged. Sorry, those are > the processes. > Filed ticket: https://fedorahosted.org/freeipa/ticket/6146 Updated patch attached (rebase and update commit message only). Thanks, Fraser -------------- next part -------------- From ef74c727e31a08af679eeeca027dd6a6bf526f0e Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 28 Jul 2016 10:55:45 +1000 Subject: [PATCH] caacl: fix regression in rule instantiation The Principal refactor causes service collections ('memberservice_service' attribute) to return Principal objects where previously it returned strings, but the HBAC machinery used for CA ACL enforcement only handles strings. Update the code to stringify service Principal objects when adding them to HBAC rules. Fixes: https://fedorahosted.org/freeipa/ticket/6146 --- ipaserver/plugins/caacl.py | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/ipaserver/plugins/caacl.py b/ipaserver/plugins/caacl.py index d316cc7c48cf2997d6be6b052dc1efa6d6fcdb6a..a7817c4cf64f070c74557f52e9f26c9013a4963c 100644 --- a/ipaserver/plugins/caacl.py +++ b/ipaserver/plugins/caacl.py @@ -132,16 +132,21 @@ def _acl_make_rule(principal_type, obj): rule.services.names = obj.get(attr, []) # add principals and principal's groups - m = {'user': 'group', 'host': 'hostgroup', 'service': None} category_attr = '{}category'.format(principal_type) if category_attr in obj and obj[category_attr][0].lower() == 'all': rule.users.category = {pyhbac.HBAC_CATEGORY_ALL} else: - principal_attr = 'member{}_{}'.format(principal_type, principal_type) - rule.users.names = obj.get(principal_attr, []) - if m[principal_type] is not None: - group_attr = 'member{}_{}'.format(principal_type, m[principal_type]) - rule.users.groups = obj.get(group_attr, []) + if principal_type == 'user': + rule.users.names = obj.get('memberuser_user', []) + rule.users.groups = obj.get('memberuser_group', []) + elif principal_type == 'host': + rule.users.names = obj.get('memberhost_host', []) + rule.users.groups = obj.get('memberhost_hostgroup', []) + elif principal_type == 'service': + rule.users.names = [ + unicode(principal) + for principal in obj.get('memberservice_service', []) + ] return rule -- 2.5.5 From jcholast at redhat.com Fri Jul 29 05:40:13 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 Jul 2016 07:40:13 +0200 Subject: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain In-Reply-To: <2710813d-2aa0-d647-5bf4-6cb21e98428d@redhat.com> References: <74ee6686-c8de-d80f-3e2f-3fca3bfb4f8d@redhat.com> <2710813d-2aa0-d647-5bf4-6cb21e98428d@redhat.com> Message-ID: <360f1ed0-17c1-c8aa-192c-02598e79c55c@redhat.com> On 28.7.2016 16:53, Petr Spacek wrote: > On 28.7.2016 16:39, Jan Cholasta wrote: >> On 25.7.2016 16:36, Petr Spacek wrote: >>> On 25.7.2016 16:16, Jan Cholasta wrote: >>>> On 25.7.2016 15:55, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> replica-install: Fix --domain >>>>> >>>>> Replica installation must not check existence of --domain - the domain >>>>> must (logically) exist. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/6130 >>>> >>>> Note that Server.domain_name is already defined on line 1204 in >>>> ipaserver/install/server/install.py. >>> >>> My bad, here is updated patch. >> >> Please use the original domain_name definition in Server, the order of knobs >> in the class matters. > > Ah, the order in class is re-used for ordering in --help. > > Given that --domain option depends on setup_dns which is defined before, I had > to move realm option down so realm & domain are next to each other. Right. Works for me, ACK. Pushed to master: 6eb9eb730350937692a442b66e4d79d3ebd4eb01 -- Jan Cholasta From mbasti at redhat.com Fri Jul 29 07:07:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 09:07:06 +0200 Subject: [Freeipa-devel] [PATCH 42-44, 48-51][tests] RFE: Allow users to authenticate with alternative names In-Reply-To: <280c27fc-1e82-0893-a3a2-3af281381629@redhat.com> References: <01039ee7-4d13-c816-4170-cb33e541e545@redhat.com> <35385bd8-7bd3-255b-7b0d-e1d5efecd949@redhat.com> <70cd2dfa-b457-74b8-8bcb-ce2a547e4cb9@redhat.com> <1005f935-f761-1754-9d84-0e4fca33a7a6@redhat.com> <07201acb-5154-d615-8859-f1c0851fb7cc@redhat.com> <280c27fc-1e82-0893-a3a2-3af281381629@redhat.com> Message-ID: <670e8a18-0263-572e-c055-fa5b3cb46139@redhat.com> On 28.07.2016 18:10, Martin Babinsky wrote: > On 07/28/2016 01:44 PM, Milan Kub?k wrote: >> On 07/28/2016 12:51 PM, Martin Babinsky wrote: >>> On 07/27/2016 11:54 AM, Milan Kub?k wrote: >>>> >>>>>> >>>>>> >>>>> >>>>> Hi Milan, >>>>> >>>>> the tests seem to work as expected except >>>>> `test_enterprise_principal_UPN_overlap_without_additional_suffix` >>>>> which crashes on #6099. I have a few comments, however: >>>> This is a test that hits a known bug. I have added an expected fail >>>> marker for it. >>>>> >>>>> Patch 42: >>>>> >>>>> 1.) >>>>> +class KerberosAliasMixin: >>>>> >>>>> make sure the class inherits from 'object' so that it behaves like >>>>> new-style class in Python 2. >>>>> >>>>> Also, I think that 'check_for_tracker' method is slightly redundant. >>>>> If somebody would use the mixin directly, then he will still get >>>>> "NotImplementedError" exceptions and see that he probably did >>>>> something wrong. >>>>> >>>>> If you really really want to treat to prevent the instantiation of >>>>> the >>>>> class, then use ABC module to turn it into proper abstract class. >>>>> >>>>> But in this case it should IMHO be enough that you explained the >>>>> class >>>>> usage in the module docstring. >>>> Ok. Fixed the inheritance and removed the check for Tracker. The check >>>> for krbprincipalname attribute has been kept. >>>>> >>>>> 2.) >>>>> + def _make_add_alias_cmd(self): >>>>> + raise RuntimeError("The _make_add_alias_cmd method " >>>>> + "is not implemented.") >>>>> + >>>>> + def _make_remove_alias_cmd(self): >>>>> + raise RuntimeError("The _make_remove_alias_cmd method " >>>>> + "is not implemented." >>>>> >>>>> Abstract methods should raise "NotImplementedError" exception. >>>>> >>>> Fixed. >>>>> 3.) >>>>> is the 'options=None' kwarg in {add,remove}_principals methods >>>>> necessary? I didn't see it anywhere in the later commits so I guess >>>>> you can safely remove it. Better yet, you can just replace it with >>>>> '**options' since all it does is to pass options to the >>>>> `*-add/remove-principal` commands. >>>>> >>>> Fixed to **options. >>>>> 4.) >>>>> a nitpick but IIRC the mixin class should be listed before the actual >>>>> hierarchy base so that MRO works as expected. >>>>> >>>>> So instead >>>>> >>>>> +class UserTracker(Tracker, KerberosAliasMixin): >>>>> >>>>> It should say >>>>> +class UserTracker(KerberosAliasMixin, Tracker): >>>> Fixed in all three classes. >>>>> >>>>> PATCH 43: LGTM >>>>> >>>>> PATCH 44: >>>>> >>>>> Please do not create any more utility modules. Either put it to >>>>> existing 'ipatests/util.py' or better yet, rename the module to >>>>> something like 'mock_trust' since the scope of it is to provide >>>>> mocked >>>>> trust entries. >>>> Moved the functions from test_range_plugin.py module to a new >>>> mock_trust >>>> module. The fix for the range plugin test introduced a new commit >>>> here. >>>>> >>>>> PATCH 45: >>>>> >>>>> It would be nice if you could add '-E' option in the same way to >>>>> indicate enterprise principal name resolution. >>>> Done. >>>>> >>>>> PATCH 46: LGTM >>>>> PATCH 47: >>>>> >>>>> 1.) >>>>> +from ipatests.test_xmlrpc.test_range_plugin import ( >>>>> + get_trust_dn, get_trusted_dom_dict, encode_mockldap_value) >>>>> >>>>> Since you already introduced a module grouping all trust-mocking >>>>> machinery in patch 44, you could extract these functions and put it >>>>> there to improve code reuse. >>>> Fixed. >>>>> >>>>> 2.) >>>>> I am not a big fan of duplicate code in 'trusted_domain' and >>>>> 'trusted_domain_with_suffix' fixtures. Use some module-level mapping >>>>> for common attributes and add more specific attributes per fixture. >>>> Fixed >>>>> >>>>> 3.) >>>>> I would like to expand the test cases for AD realm namespace overlap >>>>> checks. We should reject enterprise principals with suffixes >>>>> coinciding with realm names, NETBIOS names, and UPN suffixes and I >>>>> would like to test all three cases to get a full coverage. >>>>> >>>> Extended with explicit checks fot rhe AD realm and NETBIOS name by >>>> constructing the enterprise principal from corresponding LDAP >>>> attributes. >>>> >>>> The fixed and rebased version of the commits is in my repo [1]. >>>> >>>> [1]: >>>> https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test >>>> >>>> Regards >>>> >>> >>> Tests works and code is ok, however you will need to create a separate >>> ticket to your patches, since it is not allowed to add fixes to >>> tickets in closed milestones. Sorry that I didn't notice it earlier. >>> >>> cond-ACK if you create ticket and remove the xfail from >>> `test_enterprise_principal_overlap_with_AD_realm` test case as the fix >>> for #6099 was pushed to master. >>> >> >> Hi, >> >> thanks for the review. The xfail marker was removed. The commit messages >> now reffer to new ticket [1]. >> Since the changes during review introduced new commit in the sequence, I >> have abandoned the patches 45 to 47 and renumbered them (with the new >> one) from 48 onwards. >> >> [1]: https://fedorahosted.org/freeipa/ticket/6142 >> >> Regards >> > > Thanks, ACK. > master: * 5582d1df3213a0727e313d543ee560a09d0cdff8 ipatests: Add tracker class for kerberos principal aliases * dde1240f5d71f3a8c50226a720af6f1000a35be1 ipatests: Extend the MockLDAP utility class * 7c03708734ad7cb8f1a6edd39817212794b5aabd ipatests: Provide a context manager for mocking a trust in RPC tests * ddb7a08084d69a119abdd39a3c82113bb8586db6 ipatests: Move trust mock helper functions to a separate module * 8e83b9715a04fab8d7864b6e02e1210df885119c ipapython: Extend kinit_password to support principal canonicalization * e17ec08daef521b33dcc5db131f36f4269edcdb2 ipatests: Allow change_principal context manager to use canonicalization * dd2e3a5547f7305cb40d94b00f7b8b14b9a73885 ipatests: Add kerberos principal alias tests From ldoudova at redhat.com Fri Jul 29 07:13:37 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 29 Jul 2016 09:13:37 +0200 Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember tests in 4.3 In-Reply-To: <267013028.45213877.1469722094808.JavaMail.zimbra@redhat.com> References: <4237887a-917f-4fb2-0a7c-1eeb79ee6996@redhat.com> <267013028.45213877.1469722094808.JavaMail.zimbra@redhat.com> Message-ID: On 07/28/2016 06:08 PM, Ganna Kaihorodova wrote: > Greetings! > > ACK > > Best regards, > Ganna Kaihorodova > Associate Software Quality Engineer > > > ----- Original Message ----- > From: "Lenka Doudova" > To: "freeipa-devel" > Sent: Wednesday, July 13, 2016 3:21:25 PM > Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember tests in 4.3 > > Hi, > > providing patch to fix two failing automember tests in 4.3 branch. The > reason of the failure was the output normalization (specifically manager > attribute for user). > > The patch is intended for ipa-4-3 branch only. > > > Lenka > > Hi, minor fix to the patch - added link to ticket to commit message. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0027.2-Tests-Fix-failing-automember-tests.patch Type: text/x-patch Size: 1702 bytes Desc: not available URL: From Peter.Marx at knorr-bremse.com Fri Jul 29 08:20:07 2016 From: Peter.Marx at knorr-bremse.com (Marx, Peter) Date: Fri, 29 Jul 2016 08:20:07 +0000 Subject: [Freeipa-devel] certmonger EST RFC7030 support possible ? Message-ID: <2C720BBFE8885346B9A4377911BABE7886886511@MUCS72046.corp.knorr-bremse.com> Hi, we are using certmonger with SCEP. But SCEP does not support Elliptic curve keys, only RSA. The successor protocol EST (Enrollment over Secure Transport) would support ECC. Is a EST helper for certmonger/getcert on the roadmap ? If yes, when ? How complicated is it to create such a helper around the Cisco open-sourced libest ? Peter Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Jul 29 08:30:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 10:30:17 +0200 Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember tests in 4.3 In-Reply-To: References: <4237887a-917f-4fb2-0a7c-1eeb79ee6996@redhat.com> <267013028.45213877.1469722094808.JavaMail.zimbra@redhat.com> Message-ID: On 29.07.2016 09:13, Lenka Doudova wrote: > On 07/28/2016 06:08 PM, Ganna Kaihorodova wrote: >> Greetings! >> >> ACK >> >> Best regards, >> Ganna Kaihorodova >> Associate Software Quality Engineer >> >> >> ----- Original Message ----- >> From: "Lenka Doudova" >> To: "freeipa-devel" >> Sent: Wednesday, July 13, 2016 3:21:25 PM >> Subject: [Freeipa-devel] [PATCH 0027][Tests] Fix failing automember >> tests in 4.3 >> >> Hi, >> >> providing patch to fix two failing automember tests in 4.3 branch. The >> reason of the failure was the output normalization (specifically manager >> attribute for user). >> >> The patch is intended for ipa-4-3 branch only. >> >> >> Lenka >> >> > Hi, > > minor fix to the patch - added link to ticket to commit message. > > Lenka > > Pushed to ipa-4-3: ffe146fbba2e9577a9af5dd1521a110570024455 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldoudova at redhat.com Fri Jul 29 09:41:38 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 29 Jul 2016 11:41:38 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> Message-ID: On 07/28/2016 01:35 PM, Peter Lacko wrote: > Hops, fixed. > > Peter > > > ----- Original Message ----- > From: "Lenka Doudova" > To: freeipa-devel at redhat.com > Sent: Thursday, July 28, 2016 1:32:25 PM > Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate > > Hi, > > I cannot find any attached patch :) > > Lenka > > > On 07/28/2016 01:30 PM, Peter Lacko wrote: >> Attached you can find a patch adding test for URIs in generated certificate >> ipatests/test_xmlrpc/test_cert_plugin.py >> Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. >> >> Regards, >> >> Peter >> > > Hi, NACK. Code looks fine and works well on master branch, but patch does not apply on 4-3 and 4-2 branches. Peter left the company but claimed he can fix the patch if necessary, I'll communicate it with him or fix it myself. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldoudova at redhat.com Fri Jul 29 09:43:05 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 29 Jul 2016 11:43:05 +0200 Subject: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate In-Reply-To: References: <1004948019.9643194.1469705403940.JavaMail.zimbra@redhat.com> <11d0579b-2ca2-af88-ed97-2efa477290c0@redhat.com> <529785673.9646711.1469705707399.JavaMail.zimbra@redhat.com> Message-ID: On 07/29/2016 11:41 AM, Lenka Doudova wrote: > > On 07/28/2016 01:35 PM, Peter Lacko wrote: >> Hops, fixed. >> >> Peter >> >> >> ----- Original Message ----- >> From: "Lenka Doudova" >> To:freeipa-devel at redhat.com >> Sent: Thursday, July 28, 2016 1:32:25 PM >> Subject: Re: [Freeipa-devel] [PATCH 0003] Test validity of URIs in certificate >> >> Hi, >> >> I cannot find any attached patch :) >> >> Lenka >> >> >> On 07/28/2016 01:30 PM, Peter Lacko wrote: >>> Attached you can find a patch adding test for URIs in generated certificate >>> ipatests/test_xmlrpc/test_cert_plugin.py >>> Since I'm leaving Red Hat in end of July, I won't be able to modify this patch anymore. >>> >>> Regards, >>> >>> Peter >>> >> >> > Hi, > > NACK. Code looks fine and works well on master branch, but patch does > not apply on 4-3 and 4-2 branches. > Peter left the company but claimed he can fix the patch if necessary, > I'll communicate it with him or fix it myself. > > Lenka > > Oh, and forgot this one - PEP8 error: ./ipatests/test_xmlrpc/test_cert_plugin.py:191:80: E501 line too long (105 > 79 characters) Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Fri Jul 29 12:42:25 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 29 Jul 2016 14:42:25 +0200 Subject: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users In-Reply-To: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> References: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> Message-ID: On 07/28/2016 10:56 AM, Martin Babinsky wrote: > Fixes https://fedorahosted.org/freeipa/ticket/6101 > > I have also noticed that the principal aliases are not preserved during > migration from FreeIPA 4.4. > > That, however, requires more powerful runes to transform the realm of > all values and warrants a separate ticket if we even want to support > migration of user aliases. > > > Hi Martin, thanks for your patch. From a technical standpoint, it looks good to me as I tested the following scenarios: 1/ without --user-ignore-attribute - call ipa migrate-ds without specifying any attributes to ignore The user entries are migrated, and contain a migrated krbprincipalname and krbcanonicalname. At this point kinit fails but this is expected as the krb attributes were not re-generated. Login to the web https://hostname/ipa/ui also fails as expected. - login to https://hostname/ipa/migration with the user credentials - perform kinit => OK - login to https://hostname/ipa/ui => OK 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} as explained in the Migration page [1] At this point kinit fails as expected, as well as login to the web ipa/ui. - login to https://hostname/ipa/migration with the user credentials - perform kinit => OK - login to https://hostname/ipa/ui => OK But the patch produces new pep8 complaints: ./ipaserver/plugins/migration.py:39:1: E402 module level import not at top of file Flo. ---- [1] https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA From pvomacka at redhat.com Fri Jul 29 12:54:12 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 29 Jul 2016 14:54:12 +0200 Subject: [Freeipa-devel] [PATCH] webui: Fix coverity bugs Message-ID: <17dedc13-dab5-4ae2-5a7b-d7921458a46f@redhat.com> Hello, please review attached patches which fixes errors from Coverity. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0085-Coverity-null-pointer-exception.patch Type: text/x-patch Size: 1042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0086-Coverity-null-pointer-exception.patch Type: text/x-patch Size: 974 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0087-Coverity-not-initialized-variable.patch Type: text/x-patch Size: 897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0088-Coverity-identical-code-for-different-branches.patch Type: text/x-patch Size: 1456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0089-Coverity-Accesing-attribute-of-null.patch Type: text/x-patch Size: 1135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0090-Coverity-removed-dead-code.patch Type: text/x-patch Size: 1370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0091-Coverity-true-branch-can-t-be-executed.patch Type: text/x-patch Size: 1224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0092-Coverity-true-branch-can-t-be-executed.patch Type: text/x-patch Size: 1125 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0093-Coverity-null-pointer-dereference.patch Type: text/x-patch Size: 1406 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0094-Coverity-iterating-over-variable-which-could-be-null.patch Type: text/x-patch Size: 1409 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0095-Coverity-opens-dialog-which-might-not-be-created.patch Type: text/x-patch Size: 905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0096-Coverity-accessing-attribute-of-variable-which-can-p.patch Type: text/x-patch Size: 1307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0097-Coverity-null-pointer-dereference.patch Type: text/x-patch Size: 1012 bytes Desc: not available URL: From pvomacka at redhat.com Fri Jul 29 13:00:11 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 29 Jul 2016 15:00:11 +0200 Subject: [Freeipa-devel] [PATCH] 0078-82: webui tests: tests for new certificate widget In-Reply-To: <7298654a-0ea9-8f42-dc24-f48f0dabeeb4@redhat.com> References: <3e447bbe-fade-c5e5-2415-15ed7ae0b2ea@redhat.com> <7298654a-0ea9-8f42-dc24-f48f0dabeeb4@redhat.com> Message-ID: On 07/28/2016 08:16 AM, Lenka Doudova wrote: > > > > On 07/20/2016 04:51 PM, Pavel Vomacka wrote: >> Please review attached patches, which add tests for new certificate >> widget in WebUI. >> >> https://fedorahosted.org/freeipa/ticket/6064 >> >> >> > Hi, > thanks for patches. > Functionally ok, but you have lots of PEP8 errors in patches 78, 80, > 81 and 82 -> NACK. > Also in patch 82, method test_arbitrary_certificate, comment says user > needs to have "arbitrary_cert" configured, but the property in config > file is correctly "arbitrary_cert_path", so it's a bit misleading. > > Patch 79 is OK, ACK. > > Lenka > > Thank you for review. Attaching patches which have fixed all pep8 erros. Bad property of config file was also mentioned in patch 81. These are also fixed. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0078-2-Add-possibility-to-choose-parent-element-by-css.patch Type: text/x-patch Size: 3947 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0079-Add-function-which-check-whether-the-field-is-empty.patch Type: text/x-patch Size: 1214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0080-2-TEST-managing-user-certificates.patch Type: text/x-patch Size: 5295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0081-2-TEST-managing-host-certificates.patch Type: text/x-patch Size: 8623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0082-2-TEST-managing-service-certificates.patch Type: text/x-patch Size: 9113 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 29 13:10:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 15:10:46 +0200 Subject: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users In-Reply-To: References: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> Message-ID: <68c315f8-1602-e0a4-5778-b3fd11e37776@redhat.com> On 29.07.2016 14:42, Florence Blanc-Renaud wrote: > On 07/28/2016 10:56 AM, Martin Babinsky wrote: >> Fixes https://fedorahosted.org/freeipa/ticket/6101 >> >> I have also noticed that the principal aliases are not preserved during >> migration from FreeIPA 4.4. >> >> That, however, requires more powerful runes to transform the realm of >> all values and warrants a separate ticket if we even want to support >> migration of user aliases. >> >> >> > Hi Martin, > > thanks for your patch. From a technical standpoint, it looks good to > me as I tested the following scenarios: > > 1/ without --user-ignore-attribute > - call ipa migrate-ds without specifying any attributes to ignore > The user entries are migrated, and contain a migrated krbprincipalname > and krbcanonicalname. > At this point kinit fails but this is expected as the krb attributes > were not re-generated. Login to the web https://hostname/ipa/ui also > fails as expected. > - login to https://hostname/ipa/migration with the user credentials > - perform kinit => OK > - login to https://hostname/ipa/ui => OK > > 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} as > explained in the Migration page [1] > At this point kinit fails as expected, as well as login to the web > ipa/ui. > - login to https://hostname/ipa/migration with the user credentials > - perform kinit => OK > - login to https://hostname/ipa/ui => OK > > > But the patch produces new pep8 complaints: > ./ipaserver/plugins/migration.py:39:1: E402 module level import not at > top of file This is caused by old code, it should not prevent this patch to be acked. Imports are heavily mixed in code already, it is not possible to keep importing right without fixing old ones. Martin^2 > > Flo. > > ---- > [1] > https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA > From simo at redhat.com Fri Jul 29 13:12:16 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 Jul 2016 09:12:16 -0400 Subject: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users In-Reply-To: <68c315f8-1602-e0a4-5778-b3fd11e37776@redhat.com> References: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> <68c315f8-1602-e0a4-5778-b3fd11e37776@redhat.com> Message-ID: <1469797936.3587.70.camel@redhat.com> On Fri, 2016-07-29 at 15:10 +0200, Martin Basti wrote: > > On 29.07.2016 14:42, Florence Blanc-Renaud wrote: > > On 07/28/2016 10:56 AM, Martin Babinsky wrote: > >> Fixes https://fedorahosted.org/freeipa/ticket/6101 > >> > >> I have also noticed that the principal aliases are not preserved during > >> migration from FreeIPA 4.4. > >> > >> That, however, requires more powerful runes to transform the realm of > >> all values and warrants a separate ticket if we even want to support > >> migration of user aliases. > >> > >> > >> > > Hi Martin, > > > > thanks for your patch. From a technical standpoint, it looks good to > > me as I tested the following scenarios: > > > > 1/ without --user-ignore-attribute > > - call ipa migrate-ds without specifying any attributes to ignore > > The user entries are migrated, and contain a migrated krbprincipalname > > and krbcanonicalname. > > At this point kinit fails but this is expected as the krb attributes > > were not re-generated. Login to the web https://hostname/ipa/ui also > > fails as expected. > > - login to https://hostname/ipa/migration with the user credentials > > - perform kinit => OK > > - login to https://hostname/ipa/ui => OK > > > > 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} as > > explained in the Migration page [1] > > At this point kinit fails as expected, as well as login to the web > > ipa/ui. > > - login to https://hostname/ipa/migration with the user credentials > > - perform kinit => OK > > - login to https://hostname/ipa/ui => OK > > > > > > But the patch produces new pep8 complaints: > > ./ipaserver/plugins/migration.py:39:1: E402 module level import not at > > top of file > > This is caused by old code, it should not prevent this patch to be > acked. Imports are heavily mixed in code already, it is not possible to > keep importing right without fixing old ones. > Martin^2 Can we make a patch to fix all import order issues across the code base so we can maintain them properly going forward ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Jul 29 13:19:48 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 15:19:48 +0200 Subject: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users In-Reply-To: <1469797936.3587.70.camel@redhat.com> References: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> <68c315f8-1602-e0a4-5778-b3fd11e37776@redhat.com> <1469797936.3587.70.camel@redhat.com> Message-ID: <5c57ae0f-5caa-7ead-911c-7956baabd287@redhat.com> On 29.07.2016 15:12, Simo Sorce wrote: > On Fri, 2016-07-29 at 15:10 +0200, Martin Basti wrote: >> On 29.07.2016 14:42, Florence Blanc-Renaud wrote: >>> On 07/28/2016 10:56 AM, Martin Babinsky wrote: >>>> Fixes https://fedorahosted.org/freeipa/ticket/6101 >>>> >>>> I have also noticed that the principal aliases are not preserved during >>>> migration from FreeIPA 4.4. >>>> >>>> That, however, requires more powerful runes to transform the realm of >>>> all values and warrants a separate ticket if we even want to support >>>> migration of user aliases. >>>> >>>> >>>> >>> Hi Martin, >>> >>> thanks for your patch. From a technical standpoint, it looks good to >>> me as I tested the following scenarios: >>> >>> 1/ without --user-ignore-attribute >>> - call ipa migrate-ds without specifying any attributes to ignore >>> The user entries are migrated, and contain a migrated krbprincipalname >>> and krbcanonicalname. >>> At this point kinit fails but this is expected as the krb attributes >>> were not re-generated. Login to the web https://hostname/ipa/ui also >>> fails as expected. >>> - login to https://hostname/ipa/migration with the user credentials >>> - perform kinit => OK >>> - login to https://hostname/ipa/ui => OK >>> >>> 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} as >>> explained in the Migration page [1] >>> At this point kinit fails as expected, as well as login to the web >>> ipa/ui. >>> - login to https://hostname/ipa/migration with the user credentials >>> - perform kinit => OK >>> - login to https://hostname/ipa/ui => OK >>> >>> >>> But the patch produces new pep8 complaints: >>> ./ipaserver/plugins/migration.py:39:1: E402 module level import not at >>> top of file >> This is caused by old code, it should not prevent this patch to be >> acked. Imports are heavily mixed in code already, it is not possible to >> keep importing right without fixing old ones. >> Martin^2 > Can we make a patch to fix all import order issues across the code base > so we can maintain them properly going forward ? > > Simo. > Is it worth it? a) it will makes git blame harder, you will have to go always deeper to history with any import b) it makes backporting of patches harder. We fixed unused imports in 4.4, and it was PITA to backport patches, always conflicts, several bugs. Changing all import to correct order will be even worse. However plus is, when we once fix it, we can enable pylint check to keep it right forever. We can open refactoring ticket and we'll see. Martin^2 From simo at redhat.com Fri Jul 29 13:23:21 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 Jul 2016 09:23:21 -0400 Subject: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users In-Reply-To: <5c57ae0f-5caa-7ead-911c-7956baabd287@redhat.com> References: <12385b87-34ee-6cf4-8a8a-f2a7ce4a85e2@redhat.com> <68c315f8-1602-e0a4-5778-b3fd11e37776@redhat.com> <1469797936.3587.70.camel@redhat.com> <5c57ae0f-5caa-7ead-911c-7956baabd287@redhat.com> Message-ID: <1469798601.3587.73.camel@redhat.com> On Fri, 2016-07-29 at 15:19 +0200, Martin Basti wrote: > > On 29.07.2016 15:12, Simo Sorce wrote: > > On Fri, 2016-07-29 at 15:10 +0200, Martin Basti wrote: > >> On 29.07.2016 14:42, Florence Blanc-Renaud wrote: > >>> On 07/28/2016 10:56 AM, Martin Babinsky wrote: > >>>> Fixes https://fedorahosted.org/freeipa/ticket/6101 > >>>> > >>>> I have also noticed that the principal aliases are not preserved during > >>>> migration from FreeIPA 4.4. > >>>> > >>>> That, however, requires more powerful runes to transform the realm of > >>>> all values and warrants a separate ticket if we even want to support > >>>> migration of user aliases. > >>>> > >>>> > >>>> > >>> Hi Martin, > >>> > >>> thanks for your patch. From a technical standpoint, it looks good to > >>> me as I tested the following scenarios: > >>> > >>> 1/ without --user-ignore-attribute > >>> - call ipa migrate-ds without specifying any attributes to ignore > >>> The user entries are migrated, and contain a migrated krbprincipalname > >>> and krbcanonicalname. > >>> At this point kinit fails but this is expected as the krb attributes > >>> were not re-generated. Login to the web https://hostname/ipa/ui also > >>> fails as expected. > >>> - login to https://hostname/ipa/migration with the user credentials > >>> - perform kinit => OK > >>> - login to https://hostname/ipa/ui => OK > >>> > >>> 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} as > >>> explained in the Migration page [1] > >>> At this point kinit fails as expected, as well as login to the web > >>> ipa/ui. > >>> - login to https://hostname/ipa/migration with the user credentials > >>> - perform kinit => OK > >>> - login to https://hostname/ipa/ui => OK > >>> > >>> > >>> But the patch produces new pep8 complaints: > >>> ./ipaserver/plugins/migration.py:39:1: E402 module level import not at > >>> top of file > >> This is caused by old code, it should not prevent this patch to be > >> acked. Imports are heavily mixed in code already, it is not possible to > >> keep importing right without fixing old ones. > >> Martin^2 > > Can we make a patch to fix all import order issues across the code base > > so we can maintain them properly going forward ? > > > > Simo. > > > > Is it worth it? > > a) it will makes git blame harder, you will have to go always deeper to > history with any import I considered this, but I rarely found that imports were such a big issue, usually it's code in the file that is, so IMO the trade-off is worth it. > b) it makes backporting of patches harder. We fixed unused imports in > 4.4, and it was PITA to backport patches, always conflicts, several > bugs. Changing all import to correct order will be even worse. Sure backports will be somewhat harder, but I wouldn't say it is a nightmare, it is not code logic that changes, it is just individual import lines. > However plus is, when we once fix it, we can enable pylint check to keep > it right forever. Exactly, this is the appealing point, we get it right once and then the tool keeps us honest going forward. > We can open refactoring ticket and we'll see. Please do. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Fri Jul 29 13:25:34 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Jul 2016 16:25:34 +0300 Subject: [Freeipa-devel] [PATCH] webui: Fix coverity bugs In-Reply-To: <17dedc13-dab5-4ae2-5a7b-d7921458a46f@redhat.com> References: <17dedc13-dab5-4ae2-5a7b-d7921458a46f@redhat.com> Message-ID: <20160729132534.sdsdlda5c2gtvqj6@redhat.com> On Fri, 29 Jul 2016, Pavel Vomacka wrote: >Hello, > >please review attached patches which fixes errors from Coverity. > >-- >Pavel^3 Vomacka > >From 0391289b3f6844897e2a9f3ae549bd4c33233ffc Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 10:36:47 +0200 >Subject: [PATCH 01/13] Coverity - null pointer exception > >Variable 'option' can be null and there will be error of reading property of null. >--- > install/ui/src/freeipa/widget.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js >index 9151ebac9438e9e674f81bfb1ccfe7a63872b1ae..cfdf5d4750951e4549c16a2b9b9c355f61e90c39 100644 >--- a/install/ui/src/freeipa/widget.js >+++ b/install/ui/src/freeipa/widget.js >@@ -2249,7 +2249,7 @@ IPA.option_widget_base = function(spec, that) { > var child_values = []; > var option = that.get_option(value); > >- if (option.widget) { >+ if (option && option.widget) { > child_values = option.widget.save(); > values.push.apply(values, child_values); > } >-- >2.5.5 > ACK >From 6df8e608232e25daa9aefe4fccbdeca4dbaf1998 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 10:43:00 +0200 >Subject: [PATCH 02/13] Coverity - null pointer exception > >Variable 'row' could be null in some cases. And set css to variable which is pointing to null >causes error. Therefore there is new check. >--- > install/ui/src/freeipa/widget.js | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js >index cfdf5d4750951e4549c16a2b9b9c355f61e90c39..5844436abf090f12d5a9d65efe7a1aaee14097e2 100644 >--- a/install/ui/src/freeipa/widget.js >+++ b/install/ui/src/freeipa/widget.js >@@ -5766,6 +5766,8 @@ exp.fluid_layout = IPA.fluid_layout = function(spec) { > that.on_visible_change = function(event) { > > var row = that._get_row(event); >+ if (!row) return; >+ > if (event.visible) { > row.css('display', ''); > } else { >-- >2.5.5 > ACK >From 6f2ddc9e1c5323a640bdf744d2da00bfee7ab766 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 13:48:16 +0200 >Subject: [PATCH 03/13] Coverity - not initialized variable > >The variable hasn't been initialized, now it is set to null by default. >--- > install/ui/src/freeipa/widget.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js >index 5844436abf090f12d5a9d65efe7a1aaee14097e2..43804c5ea524ca741017d02f6e12ccf60d50b5df 100644 >--- a/install/ui/src/freeipa/widget.js >+++ b/install/ui/src/freeipa/widget.js >@@ -1047,7 +1047,7 @@ IPA.multivalued_widget = function(spec) { > > that.child_spec = spec.child_spec; > that.size = spec.size || 30; >- that.undo_control; >+ that.undo_control = null; > that.initialized = true; > that.updating = false; > >-- >2.5.5 > ACK >From b9ddd32ec45aadae5a79e372c3e1b70990071e60 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 14:42:50 +0200 >Subject: [PATCH 04/13] Coverity - identical code for different branches > >In both cases when the condition is true or false ut is set the same value. >Changed to assign the value directly. >--- > install/ui/src/freeipa/topology_graph.js | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/install/ui/src/freeipa/topology_graph.js b/install/ui/src/freeipa/topology_graph.js >index ce2ebeaff611987ae27f2655b5da80bdcd1b4f8a..712d38fbe67e87ffa773e0a3a1f8937e9595c9a6 100644 >--- a/install/ui/src/freeipa/topology_graph.js >+++ b/install/ui/src/freeipa/topology_graph.js >@@ -325,8 +325,8 @@ topology_graph.TopoGraph = declare([Evented], { > off = dir ? -1 : 1, // determines shift direction of curve > ns = 5, // shift on normal vector > s = target_count > 1 ? 1 : 0, // shift from center? >- spad = d.left ? 18 : 18, // source padding >- tpad = d.right ? 18 : 18, // target padding >+ spad = d.left = 18, // source padding >+ tpad = d.right = 18, // target padding > sourceX = d.source.x + (spad * ux) + off * nx * ns * s, > sourceY = d.source.y + (spad * uy) + off * ny * ns * s, > targetX = d.target.x - (tpad * ux) + off * nx * ns * s, >-- >2.5.5 > ACK >From f1f2b55247d6c7f41f8053f372a47945c93fc8a4 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 14:52:15 +0200 >Subject: [PATCH 05/13] Coverity - Accesing attribute of null > >There is a possibility that widget is null and then there could be an error. >Therefore there is new check of widget variable. >--- > install/ui/src/freeipa/widgets/APIBrowserWidget.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >index 1a3726190d4a5d628a8f7c2b564c4c9f6e7cea1f..50c2989fcc126585787df61cdd19493632ed37b9 100644 >--- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >+++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >@@ -252,7 +252,7 @@ widgets.APIBrowserWidget = declare([Stateful, Evented], { > } > > // switch widget >- if (!widget.el) widget.render(); >+ if (widget && !widget.el) widget.render(); > if (this.current_details_w !== widget) { > this.details_el.empty(); > this.details_el.append(widget.el); >-- >2.5.5 > ACK >From 1476b5ed3ab5c4ec55f3ed20ad07a5b88cfd45f2 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 16:47:22 +0200 >Subject: [PATCH 06/13] Coverity - removed dead code > >There cannot be string value because of previous checks. >--- > install/ui/src/freeipa/dns.js | 12 ++++-------- > 1 file changed, 4 insertions(+), 8 deletions(-) > >diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js >index 2d424aeae8ef735d02426a0f08b6261ec2f04c19..822c0b3cedb3988563c0a1f83862f56e95eed21b 100644 >--- a/install/ui/src/freeipa/dns.js >+++ b/install/ui/src/freeipa/dns.js >@@ -1509,14 +1509,10 @@ IPA.dns.record_prepare_editor_for_type = function(type, fields, widgets, update) > > //create editor widget > var widget = {}; >- if (typeof attribute === 'string') { >- widget.name = attribute; >- } else { >- widget.name = attribute.name; >- set_defined(attribute.$type, widget, '$type'); >- set_defined(attribute.options, widget, 'options'); >- copy_obj(widget, attribute.widget_opt); >- } >+ widget.name = attribute.name; >+ set_defined(attribute.$type, widget, '$type'); >+ set_defined(attribute.options, widget, 'options'); >+ copy_obj(widget, attribute.widget_opt); > section.widgets.push(widget); > } > }; >-- >2.5.5 > ACK >From b1dd66f3b08889b51430d9176035366cb055324e Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 17:44:56 +0200 >Subject: [PATCH 07/13] Coverity - true branch can't be executed > >The 'data' variable is always false because of previous condition. >Therefore there is direct assignment. >--- > install/ui/src/freeipa/rpc.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/ui/src/freeipa/rpc.js b/install/ui/src/freeipa/rpc.js >index a185585f4176658e299e7e92434522c936cc36b4..88aaf6ede72ea69495c369dd74c657d0419a3605 100644 >--- a/install/ui/src/freeipa/rpc.js >+++ b/install/ui/src/freeipa/rpc.js >@@ -372,7 +372,7 @@ rpc.command = function(spec) { > error_handler.call(this, xhr, text_status, /* error_thrown */ { > name: text.get('@i18n:errors.http_error', 'HTTP Error')+' '+xhr.status, > url: this.url, >- message: data ? xhr.statusText : text.get('@i18n:errors.no_response', 'No response') >+ message: text.get('@i18n:errors.no_response', 'No response') > }); > > } else if (IPA.version && data.version && IPA.version !== data.version) { >-- >2.5.5 > ACK >From 463f24936469d87890b666dfd7edabbe90541491 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 17:49:50 +0200 >Subject: [PATCH 08/13] Coverity - true branch can't be executed > >The 'result' variable is always false because of previous condition. >Therefore there is direct assignment. >--- > install/ui/src/freeipa/rpc.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/ui/src/freeipa/rpc.js b/install/ui/src/freeipa/rpc.js >index 88aaf6ede72ea69495c369dd74c657d0419a3605..30a5366787974b2d127114f7683d0589ed332f5a 100644 >--- a/install/ui/src/freeipa/rpc.js >+++ b/install/ui/src/freeipa/rpc.js >@@ -628,7 +628,7 @@ rpc.batch_command = function(spec) { > > if (!result) { > name = text.get('@i18n:errors.internal_error', 'Internal Error')+' '+xhr.status; >- message = result ? xhr.statusText : text.get('@i18n:errors.internal_error', 'Internal Error'); >+ message = text.get('@i18n:errors.internal_error', 'Internal Error'); > > that.errors.add(command, name, message, text_status); > >-- >2.5.5 > ACK >From c0ba1c141b6191e2a7ef33bc9eaaad5c970f9d0e Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Mon, 25 Jul 2016 18:25:36 +0200 >Subject: [PATCH 09/13] Coverity - null pointer dereference > >The 'obj' variable could be null, so there could be error when it is used. >A new check that 'obj' is not false is added. >--- > install/ui/src/freeipa/widgets/browser_widgets.js | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > >diff --git a/install/ui/src/freeipa/widgets/browser_widgets.js b/install/ui/src/freeipa/widgets/browser_widgets.js >index 57ad2bd984ea35f03b302b59fc1d014def162bd8..91bb850a638fd6f16f207b1111d126fbb4fe2dd8 100644 >--- a/install/ui/src/freeipa/widgets/browser_widgets.js >+++ b/install/ui/src/freeipa/widgets/browser_widgets.js >@@ -427,11 +427,11 @@ widgets.browser_widgets.CommandDetailWidget = declare([base], { > if (i>0) { > out_params_cnt.append(', '); > } >- if (!param) { >- out_params_cnt.append(param_name); >- } else { >+ if (param && obj) { > var link = this.render_param_link(obj.name, param_name); > out_params_cnt.append(link); >+ } else { >+ out_params_cnt.append(param_name); > } > } > out_params_cnt.appendTo(this.el); >-- >2.5.5 > ACK >From a9f7ecf5833db379fe9731184aa4f7aef8845995 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Tue, 26 Jul 2016 09:48:32 +0200 >Subject: [PATCH 10/13] Coverity - iterating over variable which could be null > >Change condition to check also variable which could be null. >--- > install/ui/src/freeipa/widgets/APIBrowserWidget.js | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > >diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >index 50c2989fcc126585787df61cdd19493632ed37b9..18773536d3587cdeb9e5fecedcc5e42c05bfe120 100644 >--- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >+++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >@@ -135,7 +135,7 @@ widgets.APIBrowserWidget = declare([Stateful, Evented], { > groups = this._get_params(parts[0]); > } > >- if (filter) { >+ if (filter && groups) { > filter = filter.toLowerCase(); > var new_groups = []; > for (var i=0,l=groups.length; i@@ -153,10 +153,10 @@ widgets.APIBrowserWidget = declare([Stateful, Evented], { > new_groups.push(groups[i]); > } > } >- return new_groups; >- } else { >- return groups; >+ groups = new_groups; > } >+ >+ return groups; > }, > > /** >-- >2.5.5 > ACK >From 3d63ca1d5cb7a7b84cf20c26d4b1ea5b657c44c4 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Tue, 26 Jul 2016 12:03:28 +0200 >Subject: [PATCH 11/13] Coverity - opens dialog which might not be created > >Check whether dialog object is created before opening it. >--- > install/ui/src/freeipa/search.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/ui/src/freeipa/search.js b/install/ui/src/freeipa/search.js >index 25f21e70db170daf0d45a6862ee9adb528ad03bc..fee1bc7523d6afdb3e2b23db2833a415febb85ec 100644 >--- a/install/ui/src/freeipa/search.js >+++ b/install/ui/src/freeipa/search.js >@@ -221,7 +221,7 @@ IPA.search_facet = function(spec, no_init) { > that.show_remove_dialog = function() { > > var dialog = that.create_remove_dialog(); >- dialog.open(); >+ if (dialog) dialog.open(); > }; > > that.find = function() { >-- >2.5.5 > ACK >From 7819293fc546de31cc5eea246242742af3be094e Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Tue, 26 Jul 2016 13:07:30 +0200 >Subject: [PATCH 12/13] Coverity - accessing attribute of variable which can > point to null > >Added check whether variable is pointing to null or not. >--- > install/ui/src/freeipa/widget.js | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js >index 43804c5ea524ca741017d02f6e12ccf60d50b5df..1f61ce7341b1b8e13d4df5acea1f8901a63a290a 100644 >--- a/install/ui/src/freeipa/widget.js >+++ b/install/ui/src/freeipa/widget.js >@@ -4938,7 +4938,7 @@ IPA.combobox_widget = function(spec) { > var value = that.list.val(); > var option = $('option[value="'+value+'"]', that.list); > var next = option.next(); >- if (!next.length) return; >+ if (!next || !next.length) return; > that.select(next.val()); > }; > >@@ -4946,7 +4946,7 @@ IPA.combobox_widget = function(spec) { > var value = that.list.val(); > var option = $('option[value="'+value+'"]', that.list); > var prev = option.prev(); >- if (!prev.length) return; >+ if (!prev || !prev.length) return; > that.select(prev.val()); > }; > >-- >2.5.5 > ACK >From 3ba5110fa8b2255b83fa3e7a4135ec33b85a7fd8 Mon Sep 17 00:00:00 2001 >From: Pavel Vomacka >Date: Fri, 29 Jul 2016 10:13:21 +0200 >Subject: [PATCH 13/13] Coverity - null pointer dereference > >Add check which protect from calling method of null. >--- > install/ui/src/freeipa/widgets/APIBrowserWidget.js | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/ui/src/freeipa/widgets/APIBrowserWidget.js b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >index 18773536d3587cdeb9e5fecedcc5e42c05bfe120..2164df2f5ffa00edf9ac41fd4cf6254f6d4eb9a3 100644 >--- a/install/ui/src/freeipa/widgets/APIBrowserWidget.js >+++ b/install/ui/src/freeipa/widgets/APIBrowserWidget.js >@@ -264,7 +264,7 @@ widgets.APIBrowserWidget = declare([Stateful, Evented], { > this.list_w.select(item); > > // set item >- widget.set('item', item); >+ if (widget) widget.set('item', item); > this.set('current', { > item: item, > type: type, >-- >2.5.5 > ACK -- / Alexander Bokovoy From pspacek at redhat.com Fri Jul 29 13:39:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 29 Jul 2016 15:39:06 +0200 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> Message-ID: <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> On 27.7.2016 19:06, Ben Lipton wrote: > Hi all, > > I think the automatic CSR generation feature > (https://fedorahosted.org/freeipa/ticket/4899, > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) is > stable enough to review now. The following are summaries of the attached patches: > 0004: LDAP schema changes for the new feature > 0005: Basic API for new objects and CSR generation > 0006: Update install automation to create some default mapping rules > 0007: Implement the lookups and text processing that generates the CSR config > 0008 and 0009: Implement some actual transformation rules so that the feature > is usable > 0010: Add a new cert profile for user certs, with mappings > 0011: Implement import/export of cert profiles with mappings > 0012: Tests for profile import/export > > Generally speaking, later patches depend on earlier ones, but I don't > anticipate any problems from committing earlier patches without later ones. > > If you prefer, you can also comment on the pull request version: > https://github.com/LiptonB/freeipa/pull/4. Note that I may force push on this > branch. > > Allocation of OIDs for schema change also needs review: > https://code.engineering.redhat.com/gerrit/#/c/80061/ > > Known issues: > - When the requested principal does not have some of the requested data, > produces funny-looking configs with extra commas, empty sections, etc. They > are still accepted by my copies of openssl and certutil, but they look ugly. > - The new objects don't have any ACIs, so for the moment only admin can run > the new commands. > - Does not yet have support for prompting user for field values, so currently > all data must come from the database. > - All processing happens on the server side. As discussed in a previous > thread, it would be desirable to break this out into a library so it could be > used client-side. > > Very excited to hear your thoughts! Hi Ben, I wanted to give it a try from user's point of view first, before diving into implementation details. Here are some observations: 0. Design pages are using term "helper" and it is used even as option in the example with smartcards. Please fix either design page or the code so they are consistent. 1. The "ipa cert-request" command is missing options --autofill and --use (aka helper aka format :-) which are mentioned in the design pages. 2. "ipa cert_get_requestdata" command passes even without --profile-id and generates empty config. I think that this is not expected :-) 3. "ipa cert_get_requestdata --format=openssl" prints the text to stdout including label "Configuration file contents:". This is hard to use because simple redirection like "ipa cert_get_requestdata --format=openssl > config" will not give you valid OpenSSL config file - it needs hand-editing. It would be good to add --out parameter you envisioned in the design page. Please ask jcholast for proper name and semantics :-) With --out option the command can be used to generate valid config (or script if certutil was selected). 4. "ipa cert_get_requestdata --format=openssl" could print hint what OpenSSL command should be executed on the generated config file. For testing I've used command "openssl req -new -out csr -text -config config" (stolen and modified from smart card example). Also, as a second hint, it could print the IPA command which needs to be used to sign the CSR generated by the helper. 5. My naive attempt to get userCert for admin failed: $ ipa cert_get_requestdata --format=openssl --principal=admin --profile-id=userCert > usercert.conf # remove the trailing label $ openssl req -new -out csr -text -config usercert.conf $ ipa cert-request --principal=admin --profile-id=userCert usercert.csr ipa: ERROR: invalid 'csr': No Common Name was found in subject of request. I'm attaching files generated by the commands above. I did not modify anything in the templates or profiles, just tried to use the new profile added by freeipa-blipton-0010-Add-a-new-cert-profile-for-users.patch . Hopefully I will get to other things soon (but not this week). Anyway, all this seems like (expected) initial problems. In general the first touch with user interface seems reasonable and needs only small improvements. Good work! -- Petr^2 Spacek -------------- next part -------------- [ req ] prompt = no encrypt_key = no distinguished_name = sec0 [ sec0 ] O=DOM-058-082.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM UID=admin -------------- next part -------------- A non-text attachment was scrubbed... Name: usercert.csr Type: application/pkcs10 Size: 3435 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 29 14:50:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 16:50:39 +0200 Subject: [Freeipa-devel] [PATCH 0558] idrange: fix unassigned global variable Message-ID: <2b941eef-8d6e-b9e0-4e3c-93a4ee300005@redhat.com> https://fedorahosted.org/freeipa/ticket/6082 patch attached Traceback (most recent call last): File "/usr/libexec/ipa/oddjob/com.redhat.idm.trust-fetch-domains", line 174, in trust.add_new_domains_from_trust(api, None, trust_domain_object, domains) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 1684, in add_new_domains_from_trust trust_name, name, **dom) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", line 435, in add_range ipanttrusteddomainsid=dom_sid) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__ return self.__do_call(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in __do_call ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run return self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line 1181, in execute *keys, **options) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line 465, in pre_callback entry_attrs['ipanttrusteddomainsid']) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line 338, in validate_trusted_domain_sid domain_validator = self.get_domain_validator() File "/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line 322, in get_domain_validator if not _dcerpc_bindings_installed: NameError: global name '_dcerpc_bindings_installed' is not defined -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0558-idrange-fix-unassigned-global-variable.patch Type: text/x-patch Size: 1030 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 29 14:54:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 16:54:45 +0200 Subject: [Freeipa-devel] [PATCH 0559] Increase default length of auto-generated passwords Message-ID: https://fedorahosted.org/freeipa/ticket/6116 Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0559-Increase-default-length-of-auto-generated-passwords.patch Type: text/x-patch Size: 4443 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 29 14:56:30 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 16:56:30 +0200 Subject: [Freeipa-devel] [PATCH 0560] ipa-client-automount: don not initialize API during uninstall Message-ID: https://fedorahosted.org/freeipa/ticket/6072 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0560-Do-not-initialize-API-in-ipa-client-automount-uninst.patch Type: text/x-patch Size: 1291 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jul 29 15:07:00 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Jul 2016 18:07:00 +0300 Subject: [Freeipa-devel] [PATCH 0558] idrange: fix unassigned global variable In-Reply-To: <2b941eef-8d6e-b9e0-4e3c-93a4ee300005@redhat.com> References: <2b941eef-8d6e-b9e0-4e3c-93a4ee300005@redhat.com> Message-ID: <20160729150700.o5mrfngtycwc66vz@redhat.com> On Fri, 29 Jul 2016, Martin Basti wrote: >https://fedorahosted.org/freeipa/ticket/6082 > >patch attached > > >Traceback (most recent call last): > File "/usr/libexec/ipa/oddjob/com.redhat.idm.trust-fetch-domains", >line 174, in > trust.add_new_domains_from_trust(api, None, trust_domain_object, >domains) > File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", >line 1684, in add_new_domains_from_trust > trust_name, name, **dom) > File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", >line 435, in add_range > ipanttrusteddomainsid=dom_sid) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >447, in __call__ > return self.__do_call(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >475, in __do_call > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >797, in run > return self.execute(*args, **options) > File >"/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line >1181, in execute > *keys, **options) > File >"/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line >465, in pre_callback > entry_attrs['ipanttrusteddomainsid']) > File >"/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line >338, in validate_trusted_domain_sid > domain_validator = self.get_domain_validator() > File >"/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line >322, in get_domain_validator > if not _dcerpc_bindings_installed: >NameError: global name '_dcerpc_bindings_installed' is not defined > >From 0e0c860f8b555fb5fef7d13a7e3f9d3f361363c4 Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Fri, 29 Jul 2016 16:46:09 +0200 >Subject: [PATCH] idrange: fix unassigned global variable > >Global variable '_dcerpc_bindings_installed' is in some cases used >before assigment. This patch ensures that _dcerpc_bindings_installed is >always initialized. > >https://fedorahosted.org/freeipa/ticket/6082 >--- > ipaserver/plugins/idrange.py | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/ipaserver/plugins/idrange.py b/ipaserver/plugins/idrange.py >index ccd67995e5b42634387e1064e7c819b711f3ef99..3e9db0b6b734513547423901a8b3212b3cee9147 100644 >--- a/ipaserver/plugins/idrange.py >+++ b/ipaserver/plugins/idrange.py >@@ -35,6 +35,9 @@ if api.env.in_server and api.env.context in ['lite', 'server']: > _dcerpc_bindings_installed = True > except ImportError: > _dcerpc_bindings_installed = False >+else: >+ _dcerpc_bindings_installed = False >+ > > ID_RANGE_VS_DNA_WARNING = """======= > WARNING: >-- >2.5.5 > ACK. I was intending to look at this but you got there faster. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jul 29 15:09:57 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Jul 2016 18:09:57 +0300 Subject: [Freeipa-devel] [PATCH 0559] Increase default length of auto-generated passwords In-Reply-To: References: Message-ID: <20160729150957.d5cfwp6xbleir5nt@redhat.com> On Fri, 29 Jul 2016, Martin Basti wrote: >https://fedorahosted.org/freeipa/ticket/6116 > > >Patch attached > >From ca5305e032137b7c9197d0c1050191079a72124e Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Fri, 22 Jul 2016 16:41:29 +0200 >Subject: [PATCH] Increase default length of auto generated passwords > >Installer/IPA generates passwords for warious purpose: >* KRA >* kerberos master key >* NSSDB password >* temporary passwords during installation > >Length of passwords should be increased to 22, ~128bits of entropy, to >be safe nowadays. > >https://fedorahosted.org/freeipa/ticket/6116 ACK with a minor comment. >--- > ipapython/ipautil.py | 2 +- > ipaserver/plugins/baseuser.py | 3 ++- > ipaserver/plugins/host.py | 3 ++- > ipaserver/plugins/stageuser.py | 3 ++- > ipaserver/plugins/user.py | 3 ++- > 5 files changed, 9 insertions(+), 5 deletions(-) > >diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py >index 9964fba4f694b57242b3bd3065a418917d977533..ca7e81d666cd6c345bdbbf4660c3451ac1f2c045 100644 >--- a/ipapython/ipautil.py >+++ b/ipapython/ipautil.py >@@ -57,7 +57,7 @@ from ipapython.dn import DN > SHARE_DIR = paths.USR_SHARE_IPA_DIR > PLUGINS_SHARE_DIR = paths.IPA_PLUGINS > >-GEN_PWD_LEN = 12 >+GEN_PWD_LEN = 22 It would be good to add a temporary password constant too +GEN_TMP_PWD_LEN = 12 and then use it instead of pwd_len=12 below. > # Having this in krb_utils would cause circular import > KRB5_KDC_UNREACH = 2529639068 # Cannot contact any KDC for requested realm >diff --git a/ipaserver/plugins/baseuser.py b/ipaserver/plugins/baseuser.py >index e4288a5a131157815ffb2452692a7edb342f6ac3..5e0752c8d3d246fa7c283f05b82ef01de2e5bf34 100644 >--- a/ipaserver/plugins/baseuser.py >+++ b/ipaserver/plugins/baseuser.py >@@ -552,7 +552,8 @@ class baseuser_mod(LDAPUpdate): > > def check_userpassword(self, entry_attrs, **options): > if 'userpassword' not in entry_attrs and options.get('random'): >- entry_attrs['userpassword'] = ipa_generate_password(baseuser_pwdchars) >+ entry_attrs['userpassword'] = ipa_generate_password( >+ baseuser_pwdchars, pwd_len=12) > # save the password so it can be displayed in post_callback > setattr(context, 'randompassword', entry_attrs['userpassword']) > >diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py >index 413dcf15e0423170d8334902b9dcf8fb5aa14de6..1cefb6224e1a6dad0080369edee35c4524e5bd39 100644 >--- a/ipaserver/plugins/host.py >+++ b/ipaserver/plugins/host.py >@@ -683,7 +683,8 @@ class host_add(LDAPCreate): > if 'krbprincipal' in entry_attrs['objectclass']: > entry_attrs['objectclass'].remove('krbprincipal') > if options.get('random'): >- entry_attrs['userpassword'] = ipa_generate_password(characters=host_pwd_chars) >+ entry_attrs['userpassword'] = ipa_generate_password( >+ characters=host_pwd_chars, pwd_len=12) > # save the password so it can be displayed in post_callback > setattr(context, 'randompassword', entry_attrs['userpassword']) > certs = options.get('usercertificate', []) >diff --git a/ipaserver/plugins/stageuser.py b/ipaserver/plugins/stageuser.py >index 3b9388f6020b9a6c40caedd36f3640a05a13da65..6df189c3913171b4990ce115b296b19c7447592d 100644 >--- a/ipaserver/plugins/stageuser.py >+++ b/ipaserver/plugins/stageuser.py >@@ -339,7 +339,8 @@ class stageuser_add(baseuser_add): > > # If requested, generate a userpassword > if 'userpassword' not in entry_attrs and options.get('random'): >- entry_attrs['userpassword'] = ipa_generate_password(baseuser_pwdchars) >+ entry_attrs['userpassword'] = ipa_generate_password( >+ baseuser_pwdchars, pwd_len=12) > # save the password so it can be displayed in post_callback > setattr(context, 'randompassword', entry_attrs['userpassword']) > >diff --git a/ipaserver/plugins/user.py b/ipaserver/plugins/user.py >index b3ae7646fdcfa1dce10d90063dae2a24c091e8ee..62ec529062c7ac39661df2a8c3d2277711268b11 100644 >--- a/ipaserver/plugins/user.py >+++ b/ipaserver/plugins/user.py >@@ -517,7 +517,8 @@ class user_add(baseuser_add): > entry_attrs['gidnumber'] = group_attrs['gidnumber'] > > if 'userpassword' not in entry_attrs and options.get('random'): >- entry_attrs['userpassword'] = ipa_generate_password(baseuser_pwdchars) >+ entry_attrs['userpassword'] = ipa_generate_password( >+ baseuser_pwdchars, pwd_len=12) > # save the password so it can be displayed in post_callback > setattr(context, 'randompassword', entry_attrs['userpassword']) > >-- >2.5.5 > >-- >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 -- / Alexander Bokovoy From rcritten at redhat.com Fri Jul 29 15:10:28 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 29 Jul 2016 11:10:28 -0400 Subject: [Freeipa-devel] certmonger EST RFC7030 support possible ? In-Reply-To: <2C720BBFE8885346B9A4377911BABE7886886511@MUCS72046.corp.knorr-bremse.com> References: <2C720BBFE8885346B9A4377911BABE7886886511@MUCS72046.corp.knorr-bremse.com> Message-ID: <579B71E4.8080607@redhat.com> Marx, Peter wrote: > Hi, > > we are using certmonger with SCEP. But SCEP does not support Elliptic > curve keys, only RSA. > > The successor protocol EST (Enrollment over Secure Transport) would > support ECC. > > Is a EST helper for certmonger/getcert on the roadmap ? No. I added a ticket to track it, https://fedorahosted.org/certmonger/ticket/53 > If yes, when ? > > How complicated is it to create such a helper around the Cisco > open-sourced libest ? Hard to say without digging into the library. The library was open-sourced less than 3 weeks ago AFAICT. Practically this also means someone will need to package it for the various Linux distributions. rob From mbasti at redhat.com Fri Jul 29 15:12:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 17:12:02 +0200 Subject: [Freeipa-devel] [PATCH 0558] idrange: fix unassigned global variable In-Reply-To: <20160729150700.o5mrfngtycwc66vz@redhat.com> References: <2b941eef-8d6e-b9e0-4e3c-93a4ee300005@redhat.com> <20160729150700.o5mrfngtycwc66vz@redhat.com> Message-ID: On 29.07.2016 17:07, Alexander Bokovoy wrote: > On Fri, 29 Jul 2016, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6082 >> >> patch attached >> >> >> Traceback (most recent call last): >> File "/usr/libexec/ipa/oddjob/com.redhat.idm.trust-fetch-domains", >> line 174, in >> trust.add_new_domains_from_trust(api, None, trust_domain_object, >> domains) >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", >> line 1684, in add_new_domains_from_trust >> trust_name, name, **dom) >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/trust.py", >> line 435, in add_range >> ipanttrusteddomainsid=dom_sid) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >> 447, in __call__ >> return self.__do_call(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >> 475, in __do_call >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >> 797, in run >> return self.execute(*args, **options) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", >> line 1181, in execute >> *keys, **options) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line >> 465, in pre_callback >> entry_attrs['ipanttrusteddomainsid']) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line >> 338, in validate_trusted_domain_sid >> domain_validator = self.get_domain_validator() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idrange.py", line >> 322, in get_domain_validator >> if not _dcerpc_bindings_installed: >> NameError: global name '_dcerpc_bindings_installed' is not defined >> > >> From 0e0c860f8b555fb5fef7d13a7e3f9d3f361363c4 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Fri, 29 Jul 2016 16:46:09 +0200 >> Subject: [PATCH] idrange: fix unassigned global variable >> >> Global variable '_dcerpc_bindings_installed' is in some cases used >> before assigment. This patch ensures that _dcerpc_bindings_installed is >> always initialized. >> >> https://fedorahosted.org/freeipa/ticket/6082 >> --- >> ipaserver/plugins/idrange.py | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/ipaserver/plugins/idrange.py b/ipaserver/plugins/idrange.py >> index >> ccd67995e5b42634387e1064e7c819b711f3ef99..3e9db0b6b734513547423901a8b3212b3cee9147 >> 100644 >> --- a/ipaserver/plugins/idrange.py >> +++ b/ipaserver/plugins/idrange.py >> @@ -35,6 +35,9 @@ if api.env.in_server and api.env.context in >> ['lite', 'server']: >> _dcerpc_bindings_installed = True >> except ImportError: >> _dcerpc_bindings_installed = False >> +else: >> + _dcerpc_bindings_installed = False >> + >> >> ID_RANGE_VS_DNA_WARNING = """======= >> WARNING: >> -- >> 2.5.5 >> > ACK. I was intending to look at this but you got there faster. > Pushed to master: c2edfa0adbc1a603a146aa44d73a4024e06063f0 From blipton at redhat.com Fri Jul 29 15:13:16 2016 From: blipton at redhat.com (Ben Lipton) Date: Fri, 29 Jul 2016 11:13:16 -0400 Subject: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation In-Reply-To: <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> References: <932c3549-772a-cb8a-aa55-5c3a310121d6@redhat.com> <9fd67263-2de4-cd25-36cb-c2d5afe31d20@redhat.com> Message-ID: <968f040a-89bb-6186-9f1c-d50e8b899eed@redhat.com> On 07/29/2016 09:39 AM, Petr Spacek wrote: > On 27.7.2016 19:06, Ben Lipton wrote: >> Hi all, >> >> I think the automatic CSR generation feature >> (https://fedorahosted.org/freeipa/ticket/4899, >> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation) is >> stable enough to review now. The following are summaries of the attached patches: >> 0004: LDAP schema changes for the new feature >> 0005: Basic API for new objects and CSR generation >> 0006: Update install automation to create some default mapping rules >> 0007: Implement the lookups and text processing that generates the CSR config >> 0008 and 0009: Implement some actual transformation rules so that the feature >> is usable >> 0010: Add a new cert profile for user certs, with mappings >> 0011: Implement import/export of cert profiles with mappings >> 0012: Tests for profile import/export >> >> Generally speaking, later patches depend on earlier ones, but I don't >> anticipate any problems from committing earlier patches without later ones. >> >> If you prefer, you can also comment on the pull request version: >> https://github.com/LiptonB/freeipa/pull/4. Note that I may force push on this >> branch. >> >> Allocation of OIDs for schema change also needs review: >> https://code.engineering.redhat.com/gerrit/#/c/80061/ >> >> Known issues: >> - When the requested principal does not have some of the requested data, >> produces funny-looking configs with extra commas, empty sections, etc. They >> are still accepted by my copies of openssl and certutil, but they look ugly. >> - The new objects don't have any ACIs, so for the moment only admin can run >> the new commands. >> - Does not yet have support for prompting user for field values, so currently >> all data must come from the database. >> - All processing happens on the server side. As discussed in a previous >> thread, it would be desirable to break this out into a library so it could be >> used client-side. >> >> Very excited to hear your thoughts! > Hi Ben, > > I wanted to give it a try from user's point of view first, before diving into > implementation details. Here are some observations: Thanks for giving it a try! This is great feedback. > > 0. Design pages are using term "helper" and it is used even as option in the > example with smartcards. Please fix either design page or the code so they are > consistent. Good point. In a previous discussion, Alexander remarked that --helper sounded too low-level, but I find that --use sounds very generic and --format doesn't make a lot of sense for ipa cert-request, which never actually gives you the config that's generated. So if they're all going to be the same word, which is probably a good idea, I might be leaning towards --helper, but I'm interested to hear opinions on this. > > 1. The "ipa cert-request" command is missing options --autofill and --use (aka > helper aka format :-) which are mentioned in the design pages. Yeah, I haven't managed to implement much of the UI niceness suggested by the design page. I probably should have mentioned that in the email - all that I expect to be working at this point is 'ipa cert-get-requestdata' and CRUD for the mapping rules/profiles themselves. > > 2. "ipa cert_get_requestdata" command passes even without --profile-id and > generates empty config. I think that this is not expected :-) More expected than you might think :) I'm guessing what's happening is that you're passing a user principal and it's defaulting to the caIPAserviceCert profile, then failing to fill out any of the fields because the data it needs is not there. I agree this isn't great. I was planning to address this by having it throw an error if it can't generate at least the subject of the request, and maybe suggest using a different profile. I chose to have it default to caIPAserviceCert because that's what ipa cert-request does, but maybe that's not as predictable as I thought. > > 3. "ipa cert_get_requestdata --format=openssl" prints the text to stdout > including label "Configuration file contents:". This is hard to use because > simple redirection like "ipa cert_get_requestdata --format=openssl > config" > will not give you valid OpenSSL config file - it needs hand-editing. > > It would be good to add --out parameter you envisioned in the design page. > Please ask jcholast for proper name and semantics :-) With --out option the > command can be used to generate valid config (or script if certutil was selected). Agreed. Another example of the UI not being quite right yet. I've been unsure how to handle this, because of certutil taking a command line and openssl a config file. It actually gets even more complicated because, as you point out in the next item, openssl also needs a command in addition to the config file. I'm interested in thinking about how to handle this cleanly from a user perspective. Generating a script, or providing the command lines as hints, might be ways to get around these concerns. > 4. "ipa cert_get_requestdata --format=openssl" could print hint what OpenSSL > command should be executed on the generated config file. For testing I've used > command "openssl req -new -out csr -text -config config" (stolen and modified > from smart card example). Also, as a second hint, it could print the IPA > command which needs to be used to sign the CSR generated by the helper. Also agreed, the framework should be able to generate and (for purposes of 'ipa cert-request --autofill') even execute the command required to make the CSR. > > 5. My naive attempt to get userCert for admin failed: > $ ipa cert_get_requestdata --format=openssl --principal=admin > --profile-id=userCert > usercert.conf > # remove the trailing label > $ openssl req -new -out csr -text -config usercert.conf > $ ipa cert-request --principal=admin --profile-id=userCert usercert.csr > ipa: ERROR: invalid 'csr': No Common Name was found in subject of request. > > I'm attaching files generated by the commands above. I did not modify anything > in the templates or profiles, just tried to use the new profile added by > freeipa-blipton-0010-Add-a-new-cert-profile-for-users.patch . Hah! This is what I get for thinking I know what the output has to look like, and not testing all the way through to requesting the cert. I'll change the profile to generate a subject with CN= instead of UID=. Updated patch is attached. Unfortunately these rules are only updated at ipa-server-install time, so if you'd like to fix it without reinstalling: ipa certtransformationrule-mod dataUsernameCN dataUsernameCertutil --template 'CN={{ipa.datafield(subject.uid.0)|quote}},{{ipa.datafield(config.ipacertificatesubjectbase.0)|quote}}' ipa certtransformationrule-mod dataUsernameCN dataUsernameOpenssl --template '{{ipa.datafield(config.ipacertificatesubjectbase.0)}} CN={{ipa.datafield(subject.uid.0)}}' Yes, that must be an actual linebreak between the subjectbase and the CN in the openssl one. I know :-/ > > Hopefully I will get to other things soon (but not this week). > > > Anyway, all this seems like (expected) initial problems. In general the first > touch with user interface seems reasonable and needs only small improvements. > > Good work! > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-blipton-0010-2-Add-a-new-cert-profile-for-users.patch Type: text/x-patch Size: 9454 bytes Desc: not available URL: From mbasti at redhat.com Fri Jul 29 15:56:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Jul 2016 17:56:40 +0200 Subject: [Freeipa-devel] [PATCH 0559] Increase default length of auto-generated passwords In-Reply-To: <20160729150957.d5cfwp6xbleir5nt@redhat.com> References: <20160729150957.d5cfwp6xbleir5nt@redhat.com> Message-ID: <4320f103-3632-e45e-31c7-a7b94375acb3@redhat.com> On 29.07.2016 17:09, Alexander Bokovoy wrote: > On Fri, 29 Jul 2016, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/6116 >> >> >> Patch attached >> > >> From ca5305e032137b7c9197d0c1050191079a72124e Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Fri, 22 Jul 2016 16:41:29 +0200 >> Subject: [PATCH] Increase default length of auto generated passwords >> >> Installer/IPA generates passwords for warious purpose: >> * KRA >> * kerberos master key >> * NSSDB password >> * temporary passwords during installation >> >> Length of passwords should be increased to 22, ~128bits of entropy, to >> be safe nowadays. >> >> https://fedorahosted.org/freeipa/ticket/6116 > ACK with a minor comment. > >> --- >> ipapython/ipautil.py | 2 +- >> ipaserver/plugins/baseuser.py | 3 ++- >> ipaserver/plugins/host.py | 3 ++- >> ipaserver/plugins/stageuser.py | 3 ++- >> ipaserver/plugins/user.py | 3 ++- >> 5 files changed, 9 insertions(+), 5 deletions(-) >> >> diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py >> index >> 9964fba4f694b57242b3bd3065a418917d977533..ca7e81d666cd6c345bdbbf4660c3451ac1f2c045 >> 100644 >> --- a/ipapython/ipautil.py >> +++ b/ipapython/ipautil.py >> @@ -57,7 +57,7 @@ from ipapython.dn import DN >> SHARE_DIR = paths.USR_SHARE_IPA_DIR >> PLUGINS_SHARE_DIR = paths.IPA_PLUGINS >> >> -GEN_PWD_LEN = 12 >> +GEN_PWD_LEN = 22 > It would be good to add a temporary password constant too > +GEN_TMP_PWD_LEN = 12 > > and then use it instead of pwd_len=12 below. > >> # Having this in krb_utils would cause circular import >> KRB5_KDC_UNREACH = 2529639068 # Cannot contact any KDC for requested >> realm >> diff --git a/ipaserver/plugins/baseuser.py >> b/ipaserver/plugins/baseuser.py >> index >> e4288a5a131157815ffb2452692a7edb342f6ac3..5e0752c8d3d246fa7c283f05b82ef01de2e5bf34 >> 100644 >> --- a/ipaserver/plugins/baseuser.py >> +++ b/ipaserver/plugins/baseuser.py >> @@ -552,7 +552,8 @@ class baseuser_mod(LDAPUpdate): >> >> def check_userpassword(self, entry_attrs, **options): >> if 'userpassword' not in entry_attrs and options.get('random'): >> - entry_attrs['userpassword'] = >> ipa_generate_password(baseuser_pwdchars) >> + entry_attrs['userpassword'] = ipa_generate_password( >> + baseuser_pwdchars, pwd_len=12) >> # save the password so it can be displayed in post_callback >> setattr(context, 'randompassword', >> entry_attrs['userpassword']) >> >> diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py >> index >> 413dcf15e0423170d8334902b9dcf8fb5aa14de6..1cefb6224e1a6dad0080369edee35c4524e5bd39 >> 100644 >> --- a/ipaserver/plugins/host.py >> +++ b/ipaserver/plugins/host.py >> @@ -683,7 +683,8 @@ class host_add(LDAPCreate): >> if 'krbprincipal' in entry_attrs['objectclass']: >> entry_attrs['objectclass'].remove('krbprincipal') >> if options.get('random'): >> - entry_attrs['userpassword'] = >> ipa_generate_password(characters=host_pwd_chars) >> + entry_attrs['userpassword'] = ipa_generate_password( >> + characters=host_pwd_chars, pwd_len=12) >> # save the password so it can be displayed in post_callback >> setattr(context, 'randompassword', >> entry_attrs['userpassword']) >> certs = options.get('usercertificate', []) >> diff --git a/ipaserver/plugins/stageuser.py >> b/ipaserver/plugins/stageuser.py >> index >> 3b9388f6020b9a6c40caedd36f3640a05a13da65..6df189c3913171b4990ce115b296b19c7447592d >> 100644 >> --- a/ipaserver/plugins/stageuser.py >> +++ b/ipaserver/plugins/stageuser.py >> @@ -339,7 +339,8 @@ class stageuser_add(baseuser_add): >> >> # If requested, generate a userpassword >> if 'userpassword' not in entry_attrs and options.get('random'): >> - entry_attrs['userpassword'] = >> ipa_generate_password(baseuser_pwdchars) >> + entry_attrs['userpassword'] = ipa_generate_password( >> + baseuser_pwdchars, pwd_len=12) >> # save the password so it can be displayed in post_callback >> setattr(context, 'randompassword', >> entry_attrs['userpassword']) >> >> diff --git a/ipaserver/plugins/user.py b/ipaserver/plugins/user.py >> index >> b3ae7646fdcfa1dce10d90063dae2a24c091e8ee..62ec529062c7ac39661df2a8c3d2277711268b11 >> 100644 >> --- a/ipaserver/plugins/user.py >> +++ b/ipaserver/plugins/user.py >> @@ -517,7 +517,8 @@ class user_add(baseuser_add): >> entry_attrs['gidnumber'] = group_attrs['gidnumber'] >> >> if 'userpassword' not in entry_attrs and options.get('random'): >> - entry_attrs['userpassword'] = >> ipa_generate_password(baseuser_pwdchars) >> + entry_attrs['userpassword'] = ipa_generate_password( >> + baseuser_pwdchars, pwd_len=12) >> # save the password so it can be displayed in post_callback >> setattr(context, 'randompassword', >> entry_attrs['userpassword']) >> >> -- >> 2.5.5 >> > >> -- >> 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 > > Thanks Updated patch attached Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0559.2-Increase-default-length-of-auto-generated-passwords.patch Type: text/x-patch Size: 6088 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jul 29 16:19:15 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 29 Jul 2016 19:19:15 +0300 Subject: [Freeipa-devel] [PATCH 0559] Increase default length of auto-generated passwords In-Reply-To: <4320f103-3632-e45e-31c7-a7b94375acb3@redhat.com> References: <20160729150957.d5cfwp6xbleir5nt@redhat.com> <4320f103-3632-e45e-31c7-a7b94375acb3@redhat.com> Message-ID: <20160729161915.mnmnwo2pqvp35gvu@redhat.com> On Fri, 29 Jul 2016, Martin Basti wrote: > > > On 29.07.2016 17:09, Alexander Bokovoy wrote: > > On Fri, 29 Jul 2016, Martin Basti wrote: > > > https://fedorahosted.org/freeipa/ticket/6116 > > > > > > > > > Patch attached > > > > > > > > From ca5305e032137b7c9197d0c1050191079a72124e Mon Sep 17 00:00:00 2001 > > > From: Martin Basti > > > Date: Fri, 22 Jul 2016 16:41:29 +0200 > > > Subject: [PATCH] Increase default length of auto generated passwords > > > > > > Installer/IPA generates passwords for warious purpose: > > > * KRA > > > * kerberos master key > > > * NSSDB password > > > * temporary passwords during installation > > > > > > Length of passwords should be increased to 22, ~128bits of entropy, to > > > be safe nowadays. > > > > > > https://fedorahosted.org/freeipa/ticket/6116 > > ACK with a minor comment. > > > > > --- > > > ipapython/ipautil.py | 2 +- > > > ipaserver/plugins/baseuser.py | 3 ++- > > > ipaserver/plugins/host.py | 3 ++- > > > ipaserver/plugins/stageuser.py | 3 ++- > > > ipaserver/plugins/user.py | 3 ++- > > > 5 files changed, 9 insertions(+), 5 deletions(-) > > > > > > diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py > > > index 9964fba4f694b57242b3bd3065a418917d977533..ca7e81d666cd6c345bdbbf4660c3451ac1f2c045 > > > 100644 > > > --- a/ipapython/ipautil.py > > > +++ b/ipapython/ipautil.py > > > @@ -57,7 +57,7 @@ from ipapython.dn import DN > > > SHARE_DIR = paths.USR_SHARE_IPA_DIR > > > PLUGINS_SHARE_DIR = paths.IPA_PLUGINS > > > > > > -GEN_PWD_LEN = 12 > > > +GEN_PWD_LEN = 22 > > It would be good to add a temporary password constant too > > +GEN_TMP_PWD_LEN = 12 > > > > and then use it instead of pwd_len=12 below. > > > > > # Having this in krb_utils would cause circular import > > > KRB5_KDC_UNREACH = 2529639068 # Cannot contact any KDC for requested > > > realm > > > diff --git a/ipaserver/plugins/baseuser.py > > > b/ipaserver/plugins/baseuser.py > > > index e4288a5a131157815ffb2452692a7edb342f6ac3..5e0752c8d3d246fa7c283f05b82ef01de2e5bf34 > > > 100644 > > > --- a/ipaserver/plugins/baseuser.py > > > +++ b/ipaserver/plugins/baseuser.py > > > @@ -552,7 +552,8 @@ class baseuser_mod(LDAPUpdate): > > > > > > def check_userpassword(self, entry_attrs, **options): > > > if 'userpassword' not in entry_attrs and options.get('random'): > > > - entry_attrs['userpassword'] = > > > ipa_generate_password(baseuser_pwdchars) > > > + entry_attrs['userpassword'] = ipa_generate_password( > > > + baseuser_pwdchars, pwd_len=12) > > > # save the password so it can be displayed in post_callback > > > setattr(context, 'randompassword', > > > entry_attrs['userpassword']) > > > > > > diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py > > > index 413dcf15e0423170d8334902b9dcf8fb5aa14de6..1cefb6224e1a6dad0080369edee35c4524e5bd39 > > > 100644 > > > --- a/ipaserver/plugins/host.py > > > +++ b/ipaserver/plugins/host.py > > > @@ -683,7 +683,8 @@ class host_add(LDAPCreate): > > > if 'krbprincipal' in entry_attrs['objectclass']: > > > entry_attrs['objectclass'].remove('krbprincipal') > > > if options.get('random'): > > > - entry_attrs['userpassword'] = > > > ipa_generate_password(characters=host_pwd_chars) > > > + entry_attrs['userpassword'] = ipa_generate_password( > > > + characters=host_pwd_chars, pwd_len=12) > > > # save the password so it can be displayed in post_callback > > > setattr(context, 'randompassword', > > > entry_attrs['userpassword']) > > > certs = options.get('usercertificate', []) > > > diff --git a/ipaserver/plugins/stageuser.py > > > b/ipaserver/plugins/stageuser.py > > > index 3b9388f6020b9a6c40caedd36f3640a05a13da65..6df189c3913171b4990ce115b296b19c7447592d > > > 100644 > > > --- a/ipaserver/plugins/stageuser.py > > > +++ b/ipaserver/plugins/stageuser.py > > > @@ -339,7 +339,8 @@ class stageuser_add(baseuser_add): > > > > > > # If requested, generate a userpassword > > > if 'userpassword' not in entry_attrs and options.get('random'): > > > - entry_attrs['userpassword'] = > > > ipa_generate_password(baseuser_pwdchars) > > > + entry_attrs['userpassword'] = ipa_generate_password( > > > + baseuser_pwdchars, pwd_len=12) > > > # save the password so it can be displayed in post_callback > > > setattr(context, 'randompassword', > > > entry_attrs['userpassword']) > > > > > > diff --git a/ipaserver/plugins/user.py b/ipaserver/plugins/user.py > > > index b3ae7646fdcfa1dce10d90063dae2a24c091e8ee..62ec529062c7ac39661df2a8c3d2277711268b11 > > > 100644 > > > --- a/ipaserver/plugins/user.py > > > +++ b/ipaserver/plugins/user.py > > > @@ -517,7 +517,8 @@ class user_add(baseuser_add): > > > entry_attrs['gidnumber'] = group_attrs['gidnumber'] > > > > > > if 'userpassword' not in entry_attrs and options.get('random'): > > > - entry_attrs['userpassword'] = > > > ipa_generate_password(baseuser_pwdchars) > > > + entry_attrs['userpassword'] = ipa_generate_password( > > > + baseuser_pwdchars, pwd_len=12) > > > # save the password so it can be displayed in post_callback > > > setattr(context, 'randompassword', > > > entry_attrs['userpassword']) > > > > > > -- > > > 2.5.5 > > > > > > > > -- > > > 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 > > > > > Thanks > Updated patch attached Thanks, ACK. -- / Alexander Bokovoy