From jcholast at redhat.com Tue Sep 1 05:06:45 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 1 Sep 2015 07:06:45 +0200 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E4B5DD.5060206@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> Message-ID: <55E53265.4010400@redhat.com> On 31.8.2015 22:15, Endi Sukma Dewata wrote: > On 8/31/2015 6:18 AM, Martin Basti wrote: >> >> >> On 08/27/2015 09:41 PM, Endi Sukma Dewata wrote: >>> The CA and KRA installation code has been modified to use LDAPI >>> to create the CA and KRA agents directly in the CA and KRA >>> database. This way it's no longer necessary to use the Directory >>> Manager password or CA and KRA admin certificate. >>> >>> https://fedorahosted.org/freeipa/ticket/5257 >>> >>> >>> >> >> Thank you. >> >> 1) Can you use following code instead of direct call of ldap2.ldap2()? >> >> if not api.Backend.ldap2.is_connected(): >> api.Backend.ldap2.connect(autobind=True) >> >> conn = api.Backend.ldap2 Why would you want to do that? The original code is fine, except the connection check is not necessary (it is a new instance of ldap2, so .isconnected() will always return False). > > It's actually isconnected() instead of is_connected(), but even so, the > proposed code doesn't work: > > ipa.ipapython.install.cli.install_tool(Server): DEBUG The > ipa-server-install command failed, exception: TypeError: 'ldap2' object > is not callable > ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object > is not callable > >> 2) Patch needs rebase to master branch. > > The original patch does apply cleanly to master. Did you see a conflict? > >> 3) >> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) >> + conn.create( >> + dn=user_dn, >> >> can you use add entry() instead of create()? We don't use native >> python-ldap, but rather ipaldap methods > > It's actually calling the ldap2.create() defined in > ipaserver/plugins/ldap2.py, which calls add_entry(). NACK. We don't use ldap2.create(). Use add_entry(). > > So my original patch still stands. > -- Jan Cholasta From mbasti at redhat.com Tue Sep 1 06:52:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 1 Sep 2015 08:52:18 +0200 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E53265.4010400@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> <55E53265.4010400@redhat.com> Message-ID: <55E54B22.1050508@redhat.com> On 09/01/2015 07:06 AM, Jan Cholasta wrote: > On 31.8.2015 22:15, Endi Sukma Dewata wrote: >> On 8/31/2015 6:18 AM, Martin Basti wrote: >>> >>> >>> On 08/27/2015 09:41 PM, Endi Sukma Dewata wrote: >>>> The CA and KRA installation code has been modified to use LDAPI >>>> to create the CA and KRA agents directly in the CA and KRA >>>> database. This way it's no longer necessary to use the Directory >>>> Manager password or CA and KRA admin certificate. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5257 >>>> >>>> >>>> >>> >>> Thank you. >>> >>> 1) Can you use following code instead of direct call of ldap2.ldap2()? >>> >>> if not api.Backend.ldap2.is_connected(): >>> api.Backend.ldap2.connect(autobind=True) >>> >>> conn = api.Backend.ldap2 > > Why would you want to do that? The original code is fine, except the > connection check is not necessary (it is a new instance of ldap2, so > .isconnected() will always return False). > >> >> It's actually isconnected() instead of is_connected(), but even so, the >> proposed code doesn't work: >> >> ipa.ipapython.install.cli.install_tool(Server): DEBUG The >> ipa-server-install command failed, exception: TypeError: 'ldap2' object >> is not callable >> ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object >> is not callable >> >>> 2) Patch needs rebase to master branch. >> >> The original patch does apply cleanly to master. Did you see a conflict? Sorry my bad. Martin^2 >> >>> 3) >>> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) >>> + conn.create( >>> + dn=user_dn, >>> >>> can you use add entry() instead of create()? We don't use native >>> python-ldap, but rather ipaldap methods >> >> It's actually calling the ldap2.create() defined in >> ipaserver/plugins/ldap2.py, which calls add_entry(). > > NACK. We don't use ldap2.create(). Use add_entry(). > >> >> So my original patch still stands. >> > > From mbasti at redhat.com Tue Sep 1 06:57:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 1 Sep 2015 08:57:43 +0200 Subject: [Freeipa-devel] [PATCH 0302] DNSSEC: remove "DNSSEC is experimental" warnings In-Reply-To: <55E47B4B.5040800@redhat.com> References: <55E44E05.8080603@redhat.com> <55E47B4B.5040800@redhat.com> Message-ID: <55E54C67.1000807@redhat.com> On 08/31/2015 06:05 PM, Martin Kosek wrote: > On 08/31/2015 02:52 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5265 >> >> Patch attached. >> >> Should I remove also message class "DNSSECWarning" which is not used now, or >> just keep it there because ti has already registered error code? >> >> Martin^2 >> >> > Just for the record, I added more pointers to why we think DNSSEC is now more > stabilized to the ticket - this is an important information that should warrant > removal of the warning messages. > Thank you. From jcholast at redhat.com Tue Sep 1 09:42:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 1 Sep 2015 11:42:42 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DF1805.5040608@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> <55DC45DD.1040907@redhat.com> <55DC6815.9090804@redhat.com> <55DD6F1A.8080205@redhat.com> <55DD91D0.7040109@redhat.com> <55DEB732.5040600@redhat.com> <55DEE39E.8030203@redhat.com> <55DF1805.5040608@redhat.com> Message-ID: <55E57312.5060307@redhat.com> On 27.8.2015 16:00, Jan Cholasta wrote: > On 27.8.2015 12:17, Petr Viktorin wrote: >> On 08/27/2015 09:07 AM, Jan Cholasta wrote: >>> On 26.8.2015 12:15, Petr Viktorin wrote: >>>> On 08/26/2015 09:47 AM, Jan Cholasta wrote: >>>>> On 25.8.2015 15:05, Petr Viktorin wrote: >>>>>> On 08/25/2015 12:39 PM, Christian Heimes wrote: >>>>>>> On 2015-08-24 17:31, Petr Viktorin wrote: >>>>>>>>>>> 0701.2-Use-Python3-compatible-dict-method-names >>>>>>>>>>> NACK >>>>>>>>>>> Why are you replacing iteritems() with items() instead of using >>>>>>>>>>> six.iteritems()? >>>>>>>> >>>>>>>> It looks cleaner, and it will be easier to clean up after six is >>>>>>>> dropped. >>>>>>>> Also, the performance difference is negligible if the whole >>>>>>>> thing is >>>>>>>> iterated over. (On small dicts, which are the majority of what >>>>>>>> iteritems >>>>>>>> was used on, items() is actually a bit faster on my machine.) >>>>>>> >>>>>>> Right, for small dicts the speed difference is negligible and >>>>>>> favors the >>>>>>> items() over iteritems(). For medium sized and large dicts the >>>>>>> iterators >>>>>>> are faster and consume less memory. >>>>>>> >>>>>>> I'm preferring iterator methods everywhere because I don't have to >>>>>>> worry >>>>>>> about dict sizes. >>>>>>> >>>>>>>>>>> 0710.2-Modernize-use-of-range >>>>>>>>>>> NACK >>>>>>>>>>> Please use six.moves.range. It defaults to xrange() in Python 2. >>>>>>>> >>>>>>>> Why? What is the benefit of xrange in these situations? >>>>>>>> >>>>>>>> Like with iteritems in 0701, when iterating over the whole >>>>>>>> thing, the >>>>>>>> performance difference is negligible. I don't think a few >>>>>>>> microseconds >>>>>>>> outside of tight loops are worth the verbosity. >>>>>>> >>>>>>> It's the same reasoning as in 0701. As long as you have a small >>>>>>> range, >>>>>>> it doesn't make a difference. For large ranges the additional memory >>>>>>> usage can be problematic. >>>>>>> >>>>>>> In all above cases the iterator methods and generator functions >>>>>>> are a >>>>>>> safer choice. A malicious user can abuse the non-iterative >>>>>>> methods for >>>>>>> DoS attacks. As long as the input can't be controlled by a user and >>>>>>> the >>>>>>> range/dict/set/list is small, the non-iterative methods are fine. >>>>>>> You >>>>>>> have to verify every location, though. >>>>>> >>>>>> Keep in mind that for dicts, all the data is in memory already (in >>>>>> the >>>>>> dict). Are you worried about DoS from an extra list of references to >>>>>> existing objects? >>>>>> >>>>>>> I'm usually too busy with other stuff (aka lazy) to verify these >>>>>>> preconditions... >>>>>> >>>>>> I changed one questionable use of range. The other ones are: >>>>>> >>>>>> ipalib/plugins/dns.py: for i in range(len(relative_record_name) >>>>>> (max. ~255, verified by DNSName) >>>>>> >>>>>> ipaserver/install/dnskeysyncinstance.py: for _ in range(0, 16)) >>>>>> (16) >>>>>> >>>>>> ipaserver/install/ipa_otptoken_import.py: for i in range(1, blocks + >>>>>> 1): >>>>>> (about 7) >>>>>> >>>>>> ipaserver/install/ipa_otptoken_import.py: for k in >>>>>> range(mac.digest_size): >>>>>> (16) >>>>>> >>>>>> ipatests/data.py: for d in range(256)) >>>>>> (256) >>>>>> >>>>>> Plus tests, where it's rarely above 10. >>>>>> >>>>> >>>>> I have just pushed Michael's python-krbV removal patch, which >>>>> conflicts >>>>> with your patches. Could you please rebase them on top of current >>>>> master? >>>>> >>>> >>>> Sure, here they are. >>>> >>>> >>> >>> Patches 696-699: ACK >>> >>> Patch 700: There are some error messages which contain basestring. Do we >>> want to fix these as well? >> >> No, I think it's okay as a term. When Python 2 is dropped it can be >> shortened to str. >> >>> Patch 701: Since we are using python-six, shouldn't "six.PY2" be used >>> instead of "sys.version_info < (3, 0)"? >> >> Right, it looks a bit better. >> >>> Patches 702-709: ACK >>> >>> Patch 710: There are some "xrange"s in ipapython/p11helper.py and >>> ipatests/test_xmlrpc/test_add_remove_cert_cmd.py. >> >> Thanks, fixed. >> >>> Patch 711: ACK >>> >> > > Thanks, ACK. > > Christian, if you don't have any objections, I will push the patches. > I have heard no complaints, so I'm pushing the patches. Should you have any further concerns, they can be sorted out in additional patches. Pushed to master: 70d1c71e46811bd3d44249d5361f99613d4ce5af Honza -- Jan Cholasta From pspacek at redhat.com Tue Sep 1 11:39:56 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 1 Sep 2015 13:39:56 +0200 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55E4D85A.7080600@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> <55E4D85A.7080600@redhat.com> Message-ID: <55E58E8C.6090709@redhat.com> On 1.9.2015 00:42, Rich Megginson wrote: > On 08/31/2015 11:00 AM, Simo Sorce wrote: >> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: >>> On 08/31/2015 01:35 AM, Petr Spacek wrote: >>>> On 26.8.2015 20:09, Rich Megginson wrote: >>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: >>>>>> On 8.7.2015 19:56, Rich Megginson wrote: >>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it >>>>>>>> would be >>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>>>>>>> alongside their own JSON API. >>>>>>>> >>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add >>>>>>>> zones >>>>>>>> but still, standard protocol would mean that standard client (possibly >>>>>>>> guest >>>>>>>> OS inside VM) can update its records without any OpenStack dependency, >>>>>>>> which >>>>>>>> is very much desirable. >>>>>>>> >>>>>>>> The use case here is to allow the guest OS to publish it's SSH key >>>>>>>> (which was >>>>>>>> generated inside the VM after first boot) to prevent Man in the middle >>>>>>>> attacks. >>>>> I'm working on a different approach for guest OS registration. This >>>>> involves >>>>> a Nova hook/plugin: >>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the >>>>> OTP - add OTP to new host metadata - add ipa-client-registration script >>>>> to new >>>>> host cloud-init >>>>> * new instance calls script - will wait for OTP to become available in >>>>> metadata, then call ipa-client-install with OTP >>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with >>>>> new IP >>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. >>>> ipa-client-install is using DNS UPDATE today. >>> I already have to support the IPA JSON REST interface with kerberos >>> credentials to do the host add, so it is easy to support dsrecord-add. >>> >>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova >>>>> >>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service >>>>>>>> discovery using DNS, where a guest/container running a distributed >>>>>>>> service >>>>>>>> can >>>>>>>> publish it's existence in DNS. >>>>>>>> >>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>>>>>>> widely supported, too. >>>>>>>> >>>>>>>> So DNS UPDATE is my biggest wish :-) >>>>>>>> >>>>>>> Ok. There was a Designate blueprint for such a feature, but I can't >>>>>>> find it >>>>>>> and neither can the Designate guys. There is a mention of nsupdate in the >>>>>>> minidns blueprint, but that's about it. The fact that Designate upstream >>>>>>> can't find the bp suggests that this is not a high priority for them >>>>>>> and will >>>>>>> not likely implement it on their own i.e. we would have to contribute this >>>>>>> feature. >>>>>>> >>>>>>> If Designate had such a feature, how would this help us integrate >>>>>>> FreeIPA with >>>>>>> Designate? >>>>>> It would greatly simplify integration with FreeIPA. There is a plan to >>>>>> support >>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA >>>>>> servers to >>>>>> external DNS servers, so we could use the same code to integrate with AD & >>>>>> Designate at the same time. >>>>>> >>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) >>>>>> >>>>> For Designate for our use cases, we want IPA to be the authoritative >>>>> source of >>>>> DNS data. >>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is >>>> built around assumption that there is only one authoritative source of data >>>> and as far as I can tell all attempts to bend this assumption did not end >>>> well. >>> But what about users/operators who want to integrate OpenStack with >>> their existing DNS deployment (e.g. IPA or AD)? Will they allow >>> converting their IPA/AD DNS to be a replica of Designate? >> No, they would not want to, or have no permissions to do so. >> But that shouldn't be a big issue, designate will probably be made to >> manage a completely unrelated namespace. >> >>> This seems to >>> be the obverse of most of the ways OpenStack is integrated into existing >>> deployments. For example, for Keystone Identity, you don't configure >>> Keystone to be the authoritative source of data for identity, then >>> configure IPA or AD to be a replica of Keystone. You configure Keystone >>> to use IPA/AD for its identity information. >> Indeed. >> >>>> In my eyes IPA should have ability to integrate with whatever DNS server >>>> admin >>>> wants to use, using standard protocols. >>> Does this mean the best way to support Designate will be to change IPA >>> DNS so that it can be a replica of Designate, and get its data via AXFR >>> from Designate? >> No, we should probably just make it possible for IPA to talk to >> designate to add the necessary records. If Designate is in use, the IPA >> DNS will not be in use and turned off. > > Then why use IPA at all? Would be much simpler for the user to stand up a > PowerDNS or BIND9 which are supported out of the box. Yes, that is basically what I'm saying :-) In my eyes IPA should integrate with whatever DNS server you want to use, be it Designate or anything else. If we have such integration then there is no point in doing two-way synchronization between IPA DNS and DNS. >> It makes little to no sense to replicate stuff out of designate if we >> are not the master server. -- Petr^2 Spacek From mbasti at redhat.com Tue Sep 1 12:19:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 1 Sep 2015 14:19:49 +0200 Subject: [Freeipa-devel] [PATCH 0302] DNSSEC: remove "DNSSEC is experimental" warnings In-Reply-To: <55E54C67.1000807@redhat.com> References: <55E44E05.8080603@redhat.com> <55E47B4B.5040800@redhat.com> <55E54C67.1000807@redhat.com> Message-ID: <55E597E5.9010209@redhat.com> On 09/01/2015 08:57 AM, Martin Basti wrote: > > > On 08/31/2015 06:05 PM, Martin Kosek wrote: >> On 08/31/2015 02:52 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5265 >>> >>> Patch attached. >>> >>> Should I remove also message class "DNSSECWarning" which is not used >>> now, or >>> just keep it there because ti has already registered error code? >>> >>> Martin^2 >>> >>> >> Just for the record, I added more pointers to why we think DNSSEC is >> now more >> stabilized to the ticket - this is an important information that >> should warrant >> removal of the warning messages. >> > Thank you. > Rebased patches for master attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.2-mbasti-0302-DNSSEC-remove-DNSSEC-is-experimental-warnings.patch Type: text/x-patch Size: 3320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0302-DNSSEC-remove-DNSSEC-is-experimental-warnings.patch Type: text/x-patch Size: 3327 bytes Desc: not available URL: From rmeggins at redhat.com Tue Sep 1 13:17:32 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 1 Sep 2015 07:17:32 -0600 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55E58E8C.6090709@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> <55E4D85A.7080600@redhat.com> <55E58E8C.6090709@redhat.com> Message-ID: <55E5A56C.7090600@redhat.com> On 09/01/2015 05:39 AM, Petr Spacek wrote: > On 1.9.2015 00:42, Rich Megginson wrote: >> On 08/31/2015 11:00 AM, Simo Sorce wrote: >>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: >>>> On 08/31/2015 01:35 AM, Petr Spacek wrote: >>>>> On 26.8.2015 20:09, Rich Megginson wrote: >>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: >>>>>>> On 8.7.2015 19:56, Rich Megginson wrote: >>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it >>>>>>>>> would be >>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>>>>>>>> alongside their own JSON API. >>>>>>>>> >>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add >>>>>>>>> zones >>>>>>>>> but still, standard protocol would mean that standard client (possibly >>>>>>>>> guest >>>>>>>>> OS inside VM) can update its records without any OpenStack dependency, >>>>>>>>> which >>>>>>>>> is very much desirable. >>>>>>>>> >>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key >>>>>>>>> (which was >>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle >>>>>>>>> attacks. >>>>>> I'm working on a different approach for guest OS registration. This >>>>>> involves >>>>>> a Nova hook/plugin: >>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the >>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script >>>>>> to new >>>>>> host cloud-init >>>>>> * new instance calls script - will wait for OTP to become available in >>>>>> metadata, then call ipa-client-install with OTP >>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with >>>>>> new IP >>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. >>>>> ipa-client-install is using DNS UPDATE today. >>>> I already have to support the IPA JSON REST interface with kerberos >>>> credentials to do the host add, so it is easy to support dsrecord-add. >>>> >>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova >>>>>> >>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service >>>>>>>>> discovery using DNS, where a guest/container running a distributed >>>>>>>>> service >>>>>>>>> can >>>>>>>>> publish it's existence in DNS. >>>>>>>>> >>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>>>>>>>> widely supported, too. >>>>>>>>> >>>>>>>>> So DNS UPDATE is my biggest wish :-) >>>>>>>>> >>>>>>>> Ok. There was a Designate blueprint for such a feature, but I can't >>>>>>>> find it >>>>>>>> and neither can the Designate guys. There is a mention of nsupdate in the >>>>>>>> minidns blueprint, but that's about it. The fact that Designate upstream >>>>>>>> can't find the bp suggests that this is not a high priority for them >>>>>>>> and will >>>>>>>> not likely implement it on their own i.e. we would have to contribute this >>>>>>>> feature. >>>>>>>> >>>>>>>> If Designate had such a feature, how would this help us integrate >>>>>>>> FreeIPA with >>>>>>>> Designate? >>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to >>>>>>> support >>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA >>>>>>> servers to >>>>>>> external DNS servers, so we could use the same code to integrate with AD & >>>>>>> Designate at the same time. >>>>>>> >>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) >>>>>>> >>>>>> For Designate for our use cases, we want IPA to be the authoritative >>>>>> source of >>>>>> DNS data. >>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is >>>>> built around assumption that there is only one authoritative source of data >>>>> and as far as I can tell all attempts to bend this assumption did not end >>>>> well. >>>> But what about users/operators who want to integrate OpenStack with >>>> their existing DNS deployment (e.g. IPA or AD)? Will they allow >>>> converting their IPA/AD DNS to be a replica of Designate? >>> No, they would not want to, or have no permissions to do so. >>> But that shouldn't be a big issue, designate will probably be made to >>> manage a completely unrelated namespace. >>> >>>> This seems to >>>> be the obverse of most of the ways OpenStack is integrated into existing >>>> deployments. For example, for Keystone Identity, you don't configure >>>> Keystone to be the authoritative source of data for identity, then >>>> configure IPA or AD to be a replica of Keystone. You configure Keystone >>>> to use IPA/AD for its identity information. >>> Indeed. >>> >>>>> In my eyes IPA should have ability to integrate with whatever DNS server >>>>> admin >>>>> wants to use, using standard protocols. >>>> Does this mean the best way to support Designate will be to change IPA >>>> DNS so that it can be a replica of Designate, and get its data via AXFR >>>> from Designate? >>> No, we should probably just make it possible for IPA to talk to >>> designate to add the necessary records. If Designate is in use, the IPA >>> DNS will not be in use and turned off. >> Then why use IPA at all? Would be much simpler for the user to stand up a >> PowerDNS or BIND9 which are supported out of the box. > Yes, that is basically what I'm saying :-) In my eyes IPA should integrate > with whatever DNS server you want to use, be it Designate or anything else. If > we have such integration then there is no point in doing two-way > synchronization between IPA DNS and DNS. What does "integration" mean in this context, if it doesn't mean synchronization or zone transfers? > >>> It makes little to no sense to replicate stuff out of designate if we >>> are not the master server. From simo at redhat.com Tue Sep 1 13:34:16 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Sep 2015 09:34:16 -0400 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55E5A56C.7090600@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> <55E4D85A.7080600@redhat.com> <55E58E8C.6090709@redhat.com> <55E5A56C.7090600@redhat.com> Message-ID: <1441114456.28131.110.camel@willson.usersys.redhat.com> On Tue, 2015-09-01 at 07:17 -0600, Rich Megginson wrote: > On 09/01/2015 05:39 AM, Petr Spacek wrote: > > On 1.9.2015 00:42, Rich Megginson wrote: > >> On 08/31/2015 11:00 AM, Simo Sorce wrote: > >>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: > >>>> On 08/31/2015 01:35 AM, Petr Spacek wrote: > >>>>> On 26.8.2015 20:09, Rich Megginson wrote: > >>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: > >>>>>>> On 8.7.2015 19:56, Rich Megginson wrote: > >>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: > >>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it > >>>>>>>>> would be > >>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) > >>>>>>>>> alongside their own JSON API. > >>>>>>>>> > >>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add > >>>>>>>>> zones > >>>>>>>>> but still, standard protocol would mean that standard client (possibly > >>>>>>>>> guest > >>>>>>>>> OS inside VM) can update its records without any OpenStack dependency, > >>>>>>>>> which > >>>>>>>>> is very much desirable. > >>>>>>>>> > >>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key > >>>>>>>>> (which was > >>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle > >>>>>>>>> attacks. > >>>>>> I'm working on a different approach for guest OS registration. This > >>>>>> involves > >>>>>> a Nova hook/plugin: > >>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the > >>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script > >>>>>> to new > >>>>>> host cloud-init > >>>>>> * new instance calls script - will wait for OTP to become available in > >>>>>> metadata, then call ipa-client-install with OTP > >>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with > >>>>>> new IP > >>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. > >>>>> ipa-client-install is using DNS UPDATE today. > >>>> I already have to support the IPA JSON REST interface with kerberos > >>>> credentials to do the host add, so it is easy to support dsrecord-add. > >>>> > >>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova > >>>>>> > >>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service > >>>>>>>>> discovery using DNS, where a guest/container running a distributed > >>>>>>>>> service > >>>>>>>>> can > >>>>>>>>> publish it's existence in DNS. > >>>>>>>>> > >>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is > >>>>>>>>> widely supported, too. > >>>>>>>>> > >>>>>>>>> So DNS UPDATE is my biggest wish :-) > >>>>>>>>> > >>>>>>>> Ok. There was a Designate blueprint for such a feature, but I can't > >>>>>>>> find it > >>>>>>>> and neither can the Designate guys. There is a mention of nsupdate in the > >>>>>>>> minidns blueprint, but that's about it. The fact that Designate upstream > >>>>>>>> can't find the bp suggests that this is not a high priority for them > >>>>>>>> and will > >>>>>>>> not likely implement it on their own i.e. we would have to contribute this > >>>>>>>> feature. > >>>>>>>> > >>>>>>>> If Designate had such a feature, how would this help us integrate > >>>>>>>> FreeIPA with > >>>>>>>> Designate? > >>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to > >>>>>>> support > >>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA > >>>>>>> servers to > >>>>>>> external DNS servers, so we could use the same code to integrate with AD & > >>>>>>> Designate at the same time. > >>>>>>> > >>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) > >>>>>>> > >>>>>> For Designate for our use cases, we want IPA to be the authoritative > >>>>>> source of > >>>>>> DNS data. > >>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is > >>>>> built around assumption that there is only one authoritative source of data > >>>>> and as far as I can tell all attempts to bend this assumption did not end > >>>>> well. > >>>> But what about users/operators who want to integrate OpenStack with > >>>> their existing DNS deployment (e.g. IPA or AD)? Will they allow > >>>> converting their IPA/AD DNS to be a replica of Designate? > >>> No, they would not want to, or have no permissions to do so. > >>> But that shouldn't be a big issue, designate will probably be made to > >>> manage a completely unrelated namespace. > >>> > >>>> This seems to > >>>> be the obverse of most of the ways OpenStack is integrated into existing > >>>> deployments. For example, for Keystone Identity, you don't configure > >>>> Keystone to be the authoritative source of data for identity, then > >>>> configure IPA or AD to be a replica of Keystone. You configure Keystone > >>>> to use IPA/AD for its identity information. > >>> Indeed. > >>> > >>>>> In my eyes IPA should have ability to integrate with whatever DNS server > >>>>> admin > >>>>> wants to use, using standard protocols. > >>>> Does this mean the best way to support Designate will be to change IPA > >>>> DNS so that it can be a replica of Designate, and get its data via AXFR > >>>> from Designate? > >>> No, we should probably just make it possible for IPA to talk to > >>> designate to add the necessary records. If Designate is in use, the IPA > >>> DNS will not be in use and turned off. > >> Then why use IPA at all? Would be much simpler for the user to stand up a > >> PowerDNS or BIND9 which are supported out of the box. > > Yes, that is basically what I'm saying :-) In my eyes IPA should integrate > > with whatever DNS server you want to use, be it Designate or anything else. If > > we have such integration then there is no point in doing two-way > > synchronization between IPA DNS and DNS. > > What does "integration" mean in this context, if it doesn't mean > synchronization or zone transfers? It means that the IPA framework operates directly no an external DNS server instead of using its own. This means we can still have automatic changes in DNS w/o using the integrated one. There may be limitations (like no DNSSEC available, no ability to create forward zones, no discovery location support or similar) but at least it should be possible to set the core names that are needed for client discovery and similar. Simo. > > > >>> It makes little to no sense to replicate stuff out of designate if we > >>> are not the master server. > -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Sep 1 14:26:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 1 Sep 2015 16:26:05 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55DDA17E.9050403@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> Message-ID: <55E5B57D.8030109@redhat.com> On 26.8.2015 13:22, Petr Vobornik wrote: > On 08/25/2015 08:04 PM, Petr Vobornik wrote: >> adds commands: >> * vaultcontainer-show [--service |--user ] >> * vaultcontainer-add-owner >> [--service |--user ] >> [--users ] [--groups ] [--services ] >> * vaultcontainer-remove-owner >> [--service |--user ] >> [--users ] [--groups ] [--services ] >> >> https://fedorahosted.org/freeipa/ticket/5250 >> >> Use cases: >> 1. When user/service is deleted, associated vault container looses >> owner. There was no API command to set the owner. >> 2. Change owner of container by admin to manage access. >> >> Show command was added to show current owners. >> >> Find command was not added, should it be? >> >> > > There is also a design for vault container ownership handling created by > Endi - it's for future Vault 2.0. > > http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner > > This patch has a different API than the proposed - different way of > specifying the container. The design page uses path e.g. /users/foobar. > This patch uses the same way as vaults e.g. --user=foobar. This means > that the implementation in this patch cannot manage ownership of parent > vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. > > Do we want to go with this approach in 4.2? > > Attaching also new path which removes setting of owner which doesn't > exist so that integrity is OK and that it is consistent with removing of > user. > > Updated patch attached - output fix. We had a long discussion about this with Petr and we think the best approach is as follows: * Add new "Vault administrators" privilege. Vault administrators will have unrestricted access to vaults and vault containers, including the power to add/remove owners of vaults and vault containers. * Remove the ability of vault owners to add/remove other vault owners. If vault owner needs to be changed, vault administrator has to do it. Note that vault owners will still have the ability to add/remove vault members. * When adding new vault container, set owner to the current user. If vault container owner needs to be changed, vault administrator has to do it. * Allow adding vaults and vault containers only if the owner is set to the current user. * Introduce commands to modify vault container owner and to delete vault container, so the administrator has a choice between assigning ownership or deleting an unowned container. Honza -- Jan Cholasta From mbasti at redhat.com Tue Sep 1 14:28:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 1 Sep 2015 16:28:42 +0200 Subject: [Freeipa-devel] [PATCH 0303] backup: back up hosts file Message-ID: <55E5B61A.8010509@redhat.com> https://fedorahosted.org/freeipa/ticket/5275 Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0303-Backup-back-up-the-hosts-file.patch Type: text/x-patch Size: 884 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 1 14:39:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 1 Sep 2015 16:39:35 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55E5B57D.8030109@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> Message-ID: <55E5B8A7.9090700@redhat.com> On 1.9.2015 16:26, Jan Cholasta wrote: > On 26.8.2015 13:22, Petr Vobornik wrote: >> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>> adds commands: >>> * vaultcontainer-show [--service |--user ] >>> * vaultcontainer-add-owner >>> [--service |--user ] >>> [--users ] [--groups ] [--services ] >>> * vaultcontainer-remove-owner >>> [--service |--user ] >>> [--users ] [--groups ] [--services ] >>> >>> https://fedorahosted.org/freeipa/ticket/5250 >>> >>> Use cases: >>> 1. When user/service is deleted, associated vault container looses >>> owner. There was no API command to set the owner. >>> 2. Change owner of container by admin to manage access. >>> >>> Show command was added to show current owners. >>> >>> Find command was not added, should it be? >>> >>> >> >> There is also a design for vault container ownership handling created by >> Endi - it's for future Vault 2.0. >> >> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >> >> This patch has a different API than the proposed - different way of >> specifying the container. The design page uses path e.g. /users/foobar. >> This patch uses the same way as vaults e.g. --user=foobar. This means >> that the implementation in this patch cannot manage ownership of parent >> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >> >> Do we want to go with this approach in 4.2? >> >> Attaching also new path which removes setting of owner which doesn't >> exist so that integrity is OK and that it is consistent with removing of >> user. >> >> Updated patch attached - output fix. > > We had a long discussion about this with Petr and we think the best > approach is as follows: > > * Add new "Vault administrators" privilege. Vault administrators will > have unrestricted access to vaults and vault containers, including the > power to add/remove owners of vaults and vault containers. > > * Remove the ability of vault owners to add/remove other vault > owners. If vault owner needs to be changed, vault administrator has to > do it. Note that vault owners will still have the ability to add/remove > vault members. > > * When adding new vault container, set owner to the current user. If > vault container owner needs to be changed, vault administrator has to do > it. > > * Allow adding vaults and vault containers only if the owner is set > to the current user. > > * Introduce commands to modify vault container owner and to delete > vault container, so the administrator has a choice between assigning > ownership or deleting an unowned container. Also: * Control access to vault data using an ipaProtectedOperation ACI. Users which have read access to "ipaProtectedOperation;accessKRA" on a vault can retrieve data from the vault and users which have write access to "ipaProtectedOperation;accessKRA" on a vault can archive data in the vault. Honza -- Jan Cholasta From mbabinsk at redhat.com Tue Sep 1 14:39:59 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 1 Sep 2015 16:39:59 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA Message-ID: <55E5B8BF.4080101@redhat.com> Hi list, I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 and I would like to clarify what needs to be done in order to make IPA to fully support multiple aliases per entry. So far I have identified these task based on the ticket comments and discussion with Simo way back in the past: 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is not used in the new code. 2.) fix ACIs that do not permit setting multiple values of 'krbPrincipalName' attribute per entry (see https://fedorahosted.org/freeipa/ticket/3961) 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 'ipadb_find_principal' functions) to correctly perform lookup of krbprincipalname/krbcanonicalname, i.e. search krbprincipalname case-insensitively and krbcanonicalname case-sensitively, return krbcanonicalname when canonicalization is requested. 4.) Modify KDB backend and IPA framework to handle creation of both krbprincipalname and krbcanonicalname. I am not quite sure what cases should be covered here (I remember that we should create krbcanonicalname when we add another aliases to krbprincipalname), so it would be nice if you could comment on this. 5.) write tests which cover all this stuff so that we don't shoot ourselves in the foot. I am not very well versed in Kerberos so I might get some of this stuff wrong. If that's the case please point me to the right direction. Also please write me some additional stuff which I have fogot and needs to be done. -- Martin^3 Babinsky From jcholast at redhat.com Tue Sep 1 14:47:08 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 1 Sep 2015 16:47:08 +0200 Subject: [Freeipa-devel] [PATCHES 481-486] Metaclass and str modernization Message-ID: <55E5BA6C.2080502@redhat.com> Hi, the attached patches add some more modernization to our code. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-481-Use-six.with_metaclass-to-specify-metaclasses.patch Type: text/x-patch Size: 3044 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-482-Use-six.python_2_unicode_compatible.patch Type: text/x-patch Size: 5266 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-483-Decode-script-arguments-using-file-system-encoding.patch Type: text/x-patch Size: 4099 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-484-Use-six.text_type-instead-of-unicode.patch Type: text/x-patch Size: 223432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-485-Use-six.binary_type-instead-of-str-where-appropriate.patch Type: text/x-patch Size: 11099 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-486-Use-byte-literals-where-appropriate.patch Type: text/x-patch Size: 11211 bytes Desc: not available URL: From simo at redhat.com Tue Sep 1 14:53:42 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Sep 2015 10:53:42 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E5B8BF.4080101@redhat.com> References: <55E5B8BF.4080101@redhat.com> Message-ID: <1441119222.28131.125.camel@willson.usersys.redhat.com> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > Hi list, > > I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > and I would like to clarify what needs to be done in order to make IPA > to fully support multiple aliases per entry. > > So far I have identified these task based on the ticket comments and > discussion with Simo way back in the past: > > 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > not used in the new code. > > 2.) fix ACIs that do not permit setting multiple values of > 'krbPrincipalName' attribute per entry (see > https://fedorahosted.org/freeipa/ticket/3961) > > 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > 'ipadb_find_principal' functions) to correctly perform lookup of > krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > case-insensitively and krbcanonicalname case-sensitively, return > krbcanonicalname when canonicalization is requested. > > 4.) Modify KDB backend and IPA framework to handle creation of both > krbprincipalname and krbcanonicalname. I am not quite sure what cases > should be covered here (I remember that we should create > krbcanonicalname when we add another aliases to krbprincipalname), so it > would be nice if you could comment on this. > > 5.) write tests which cover all this stuff so that we don't shoot > ourselves in the foot. > > I am not very well versed in Kerberos so I might get some of this stuff > wrong. If that's the case please point me to the right direction. Also > please write me some additional stuff which I have fogot and needs to be > done. > I think the summary is correct, the only thing we need to be careful is to keep handling entries that have only a single valued krbprincipalname correctly as that will happen in upgrade paths and potentially if someone uses external tools. The tricky part for point 3 is to implement it *without* changing the schema. KrbPrincipalName is case-sensitive, however I think we can solve the issue of "searching case-insensitively" by always lower-casing the principal name components and always upper casing the realm part on storage. If we always store a krbCanonicalName we get the "correct" case there anyway so out mucking with the krbPrincipalName case will not be a problem for any new entry. This *may* cause issues with upgrades though, so we may need fallback code that searches with the case sent by the client if we determine the entry has no krbCanonicalName attribute (sign that it was created before we started adding krbCanonicalName and never "updated"). Note that we also need to think what will happen during and upgrade when some servers still use the current code and some servers will use the new code. So I guess it would be nice if you could write down a table with all possible forms a principal can be in on rows, and old/new server states in columns, and mark what will happen for various operations in each case. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Tue Sep 1 15:15:57 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 1 Sep 2015 17:15:57 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55E5B8A7.9090700@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> Message-ID: <55E5C12D.1040007@redhat.com> On 09/01/2015 04:39 PM, Jan Cholasta wrote: > On 1.9.2015 16:26, Jan Cholasta wrote: >> On 26.8.2015 13:22, Petr Vobornik wrote: >>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>> adds commands: >>>> * vaultcontainer-show [--service |--user ] >>>> * vaultcontainer-add-owner >>>> [--service |--user ] >>>> [--users ] [--groups ] [--services ] >>>> * vaultcontainer-remove-owner >>>> [--service |--user ] >>>> [--users ] [--groups ] [--services ] >>>> >>>> https://fedorahosted.org/freeipa/ticket/5250 >>>> >>>> Use cases: >>>> 1. When user/service is deleted, associated vault container looses >>>> owner. There was no API command to set the owner. >>>> 2. Change owner of container by admin to manage access. >>>> >>>> Show command was added to show current owners. >>>> >>>> Find command was not added, should it be? >>>> >>>> >>> >>> There is also a design for vault container ownership handling created by >>> Endi - it's for future Vault 2.0. >>> >>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>> >>> This patch has a different API than the proposed - different way of >>> specifying the container. The design page uses path e.g. /users/foobar. >>> This patch uses the same way as vaults e.g. --user=foobar. This means >>> that the implementation in this patch cannot manage ownership of parent >>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>> >>> Do we want to go with this approach in 4.2? >>> >>> Attaching also new path which removes setting of owner which doesn't >>> exist so that integrity is OK and that it is consistent with removing of >>> user. >>> >>> Updated patch attached - output fix. >> >> We had a long discussion about this with Petr and we think the best >> approach is as follows: >> >> * Add new "Vault administrators" privilege. Vault administrators will >> have unrestricted access to vaults and vault containers, including the >> power to add/remove owners of vaults and vault containers. >> >> * Remove the ability of vault owners to add/remove other vault >> owners. If vault owner needs to be changed, vault administrator has to >> do it. Note that vault owners will still have the ability to add/remove >> vault members. >> >> * When adding new vault container, set owner to the current user. If >> vault container owner needs to be changed, vault administrator has to do >> it. >> >> * Allow adding vaults and vault containers only if the owner is set >> to the current user. >> >> * Introduce commands to modify vault container owner and to delete >> vault container, so the administrator has a choice between assigning >> ownership or deleting an unowned container. > > Also: > > * Control access to vault data using an ipaProtectedOperation ACI. > Users which have read access to "ipaProtectedOperation;accessKRA" on a > vault can retrieve data from the vault and users which have write access > to "ipaProtectedOperation;accessKRA" on a vault can archive data in the > vault. > > Honza > +1 CCing Simo and Endi to check the proposal. And Scott (related to #5216, #5215) -- Petr Vobornik From simo at redhat.com Tue Sep 1 15:22:52 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Sep 2015 11:22:52 -0400 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55E5C12D.1040007@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> Message-ID: <1441120972.28131.130.camel@willson.usersys.redhat.com> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: > On 09/01/2015 04:39 PM, Jan Cholasta wrote: > > On 1.9.2015 16:26, Jan Cholasta wrote: > >> On 26.8.2015 13:22, Petr Vobornik wrote: > >>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: > >>>> adds commands: > >>>> * vaultcontainer-show [--service |--user ] > >>>> * vaultcontainer-add-owner > >>>> [--service |--user ] > >>>> [--users ] [--groups ] [--services ] > >>>> * vaultcontainer-remove-owner > >>>> [--service |--user ] > >>>> [--users ] [--groups ] [--services ] > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/5250 > >>>> > >>>> Use cases: > >>>> 1. When user/service is deleted, associated vault container looses > >>>> owner. There was no API command to set the owner. > >>>> 2. Change owner of container by admin to manage access. > >>>> > >>>> Show command was added to show current owners. > >>>> > >>>> Find command was not added, should it be? > >>>> > >>>> > >>> > >>> There is also a design for vault container ownership handling created by > >>> Endi - it's for future Vault 2.0. > >>> > >>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner > >>> > >>> This patch has a different API than the proposed - different way of > >>> specifying the container. The design page uses path e.g. /users/foobar. > >>> This patch uses the same way as vaults e.g. --user=foobar. This means > >>> that the implementation in this patch cannot manage ownership of parent > >>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. > >>> > >>> Do we want to go with this approach in 4.2? > >>> > >>> Attaching also new path which removes setting of owner which doesn't > >>> exist so that integrity is OK and that it is consistent with removing of > >>> user. > >>> > >>> Updated patch attached - output fix. > >> > >> We had a long discussion about this with Petr and we think the best > >> approach is as follows: > >> > >> * Add new "Vault administrators" privilege. Vault administrators will > >> have unrestricted access to vaults and vault containers, including the > >> power to add/remove owners of vaults and vault containers. > >> > >> * Remove the ability of vault owners to add/remove other vault > >> owners. If vault owner needs to be changed, vault administrator has to > >> do it. Note that vault owners will still have the ability to add/remove > >> vault members. > >> > >> * When adding new vault container, set owner to the current user. If > >> vault container owner needs to be changed, vault administrator has to do > >> it. > >> > >> * Allow adding vaults and vault containers only if the owner is set > >> to the current user. > >> > >> * Introduce commands to modify vault container owner and to delete > >> vault container, so the administrator has a choice between assigning > >> ownership or deleting an unowned container. > > > > Also: > > > > * Control access to vault data using an ipaProtectedOperation ACI. > > Users which have read access to "ipaProtectedOperation;accessKRA" on a > > vault can retrieve data from the vault and users which have write access > > to "ipaProtectedOperation;accessKRA" on a vault can archive data in the > > vault. > > > > Honza > > > > +1 > > CCing Simo and Endi to check the proposal. > > And Scott (related to #5216, #5215) Sounds reasonable to me. I can see that allowing owners to hand over vaults w/o admin intervention may have some appeal in some use cases, but I also see it can bring downsides with it, so all in all I think I agree with the above points. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Tue Sep 1 15:55:01 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 1 Sep 2015 17:55:01 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <1441119222.28131.125.camel@willson.usersys.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> Message-ID: <55E5CA55.7090104@redhat.com> On 09/01/2015 04:53 PM, Simo Sorce wrote: > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >> Hi list, >> >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >> and I would like to clarify what needs to be done in order to make IPA >> to fully support multiple aliases per entry. >> >> So far I have identified these task based on the ticket comments and >> discussion with Simo way back in the past: >> >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >> not used in the new code. >> >> 2.) fix ACIs that do not permit setting multiple values of >> 'krbPrincipalName' attribute per entry (see >> https://fedorahosted.org/freeipa/ticket/3961) >> >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >> 'ipadb_find_principal' functions) to correctly perform lookup of >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >> case-insensitively and krbcanonicalname case-sensitively, return >> krbcanonicalname when canonicalization is requested. >> >> 4.) Modify KDB backend and IPA framework to handle creation of both >> krbprincipalname and krbcanonicalname. I am not quite sure what cases >> should be covered here (I remember that we should create >> krbcanonicalname when we add another aliases to krbprincipalname), so it >> would be nice if you could comment on this. >> >> 5.) write tests which cover all this stuff so that we don't shoot >> ourselves in the foot. >> >> I am not very well versed in Kerberos so I might get some of this stuff >> wrong. If that's the case please point me to the right direction. Also >> please write me some additional stuff which I have fogot and needs to be >> done. >> > > I think the summary is correct, the only thing we need to be careful is > to keep handling entries that have only a single valued krbprincipalname > correctly as that will happen in upgrade paths and potentially if > someone uses external tools. > Just to be sure, the new code should add 'krbcanonicalname' even if 'krbprinicpalname' contains only single value? So if for example we create a new entry, should it have both krbprincipalname and krbcanonical name set at creation? > The tricky part for point 3 is to implement it *without* changing the > schema. KrbPrincipalName is case-sensitive, however I think we can solve > the issue of "searching case-insensitively" by always lower-casing the > principal name components and always upper casing the realm part on > storage. If we always store a krbCanonicalName we get the "correct" case > there anyway so out mucking with the krbPrincipalName case will not be a > problem for any new entry. > > This *may* cause issues with upgrades though, so we may need fallback > code that searches with the case sent by the client if we determine the > entry has no krbCanonicalName attribute (sign that it was created before > we started adding krbCanonicalName and never "updated"). > > Note that we also need to think what will happen during and upgrade when > some servers still use the current code and some servers will use the > new code. So I guess it would be nice if you could write down a table > with all possible forms a principal can be in on rows, and old/new > server states in columns, and mark what will happen for various > operations in each case. > Yes we need to be extra careful to get it right here. > Simo. > -- Martin^3 Babinsky From simo at redhat.com Tue Sep 1 16:00:02 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Sep 2015 12:00:02 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E5CA55.7090104@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E5CA55.7090104@redhat.com> Message-ID: <1441123202.28131.131.camel@willson.usersys.redhat.com> On Tue, 2015-09-01 at 17:55 +0200, Martin Babinsky wrote: > On 09/01/2015 04:53 PM, Simo Sorce wrote: > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >> Hi list, > >> > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >> and I would like to clarify what needs to be done in order to make IPA > >> to fully support multiple aliases per entry. > >> > >> So far I have identified these task based on the ticket comments and > >> discussion with Simo way back in the past: > >> > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >> not used in the new code. > >> > >> 2.) fix ACIs that do not permit setting multiple values of > >> 'krbPrincipalName' attribute per entry (see > >> https://fedorahosted.org/freeipa/ticket/3961) > >> > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >> 'ipadb_find_principal' functions) to correctly perform lookup of > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >> case-insensitively and krbcanonicalname case-sensitively, return > >> krbcanonicalname when canonicalization is requested. > >> > >> 4.) Modify KDB backend and IPA framework to handle creation of both > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >> should be covered here (I remember that we should create > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > >> would be nice if you could comment on this. > >> > >> 5.) write tests which cover all this stuff so that we don't shoot > >> ourselves in the foot. > >> > >> I am not very well versed in Kerberos so I might get some of this stuff > >> wrong. If that's the case please point me to the right direction. Also > >> please write me some additional stuff which I have fogot and needs to be > >> done. > >> > > > > I think the summary is correct, the only thing we need to be careful is > > to keep handling entries that have only a single valued krbprincipalname > > correctly as that will happen in upgrade paths and potentially if > > someone uses external tools. > > > > Just to be sure, the new code should add 'krbcanonicalname' even if > 'krbprinicpalname' contains only single value? So if for example we > create a new entry, should it have both krbprincipalname and > krbcanonical name set at creation? It wouldn't hurt. Simo. > > The tricky part for point 3 is to implement it *without* changing the > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > the issue of "searching case-insensitively" by always lower-casing the > > principal name components and always upper casing the realm part on > > storage. If we always store a krbCanonicalName we get the "correct" case > > there anyway so out mucking with the krbPrincipalName case will not be a > > problem for any new entry. > > > > This *may* cause issues with upgrades though, so we may need fallback > > code that searches with the case sent by the client if we determine the > > entry has no krbCanonicalName attribute (sign that it was created before > > we started adding krbCanonicalName and never "updated"). > > > > Note that we also need to think what will happen during and upgrade when > > some servers still use the current code and some servers will use the > > new code. So I guess it would be nice if you could write down a table > > with all possible forms a principal can be in on rows, and old/new > > server states in columns, and mark what will happen for various > > operations in each case. > > > Yes we need to be extra careful to get it right here. > > Simo. > > > > -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Sep 1 16:16:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 1 Sep 2015 18:16:59 +0200 Subject: [Freeipa-devel] [PATCH 0057] DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5 Message-ID: <55E5CF7B.6080809@redhat.com> Hello, DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5. This fixes an forgotten TODO in ipa-ods-exporter. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0057-DNSSEC-Wrap-master-key-using-RSA-OAEP-instead-of-old.patch Type: text/x-patch Size: 1522 bytes Desc: not available URL: From ftweedal at redhat.com Wed Sep 2 01:16:21 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 2 Sep 2015 11:16:21 +1000 Subject: [Freeipa-devel] [PATCH] 0041 certprofile: remove 'rename' option Message-ID: <20150902011621.GN5879@dhcp-40-8.bne.redhat.com> This patch *removes* the --rename option from certprofile-mod. For context see: https://bugzilla.redhat.com/show_bug.cgi?id=1257163#c6 Thanks, Fraser -------------- next part -------------- From 89fae00bfa31cca3784afbbf057a62942e6729e3 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 1 Sep 2015 21:04:34 -0400 Subject: [PATCH] certprofile: remove 'rename' option The initial fix of ticket 5247 rejected renames, but left the option behind for API compatibility. Remove the option now, according to the consensus that because it never worked, it is fine to remove it. Fixes: https://fedorahosted.org/freeipa/ticket/5247 --- API.txt | 3 +-- VERSION | 4 ++-- ipalib/plugins/certprofile.py | 3 +-- 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/API.txt b/API.txt index 871ddb5b7ee8b9bbae219eac673d52ad7229edc7..5253e1585e000f39d6e185a94548037dfe54d4d8 100644 --- a/API.txt +++ b/API.txt @@ -731,7 +731,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: certprofile_mod -args: 1,11,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='id', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -740,7 +740,6 @@ option: Str('description', attribute=True, autofill=False, cli_name='desc', mult option: File('file?', cli_name='file') option: Bool('ipacertprofilestoreissued', attribute=True, autofill=False, cli_name='store', default=True, multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') -option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) option: Flag('rights', autofill=True, default=False) option: Str('setattr*', cli_name='setattr', exclude='webui') option: Str('version?', exclude='webui') diff --git a/VERSION b/VERSION index c102e020bbbec921b0f4a2141d1c768ac093acf8..da721fdd548023dc3dcd9b4f6a8ba72922a3c6f2 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=154 -# Last change: pvoborni - change default vault type to 'symmetric' +IPA_API_VERSION_MINOR=155 +# Last change: ftweedal - remove certprofile 'rename' option diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index a0ffa38608400860994c771e4eba81304ead27be..bd835f4c241ba1936555869d481262a8093bbb42 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -115,7 +115,6 @@ class certprofile(LDAPObject): search_attributes = [ 'cn', 'description', 'ipacertprofilestoreissued' ] - rdn_is_primary_key = True label = _('Certificate Profiles') label_singular = _('Certificate Profile') @@ -323,7 +322,7 @@ class certprofile_mod(LDAPUpdate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): ca_enabled_check() # Once a profile id is set it cannot be changed - if 'rename' in options or 'cn' in entry_attrs: + if 'cn' in entry_attrs: raise errors.ProtectedEntryError(label='certprofile', key=keys[0], reason=_('Certificate profiles cannot be renamed')) if 'file' in options: -- 2.4.3 From edewata at redhat.com Wed Sep 2 04:42:33 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 1 Sep 2015 23:42:33 -0500 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E54B22.1050508@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> <55E53265.4010400@redhat.com> <55E54B22.1050508@redhat.com> Message-ID: <55E67E39.3090907@redhat.com> On 9/1/2015 1:52 AM, Martin Basti wrote: >>>>> The CA and KRA installation code has been modified to use LDAPI >>>>> to create the CA and KRA agents directly in the CA and KRA >>>>> database. This way it's no longer necessary to use the Directory >>>>> Manager password or CA and KRA admin certificate. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5257 >>>>> >>>>> >>>>> >>>> >>>> Thank you. >>>> >>>> 1) Can you use following code instead of direct call of ldap2.ldap2()? >>>> >>>> if not api.Backend.ldap2.is_connected(): >>>> api.Backend.ldap2.connect(autobind=True) >>>> >>>> conn = api.Backend.ldap2 >> >> Why would you want to do that? The original code is fine, except the >> connection check is not necessary (it is a new instance of ldap2, so >> .isconnected() will always return False). >> >>> >>> It's actually isconnected() instead of is_connected(), but even so, the >>> proposed code doesn't work: >>> >>> ipa.ipapython.install.cli.install_tool(Server): DEBUG The >>> ipa-server-install command failed, exception: TypeError: 'ldap2' object >>> is not callable >>> ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object >>> is not callable >>> >>>> 2) Patch needs rebase to master branch. >>> >>> The original patch does apply cleanly to master. Did you see a conflict? > Sorry my bad. > > Martin^2 >>> >>>> 3) >>>> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) >>>> + conn.create( >>>> + dn=user_dn, >>>> >>>> can you use add entry() instead of create()? We don't use native >>>> python-ldap, but rather ipaldap methods >>> >>> It's actually calling the ldap2.create() defined in >>> ipaserver/plugins/ldap2.py, which calls add_entry(). >> >> NACK. We don't use ldap2.create(). Use add_entry(). >> >>> >>> So my original patch still stands. New patch attached. -- Endi S. Dewata -------------- next part -------------- >From e03882e89d2acdb23fe289d59dd2db04662bf051 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Thu, 27 Aug 2015 06:44:29 +0200 Subject: [PATCH] Using LDAPI to setup CA and KRA agents. The CA and KRA installation code has been modified to use LDAPI to create the CA and KRA agents directly in the CA and KRA database. This way it's no longer necessary to use the Directory Manager password or CA and KRA admin certificate. https://fedorahosted.org/freeipa/ticket/5257 --- ipaplatform/base/paths.py | 2 - ipaserver/install/cainstance.py | 49 ++++++++++------- ipaserver/install/krainstance.py | 113 +++++++++++++++------------------------ ipaserver/plugins/ldap2.py | 2 + 4 files changed, 74 insertions(+), 92 deletions(-) diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index 5c8f25d6ef85fab2b9b30a660cd1c0360dbe9931..0dd3c7fda3020264a1ace8f2d13557cfddf18c2d 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -343,8 +343,6 @@ class BasePathNamespace(object): SLAPD_INSTANCE_SOCKET_TEMPLATE = "/var/run/slapd-%s.socket" ALL_SLAPD_INSTANCE_SOCKETS = "/var/run/slapd-*.socket" ADMIN_CERT_PATH = '/root/.dogtag/pki-tomcat/ca_admin.cert' - KRA_NSSDB_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/password.conf" - KRA_PKCS12_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/pkcs12_password.conf" ENTROPY_AVAIL = '/proc/sys/kernel/random/entropy_avail' LDIF2DB = '/usr/sbin/ldif2db' DB2LDIF = '/usr/sbin/db2ldif' diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 6f565dd14a1ce3f22bf1d033eed364dc4b87281b..85ce6cba59442fe934cc96f4983b21c16d9ea8de 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -466,7 +466,7 @@ class CAInstance(DogtagInstance): self.step("restarting certificate server", self.restart_instance) self.step("requesting RA certificate from CA", self.__request_ra_certificate) self.step("issuing RA agent certificate", self.__issue_ra_cert) - self.step("adding RA agent as a trusted user", self.__configure_ra) + self.step("adding RA agent as a trusted user", self.__create_ca_agent) self.step("authorizing RA to modify profiles", self.__configure_profiles_acl) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) @@ -905,18 +905,26 @@ class CAInstance(DogtagInstance): self.configure_agent_renewal() - def __configure_ra(self): - # Create an RA user in the CA LDAP server and add that user to - # the appropriate groups so it can issue certificates without - # manual intervention. - conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) - conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) + def __create_ca_agent(self): + """ + Create CA agent, assign a certificate, and add the user to + the appropriate groups for accessing CA services. + """ - decoded = base64.b64decode(self.ra_cert) + # get ipaCert certificate + cert_data = base64.b64decode(self.ra_cert) + cert = x509.load_certificate(cert_data, x509.DER) - entry_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) + # connect to CA database + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) + conn.connect(autobind=True) + + # create ipara user with ipaCert certificate + user_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) entry = conn.make_entry( - entry_dn, + user_dn, objectClass=['top', 'person', 'organizationalPerson', 'inetOrgPerson', 'cmsuser'], uid=["ipara"], @@ -924,23 +932,24 @@ class CAInstance(DogtagInstance): cn=["ipara"], usertype=["agentType"], userstate=["1"], - userCertificate=[decoded], + userCertificate=[cert_data], description=['2;%s;%s;%s' % ( - str(self.requestId), + cert.serial_number, DN(('CN', 'Certificate Authority'), self.subject_base), DN(('CN', 'IPA RA'), self.subject_base))]) - conn.add_entry(entry) - dn = DN(('cn', 'Certificate Manager Agents'), ('ou', 'groups'), self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) + # add ipara user to Certificate Manager Agents group + group_dn = DN(('cn', 'Certificate Manager Agents'), ('ou', 'groups'), + self.basedn) + conn.add_entry_to_group(user_dn, group_dn, 'uniqueMember') - dn = DN(('cn', 'Registration Manager Agents'), ('ou', 'groups'), self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) + # add ipara user to Registration Manager Agents group + group_dn = DN(('cn', 'Registration Manager Agents'), ('ou', 'groups'), + self.basedn) + conn.add_entry_to_group(user_dn, group_dn, 'uniqueMember') - conn.unbind() + conn.disconnect() def __configure_profiles_acl(self): """Allow the Certificate Manager Agents group to modify profiles.""" diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index e5cdbf5e7714603041e3f0156e87311994175b18..958fe6fb095e69f83342ce8299d1586b8bbacd47 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -25,17 +25,21 @@ import sys import tempfile from ipalib import api +from ipalib import x509 from ipaplatform import services from ipaplatform.paths import paths +from ipapython import certdb from ipapython import dogtag from ipapython import ipautil from ipapython.dn import DN from ipaserver.install import certs from ipaserver.install import cainstance +from ipaserver.install import installutils from ipaserver.install import ldapupdate from ipaserver.install import service from ipaserver.install.dogtaginstance import DogtagInstance from ipaserver.install.dogtaginstance import DEFAULT_DSPORT, PKI_USER +from ipaserver.plugins import ldap2 from ipapython.ipa_log_manager import log_mgr # When IPA is installed with DNS support, this CNAME should hold all IPA @@ -111,8 +115,8 @@ class KRAInstance(DogtagInstance): self.step("configuring KRA instance", self.__spawn_instance) if not self.clone: - self.step("add RA user to KRA agent group", - self.__add_ra_user_to_agent_group) + self.step("create KRA agent", + self.__create_kra_agent) self.step("restarting KRA", self.restart_instance) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) @@ -267,77 +271,46 @@ class KRAInstance(DogtagInstance): self.log.debug("completed creating KRA instance") - def __add_ra_user_to_agent_group(self): + def __create_kra_agent(self): """ - Add RA agent created for CA to KRA agent group. + Create KRA agent, assign a certificate, and add the user to + the appropriate groups for accessing KRA services. """ - # import CA certificate into temporary security database - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "client-cert-import", - "--pkcs12", paths.KRACERT_P12, - "--pkcs12-password-file", paths.KRA_PKCS12_PASSWORD_FILE] - ipautil.run(args) - - # trust CA certificate - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "client-cert-mod", "Certificate Authority - %s" % api.env.realm, - "--trust", "CT,c,"] - ipautil.run(args) - - # import Dogtag admin certificate into temporary security database - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "client-cert-import", - "--pkcs12", paths.DOGTAG_ADMIN_P12, - "--pkcs12-password-file", paths.KRA_PKCS12_PASSWORD_FILE] - ipautil.run(args) - - # as Dogtag admin, create ipakra user in KRA - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "-n", "ipa-ca-agent", - "kra-user-add", "ipakra", - "--fullName", "IPA KRA User"] - ipautil.run(args) - - # as Dogtag admin, add ipakra into KRA agents group - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "-n", "ipa-ca-agent", - "kra-user-membership-add", "ipakra", "Data Recovery Manager Agents"] - ipautil.run(args) - - # assign ipaCert to ipakra - (file, filename) = tempfile.mkstemp() - os.close(file) - try: - # export ipaCert without private key - args = ["/usr/bin/pki", - "-d", paths.HTTPD_ALIAS_DIR, - "-C", paths.ALIAS_PWDFILE_TXT, - "client-cert-show", "ipaCert", - "--cert", filename] - ipautil.run(args) - - # as Dogtag admin, upload and assign ipaCert to ipakra - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "-n", "ipa-ca-agent", - "kra-user-cert-add", "ipakra", - "--input", filename] - ipautil.run(args) - - finally: - os.remove(filename) + # get ipaCert certificate + with certdb.NSSDatabase(paths.HTTPD_ALIAS_DIR) as ipa_nssdb: + cert_data = ipa_nssdb.get_cert("ipaCert") + cert = x509.load_certificate(cert_data, x509.DER) + + # connect to KRA database + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) + conn.connect(autobind=True) + + # create ipakra user with ipaCert certificate + user_dn = DN(('uid', "ipakra"), ('ou', 'people'), self.basedn) + entry = conn.make_entry( + user_dn, + objectClass=['top', 'person', 'organizationalPerson', + 'inetOrgPerson', 'cmsuser'], + uid=["ipakra"], + sn=["IPA KRA User"], + cn=["IPA KRA User"], + usertype=["undefined"], + userCertificate=[cert_data], + description=['2;%s;%s;%s' % ( + cert.serial_number, + DN(('CN', 'Certificate Authority'), self.subject_base), + DN(('CN', 'IPA RA'), self.subject_base))]) + conn.add_entry(entry) + + # add ipakra user to Data Recovery Manager Agents group + group_dn = DN(('cn', 'Data Recovery Manager Agents'), ('ou', 'groups'), + self.basedn) + conn.add_entry_to_group(user_dn, group_dn, 'uniqueMember') + + conn.disconnect() def __add_vault_container(self): sub_dict = { diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py index acaf45fddb7ba54a42af15270534e1cde81fc2bd..7e19802e2350ecbefcabbc3f3626e19fd759cf73 100644 --- a/ipaserver/plugins/ldap2.py +++ b/ipaserver/plugins/ldap2.py @@ -493,6 +493,8 @@ class ldap2(CrudBackend, LDAPClient): Create a new entry and return it as one dict (DN included). Extends CrudBackend.create. + + NOTE: Do not use this method. """ assert 'dn' in kw dn = kw['dn'] -- 2.4.3 From edewata at redhat.com Wed Sep 2 05:26:48 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 2 Sep 2015 00:26:48 -0500 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <1441120972.28131.130.camel@willson.usersys.redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> Message-ID: <55E68898.1000300@redhat.com> On 9/1/2015 10:22 AM, Simo Sorce wrote: > On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>> adds commands: >>>>>> * vaultcontainer-show [--service |--user ] >>>>>> * vaultcontainer-add-owner >>>>>> [--service |--user ] >>>>>> [--users ] [--groups ] [--services ] >>>>>> * vaultcontainer-remove-owner >>>>>> [--service |--user ] >>>>>> [--users ] [--groups ] [--services ] >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>> >>>>>> Use cases: >>>>>> 1. When user/service is deleted, associated vault container looses >>>>>> owner. There was no API command to set the owner. >>>>>> 2. Change owner of container by admin to manage access. >>>>>> >>>>>> Show command was added to show current owners. >>>>>> >>>>>> Find command was not added, should it be? >>>>>> >>>>>> >>>>> >>>>> There is also a design for vault container ownership handling created by >>>>> Endi - it's for future Vault 2.0. >>>>> >>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>> >>>>> This patch has a different API than the proposed - different way of >>>>> specifying the container. The design page uses path e.g. /users/foobar. >>>>> This patch uses the same way as vaults e.g. --user=foobar. This means >>>>> that the implementation in this patch cannot manage ownership of parent >>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>> >>>>> Do we want to go with this approach in 4.2? >>>>> >>>>> Attaching also new path which removes setting of owner which doesn't >>>>> exist so that integrity is OK and that it is consistent with removing of >>>>> user. >>>>> >>>>> Updated patch attached - output fix. >>>> >>>> We had a long discussion about this with Petr and we think the best >>>> approach is as follows: >>>> >>>> * Add new "Vault administrators" privilege. Vault administrators will >>>> have unrestricted access to vaults and vault containers, including the >>>> power to add/remove owners of vaults and vault containers. >>>> >>>> * Remove the ability of vault owners to add/remove other vault >>>> owners. If vault owner needs to be changed, vault administrator has to >>>> do it. Note that vault owners will still have the ability to add/remove >>>> vault members. >>>> >>>> * When adding new vault container, set owner to the current user. If >>>> vault container owner needs to be changed, vault administrator has to do >>>> it. >>>> >>>> * Allow adding vaults and vault containers only if the owner is set >>>> to the current user. >>>> >>>> * Introduce commands to modify vault container owner and to delete >>>> vault container, so the administrator has a choice between assigning >>>> ownership or deleting an unowned container. >>> >>> Also: >>> >>> * Control access to vault data using an ipaProtectedOperation ACI. >>> Users which have read access to "ipaProtectedOperation;accessKRA" on a >>> vault can retrieve data from the vault and users which have write access >>> to "ipaProtectedOperation;accessKRA" on a vault can archive data in the >>> vault. >>> >>> Honza >>> >> >> +1 >> >> CCing Simo and Endi to check the proposal. >> >> And Scott (related to #5216, #5215) > > Sounds reasonable to me. > I can see that allowing owners to hand over vaults w/o admin > intervention may have some appeal in some use cases, but I also see it > can bring downsides with it, so all in all I think I agree with the > above points. > > Simo. > Not a total objection, but if many people in unrelated groups are using vaults, and they are sharing the vaults only with members of each group, having to ask a Vault Administrator for each ownership change sounds a bit cumbersome. Since the Vault Adminstrator will have access to all vaults in all groups, only a small number of people can be trusted to hold that role. If there are many ownership changes the Vault Administrator will have to handle all those requests, and the vault users may have to wait until the change is completed. If owners are allowed to add others as owners, the vaults will be pretty much maintenance free to the admin. Regardless, please update the wiki page to describe the new behavior when it's implemented: http://www.freeipa.org/page/V4/Password_Vault_1.1 -- Endi S. Dewata From jcholast at redhat.com Wed Sep 2 06:08:09 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 2 Sep 2015 08:08:09 +0200 Subject: [Freeipa-devel] [PATCH] 0041 certprofile: remove 'rename' option In-Reply-To: <20150902011621.GN5879@dhcp-40-8.bne.redhat.com> References: <20150902011621.GN5879@dhcp-40-8.bne.redhat.com> Message-ID: <55E69249.6050609@redhat.com> Hi, On 2.9.2015 03:16, Fraser Tweedale wrote: > This patch *removes* the --rename option from certprofile-mod. > For context see: https://bugzilla.redhat.com/show_bug.cgi?id=1257163#c6 Instead of just removing it, you could also add: DeprecatedParam( 'rename?', label=_("Rename"), doc=_("Rename the Certificate Profile object"), ) to certprofile_mod.takes_options to make the option available, but deprecated. Honza -- Jan Cholasta From dkupka at redhat.com Wed Sep 2 06:11:32 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 2 Sep 2015 08:11:32 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <1441119222.28131.125.camel@willson.usersys.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> Message-ID: <55E69314.9070804@redhat.com> On 01/09/15 16:53, Simo Sorce wrote: > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >> Hi list, >> >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >> and I would like to clarify what needs to be done in order to make IPA >> to fully support multiple aliases per entry. >> >> So far I have identified these task based on the ticket comments and >> discussion with Simo way back in the past: >> >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >> not used in the new code. >> >> 2.) fix ACIs that do not permit setting multiple values of >> 'krbPrincipalName' attribute per entry (see >> https://fedorahosted.org/freeipa/ticket/3961) >> >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >> 'ipadb_find_principal' functions) to correctly perform lookup of >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >> case-insensitively and krbcanonicalname case-sensitively, return >> krbcanonicalname when canonicalization is requested. >> >> 4.) Modify KDB backend and IPA framework to handle creation of both >> krbprincipalname and krbcanonicalname. I am not quite sure what cases >> should be covered here (I remember that we should create >> krbcanonicalname when we add another aliases to krbprincipalname), so it >> would be nice if you could comment on this. >> >> 5.) write tests which cover all this stuff so that we don't shoot >> ourselves in the foot. >> >> I am not very well versed in Kerberos so I might get some of this stuff >> wrong. If that's the case please point me to the right direction. Also >> please write me some additional stuff which I have fogot and needs to be >> done. >> > > I think the summary is correct, the only thing we need to be careful is > to keep handling entries that have only a single valued krbprincipalname > correctly as that will happen in upgrade paths and potentially if > someone uses external tools. > > The tricky part for point 3 is to implement it *without* changing the > schema. KrbPrincipalName is case-sensitive, however I think we can solve > the issue of "searching case-insensitively" by always lower-casing the > principal name components and always upper casing the realm part on > storage. If we always store a krbCanonicalName we get the "correct" case > there anyway so out mucking with the krbPrincipalName case will not be a > problem for any new entry. Or as Honza pointed out we can use case-insensitive search like this: (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return all variants of casing and reduce the need for fallback code. > > This *may* cause issues with upgrades though, so we may need fallback > code that searches with the case sent by the client if we determine the > entry has no krbCanonicalName attribute (sign that it was created before > we started adding krbCanonicalName and never "updated"). > > Note that we also need to think what will happen during and upgrade when > some servers still use the current code and some servers will use the > new code. So I guess it would be nice if you could write down a table > with all possible forms a principal can be in on rows, and old/new > server states in columns, and mark what will happen for various > operations in each case. > > Simo. > -- David Kupka From pspacek at redhat.com Wed Sep 2 06:36:15 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 2 Sep 2015 08:36:15 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E69314.9070804@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> Message-ID: <55E698DF.2060309@redhat.com> On 2.9.2015 08:11, David Kupka wrote: > On 01/09/15 16:53, Simo Sorce wrote: >> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>> Hi list, >>> >>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>> and I would like to clarify what needs to be done in order to make IPA >>> to fully support multiple aliases per entry. >>> >>> So far I have identified these task based on the ticket comments and >>> discussion with Simo way back in the past: >>> >>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>> not used in the new code. >>> >>> 2.) fix ACIs that do not permit setting multiple values of >>> 'krbPrincipalName' attribute per entry (see >>> https://fedorahosted.org/freeipa/ticket/3961) >>> >>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>> 'ipadb_find_principal' functions) to correctly perform lookup of >>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>> case-insensitively and krbcanonicalname case-sensitively, return >>> krbcanonicalname when canonicalization is requested. >>> >>> 4.) Modify KDB backend and IPA framework to handle creation of both >>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>> should be covered here (I remember that we should create >>> krbcanonicalname when we add another aliases to krbprincipalname), so it >>> would be nice if you could comment on this. >>> >>> 5.) write tests which cover all this stuff so that we don't shoot >>> ourselves in the foot. >>> >>> I am not very well versed in Kerberos so I might get some of this stuff >>> wrong. If that's the case please point me to the right direction. Also >>> please write me some additional stuff which I have fogot and needs to be >>> done. >>> >> >> I think the summary is correct, the only thing we need to be careful is >> to keep handling entries that have only a single valued krbprincipalname >> correctly as that will happen in upgrade paths and potentially if >> someone uses external tools. >> >> The tricky part for point 3 is to implement it *without* changing the >> schema. KrbPrincipalName is case-sensitive, however I think we can solve >> the issue of "searching case-insensitively" by always lower-casing the >> principal name components and always upper casing the realm part on >> storage. If we always store a krbCanonicalName we get the "correct" case >> there anyway so out mucking with the krbPrincipalName case will not be a >> problem for any new entry. > > Or as Honza pointed out we can use case-insensitive search like this: > (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return all > variants of casing and reduce the need for fallback code. +1, I was going to propose the very same thing. This is a standard LDAP thing, see http://tools.ietf.org/search/rfc4515#section-4 . Just keep in mind that we may need to add index for caseIgnoreMatch. Petr^2 Spacek >> This *may* cause issues with upgrades though, so we may need fallback >> code that searches with the case sent by the client if we determine the >> entry has no krbCanonicalName attribute (sign that it was created before >> we started adding krbCanonicalName and never "updated"). >> >> Note that we also need to think what will happen during and upgrade when >> some servers still use the current code and some servers will use the >> new code. So I guess it would be nice if you could write down a table >> with all possible forms a principal can be in on rows, and old/new >> server states in columns, and mark what will happen for various >> operations in each case. >> >> Simo. From ftweedal at redhat.com Wed Sep 2 06:37:25 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 2 Sep 2015 16:37:25 +1000 Subject: [Freeipa-devel] [PATCH] 0041 certprofile: remove 'rename' option In-Reply-To: <55E69249.6050609@redhat.com> References: <20150902011621.GN5879@dhcp-40-8.bne.redhat.com> <55E69249.6050609@redhat.com> Message-ID: <20150902063725.GQ5879@dhcp-40-8.bne.redhat.com> On Wed, Sep 02, 2015 at 08:08:09AM +0200, Jan Cholasta wrote: > Hi, > > On 2.9.2015 03:16, Fraser Tweedale wrote: > >This patch *removes* the --rename option from certprofile-mod. > >For context see: https://bugzilla.redhat.com/show_bug.cgi?id=1257163#c6 > > Instead of just removing it, you could also add: > > DeprecatedParam( > 'rename?', > label=_("Rename"), > doc=_("Rename the Certificate Profile object"), > ) > > to certprofile_mod.takes_options to make the option available, but > deprecated. > Petr Viktorin suggested that due to a) certprofile being a new command and b) rename having always been refused, it made sense to just remove it. Petr, are you in agreement or is Honza's suggestion the way to go? Cheers, Fraser > Honza > > -- > Jan Cholasta From jcholast at redhat.com Wed Sep 2 06:40:13 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 2 Sep 2015 08:40:13 +0200 Subject: [Freeipa-devel] [PATCH] 0041 certprofile: remove 'rename' option In-Reply-To: <20150902063725.GQ5879@dhcp-40-8.bne.redhat.com> References: <20150902011621.GN5879@dhcp-40-8.bne.redhat.com> <55E69249.6050609@redhat.com> <20150902063725.GQ5879@dhcp-40-8.bne.redhat.com> Message-ID: <55E699CD.6000001@redhat.com> On 2.9.2015 08:37, Fraser Tweedale wrote: > On Wed, Sep 02, 2015 at 08:08:09AM +0200, Jan Cholasta wrote: >> Hi, >> >> On 2.9.2015 03:16, Fraser Tweedale wrote: >>> This patch *removes* the --rename option from certprofile-mod. >>> For context see: https://bugzilla.redhat.com/show_bug.cgi?id=1257163#c6 >> >> Instead of just removing it, you could also add: >> >> DeprecatedParam( >> 'rename?', >> label=_("Rename"), >> doc=_("Rename the Certificate Profile object"), >> ) >> >> to certprofile_mod.takes_options to make the option available, but >> deprecated. >> > Petr Viktorin suggested that due to a) certprofile being a new > command and b) rename having always been refused, it made sense to > just remove it. > > Petr, are you in agreement or is Honza's suggestion the way to go? FYI I'm fine with just removing the option, this was just a suggestion in case deprecation was overlooked. -- Jan Cholasta From mbabinsk at redhat.com Wed Sep 2 08:18:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 2 Sep 2015 10:18:39 +0200 Subject: [Freeipa-devel] [PATCH 0302] DNSSEC: remove "DNSSEC is experimental" warnings In-Reply-To: <55E597E5.9010209@redhat.com> References: <55E44E05.8080603@redhat.com> <55E47B4B.5040800@redhat.com> <55E54C67.1000807@redhat.com> <55E597E5.9010209@redhat.com> Message-ID: <55E6B0DF.5050207@redhat.com> On 09/01/2015 02:19 PM, Martin Basti wrote: > > > On 09/01/2015 08:57 AM, Martin Basti wrote: >> >> >> On 08/31/2015 06:05 PM, Martin Kosek wrote: >>> On 08/31/2015 02:52 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5265 >>>> >>>> Patch attached. >>>> >>>> Should I remove also message class "DNSSECWarning" which is not used >>>> now, or >>>> just keep it there because ti has already registered error code? >>>> >>>> Martin^2 >>>> >>>> >>> Just for the record, I added more pointers to why we think DNSSEC is >>> now more >>> stabilized to the ticket - this is an important information that >>> should warrant >>> removal of the warning messages. >>> >> Thank you. >> > Rebased patches for master attached. > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Wed Sep 2 08:27:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 2 Sep 2015 10:27:43 +0200 Subject: [Freeipa-devel] [PATCH 0302] DNSSEC: remove "DNSSEC is experimental" warnings In-Reply-To: <55E6B0DF.5050207@redhat.com> References: <55E44E05.8080603@redhat.com> <55E47B4B.5040800@redhat.com> <55E54C67.1000807@redhat.com> <55E597E5.9010209@redhat.com> <55E6B0DF.5050207@redhat.com> Message-ID: <55E6B2FF.8080403@redhat.com> On 09/02/2015 10:18 AM, Martin Babinsky wrote: > On 09/01/2015 02:19 PM, Martin Basti wrote: >> >> >> On 09/01/2015 08:57 AM, Martin Basti wrote: >>> >>> >>> On 08/31/2015 06:05 PM, Martin Kosek wrote: >>>> On 08/31/2015 02:52 PM, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5265 >>>>> >>>>> Patch attached. >>>>> >>>>> Should I remove also message class "DNSSECWarning" which is not used >>>>> now, or >>>>> just keep it there because ti has already registered error code? >>>>> >>>>> Martin^2 >>>>> >>>>> >>>> Just for the record, I added more pointers to why we think DNSSEC is >>>> now more >>>> stabilized to the ticket - this is an important information that >>>> should warrant >>>> removal of the warning messages. >>>> >>> Thank you. >>> >> Rebased patches for master attached. >> >> > ACK > Pushed to master: 740f7fd817b399dd1a546a20ab260ea3a6cd4ed2 Pushed to ipa-4-2: cdad393413aeada5a33edcb2acc8de8f90667a89 From mbabinsk at redhat.com Wed Sep 2 11:19:11 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 2 Sep 2015 13:19:11 +0200 Subject: [Freeipa-devel] [PATCH 0303] backup: back up hosts file In-Reply-To: <55E5B61A.8010509@redhat.com> References: <55E5B61A.8010509@redhat.com> Message-ID: <55E6DB2F.6000105@redhat.com> On 09/01/2015 04:28 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5275 > > Patch attached > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Wed Sep 2 11:21:28 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 2 Sep 2015 13:21:28 +0200 Subject: [Freeipa-devel] [PATCH 0303] backup: back up hosts file In-Reply-To: <55E6DB2F.6000105@redhat.com> References: <55E5B61A.8010509@redhat.com> <55E6DB2F.6000105@redhat.com> Message-ID: <55E6DBB8.2010407@redhat.com> On 09/02/2015 01:19 PM, Martin Babinsky wrote: > On 09/01/2015 04:28 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5275 >> >> Patch attached >> >> > ACK > Pushed to: master: 7b3bd4e85d7d0358d7ee969bd9197358fd948798 ipa-4-2: e6a018276b262d4fa009a19c9f3607ba5818e008 From pvoborni at redhat.com Wed Sep 2 11:48:17 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 2 Sep 2015 13:48:17 +0200 Subject: [Freeipa-devel] [PATCH] 0041 certprofile: remove 'rename' option In-Reply-To: <55E699CD.6000001@redhat.com> References: <20150902011621.GN5879@dhcp-40-8.bne.redhat.com> <55E69249.6050609@redhat.com> <20150902063725.GQ5879@dhcp-40-8.bne.redhat.com> <55E699CD.6000001@redhat.com> Message-ID: <55E6E201.7050505@redhat.com> On 09/02/2015 08:40 AM, Jan Cholasta wrote: > On 2.9.2015 08:37, Fraser Tweedale wrote: >> On Wed, Sep 02, 2015 at 08:08:09AM +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 2.9.2015 03:16, Fraser Tweedale wrote: >>>> This patch *removes* the --rename option from certprofile-mod. >>>> For context see: https://bugzilla.redhat.com/show_bug.cgi?id=1257163#c6 >>> >>> Instead of just removing it, you could also add: >>> >>> DeprecatedParam( >>> 'rename?', >>> label=_("Rename"), >>> doc=_("Rename the Certificate Profile object"), >>> ) >>> >>> to certprofile_mod.takes_options to make the option available, but >>> deprecated. >>> >> Petr Viktorin suggested that due to a) certprofile being a new >> command and b) rename having always been refused, it made sense to >> just remove it. >> >> Petr, are you in agreement or is Honza's suggestion the way to go? > > FYI I'm fine with just removing the option, this was just a suggestion > in case deprecation was overlooked. > ACK Pushed to: master: 86cd47af0245a216324900be39be1a145bf0741b ipa-4-2: b7386dc98506d66c6cbb1083992ced7792f938bd -- Petr Vobornik From mkosek at redhat.com Wed Sep 2 12:10:52 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 2 Sep 2015 14:10:52 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <1441119222.28131.125.camel@willson.usersys.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> Message-ID: <55E6E74C.10704@redhat.com> On 09/01/2015 04:53 PM, Simo Sorce wrote: > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >> Hi list, >> >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >> and I would like to clarify what needs to be done in order to make IPA >> to fully support multiple aliases per entry. >> >> So far I have identified these task based on the ticket comments and >> discussion with Simo way back in the past: >> >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >> not used in the new code. >> >> 2.) fix ACIs that do not permit setting multiple values of >> 'krbPrincipalName' attribute per entry (see >> https://fedorahosted.org/freeipa/ticket/3961) >> >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >> 'ipadb_find_principal' functions) to correctly perform lookup of >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >> case-insensitively and krbcanonicalname case-sensitively, return >> krbcanonicalname when canonicalization is requested. >> >> 4.) Modify KDB backend and IPA framework to handle creation of both >> krbprincipalname and krbcanonicalname. I am not quite sure what cases >> should be covered here (I remember that we should create >> krbcanonicalname when we add another aliases to krbprincipalname), so it >> would be nice if you could comment on this. >> >> 5.) write tests which cover all this stuff so that we don't shoot >> ourselves in the foot. >> >> I am not very well versed in Kerberos so I might get some of this stuff >> wrong. If that's the case please point me to the right direction. Also >> please write me some additional stuff which I have fogot and needs to be >> done. >> > > I think the summary is correct, the only thing we need to be careful is > to keep handling entries that have only a single valued krbprincipalname > correctly as that will happen in upgrade paths and potentially if > someone uses external tools. > > The tricky part for point 3 is to implement it *without* changing the > schema. KrbPrincipalName is case-sensitive, however I think we can solve > the issue of "searching case-insensitively" by always lower-casing the > principal name components and always upper casing the realm part on > storage. If we always store a krbCanonicalName we get the "correct" case > there anyway so out mucking with the krbPrincipalName case will not be a > problem for any new entry. > > This *may* cause issues with upgrades though, so we may need fallback > code that searches with the case sent by the client if we determine the > entry has no krbCanonicalName attribute (sign that it was created before > we started adding krbCanonicalName and never "updated"). > > Note that we also need to think what will happen during and upgrade when > some servers still use the current code and some servers will use the > new code. So I guess it would be nice if you could write down a table > with all possible forms a principal can be in on rows, and old/new > server states in columns, and mark what will happen for various > operations in each case. > > Simo. The list looks OK. Do we also plan to change the default RDN for new services or other objects that use krbPrincipalName as RDN at the moment? AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and then only allow krbPrincipalName to be added for the aliases. Of course, the framework needs to still work with old services having krbPrincipalName. From mbasti at redhat.com Wed Sep 2 12:12:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 2 Sep 2015 14:12:04 +0200 Subject: [Freeipa-devel] [PATCH 0304] Installer: do not modify /etc/hosts before user agreement Message-ID: <55E6E794.1090802@redhat.com> https://fedorahosted.org/freeipa/ticket/4561 This also fixes: https://fedorahosted.org/freeipa/ticket/5266 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-mbasti-0304-Installer-do-not-modify-etc-hosts-before-user-agreem.patch Type: text/x-patch Size: 9549 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.2-mbasti-0304-Installer-do-not-modify-etc-hosts-before-user-agreem.patch Type: text/x-patch Size: 9595 bytes Desc: not available URL: From sbose at redhat.com Wed Sep 2 12:19:21 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 2 Sep 2015 14:19:21 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E6E74C.10704@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E6E74C.10704@redhat.com> Message-ID: <20150902121921.GM5282@p.redhat.com> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > On 09/01/2015 04:53 PM, Simo Sorce wrote: > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >> Hi list, > >> > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >> and I would like to clarify what needs to be done in order to make IPA > >> to fully support multiple aliases per entry. > >> > >> So far I have identified these task based on the ticket comments and > >> discussion with Simo way back in the past: > >> > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >> not used in the new code. > >> > >> 2.) fix ACIs that do not permit setting multiple values of > >> 'krbPrincipalName' attribute per entry (see > >> https://fedorahosted.org/freeipa/ticket/3961) > >> > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >> 'ipadb_find_principal' functions) to correctly perform lookup of > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >> case-insensitively and krbcanonicalname case-sensitively, return > >> krbcanonicalname when canonicalization is requested. > >> > >> 4.) Modify KDB backend and IPA framework to handle creation of both > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >> should be covered here (I remember that we should create > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > >> would be nice if you could comment on this. > >> > >> 5.) write tests which cover all this stuff so that we don't shoot > >> ourselves in the foot. > >> > >> I am not very well versed in Kerberos so I might get some of this stuff > >> wrong. If that's the case please point me to the right direction. Also > >> please write me some additional stuff which I have fogot and needs to be > >> done. > >> > > > > I think the summary is correct, the only thing we need to be careful is > > to keep handling entries that have only a single valued krbprincipalname > > correctly as that will happen in upgrade paths and potentially if > > someone uses external tools. > > > > The tricky part for point 3 is to implement it *without* changing the > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > the issue of "searching case-insensitively" by always lower-casing the > > principal name components and always upper casing the realm part on > > storage. If we always store a krbCanonicalName we get the "correct" case > > there anyway so out mucking with the krbPrincipalName case will not be a > > problem for any new entry. > > > > This *may* cause issues with upgrades though, so we may need fallback > > code that searches with the case sent by the client if we determine the > > entry has no krbCanonicalName attribute (sign that it was created before > > we started adding krbCanonicalName and never "updated"). > > > > Note that we also need to think what will happen during and upgrade when > > some servers still use the current code and some servers will use the > > new code. So I guess it would be nice if you could write down a table > > with all possible forms a principal can be in on rows, and old/new > > server states in columns, and mark what will happen for various > > operations in each case. > > > > Simo. > > The list looks OK. Do we also plan to change the default RDN for new services > or other objects that use krbPrincipalName as RDN at the moment? > > AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and > then only allow krbPrincipalName to be added for the aliases. Of course, the > framework needs to still work with old services having krbPrincipalName. no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName is only optional according to the scheme. bye, Sumit > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From simo at redhat.com Wed Sep 2 12:27:47 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 08:27:47 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E69314.9070804@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> Message-ID: <1441196867.28131.159.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: > On 01/09/15 16:53, Simo Sorce wrote: > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >> Hi list, > >> > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >> and I would like to clarify what needs to be done in order to make IPA > >> to fully support multiple aliases per entry. > >> > >> So far I have identified these task based on the ticket comments and > >> discussion with Simo way back in the past: > >> > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >> not used in the new code. > >> > >> 2.) fix ACIs that do not permit setting multiple values of > >> 'krbPrincipalName' attribute per entry (see > >> https://fedorahosted.org/freeipa/ticket/3961) > >> > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >> 'ipadb_find_principal' functions) to correctly perform lookup of > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >> case-insensitively and krbcanonicalname case-sensitively, return > >> krbcanonicalname when canonicalization is requested. > >> > >> 4.) Modify KDB backend and IPA framework to handle creation of both > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >> should be covered here (I remember that we should create > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > >> would be nice if you could comment on this. > >> > >> 5.) write tests which cover all this stuff so that we don't shoot > >> ourselves in the foot. > >> > >> I am not very well versed in Kerberos so I might get some of this stuff > >> wrong. If that's the case please point me to the right direction. Also > >> please write me some additional stuff which I have fogot and needs to be > >> done. > >> > > > > I think the summary is correct, the only thing we need to be careful is > > to keep handling entries that have only a single valued krbprincipalname > > correctly as that will happen in upgrade paths and potentially if > > someone uses external tools. > > > > The tricky part for point 3 is to implement it *without* changing the > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > the issue of "searching case-insensitively" by always lower-casing the > > principal name components and always upper casing the realm part on > > storage. If we always store a krbCanonicalName we get the "correct" case > > there anyway so out mucking with the krbPrincipalName case will not be a > > problem for any new entry. > > Or as Honza pointed out we can use case-insensitive search like this: > (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return > all variants of casing and reduce the need for fallback code. The principal name is not case insensitive, a search like that would probably cause DS to do a full search through the krbPrincipalName index, it might quickly become a performance issue. Before choosing a method please create an install with a 10000 principals, and then compare the speed of a few thousand search with exact matching case and a few with specifying caseIgnoreMatch and see the difference. Simo. > > This *may* cause issues with upgrades though, so we may need fallback > > code that searches with the case sent by the client if we determine the > > entry has no krbCanonicalName attribute (sign that it was created before > > we started adding krbCanonicalName and never "updated"). > > > > Note that we also need to think what will happen during and upgrade when > > some servers still use the current code and some servers will use the > > new code. So I guess it would be nice if you could write down a table > > with all possible forms a principal can be in on rows, and old/new > > server states in columns, and mark what will happen for various > > operations in each case. > > > > Simo. > > -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed Sep 2 12:32:33 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 2 Sep 2015 14:32:33 +0200 Subject: [Freeipa-devel] [PATCH 487] ldap: Make ldap2 connection management thread-safe again Message-ID: <55E6EC61.7020104@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-487-ldap-Make-ldap2-connection-management-thread-safe-ag.patch Type: text/x-patch Size: 7237 bytes Desc: not available URL: From simo at redhat.com Wed Sep 2 12:32:38 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 08:32:38 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <20150902121921.GM5282@p.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E6E74C.10704@redhat.com> <20150902121921.GM5282@p.redhat.com> Message-ID: <1441197158.28131.160.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: > On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > > On 09/01/2015 04:53 PM, Simo Sorce wrote: > > > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > > >> Hi list, > > >> > > >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > > >> and I would like to clarify what needs to be done in order to make IPA > > >> to fully support multiple aliases per entry. > > >> > > >> So far I have identified these task based on the ticket comments and > > >> discussion with Simo way back in the past: > > >> > > >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > > >> not used in the new code. > > >> > > >> 2.) fix ACIs that do not permit setting multiple values of > > >> 'krbPrincipalName' attribute per entry (see > > >> https://fedorahosted.org/freeipa/ticket/3961) > > >> > > >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > > >> 'ipadb_find_principal' functions) to correctly perform lookup of > > >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > > >> case-insensitively and krbcanonicalname case-sensitively, return > > >> krbcanonicalname when canonicalization is requested. > > >> > > >> 4.) Modify KDB backend and IPA framework to handle creation of both > > >> krbprincipalname and krbcanonicalname. I am not quite sure what cases > > >> should be covered here (I remember that we should create > > >> krbcanonicalname when we add another aliases to krbprincipalname), so it > > >> would be nice if you could comment on this. > > >> > > >> 5.) write tests which cover all this stuff so that we don't shoot > > >> ourselves in the foot. > > >> > > >> I am not very well versed in Kerberos so I might get some of this stuff > > >> wrong. If that's the case please point me to the right direction. Also > > >> please write me some additional stuff which I have fogot and needs to be > > >> done. > > >> > > > > > > I think the summary is correct, the only thing we need to be careful is > > > to keep handling entries that have only a single valued krbprincipalname > > > correctly as that will happen in upgrade paths and potentially if > > > someone uses external tools. > > > > > > The tricky part for point 3 is to implement it *without* changing the > > > schema. KrbPrincipalName is case-sensitive, however I think we can solve > > > the issue of "searching case-insensitively" by always lower-casing the > > > principal name components and always upper casing the realm part on > > > storage. If we always store a krbCanonicalName we get the "correct" case > > > there anyway so out mucking with the krbPrincipalName case will not be a > > > problem for any new entry. > > > > > > This *may* cause issues with upgrades though, so we may need fallback > > > code that searches with the case sent by the client if we determine the > > > entry has no krbCanonicalName attribute (sign that it was created before > > > we started adding krbCanonicalName and never "updated"). > > > > > > Note that we also need to think what will happen during and upgrade when > > > some servers still use the current code and some servers will use the > > > new code. So I guess it would be nice if you could write down a table > > > with all possible forms a principal can be in on rows, and old/new > > > server states in columns, and mark what will happen for various > > > operations in each case. > > > > > > Simo. > > > > The list looks OK. Do we also plan to change the default RDN for new services > > or other objects that use krbPrincipalName as RDN at the moment? > > > > AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and > > then only allow krbPrincipalName to be added for the aliases. Of course, the > > framework needs to still work with old services having krbPrincipalName. > > no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName > is only optional according to the scheme. We might stropping using either and use CN instead for the RDN. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Sep 2 12:36:05 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 2 Sep 2015 14:36:05 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <1441197158.28131.160.camel@willson.usersys.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E6E74C.10704@redhat.com> <20150902121921.GM5282@p.redhat.com> <1441197158.28131.160.camel@willson.usersys.redhat.com> Message-ID: <55E6ED35.2060800@redhat.com> On 09/02/2015 02:32 PM, Simo Sorce wrote: > On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: >> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: >>> On 09/01/2015 04:53 PM, Simo Sorce wrote: >>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>>> Hi list, >>>>> >>>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>>>> and I would like to clarify what needs to be done in order to make IPA >>>>> to fully support multiple aliases per entry. >>>>> >>>>> So far I have identified these task based on the ticket comments and >>>>> discussion with Simo way back in the past: >>>>> >>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>>> not used in the new code. >>>>> >>>>> 2.) fix ACIs that do not permit setting multiple values of >>>>> 'krbPrincipalName' attribute per entry (see >>>>> https://fedorahosted.org/freeipa/ticket/3961) >>>>> >>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>>> case-insensitively and krbcanonicalname case-sensitively, return >>>>> krbcanonicalname when canonicalization is requested. >>>>> >>>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>>> should be covered here (I remember that we should create >>>>> krbcanonicalname when we add another aliases to krbprincipalname), so it >>>>> would be nice if you could comment on this. >>>>> >>>>> 5.) write tests which cover all this stuff so that we don't shoot >>>>> ourselves in the foot. >>>>> >>>>> I am not very well versed in Kerberos so I might get some of this stuff >>>>> wrong. If that's the case please point me to the right direction. Also >>>>> please write me some additional stuff which I have fogot and needs to be >>>>> done. >>>>> >>>> >>>> I think the summary is correct, the only thing we need to be careful is >>>> to keep handling entries that have only a single valued krbprincipalname >>>> correctly as that will happen in upgrade paths and potentially if >>>> someone uses external tools. >>>> >>>> The tricky part for point 3 is to implement it *without* changing the >>>> schema. KrbPrincipalName is case-sensitive, however I think we can solve >>>> the issue of "searching case-insensitively" by always lower-casing the >>>> principal name components and always upper casing the realm part on >>>> storage. If we always store a krbCanonicalName we get the "correct" case >>>> there anyway so out mucking with the krbPrincipalName case will not be a >>>> problem for any new entry. >>>> >>>> This *may* cause issues with upgrades though, so we may need fallback >>>> code that searches with the case sent by the client if we determine the >>>> entry has no krbCanonicalName attribute (sign that it was created before >>>> we started adding krbCanonicalName and never "updated"). >>>> >>>> Note that we also need to think what will happen during and upgrade when >>>> some servers still use the current code and some servers will use the >>>> new code. So I guess it would be nice if you could write down a table >>>> with all possible forms a principal can be in on rows, and old/new >>>> server states in columns, and mark what will happen for various >>>> operations in each case. >>>> >>>> Simo. >>> >>> The list looks OK. Do we also plan to change the default RDN for new services >>> or other objects that use krbPrincipalName as RDN at the moment? >>> >>> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and >>> then only allow krbPrincipalName to be added for the aliases. Of course, the >>> framework needs to still work with old services having krbPrincipalName. >> >> no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName >> is only optional according to the scheme. > > We might stropping using either and use CN instead for the RDN. This would make changing krbPrincipalName that happens to be RDN much easier. Wouldn't this break software that depends on this RDN already? Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? Martin From simo at redhat.com Wed Sep 2 12:38:14 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 08:38:14 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E6ED35.2060800@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E6E74C.10704@redhat.com> <20150902121921.GM5282@p.redhat.com> <1441197158.28131.160.camel@willson.usersys.redhat.com> <55E6ED35.2060800@redhat.com> Message-ID: <1441197494.28131.162.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 14:36 +0200, Martin Kosek wrote: > On 09/02/2015 02:32 PM, Simo Sorce wrote: > > On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: > >> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > >>> On 09/01/2015 04:53 PM, Simo Sorce wrote: > >>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >>>>> Hi list, > >>>>> > >>>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >>>>> and I would like to clarify what needs to be done in order to make IPA > >>>>> to fully support multiple aliases per entry. > >>>>> > >>>>> So far I have identified these task based on the ticket comments and > >>>>> discussion with Simo way back in the past: > >>>>> > >>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >>>>> not used in the new code. > >>>>> > >>>>> 2.) fix ACIs that do not permit setting multiple values of > >>>>> 'krbPrincipalName' attribute per entry (see > >>>>> https://fedorahosted.org/freeipa/ticket/3961) > >>>>> > >>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >>>>> 'ipadb_find_principal' functions) to correctly perform lookup of > >>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >>>>> case-insensitively and krbcanonicalname case-sensitively, return > >>>>> krbcanonicalname when canonicalization is requested. > >>>>> > >>>>> 4.) Modify KDB backend and IPA framework to handle creation of both > >>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >>>>> should be covered here (I remember that we should create > >>>>> krbcanonicalname when we add another aliases to krbprincipalname), so it > >>>>> would be nice if you could comment on this. > >>>>> > >>>>> 5.) write tests which cover all this stuff so that we don't shoot > >>>>> ourselves in the foot. > >>>>> > >>>>> I am not very well versed in Kerberos so I might get some of this stuff > >>>>> wrong. If that's the case please point me to the right direction. Also > >>>>> please write me some additional stuff which I have fogot and needs to be > >>>>> done. > >>>>> > >>>> > >>>> I think the summary is correct, the only thing we need to be careful is > >>>> to keep handling entries that have only a single valued krbprincipalname > >>>> correctly as that will happen in upgrade paths and potentially if > >>>> someone uses external tools. > >>>> > >>>> The tricky part for point 3 is to implement it *without* changing the > >>>> schema. KrbPrincipalName is case-sensitive, however I think we can solve > >>>> the issue of "searching case-insensitively" by always lower-casing the > >>>> principal name components and always upper casing the realm part on > >>>> storage. If we always store a krbCanonicalName we get the "correct" case > >>>> there anyway so out mucking with the krbPrincipalName case will not be a > >>>> problem for any new entry. > >>>> > >>>> This *may* cause issues with upgrades though, so we may need fallback > >>>> code that searches with the case sent by the client if we determine the > >>>> entry has no krbCanonicalName attribute (sign that it was created before > >>>> we started adding krbCanonicalName and never "updated"). > >>>> > >>>> Note that we also need to think what will happen during and upgrade when > >>>> some servers still use the current code and some servers will use the > >>>> new code. So I guess it would be nice if you could write down a table > >>>> with all possible forms a principal can be in on rows, and old/new > >>>> server states in columns, and mark what will happen for various > >>>> operations in each case. > >>>> > >>>> Simo. > >>> > >>> The list looks OK. Do we also plan to change the default RDN for new services > >>> or other objects that use krbPrincipalName as RDN at the moment? > >>> > >>> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and > >>> then only allow krbPrincipalName to be added for the aliases. Of course, the > >>> framework needs to still work with old services having krbPrincipalName. > >> > >> no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName > >> is only optional according to the scheme. > > > > We might stropping using either and use CN instead for the RDN. > > This would make changing krbPrincipalName that happens to be RDN much easier. > Wouldn't this break software that depends on this RDN already? > > Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? It would,. but so would a change to krbCanonicalName. If you need to change something we might as well go CN. Otherwise keep it as is, but I guess your worry is that the RDN becomes multivalued which is really a pain. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Sep 2 12:44:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 2 Sep 2015 14:44:49 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <1441197494.28131.162.camel@willson.usersys.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E6E74C.10704@redhat.com> <20150902121921.GM5282@p.redhat.com> <1441197158.28131.160.camel@willson.usersys.redhat.com> <55E6ED35.2060800@redhat.com> <1441197494.28131.162.camel@willson.usersys.redhat.com> Message-ID: <55E6EF41.6010204@redhat.com> On 09/02/2015 02:38 PM, Simo Sorce wrote: > On Wed, 2015-09-02 at 14:36 +0200, Martin Kosek wrote: >> On 09/02/2015 02:32 PM, Simo Sorce wrote: >>> On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: >>>> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: >>>>> On 09/01/2015 04:53 PM, Simo Sorce wrote: >>>>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>>>>> Hi list, >>>>>>> >>>>>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>>>>>> and I would like to clarify what needs to be done in order to make IPA >>>>>>> to fully support multiple aliases per entry. >>>>>>> >>>>>>> So far I have identified these task based on the ticket comments and >>>>>>> discussion with Simo way back in the past: >>>>>>> >>>>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>>>>> not used in the new code. >>>>>>> >>>>>>> 2.) fix ACIs that do not permit setting multiple values of >>>>>>> 'krbPrincipalName' attribute per entry (see >>>>>>> https://fedorahosted.org/freeipa/ticket/3961) >>>>>>> >>>>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>>>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>>>>> case-insensitively and krbcanonicalname case-sensitively, return >>>>>>> krbcanonicalname when canonicalization is requested. >>>>>>> >>>>>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>>>>> should be covered here (I remember that we should create >>>>>>> krbcanonicalname when we add another aliases to krbprincipalname), so it >>>>>>> would be nice if you could comment on this. >>>>>>> >>>>>>> 5.) write tests which cover all this stuff so that we don't shoot >>>>>>> ourselves in the foot. >>>>>>> >>>>>>> I am not very well versed in Kerberos so I might get some of this stuff >>>>>>> wrong. If that's the case please point me to the right direction. Also >>>>>>> please write me some additional stuff which I have fogot and needs to be >>>>>>> done. >>>>>>> >>>>>> >>>>>> I think the summary is correct, the only thing we need to be careful is >>>>>> to keep handling entries that have only a single valued krbprincipalname >>>>>> correctly as that will happen in upgrade paths and potentially if >>>>>> someone uses external tools. >>>>>> >>>>>> The tricky part for point 3 is to implement it *without* changing the >>>>>> schema. KrbPrincipalName is case-sensitive, however I think we can solve >>>>>> the issue of "searching case-insensitively" by always lower-casing the >>>>>> principal name components and always upper casing the realm part on >>>>>> storage. If we always store a krbCanonicalName we get the "correct" case >>>>>> there anyway so out mucking with the krbPrincipalName case will not be a >>>>>> problem for any new entry. >>>>>> >>>>>> This *may* cause issues with upgrades though, so we may need fallback >>>>>> code that searches with the case sent by the client if we determine the >>>>>> entry has no krbCanonicalName attribute (sign that it was created before >>>>>> we started adding krbCanonicalName and never "updated"). >>>>>> >>>>>> Note that we also need to think what will happen during and upgrade when >>>>>> some servers still use the current code and some servers will use the >>>>>> new code. So I guess it would be nice if you could write down a table >>>>>> with all possible forms a principal can be in on rows, and old/new >>>>>> server states in columns, and mark what will happen for various >>>>>> operations in each case. >>>>>> >>>>>> Simo. >>>>> >>>>> The list looks OK. Do we also plan to change the default RDN for new services >>>>> or other objects that use krbPrincipalName as RDN at the moment? >>>>> >>>>> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and >>>>> then only allow krbPrincipalName to be added for the aliases. Of course, the >>>>> framework needs to still work with old services having krbPrincipalName. >>>> >>>> no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName >>>> is only optional according to the scheme. >>> >>> We might stropping using either and use CN instead for the RDN. >> >> This would make changing krbPrincipalName that happens to be RDN much easier. >> Wouldn't this break software that depends on this RDN already? >> >> Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? > > It would,. but so would a change to krbCanonicalName. If you need to > change something we might as well go CN. Otherwise keep it as is, but I > guess your worry is that the RDN becomes multivalued which is really a > pain. Yes, this is the worry. I think we want to avoid issues with having to rename the whole object just because we are changing the alias. Using krbCanonicalName as default RDN always and then only allowing users to play with krbPrincipalName seemed as the most easy way long-term, but if CN is easier, I am fine with that. From mbasti at redhat.com Wed Sep 2 12:51:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 2 Sep 2015 14:51:57 +0200 Subject: [Freeipa-devel] [PATCH 487] ldap: Make ldap2 connection management thread-safe again In-Reply-To: <55E6EC61.7020104@redhat.com> References: <55E6EC61.7020104@redhat.com> Message-ID: <55E6F0ED.60200@redhat.com> On 09/02/2015 02:32 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > This patch needs a big rebase to ipa-4-2 branch -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Sep 2 12:54:45 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 08:54:45 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E6EF41.6010204@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E6E74C.10704@redhat.com> <20150902121921.GM5282@p.redhat.com> <1441197158.28131.160.camel@willson.usersys.redhat.com> <55E6ED35.2060800@redhat.com> <1441197494.28131.162.camel@willson.usersys.redhat.com> <55E6EF41.6010204@redhat.com> Message-ID: <1441198485.28131.163.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 14:44 +0200, Martin Kosek wrote: > On 09/02/2015 02:38 PM, Simo Sorce wrote: > > On Wed, 2015-09-02 at 14:36 +0200, Martin Kosek wrote: > >> On 09/02/2015 02:32 PM, Simo Sorce wrote: > >>> On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: > >>>> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: > >>>>> On 09/01/2015 04:53 PM, Simo Sorce wrote: > >>>>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >>>>>>> Hi list, > >>>>>>> > >>>>>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >>>>>>> and I would like to clarify what needs to be done in order to make IPA > >>>>>>> to fully support multiple aliases per entry. > >>>>>>> > >>>>>>> So far I have identified these task based on the ticket comments and > >>>>>>> discussion with Simo way back in the past: > >>>>>>> > >>>>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >>>>>>> not used in the new code. > >>>>>>> > >>>>>>> 2.) fix ACIs that do not permit setting multiple values of > >>>>>>> 'krbPrincipalName' attribute per entry (see > >>>>>>> https://fedorahosted.org/freeipa/ticket/3961) > >>>>>>> > >>>>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >>>>>>> 'ipadb_find_principal' functions) to correctly perform lookup of > >>>>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >>>>>>> case-insensitively and krbcanonicalname case-sensitively, return > >>>>>>> krbcanonicalname when canonicalization is requested. > >>>>>>> > >>>>>>> 4.) Modify KDB backend and IPA framework to handle creation of both > >>>>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >>>>>>> should be covered here (I remember that we should create > >>>>>>> krbcanonicalname when we add another aliases to krbprincipalname), so it > >>>>>>> would be nice if you could comment on this. > >>>>>>> > >>>>>>> 5.) write tests which cover all this stuff so that we don't shoot > >>>>>>> ourselves in the foot. > >>>>>>> > >>>>>>> I am not very well versed in Kerberos so I might get some of this stuff > >>>>>>> wrong. If that's the case please point me to the right direction. Also > >>>>>>> please write me some additional stuff which I have fogot and needs to be > >>>>>>> done. > >>>>>>> > >>>>>> > >>>>>> I think the summary is correct, the only thing we need to be careful is > >>>>>> to keep handling entries that have only a single valued krbprincipalname > >>>>>> correctly as that will happen in upgrade paths and potentially if > >>>>>> someone uses external tools. > >>>>>> > >>>>>> The tricky part for point 3 is to implement it *without* changing the > >>>>>> schema. KrbPrincipalName is case-sensitive, however I think we can solve > >>>>>> the issue of "searching case-insensitively" by always lower-casing the > >>>>>> principal name components and always upper casing the realm part on > >>>>>> storage. If we always store a krbCanonicalName we get the "correct" case > >>>>>> there anyway so out mucking with the krbPrincipalName case will not be a > >>>>>> problem for any new entry. > >>>>>> > >>>>>> This *may* cause issues with upgrades though, so we may need fallback > >>>>>> code that searches with the case sent by the client if we determine the > >>>>>> entry has no krbCanonicalName attribute (sign that it was created before > >>>>>> we started adding krbCanonicalName and never "updated"). > >>>>>> > >>>>>> Note that we also need to think what will happen during and upgrade when > >>>>>> some servers still use the current code and some servers will use the > >>>>>> new code. So I guess it would be nice if you could write down a table > >>>>>> with all possible forms a principal can be in on rows, and old/new > >>>>>> server states in columns, and mark what will happen for various > >>>>>> operations in each case. > >>>>>> > >>>>>> Simo. > >>>>> > >>>>> The list looks OK. Do we also plan to change the default RDN for new services > >>>>> or other objects that use krbPrincipalName as RDN at the moment? > >>>>> > >>>>> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and > >>>>> then only allow krbPrincipalName to be added for the aliases. Of course, the > >>>>> framework needs to still work with old services having krbPrincipalName. > >>>> > >>>> no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName > >>>> is only optional according to the scheme. > >>> > >>> We might stropping using either and use CN instead for the RDN. > >> > >> This would make changing krbPrincipalName that happens to be RDN much easier. > >> Wouldn't this break software that depends on this RDN already? > >> > >> Like "ldapsearch -b ",cn=services,cn=accounts,SUFFIX"? > > > > It would,. but so would a change to krbCanonicalName. If you need to > > change something we might as well go CN. Otherwise keep it as is, but I > > guess your worry is that the RDN becomes multivalued which is really a > > pain. > > Yes, this is the worry. I think we want to avoid issues with having to rename > the whole object just because we are changing the alias. > > Using krbCanonicalName as default RDN always and then only allowing users to > play with krbPrincipalName seemed as the most easy way long-term, but if CN is > easier, I am fine with that. If we are all ok with krbCanonicalName I am fine with that too, CN is just shorter to type :) Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Wed Sep 2 12:58:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 2 Sep 2015 14:58:22 +0200 Subject: [Freeipa-devel] [PATCH 0305-0306] DNSSEC: better cleanup after uninstall to avoid temporal malfunction Message-ID: <55E6F26E.1050708@redhat.com> Related to ticket https://fedorahosted.org/freeipa/ticket/5273 Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0305-DNSSEC-backup-and-restore-opendnssec-zone-list-file.patch Type: text/x-patch Size: 1773 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0306-DNSSEC-remove-ccache-and-keytab-of-ipa-ods-exporter.patch Type: text/x-patch Size: 2645 bytes Desc: not available URL: From dkupka at redhat.com Wed Sep 2 13:00:41 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 2 Sep 2015 15:00:41 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <20150902121921.GM5282@p.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E6E74C.10704@redhat.com> <20150902121921.GM5282@p.redhat.com> Message-ID: <55E6F2F9.6000704@redhat.com> On 02/09/15 14:19, Sumit Bose wrote: > On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: >> On 09/01/2015 04:53 PM, Simo Sorce wrote: >>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>>> and I would like to clarify what needs to be done in order to make IPA >>>> to fully support multiple aliases per entry. >>>> >>>> So far I have identified these task based on the ticket comments and >>>> discussion with Simo way back in the past: >>>> >>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>> not used in the new code. >>>> >>>> 2.) fix ACIs that do not permit setting multiple values of >>>> 'krbPrincipalName' attribute per entry (see >>>> https://fedorahosted.org/freeipa/ticket/3961) >>>> >>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>> case-insensitively and krbcanonicalname case-sensitively, return >>>> krbcanonicalname when canonicalization is requested. >>>> >>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>> should be covered here (I remember that we should create >>>> krbcanonicalname when we add another aliases to krbprincipalname), so it >>>> would be nice if you could comment on this. >>>> >>>> 5.) write tests which cover all this stuff so that we don't shoot >>>> ourselves in the foot. >>>> >>>> I am not very well versed in Kerberos so I might get some of this stuff >>>> wrong. If that's the case please point me to the right direction. Also >>>> please write me some additional stuff which I have fogot and needs to be >>>> done. >>>> >>> >>> I think the summary is correct, the only thing we need to be careful is >>> to keep handling entries that have only a single valued krbprincipalname >>> correctly as that will happen in upgrade paths and potentially if >>> someone uses external tools. >>> >>> The tricky part for point 3 is to implement it *without* changing the >>> schema. KrbPrincipalName is case-sensitive, however I think we can solve >>> the issue of "searching case-insensitively" by always lower-casing the >>> principal name components and always upper casing the realm part on >>> storage. If we always store a krbCanonicalName we get the "correct" case >>> there anyway so out mucking with the krbPrincipalName case will not be a >>> problem for any new entry. >>> >>> This *may* cause issues with upgrades though, so we may need fallback >>> code that searches with the case sent by the client if we determine the >>> entry has no krbCanonicalName attribute (sign that it was created before >>> we started adding krbCanonicalName and never "updated"). >>> >>> Note that we also need to think what will happen during and upgrade when >>> some servers still use the current code and some servers will use the >>> new code. So I guess it would be nice if you could write down a table >>> with all possible forms a principal can be in on rows, and old/new >>> server states in columns, and mark what will happen for various >>> operations in each case. >>> >>> Simo. >> >> The list looks OK. Do we also plan to change the default RDN for new services >> or other objects that use krbPrincipalName as RDN at the moment? >> >> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and >> then only allow krbPrincipalName to be added for the aliases. Of course, the >> framework needs to still work with old services having krbPrincipalName. > > no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName > is only optional according to the scheme. That's right. We should keep krbprincipalname as RDN as it must be there anyway. We just need to set krbprincipalname and krbcanonicalname to the same value at entry creation and use this value in RDN. Also we won't allow removing krbprincipalname with the same value as krbcanonicalname. This allows us to maintain backwards compatibility with no additional effort. David > > bye, > Sumit > >> >> -- >> 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 > -- David Kupka From jcholast at redhat.com Wed Sep 2 13:16:19 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 2 Sep 2015 15:16:19 +0200 Subject: [Freeipa-devel] [PATCH 487] ldap: Make ldap2 connection management thread-safe again In-Reply-To: <55E6F0ED.60200@redhat.com> References: <55E6EC61.7020104@redhat.com> <55E6F0ED.60200@redhat.com> Message-ID: <55E6F6A3.6060400@redhat.com> On 2.9.2015 14:51, Martin Basti wrote: > > > On 09/02/2015 02:32 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > > This patch needs a big rebase to ipa-4-2 branch Patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-487.0.4_2-ldap-Make-ldap2-connection-management-thread-safe-ag.patch Type: text/x-patch Size: 6509 bytes Desc: not available URL: From rmeggins at redhat.com Wed Sep 2 14:00:49 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 2 Sep 2015 08:00:49 -0600 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <1441114456.28131.110.camel@willson.usersys.redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> <55E4D85A.7080600@redhat.com> <55E58E8C.6090709@redhat.com> <55E5A56C.7090600@redhat.com> <1441114456.28131.110.camel@willson.usersys.redhat.com> Message-ID: <55E70111.4050105@redhat.com> On 09/01/2015 07:34 AM, Simo Sorce wrote: > On Tue, 2015-09-01 at 07:17 -0600, Rich Megginson wrote: >> On 09/01/2015 05:39 AM, Petr Spacek wrote: >>> On 1.9.2015 00:42, Rich Megginson wrote: >>>> On 08/31/2015 11:00 AM, Simo Sorce wrote: >>>>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: >>>>>> On 08/31/2015 01:35 AM, Petr Spacek wrote: >>>>>>> On 26.8.2015 20:09, Rich Megginson wrote: >>>>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: >>>>>>>>> On 8.7.2015 19:56, Rich Megginson wrote: >>>>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>>>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it >>>>>>>>>>> would be >>>>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>>>>>>>>>> alongside their own JSON API. >>>>>>>>>>> >>>>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add >>>>>>>>>>> zones >>>>>>>>>>> but still, standard protocol would mean that standard client (possibly >>>>>>>>>>> guest >>>>>>>>>>> OS inside VM) can update its records without any OpenStack dependency, >>>>>>>>>>> which >>>>>>>>>>> is very much desirable. >>>>>>>>>>> >>>>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key >>>>>>>>>>> (which was >>>>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle >>>>>>>>>>> attacks. >>>>>>>> I'm working on a different approach for guest OS registration. This >>>>>>>> involves >>>>>>>> a Nova hook/plugin: >>>>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the >>>>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script >>>>>>>> to new >>>>>>>> host cloud-init >>>>>>>> * new instance calls script - will wait for OTP to become available in >>>>>>>> metadata, then call ipa-client-install with OTP >>>>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with >>>>>>>> new IP >>>>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. >>>>>>> ipa-client-install is using DNS UPDATE today. >>>>>> I already have to support the IPA JSON REST interface with kerberos >>>>>> credentials to do the host add, so it is easy to support dsrecord-add. >>>>>> >>>>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova >>>>>>>> >>>>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service >>>>>>>>>>> discovery using DNS, where a guest/container running a distributed >>>>>>>>>>> service >>>>>>>>>>> can >>>>>>>>>>> publish it's existence in DNS. >>>>>>>>>>> >>>>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>>>>>>>>>> widely supported, too. >>>>>>>>>>> >>>>>>>>>>> So DNS UPDATE is my biggest wish :-) >>>>>>>>>>> >>>>>>>>>> Ok. There was a Designate blueprint for such a feature, but I can't >>>>>>>>>> find it >>>>>>>>>> and neither can the Designate guys. There is a mention of nsupdate in the >>>>>>>>>> minidns blueprint, but that's about it. The fact that Designate upstream >>>>>>>>>> can't find the bp suggests that this is not a high priority for them >>>>>>>>>> and will >>>>>>>>>> not likely implement it on their own i.e. we would have to contribute this >>>>>>>>>> feature. >>>>>>>>>> >>>>>>>>>> If Designate had such a feature, how would this help us integrate >>>>>>>>>> FreeIPA with >>>>>>>>>> Designate? >>>>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to >>>>>>>>> support >>>>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA >>>>>>>>> servers to >>>>>>>>> external DNS servers, so we could use the same code to integrate with AD & >>>>>>>>> Designate at the same time. >>>>>>>>> >>>>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) >>>>>>>>> >>>>>>>> For Designate for our use cases, we want IPA to be the authoritative >>>>>>>> source of >>>>>>>> DNS data. >>>>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is >>>>>>> built around assumption that there is only one authoritative source of data >>>>>>> and as far as I can tell all attempts to bend this assumption did not end >>>>>>> well. >>>>>> But what about users/operators who want to integrate OpenStack with >>>>>> their existing DNS deployment (e.g. IPA or AD)? Will they allow >>>>>> converting their IPA/AD DNS to be a replica of Designate? >>>>> No, they would not want to, or have no permissions to do so. >>>>> But that shouldn't be a big issue, designate will probably be made to >>>>> manage a completely unrelated namespace. >>>>> >>>>>> This seems to >>>>>> be the obverse of most of the ways OpenStack is integrated into existing >>>>>> deployments. For example, for Keystone Identity, you don't configure >>>>>> Keystone to be the authoritative source of data for identity, then >>>>>> configure IPA or AD to be a replica of Keystone. You configure Keystone >>>>>> to use IPA/AD for its identity information. >>>>> Indeed. >>>>> >>>>>>> In my eyes IPA should have ability to integrate with whatever DNS server >>>>>>> admin >>>>>>> wants to use, using standard protocols. >>>>>> Does this mean the best way to support Designate will be to change IPA >>>>>> DNS so that it can be a replica of Designate, and get its data via AXFR >>>>>> from Designate? >>>>> No, we should probably just make it possible for IPA to talk to >>>>> designate to add the necessary records. If Designate is in use, the IPA >>>>> DNS will not be in use and turned off. >>>> Then why use IPA at all? Would be much simpler for the user to stand up a >>>> PowerDNS or BIND9 which are supported out of the box. >>> Yes, that is basically what I'm saying :-) In my eyes IPA should integrate >>> with whatever DNS server you want to use, be it Designate or anything else. If >>> we have such integration then there is no point in doing two-way >>> synchronization between IPA DNS and DNS. >> What does "integration" mean in this context, if it doesn't mean >> synchronization or zone transfers? > It means that the IPA framework operates directly no an external DNS > server instead of using its own. So this is the same as the case where a customer already has DNS and wants to use it, and we tell them how to set up their DNS with the records that IPA needs? > This means we can still have automatic > changes in DNS w/o using the integrated one. How? > There may be limitations > (like no DNSSEC available, no ability to create forward zones, no > discovery location support or similar) but at least it should be > possible to set the core names that are needed for client discovery and > similar. > > Simo. > >>>>> It makes little to no sense to replicate stuff out of designate if we >>>>> are not the master server. > From simo at redhat.com Wed Sep 2 14:07:12 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 10:07:12 -0400 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55E70111.4050105@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> <55E4D85A.7080600@redhat.com> <55E58E8C.6090709@redhat.com> <55E5A56C.7090600@redhat.com> <1441114456.28131.110.camel@willson.usersys.redhat.com> <55E70111.4050105@redhat.com> Message-ID: <1441202832.28131.166.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 08:00 -0600, Rich Megginson wrote: > On 09/01/2015 07:34 AM, Simo Sorce wrote: > > On Tue, 2015-09-01 at 07:17 -0600, Rich Megginson wrote: > >> On 09/01/2015 05:39 AM, Petr Spacek wrote: > >>> On 1.9.2015 00:42, Rich Megginson wrote: > >>>> On 08/31/2015 11:00 AM, Simo Sorce wrote: > >>>>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: > >>>>>> On 08/31/2015 01:35 AM, Petr Spacek wrote: > >>>>>>> On 26.8.2015 20:09, Rich Megginson wrote: > >>>>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: > >>>>>>>>> On 8.7.2015 19:56, Rich Megginson wrote: > >>>>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: > >>>>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it > >>>>>>>>>>> would be > >>>>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) > >>>>>>>>>>> alongside their own JSON API. > >>>>>>>>>>> > >>>>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add > >>>>>>>>>>> zones > >>>>>>>>>>> but still, standard protocol would mean that standard client (possibly > >>>>>>>>>>> guest > >>>>>>>>>>> OS inside VM) can update its records without any OpenStack dependency, > >>>>>>>>>>> which > >>>>>>>>>>> is very much desirable. > >>>>>>>>>>> > >>>>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key > >>>>>>>>>>> (which was > >>>>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle > >>>>>>>>>>> attacks. > >>>>>>>> I'm working on a different approach for guest OS registration. This > >>>>>>>> involves > >>>>>>>> a Nova hook/plugin: > >>>>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the > >>>>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script > >>>>>>>> to new > >>>>>>>> host cloud-init > >>>>>>>> * new instance calls script - will wait for OTP to become available in > >>>>>>>> metadata, then call ipa-client-install with OTP > >>>>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with > >>>>>>>> new IP > >>>>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. > >>>>>>> ipa-client-install is using DNS UPDATE today. > >>>>>> I already have to support the IPA JSON REST interface with kerberos > >>>>>> credentials to do the host add, so it is easy to support dsrecord-add. > >>>>>> > >>>>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova > >>>>>>>> > >>>>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service > >>>>>>>>>>> discovery using DNS, where a guest/container running a distributed > >>>>>>>>>>> service > >>>>>>>>>>> can > >>>>>>>>>>> publish it's existence in DNS. > >>>>>>>>>>> > >>>>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is > >>>>>>>>>>> widely supported, too. > >>>>>>>>>>> > >>>>>>>>>>> So DNS UPDATE is my biggest wish :-) > >>>>>>>>>>> > >>>>>>>>>> Ok. There was a Designate blueprint for such a feature, but I can't > >>>>>>>>>> find it > >>>>>>>>>> and neither can the Designate guys. There is a mention of nsupdate in the > >>>>>>>>>> minidns blueprint, but that's about it. The fact that Designate upstream > >>>>>>>>>> can't find the bp suggests that this is not a high priority for them > >>>>>>>>>> and will > >>>>>>>>>> not likely implement it on their own i.e. we would have to contribute this > >>>>>>>>>> feature. > >>>>>>>>>> > >>>>>>>>>> If Designate had such a feature, how would this help us integrate > >>>>>>>>>> FreeIPA with > >>>>>>>>>> Designate? > >>>>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to > >>>>>>>>> support > >>>>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA > >>>>>>>>> servers to > >>>>>>>>> external DNS servers, so we could use the same code to integrate with AD & > >>>>>>>>> Designate at the same time. > >>>>>>>>> > >>>>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) > >>>>>>>>> > >>>>>>>> For Designate for our use cases, we want IPA to be the authoritative > >>>>>>>> source of > >>>>>>>> DNS data. > >>>>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is > >>>>>>> built around assumption that there is only one authoritative source of data > >>>>>>> and as far as I can tell all attempts to bend this assumption did not end > >>>>>>> well. > >>>>>> But what about users/operators who want to integrate OpenStack with > >>>>>> their existing DNS deployment (e.g. IPA or AD)? Will they allow > >>>>>> converting their IPA/AD DNS to be a replica of Designate? > >>>>> No, they would not want to, or have no permissions to do so. > >>>>> But that shouldn't be a big issue, designate will probably be made to > >>>>> manage a completely unrelated namespace. > >>>>> > >>>>>> This seems to > >>>>>> be the obverse of most of the ways OpenStack is integrated into existing > >>>>>> deployments. For example, for Keystone Identity, you don't configure > >>>>>> Keystone to be the authoritative source of data for identity, then > >>>>>> configure IPA or AD to be a replica of Keystone. You configure Keystone > >>>>>> to use IPA/AD for its identity information. > >>>>> Indeed. > >>>>> > >>>>>>> In my eyes IPA should have ability to integrate with whatever DNS server > >>>>>>> admin > >>>>>>> wants to use, using standard protocols. > >>>>>> Does this mean the best way to support Designate will be to change IPA > >>>>>> DNS so that it can be a replica of Designate, and get its data via AXFR > >>>>>> from Designate? > >>>>> No, we should probably just make it possible for IPA to talk to > >>>>> designate to add the necessary records. If Designate is in use, the IPA > >>>>> DNS will not be in use and turned off. > >>>> Then why use IPA at all? Would be much simpler for the user to stand up a > >>>> PowerDNS or BIND9 which are supported out of the box. > >>> Yes, that is basically what I'm saying :-) In my eyes IPA should integrate > >>> with whatever DNS server you want to use, be it Designate or anything else. If > >>> we have such integration then there is no point in doing two-way > >>> synchronization between IPA DNS and DNS. > >> What does "integration" mean in this context, if it doesn't mean > >> synchronization or zone transfers? > > It means that the IPA framework operates directly no an external DNS > > server instead of using its own. > > So this is the same as the case where a customer already has DNS and > wants to use it, and we tell them how to set up their DNS with the > records that IPA needs? No it goes beyond that, we have the framework enabled to do changes to the DNS. > > This means we can still have automatic > > changes in DNS w/o using the integrated one. > > How? nsupdate as the simplest integration option, perhaps plugin with use of native APIs if available. Simo. > > There may be limitations > > (like no DNSSEC available, no ability to create forward zones, no > > discovery location support or similar) but at least it should be > > possible to set the core names that are needed for client discovery and > > similar. > > > > Simo. > > > >>>>> It makes little to no sense to replicate stuff out of designate if we > >>>>> are not the master server. > > > -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Wed Sep 2 14:09:07 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 2 Sep 2015 08:09:07 -0600 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <1441202832.28131.166.camel@willson.usersys.redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> <55E4D85A.7080600@redhat.com> <55E58E8C.6090709@redhat.com> <55E5A56C.7090600@redhat.com> <1441114456.28131.110.camel@willson.usersys.redhat.com> <55E70111.4050105@redhat.com> <1441202832.28131.166.camel@willson.usersys.redhat.com> Message-ID: <55E70303.6000708@redhat.com> On 09/02/2015 08:07 AM, Simo Sorce wrote: > On Wed, 2015-09-02 at 08:00 -0600, Rich Megginson wrote: >> On 09/01/2015 07:34 AM, Simo Sorce wrote: >>> On Tue, 2015-09-01 at 07:17 -0600, Rich Megginson wrote: >>>> On 09/01/2015 05:39 AM, Petr Spacek wrote: >>>>> On 1.9.2015 00:42, Rich Megginson wrote: >>>>>> On 08/31/2015 11:00 AM, Simo Sorce wrote: >>>>>>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: >>>>>>>> On 08/31/2015 01:35 AM, Petr Spacek wrote: >>>>>>>>> On 26.8.2015 20:09, Rich Megginson wrote: >>>>>>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: >>>>>>>>>>> On 8.7.2015 19:56, Rich Megginson wrote: >>>>>>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>>>>>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it >>>>>>>>>>>>> would be >>>>>>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>>>>>>>>>>>> alongside their own JSON API. >>>>>>>>>>>>> >>>>>>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add >>>>>>>>>>>>> zones >>>>>>>>>>>>> but still, standard protocol would mean that standard client (possibly >>>>>>>>>>>>> guest >>>>>>>>>>>>> OS inside VM) can update its records without any OpenStack dependency, >>>>>>>>>>>>> which >>>>>>>>>>>>> is very much desirable. >>>>>>>>>>>>> >>>>>>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key >>>>>>>>>>>>> (which was >>>>>>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle >>>>>>>>>>>>> attacks. >>>>>>>>>> I'm working on a different approach for guest OS registration. This >>>>>>>>>> involves >>>>>>>>>> a Nova hook/plugin: >>>>>>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the >>>>>>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script >>>>>>>>>> to new >>>>>>>>>> host cloud-init >>>>>>>>>> * new instance calls script - will wait for OTP to become available in >>>>>>>>>> metadata, then call ipa-client-install with OTP >>>>>>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with >>>>>>>>>> new IP >>>>>>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. >>>>>>>>> ipa-client-install is using DNS UPDATE today. >>>>>>>> I already have to support the IPA JSON REST interface with kerberos >>>>>>>> credentials to do the host add, so it is easy to support dsrecord-add. >>>>>>>> >>>>>>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova >>>>>>>>>> >>>>>>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service >>>>>>>>>>>>> discovery using DNS, where a guest/container running a distributed >>>>>>>>>>>>> service >>>>>>>>>>>>> can >>>>>>>>>>>>> publish it's existence in DNS. >>>>>>>>>>>>> >>>>>>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>>>>>>>>>>>> widely supported, too. >>>>>>>>>>>>> >>>>>>>>>>>>> So DNS UPDATE is my biggest wish :-) >>>>>>>>>>>>> >>>>>>>>>>>> Ok. There was a Designate blueprint for such a feature, but I can't >>>>>>>>>>>> find it >>>>>>>>>>>> and neither can the Designate guys. There is a mention of nsupdate in the >>>>>>>>>>>> minidns blueprint, but that's about it. The fact that Designate upstream >>>>>>>>>>>> can't find the bp suggests that this is not a high priority for them >>>>>>>>>>>> and will >>>>>>>>>>>> not likely implement it on their own i.e. we would have to contribute this >>>>>>>>>>>> feature. >>>>>>>>>>>> >>>>>>>>>>>> If Designate had such a feature, how would this help us integrate >>>>>>>>>>>> FreeIPA with >>>>>>>>>>>> Designate? >>>>>>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to >>>>>>>>>>> support >>>>>>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA >>>>>>>>>>> servers to >>>>>>>>>>> external DNS servers, so we could use the same code to integrate with AD & >>>>>>>>>>> Designate at the same time. >>>>>>>>>>> >>>>>>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) >>>>>>>>>>> >>>>>>>>>> For Designate for our use cases, we want IPA to be the authoritative >>>>>>>>>> source of >>>>>>>>>> DNS data. >>>>>>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is >>>>>>>>> built around assumption that there is only one authoritative source of data >>>>>>>>> and as far as I can tell all attempts to bend this assumption did not end >>>>>>>>> well. >>>>>>>> But what about users/operators who want to integrate OpenStack with >>>>>>>> their existing DNS deployment (e.g. IPA or AD)? Will they allow >>>>>>>> converting their IPA/AD DNS to be a replica of Designate? >>>>>>> No, they would not want to, or have no permissions to do so. >>>>>>> But that shouldn't be a big issue, designate will probably be made to >>>>>>> manage a completely unrelated namespace. >>>>>>> >>>>>>>> This seems to >>>>>>>> be the obverse of most of the ways OpenStack is integrated into existing >>>>>>>> deployments. For example, for Keystone Identity, you don't configure >>>>>>>> Keystone to be the authoritative source of data for identity, then >>>>>>>> configure IPA or AD to be a replica of Keystone. You configure Keystone >>>>>>>> to use IPA/AD for its identity information. >>>>>>> Indeed. >>>>>>> >>>>>>>>> In my eyes IPA should have ability to integrate with whatever DNS server >>>>>>>>> admin >>>>>>>>> wants to use, using standard protocols. >>>>>>>> Does this mean the best way to support Designate will be to change IPA >>>>>>>> DNS so that it can be a replica of Designate, and get its data via AXFR >>>>>>>> from Designate? >>>>>>> No, we should probably just make it possible for IPA to talk to >>>>>>> designate to add the necessary records. If Designate is in use, the IPA >>>>>>> DNS will not be in use and turned off. >>>>>> Then why use IPA at all? Would be much simpler for the user to stand up a >>>>>> PowerDNS or BIND9 which are supported out of the box. >>>>> Yes, that is basically what I'm saying :-) In my eyes IPA should integrate >>>>> with whatever DNS server you want to use, be it Designate or anything else. If >>>>> we have such integration then there is no point in doing two-way >>>>> synchronization between IPA DNS and DNS. >>>> What does "integration" mean in this context, if it doesn't mean >>>> synchronization or zone transfers? >>> It means that the IPA framework operates directly no an external DNS >>> server instead of using its own. >> So this is the same as the case where a customer already has DNS and >> wants to use it, and we tell them how to set up their DNS with the >> records that IPA needs? > No it goes beyond that, we have the framework enabled to do changes to > the DNS. > >>> This means we can still have automatic >>> changes in DNS w/o using the integrated one. >> How? > nsupdate as the simplest integration option, perhaps plugin with use of > native APIs if available. I'm assuming this option does not exist currently. Is there a freeipa ticket for this? > > Simo. > >>> There may be limitations >>> (like no DNSSEC available, no ability to create forward zones, no >>> discovery location support or similar) but at least it should be >>> possible to set the core names that are needed for client discovery and >>> similar. >>> >>> Simo. >>> >>>>>>> It makes little to no sense to replicate stuff out of designate if we >>>>>>> are not the master server. > From simo at redhat.com Wed Sep 2 14:12:07 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 10:12:07 -0400 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55E70303.6000708@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> <55E4D85A.7080600@redhat.com> <55E58E8C.6090709@redhat.com> <55E5A56C.7090600@redhat.com> <1441114456.28131.110.camel@willson.usersys.redhat.com> <55E70111.4050105@redhat.com> <1441202832.28131.166.camel@willson.usersys.redhat.com> <55E70303.6000708@redhat.com> Message-ID: <1441203127.28131.167.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 08:09 -0600, Rich Megginson wrote: > On 09/02/2015 08:07 AM, Simo Sorce wrote: > > On Wed, 2015-09-02 at 08:00 -0600, Rich Megginson wrote: > >> On 09/01/2015 07:34 AM, Simo Sorce wrote: > >>> On Tue, 2015-09-01 at 07:17 -0600, Rich Megginson wrote: > >>>> On 09/01/2015 05:39 AM, Petr Spacek wrote: > >>>>> On 1.9.2015 00:42, Rich Megginson wrote: > >>>>>> On 08/31/2015 11:00 AM, Simo Sorce wrote: > >>>>>>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: > >>>>>>>> On 08/31/2015 01:35 AM, Petr Spacek wrote: > >>>>>>>>> On 26.8.2015 20:09, Rich Megginson wrote: > >>>>>>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: > >>>>>>>>>>> On 8.7.2015 19:56, Rich Megginson wrote: > >>>>>>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: > >>>>>>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it > >>>>>>>>>>>>> would be > >>>>>>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) > >>>>>>>>>>>>> alongside their own JSON API. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add > >>>>>>>>>>>>> zones > >>>>>>>>>>>>> but still, standard protocol would mean that standard client (possibly > >>>>>>>>>>>>> guest > >>>>>>>>>>>>> OS inside VM) can update its records without any OpenStack dependency, > >>>>>>>>>>>>> which > >>>>>>>>>>>>> is very much desirable. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key > >>>>>>>>>>>>> (which was > >>>>>>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle > >>>>>>>>>>>>> attacks. > >>>>>>>>>> I'm working on a different approach for guest OS registration. This > >>>>>>>>>> involves > >>>>>>>>>> a Nova hook/plugin: > >>>>>>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the > >>>>>>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script > >>>>>>>>>> to new > >>>>>>>>>> host cloud-init > >>>>>>>>>> * new instance calls script - will wait for OTP to become available in > >>>>>>>>>> metadata, then call ipa-client-install with OTP > >>>>>>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with > >>>>>>>>>> new IP > >>>>>>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. > >>>>>>>>> ipa-client-install is using DNS UPDATE today. > >>>>>>>> I already have to support the IPA JSON REST interface with kerberos > >>>>>>>> credentials to do the host add, so it is easy to support dsrecord-add. > >>>>>>>> > >>>>>>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova > >>>>>>>>>> > >>>>>>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service > >>>>>>>>>>>>> discovery using DNS, where a guest/container running a distributed > >>>>>>>>>>>>> service > >>>>>>>>>>>>> can > >>>>>>>>>>>>> publish it's existence in DNS. > >>>>>>>>>>>>> > >>>>>>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is > >>>>>>>>>>>>> widely supported, too. > >>>>>>>>>>>>> > >>>>>>>>>>>>> So DNS UPDATE is my biggest wish :-) > >>>>>>>>>>>>> > >>>>>>>>>>>> Ok. There was a Designate blueprint for such a feature, but I can't > >>>>>>>>>>>> find it > >>>>>>>>>>>> and neither can the Designate guys. There is a mention of nsupdate in the > >>>>>>>>>>>> minidns blueprint, but that's about it. The fact that Designate upstream > >>>>>>>>>>>> can't find the bp suggests that this is not a high priority for them > >>>>>>>>>>>> and will > >>>>>>>>>>>> not likely implement it on their own i.e. we would have to contribute this > >>>>>>>>>>>> feature. > >>>>>>>>>>>> > >>>>>>>>>>>> If Designate had such a feature, how would this help us integrate > >>>>>>>>>>>> FreeIPA with > >>>>>>>>>>>> Designate? > >>>>>>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to > >>>>>>>>>>> support > >>>>>>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA > >>>>>>>>>>> servers to > >>>>>>>>>>> external DNS servers, so we could use the same code to integrate with AD & > >>>>>>>>>>> Designate at the same time. > >>>>>>>>>>> > >>>>>>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) > >>>>>>>>>>> > >>>>>>>>>> For Designate for our use cases, we want IPA to be the authoritative > >>>>>>>>>> source of > >>>>>>>>>> DNS data. > >>>>>>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is > >>>>>>>>> built around assumption that there is only one authoritative source of data > >>>>>>>>> and as far as I can tell all attempts to bend this assumption did not end > >>>>>>>>> well. > >>>>>>>> But what about users/operators who want to integrate OpenStack with > >>>>>>>> their existing DNS deployment (e.g. IPA or AD)? Will they allow > >>>>>>>> converting their IPA/AD DNS to be a replica of Designate? > >>>>>>> No, they would not want to, or have no permissions to do so. > >>>>>>> But that shouldn't be a big issue, designate will probably be made to > >>>>>>> manage a completely unrelated namespace. > >>>>>>> > >>>>>>>> This seems to > >>>>>>>> be the obverse of most of the ways OpenStack is integrated into existing > >>>>>>>> deployments. For example, for Keystone Identity, you don't configure > >>>>>>>> Keystone to be the authoritative source of data for identity, then > >>>>>>>> configure IPA or AD to be a replica of Keystone. You configure Keystone > >>>>>>>> to use IPA/AD for its identity information. > >>>>>>> Indeed. > >>>>>>> > >>>>>>>>> In my eyes IPA should have ability to integrate with whatever DNS server > >>>>>>>>> admin > >>>>>>>>> wants to use, using standard protocols. > >>>>>>>> Does this mean the best way to support Designate will be to change IPA > >>>>>>>> DNS so that it can be a replica of Designate, and get its data via AXFR > >>>>>>>> from Designate? > >>>>>>> No, we should probably just make it possible for IPA to talk to > >>>>>>> designate to add the necessary records. If Designate is in use, the IPA > >>>>>>> DNS will not be in use and turned off. > >>>>>> Then why use IPA at all? Would be much simpler for the user to stand up a > >>>>>> PowerDNS or BIND9 which are supported out of the box. > >>>>> Yes, that is basically what I'm saying :-) In my eyes IPA should integrate > >>>>> with whatever DNS server you want to use, be it Designate or anything else. If > >>>>> we have such integration then there is no point in doing two-way > >>>>> synchronization between IPA DNS and DNS. > >>>> What does "integration" mean in this context, if it doesn't mean > >>>> synchronization or zone transfers? > >>> It means that the IPA framework operates directly no an external DNS > >>> server instead of using its own. > >> So this is the same as the case where a customer already has DNS and > >> wants to use it, and we tell them how to set up their DNS with the > >> records that IPA needs? > > No it goes beyond that, we have the framework enabled to do changes to > > the DNS. > > > >>> This means we can still have automatic > >>> changes in DNS w/o using the integrated one. > >> How? > > nsupdate as the simplest integration option, perhaps plugin with use of > > native APIs if available. > > I'm assuming this option does not exist currently. Is there a freeipa > ticket for this? https://fedorahosted.org/freeipa/ticket/4424 Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Wed Sep 2 14:20:22 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 02 Sep 2015 16:20:22 +0200 Subject: [Freeipa-devel] [PATCH 487] ldap: Make ldap2 connection management thread-safe again In-Reply-To: <55E6F6A3.6060400@redhat.com> References: <55E6EC61.7020104@redhat.com> <55E6F0ED.60200@redhat.com> <55E6F6A3.6060400@redhat.com> Message-ID: <55E705A6.10007@redhat.com> On 09/02/2015 03:16 PM, Jan Cholasta wrote: > On 2.9.2015 14:51, Martin Basti wrote: >> >> >> On 09/02/2015 02:32 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes >>> . >>> >>> Honza >>> >>> >>> >> >> This patch needs a big rebase to ipa-4-2 branch > > Patch attached. > > > Hello, Two minors questions. LDAPClient close/__del__/__exit__ are now just resetting self._conn without disconnecting the connection. Only ldap2.close() disconnect the connection. Could it be a risk to see connection leaks with __del__ or __exit__ ? Also in the fix there is: @@ -118,10 +115,11 @@ class ldap2(CrudBackend, LDAPClient): if debug_level: _ldap.set_option(_ldap.OPT_DEBUG_LEVEL, debug_level) - LDAPClient._connect(self) - conn = self._conn + client = LDAPClient(self.ldap_uri, + force_schema_updates=self._force_schema_updates) + conn = client._conn Is it the same as 'conn = client.conn()' ? Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Sep 2 14:47:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 2 Sep 2015 16:47:37 +0200 Subject: [Freeipa-devel] [PATCH 487] ldap: Make ldap2 connection management thread-safe again In-Reply-To: <55E705A6.10007@redhat.com> References: <55E6EC61.7020104@redhat.com> <55E6F0ED.60200@redhat.com> <55E6F6A3.6060400@redhat.com> <55E705A6.10007@redhat.com> Message-ID: <55E70C09.4060607@redhat.com> On 2.9.2015 16:20, thierry bordaz wrote: > On 09/02/2015 03:16 PM, Jan Cholasta wrote: >> On 2.9.2015 14:51, Martin Basti wrote: >>> >>> >>> On 09/02/2015 02:32 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>>> >>>> >>>> >>> >>> This patch needs a big rebase to ipa-4-2 branch >> >> Patch attached. >> >> >> > Hello, > > Two minors questions. LDAPClient close/__del__/__exit__ are now just > resetting self._conn without disconnecting the connection. They do the same even without the patch, "object.__setattr__(self, '_conn', None)" is effectively the same as "self._conn = None". > Only ldap2.close() disconnect the connection. Could it be a risk to see > connection leaks with __del__ or __exit__ ? This behavior is unchanged, and so far no one complained about connection leaks. > > Also in the fix there is: > > @@ -118,10 +115,11 @@ class ldap2(CrudBackend, LDAPClient): > if debug_level: > _ldap.set_option(_ldap.OPT_DEBUG_LEVEL, debug_level) > > - LDAPClient._connect(self) > - conn = self._conn > + client = LDAPClient(self.ldap_uri, > + force_schema_updates=self._force_schema_updates) > + conn = client._conn > > > Is it the same as 'conn = client.conn()' ? No. It's the same as "conn = client.conn", but I'd like to get rid of LDAPClient.conn in the future (internal attributes should not be public), hence the use of self._conn. > > Thanks > thierry > -- Jan Cholasta From mbasti at redhat.com Wed Sep 2 15:57:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 2 Sep 2015 17:57:23 +0200 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed Message-ID: <55E71C63.1060907@redhat.com> Client installation is done as "Restarting web server". This step deserve own message. Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0307-Server-Install-print-message-that-client-is-being-in.patch Type: text/x-patch Size: 1769 bytes Desc: not available URL: From simo at redhat.com Wed Sep 2 16:00:38 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 12:00:38 -0400 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <55E71C63.1060907@redhat.com> References: <55E71C63.1060907@redhat.com> Message-ID: <1441209638.28131.175.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: > Client installation is done as "Restarting web server". This step > deserve own message. > > Patch attached I've seen various cases like this. And I can't understand why these steps aren't embedded in the actual instance install steps that need the restart (which implicitly also provide a message). In the promotion patchset I did move steps like this into the proper instances, so I would prefer you do the same with the install path as that is more appropriate. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 2 19:22:28 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 15:22:28 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <55E44C81.6010306@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> Message-ID: <1441221748.28131.180.camel@willson.usersys.redhat.com> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: > > On 08/26/2015 11:27 PM, Simo Sorce wrote: > > This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > > and introduces a number of required changes and dependencies to achieve > > this goal. > > This work requires the custodia project to securely transfer keys > > between ipa servers. > > > > This work is not 100% complete, it still misses the ability to install > > kra instances and the ability to install a CA (via ipa-ca-install) with > > externally signed certs. > > > > However it is massive enough that warrants review and pushing, the resat > > of the changes can be applied later as this work should not disrupt the > > classic install methods. > > > > In order to build my previous patches (530-533) are needed as well as a > > number of updated components. > > > > I used the following coprs for testing: > > simo/jwcrypto > > simo/custodia > > abbra/sssd-kkdcproxy (for sssd 1.13.1) > > lkrispen/389-ds-current (for 389 > 1.3.4.4) > > vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > > mkosek/freeipa-4.2-fedora-22 (misc) > > fedora/updates-testing (python-gssapi 1.1.2) > > > > Ludwig's copr is necessary to have a functional DNA plugin in replicas, > > eventually his patches should be committed in 389-ds-base 1.3.4.4 when > > it will be released. > > > > We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > > that may cause installation issues in some case (re-install of a > > replica). > > > > The domain must be raised to level 1 in order to use replica promotion. > > > > In order to promote a replica the server must be first joined as a > > regular client to the domain. > > > > This is the flow I usually use for testing: > > > > # ipa-client-install > > # kinit admin > > # ipa-replica-install --promote --setup-ca > > > etc...> > > > > These patches are also available in this git tree rebnase on current > > master: > > https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > > > Simo. > > > > > > > > I'm running in a issue when upgrading RPMs: > > 2015-08-31T10:53:32Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > line 48, in run > server.upgrade() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1596, in upgrade > upgrade_configuration() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1508, in upgrade_configuration > custodia.upgrade_instance() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > 57, in upgrade_instance > self.__gen_keys() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > 51, in __gen_keys > KeyStore.generate_server_keys() > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in > generate_server_keys > ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in > set_key > conn.modify_s(dn, mods) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 364, in modify_s > return self.result(msgid,all=1,timeout=self.timeout) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 465, in result > resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 469, in result2 > resp_type, resp_data, resp_msgid, resp_ctrls = > self.result3(msgid,all,timeout) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 476, in result3 > resp_ctrl_classes=resp_ctrl_classes > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 483, in result4 > ldap_result = > self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 106, in _ldap_call > result = func(*args,**kwargs) > > 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, > exception: NO_SUCH_OBJECT: {'desc': 'No such object'} > 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT > No such object Have you found out what this was about ? I just found a different probelm affecting ipa-server-upgrade on my master, it tracebacks trying to update the schema, which is odd: 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema 2015-09-02T19:06:39Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket conn= 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file /usr/share/ipa/60kerberos.ldif 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 417, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 407, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 299, in __update_schema dm_password='', ldapi=True) or self.modified File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 131, in update_schema for oids_set in _get_oid_dependency_order(new_schema, cls): File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 59, in _get_oid_dependency_order unordered_oids = set(tree) File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, in __getitem__ return self.data[lower(key)] File "/usr/lib64/python2.7/string.py", line 228, in lower return s.lower() AttributeError: 'int' object has no attribute 'lower' Any ideas about this ? Simo -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 2 20:37:48 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2015 16:37:48 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1441221748.28131.180.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> <1441221748.28131.180.camel@willson.usersys.redhat.com> Message-ID: <1441226268.28131.186.camel@willson.usersys.redhat.com> On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote: > On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: > > > > On 08/26/2015 11:27 PM, Simo Sorce wrote: > > > This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > > > and introduces a number of required changes and dependencies to achieve > > > this goal. > > > This work requires the custodia project to securely transfer keys > > > between ipa servers. > > > > > > This work is not 100% complete, it still misses the ability to install > > > kra instances and the ability to install a CA (via ipa-ca-install) with > > > externally signed certs. > > > > > > However it is massive enough that warrants review and pushing, the resat > > > of the changes can be applied later as this work should not disrupt the > > > classic install methods. > > > > > > In order to build my previous patches (530-533) are needed as well as a > > > number of updated components. > > > > > > I used the following coprs for testing: > > > simo/jwcrypto > > > simo/custodia > > > abbra/sssd-kkdcproxy (for sssd 1.13.1) > > > lkrispen/389-ds-current (for 389 > 1.3.4.4) > > > vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > > > mkosek/freeipa-4.2-fedora-22 (misc) > > > fedora/updates-testing (python-gssapi 1.1.2) > > > > > > Ludwig's copr is necessary to have a functional DNA plugin in replicas, > > > eventually his patches should be committed in 389-ds-base 1.3.4.4 when > > > it will be released. > > > > > > We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > > > that may cause installation issues in some case (re-install of a > > > replica). > > > > > > The domain must be raised to level 1 in order to use replica promotion. > > > > > > In order to promote a replica the server must be first joined as a > > > regular client to the domain. > > > > > > This is the flow I usually use for testing: > > > > > > # ipa-client-install > > > # kinit admin > > > # ipa-replica-install --promote --setup-ca > > > > > etc...> > > > > > > These patches are also available in this git tree rebnase on current > > > master: > > > https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > > > > > Simo. > > > > > > > > > > > > > I'm running in a issue when upgrading RPMs: > > > > 2015-08-31T10:53:32Z DEBUG File > > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > > execute > > return_value = self.run() > > File > > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > > line 48, in run > > server.upgrade() > > File > > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > > line 1596, in upgrade > > upgrade_configuration() > > File > > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > > line 1508, in upgrade_configuration > > custodia.upgrade_instance() > > File > > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > > 57, in upgrade_instance > > self.__gen_keys() > > File > > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > > 51, in __gen_keys > > KeyStore.generate_server_keys() > > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in > > generate_server_keys > > ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) > > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in > > set_key > > conn.modify_s(dn, mods) > > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > > 364, in modify_s > > return self.result(msgid,all=1,timeout=self.timeout) > > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > > 465, in result > > resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) > > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > > 469, in result2 > > resp_type, resp_data, resp_msgid, resp_ctrls = > > self.result3(msgid,all,timeout) > > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > > 476, in result3 > > resp_ctrl_classes=resp_ctrl_classes > > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > > 483, in result4 > > ldap_result = > > self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) > > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > > 106, in _ldap_call > > result = func(*args,**kwargs) > > > > 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, > > exception: NO_SUCH_OBJECT: {'desc': 'No such object'} > > 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT > > No such object > > Have you found out what this was about ? > > I just found a different probelm affecting ipa-server-upgrade on my > master, it tracebacks trying to update the schema, which is odd: > > 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema > 2015-09-02T19:06:39Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache > 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket conn= > 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file /usr/share/ipa/60kerberos.ldif > 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 417, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 407, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 299, in __update_schema > dm_password='', ldapi=True) or self.modified > File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 131, in update_schema > for oids_set in _get_oid_dependency_order(new_schema, cls): > File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 59, in _get_oid_dependency_order > unordered_oids = set(tree) > File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, in __getitem__ > return self.data[lower(key)] > File "/usr/lib64/python2.7/string.py", line 228, in lower > return s.lower() > AttributeError: 'int' object has no attribute 'lower' > > > Any ideas about this ? FYI: replicated this on the second replica too... I can plod through by manually hacking the script to skip the schema update check, but this never happened before, did some patch recently land that changed how schemas are handled ? Simo. -- Simo Sorce * Red Hat, Inc * New York From akasurde at redhat.com Thu Sep 3 06:16:02 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 3 Sep 2015 11:46:02 +0530 Subject: [Freeipa-devel] [PATCH] Updated no of legacy permission in ipatests In-Reply-To: <55DE9B0D.6030101@redhat.com> References: <55DE9B0D.6030101@redhat.com> Message-ID: <55E7E5A2.2090402@redhat.com> Ping On 08/27/2015 10:37 AM, Abhijeet Kasurde wrote: > Hi All, > > This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264 > > Thanks, > Abhijeet Kasurde From mbasti at redhat.com Thu Sep 3 08:19:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 10:19:35 +0200 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <1441209638.28131.175.camel@willson.usersys.redhat.com> References: <55E71C63.1060907@redhat.com> <1441209638.28131.175.camel@willson.usersys.redhat.com> Message-ID: <55E80297.20709@redhat.com> On 09/02/2015 06:00 PM, Simo Sorce wrote: > On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: >> Client installation is done as "Restarting web server". This step >> deserve own message. >> >> Patch attached > I've seen various cases like this. And I can't understand why these > steps aren't embedded in the actual instance install steps that need the > restart (which implicitly also provide a message). > > In the promotion patchset I did move steps like this into the proper > instances, so I would prefer you do the same with the install path as > that is more appropriate. > > Simo. > We need restart httpd after CA, DNS(optional) installation, so thats why it is outside of httpd instance. Client install has no own step yet, it is just call of ipa-client-install. Martin^2 From ofayans at redhat.com Thu Sep 3 08:40:57 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 3 Sep 2015 10:40:57 +0200 Subject: [Freeipa-devel] [PATCH 0053-0056] DNSSEC: Fix deadlocks & export to LDAP In-Reply-To: <55E485E7.4070803@redhat.com> References: <55E485E7.4070803@redhat.com> Message-ID: <55E80799.7000507@redhat.com> NACK from me. 2 out of 5 tests still fail with assertion errors: https://paste.fedoraproject.org/262926/44126948/ Although, I am not sure these failures are caused by the same very problem. On 08/31/2015 06:50 PM, Petr Spacek wrote: > Hello, > > Attached patch set should fix the deadlock you discovered + few more issues I > spotted when testing the original patch. > > Known problems (more patches needed): > - /etc/opendnssec/zonelist.xml should be restored during server uninstall > - ccache for ipa-ods-exporter should be removed during server uninstall > - timestamps in .private key files do not reflect (?) current key state in > OpenDNSSEC database (I will look into this tomorrow.) > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Sep 3 08:57:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 10:57:44 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1441226268.28131.186.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> <1441221748.28131.180.camel@willson.usersys.redhat.com> <1441226268.28131.186.camel@willson.usersys.redhat.com> Message-ID: <55E80B88.1080703@redhat.com> On 09/02/2015 10:37 PM, Simo Sorce wrote: > On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote: >> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: >>> On 08/26/2015 11:27 PM, Simo Sorce wrote: >>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>>> and introduces a number of required changes and dependencies to achieve >>>> this goal. >>>> This work requires the custodia project to securely transfer keys >>>> between ipa servers. >>>> >>>> This work is not 100% complete, it still misses the ability to install >>>> kra instances and the ability to install a CA (via ipa-ca-install) with >>>> externally signed certs. >>>> >>>> However it is massive enough that warrants review and pushing, the resat >>>> of the changes can be applied later as this work should not disrupt the >>>> classic install methods. >>>> >>>> In order to build my previous patches (530-533) are needed as well as a >>>> number of updated components. >>>> >>>> I used the following coprs for testing: >>>> simo/jwcrypto >>>> simo/custodia >>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>> fedora/updates-testing (python-gssapi 1.1.2) >>>> >>>> Ludwig's copr is necessary to have a functional DNA plugin in replicas, >>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>>> it will be released. >>>> >>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>>> that may cause installation issues in some case (re-install of a >>>> replica). >>>> >>>> The domain must be raised to level 1 in order to use replica promotion. >>>> >>>> In order to promote a replica the server must be first joined as a >>>> regular client to the domain. >>>> >>>> This is the flow I usually use for testing: >>>> >>>> # ipa-client-install >>>> # kinit admin >>>> # ipa-replica-install --promote --setup-ca >>>> >>> etc...> >>>> >>>> These patches are also available in this git tree rebnase on current >>>> master: >>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>> >>>> Simo. >>>> >>>> >>>> >>> I'm running in a issue when upgrading RPMs: >>> >>> 2015-08-31T10:53:32Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in >>> execute >>> return_value = self.run() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >>> line 48, in run >>> server.upgrade() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>> line 1596, in upgrade >>> upgrade_configuration() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>> line 1508, in upgrade_configuration >>> custodia.upgrade_instance() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line >>> 57, in upgrade_instance >>> self.__gen_keys() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line >>> 51, in __gen_keys >>> KeyStore.generate_server_keys() >>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in >>> generate_server_keys >>> ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) >>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in >>> set_key >>> conn.modify_s(dn, mods) >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>> 364, in modify_s >>> return self.result(msgid,all=1,timeout=self.timeout) >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>> 465, in result >>> resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>> 469, in result2 >>> resp_type, resp_data, resp_msgid, resp_ctrls = >>> self.result3(msgid,all,timeout) >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>> 476, in result3 >>> resp_ctrl_classes=resp_ctrl_classes >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>> 483, in result4 >>> ldap_result = >>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>> 106, in _ldap_call >>> result = func(*args,**kwargs) >>> >>> 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, >>> exception: NO_SUCH_OBJECT: {'desc': 'No such object'} >>> 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT >>> No such object >> Have you found out what this was about ? >> >> I just found a different probelm affecting ipa-server-upgrade on my >> master, it tracebacks trying to update the schema, which is odd: >> >> 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema >> 2015-09-02T19:06:39Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache >> 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket conn= >> 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file /usr/share/ipa/60kerberos.ldif >> 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 417, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 407, in run_step >> method() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 299, in __update_schema >> dm_password='', ldapi=True) or self.modified >> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 131, in update_schema >> for oids_set in _get_oid_dependency_order(new_schema, cls): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 59, in _get_oid_dependency_order >> unordered_oids = set(tree) >> File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, in __getitem__ >> return self.data[lower(key)] >> File "/usr/lib64/python2.7/string.py", line 228, in lower >> return s.lower() >> AttributeError: 'int' object has no attribute 'lower' >> >> >> Any ideas about this ? > FYI: replicated this on the second replica too... > > I can plod through by manually hacking the script to skip the schema > update check, but this never happened before, did some patch recently > land that changed how schemas are handled ? > > Simo. > > We did not change schemaupdater code. I saw this issue yesterday for first time. I have to inspect this, python-ldap may be broken or some py3 cahnges could break it. Martin^2 From ofayans at redhat.com Thu Sep 3 09:04:10 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 3 Sep 2015 11:04:10 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <55E80B88.1080703@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> <1441221748.28131.180.camel@willson.usersys.redhat.com> <1441226268.28131.186.camel@willson.usersys.redhat.com> <55E80B88.1080703@redhat.com> Message-ID: <55E80D0A.4090102@redhat.com> I've encountered this today too. Filed a ticket about it: https://fedorahosted.org/freeipa/ticket/5283 On 09/03/2015 10:57 AM, Martin Basti wrote: > > > On 09/02/2015 10:37 PM, Simo Sorce wrote: >> On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote: >>> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: >>>> On 08/26/2015 11:27 PM, Simo Sorce wrote: >>>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>>>> and introduces a number of required changes and dependencies to >>>>> achieve >>>>> this goal. >>>>> This work requires the custodia project to securely transfer keys >>>>> between ipa servers. >>>>> >>>>> This work is not 100% complete, it still misses the ability to install >>>>> kra instances and the ability to install a CA (via ipa-ca-install) >>>>> with >>>>> externally signed certs. >>>>> >>>>> However it is massive enough that warrants review and pushing, the >>>>> resat >>>>> of the changes can be applied later as this work should not disrupt >>>>> the >>>>> classic install methods. >>>>> >>>>> In order to build my previous patches (530-533) are needed as well >>>>> as a >>>>> number of updated components. >>>>> >>>>> I used the following coprs for testing: >>>>> simo/jwcrypto >>>>> simo/custodia >>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>>> fedora/updates-testing (python-gssapi 1.1.2) >>>>> >>>>> Ludwig's copr is necessary to have a functional DNA plugin in >>>>> replicas, >>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>>>> it will be released. >>>>> >>>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>>>> that may cause installation issues in some case (re-install of a >>>>> replica). >>>>> >>>>> The domain must be raised to level 1 in order to use replica >>>>> promotion. >>>>> >>>>> In order to promote a replica the server must be first joined as a >>>>> regular client to the domain. >>>>> >>>>> This is the flow I usually use for testing: >>>>> >>>>> # ipa-client-install >>>>> # kinit admin >>>>> # ipa-replica-install --promote --setup-ca >>>>> >>>> etc...> >>>>> >>>>> These patches are also available in this git tree rebnase on current >>>>> master: >>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>>> >>>>> >>>>> Simo. >>>>> >>>>> >>>>> >>>> I'm running in a issue when upgrading RPMs: >>>> >>>> 2015-08-31T10:53:32Z DEBUG File >>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in >>>> execute >>>> return_value = self.run() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >>>> >>>> line 48, in run >>>> server.upgrade() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>>> line 1596, in upgrade >>>> upgrade_configuration() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>>> line 1508, in upgrade_configuration >>>> custodia.upgrade_instance() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", >>>> line >>>> 57, in upgrade_instance >>>> self.__gen_keys() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", >>>> line >>>> 51, in __gen_keys >>>> KeyStore.generate_server_keys() >>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in >>>> generate_server_keys >>>> ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) >>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in >>>> set_key >>>> conn.modify_s(dn, mods) >>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>> 364, in modify_s >>>> return self.result(msgid,all=1,timeout=self.timeout) >>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>> 465, in result >>>> resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) >>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>> 469, in result2 >>>> resp_type, resp_data, resp_msgid, resp_ctrls = >>>> self.result3(msgid,all,timeout) >>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>> 476, in result3 >>>> resp_ctrl_classes=resp_ctrl_classes >>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>> 483, in result4 >>>> ldap_result = >>>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) >>>> >>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>> 106, in _ldap_call >>>> result = func(*args,**kwargs) >>>> >>>> 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, >>>> exception: NO_SUCH_OBJECT: {'desc': 'No such object'} >>>> 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT >>>> No such object >>> Have you found out what this was about ? >>> >>> I just found a different probelm affecting ipa-server-upgrade on my >>> master, it tracebacks trying to update the schema, which is odd: >>> >>> 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema >>> 2015-09-02T19:06:39Z DEBUG flushing >>> ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache >>> 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache >>> url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket >>> conn= >>> 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file >>> /usr/share/ipa/60kerberos.ldif >>> 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 417, in start_creation >>> run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 407, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", >>> line 299, in __update_schema >>> dm_password='', ldapi=True) or self.modified >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", >>> line 131, in update_schema >>> for oids_set in _get_oid_dependency_order(new_schema, cls): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", >>> line 59, in _get_oid_dependency_order >>> unordered_oids = set(tree) >>> File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, >>> in __getitem__ >>> return self.data[lower(key)] >>> File "/usr/lib64/python2.7/string.py", line 228, in lower >>> return s.lower() >>> AttributeError: 'int' object has no attribute 'lower' >>> >>> >>> Any ideas about this ? >> FYI: replicated this on the second replica too... >> >> I can plod through by manually hacking the script to skip the schema >> update check, but this never happened before, did some patch recently >> land that changed how schemas are handled ? >> >> Simo. >> >> > We did not change schemaupdater code. > I saw this issue yesterday for first time. > I have to inspect this, python-ldap may be broken or some py3 cahnges > could break it. > > Martin^2 > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From msimacek at redhat.com Thu Sep 3 10:54:32 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Thu, 3 Sep 2015 12:54:32 +0200 Subject: [Freeipa-devel] [PATCH 0004] Rewrap errors in get_principal to CCacheError Message-ID: <55E826E8.7080703@redhat.com> After porting to gssapi, the ipa command prints ugly traceback when kerberos credentials are not available. Rewrapping to CCacheError when getting the principal name results in nicer error message. https://fedorahosted.org/freeipa/ticket/5272 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0004-1-Rewrap-errors-in-get_principal-to-CCacheError.patch Type: text/x-patch Size: 3335 bytes Desc: not available URL: From mbasti at redhat.com Thu Sep 3 11:01:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 13:01:36 +0200 Subject: [Freeipa-devel] [PATCH 0308] Server Upgrade: fix traceback caused by cidict Message-ID: <55E82890.6010502@redhat.com> https://fedorahosted.org/freeipa/ticket/5283 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0308-Server-Upgrade-fix-traceback-caused-by-cidict.patch Type: text/x-patch Size: 1047 bytes Desc: not available URL: From ldoudova at redhat.com Thu Sep 3 11:40:55 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 3 Sep 2015 13:40:55 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> Message-ID: <55E831C7.1040202@redhat.com> Hi, I took a look at it at Milan's request. patch 0008 - tracker looks ok, ACK patch 0009 - test cases look ok as well, but can't get it to run, 10 out of 14 tests fail, starting with internal error, which I haven't been able to track down, nor fix it. Lenka =================================== FAILURES =================================== ____________________ TestProfileCRUD.test_create_duplicate _____________________ self = user_profile = def test_create_duplicate(self, user_profile): msg = u'Certificate Profile with name "{}" already exists' > user_profile.ensure_exists() ipatests/test_xmlrpc/test_certprofile_plugin.py:178: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists self.create(force=True) ipatests/test_xmlrpc/ldaptracker.py:206: in create result = command() ipatests/test_xmlrpc/ldaptracker.py:127: in run_command result = cmd(*args, **options) ipalib/frontend.py:443: in __call__ ret = self.run(*args, **options) ipalib/frontend.py:761: in run return self.forward(*args, **options) ipalib/frontend.py:782: in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) ipalib/rpc.py:947: in forward return self._call_command(command, params) ipalib/rpc.py:924: in _call_command return command(*params) ipalib/rpc.py:1075: in _call return self.__request(name, args) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = name = 'certprofile_import' args = (('caIPAserviceCert_mod',), {'all': False, 'description': 'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion Default policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 ', 'ipacertprofilestoreissued': True, ...}) def __request(self, name, args): payload = {'method': unicode(name), 'params': args, 'id': 0} version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES) payload = json_encode_binary(payload, version) if self.__verbose >= 2: root_logger.info('Request: %s', json.dumps(payload, sort_keys=True, indent=4)) response = self.__transport.request( self.__host, self.__handler, json.dumps(payload), verbose=self.__verbose >= 3, ) try: response = json_decode_binary(json.loads(response)) except ValueError as e: raise JSONError(str(e)) if self.__verbose >= 2: root_logger.info( 'Response: %s', json.dumps(json_encode_binary(response, version), sort_keys=True, indent=4) ) error = response.get('error') if error: try: error_class = errors_by_code[error['code']] except KeyError: raise UnknownError( code=error.get('code'), error=error.get('message'), server=self.__host, ) else: > raise error_class(message=error['message']) E InternalError: an internal error has occurred On 08/31/2015 03:25 PM, Fraser Tweedale wrote: > On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote: >> >> On 08/18/2015 04:06 PM, Milan Kub?k wrote: >>> On 08/11/2015 03:17 AM, Fraser Tweedale wrote: >>>> On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: >>>>> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>>>>> Hi list, >>>>>> >>>>>> I'm sending the test plan [1] for certificate profiles and preliminary >>>>>> patches for it. >>>>>> The plan covers basic CRUD test and some corner cases. I'm open to >>>>>> more >>>>>> suggestions. >>>>>> >>>>>> More complicated tests involving certificate profiles will require the >>>>>> code (and tests) >>>>>> for CA ACLs merged, so it's not there at the moment. >>>>>> >>>>>> There are some unfinished test cases in places I wasn't sure what the >>>>>> result should be. >>>>>> We need to iterate through these to fix it. >>>>>> >>>>>> >>>>>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>>>>> >>>>>> Cheers, >>>>>> Milan >>>>> Hi all, >>>>> >>>>> have you had some time to look at the code and proposal? >>>>> Today I want to write a basic CRUD test for the ACLs as well as a few >>>>> test >>>>> cases to check if the ACL is being enforced. It should make it into >>>>> wiki >>>>> today or by tomorrow. I'll send an update then. >>>>> >>>>> Cheers, >>>>> Milan >>>>> >>>> Hi Milan, >>>> >>>> I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of >>>> comments: >>>> >>>> - Test case: Import profile with incorrect values >>>> - Expected result: refused with error. >>>> - A simple way to provoke this condition is to add a number to >>>> ``policyset.serverCertSet.list``. >>>> - A similar test case should exist for certprofile-mod. >>>> >>>> - Test case: Delete default profile >>>> - As discussed elsewhere, expected result should be failure. >>>> I filed ticket #5198 to make it so :) >>>> >>>> I will review the patch soon. >>>> >>>> Cheers, >>>> Fraser >>> Hello, >>> >>> how is the review going? I'd like to have at least the tracker (patch >>> 0008) >>> reviewed (and merged :) if possible. It will be needed in CA ACL tests. >>> >>> Cheers, >>> Milan >>> >> Fraser, do you review this patchset? > This fell off my radar, sorry! I eyeballed it a while back and > everything seemed fine; I have not (successfully) run the tests yet > though. I will complete the review tomorrow. > > Thanks, > Fraser > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Sep 3 11:42:06 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 3 Sep 2015 13:42:06 +0200 Subject: [Freeipa-devel] [PATCH 0308] Server Upgrade: fix traceback caused by cidict In-Reply-To: <55E82890.6010502@redhat.com> References: <55E82890.6010502@redhat.com> Message-ID: <55E8320E.5090208@redhat.com> On 09/03/2015 01:01 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5283 > > Patch attached. ACK. This was caused by commit 3bf91ea, specifically the rushed reaction to Christian's comment: > Please use sorted(reference) instead of sorted(reference.keys()), > set(tree) instead of set(tree.keys()) and list(somedict) instead of > list(somedict.keys()), too. The keys() call is unnecessary and frowned upon. Turns out python-ldap's cidict is not a propper Mapping, so the keys() call *is* necessary. Sorry for missing that. -- Petr Viktorin From mbasti at redhat.com Thu Sep 3 12:12:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 14:12:23 +0200 Subject: [Freeipa-devel] [PATCH 0308] Server Upgrade: fix traceback caused by cidict In-Reply-To: <55E8320E.5090208@redhat.com> References: <55E82890.6010502@redhat.com> <55E8320E.5090208@redhat.com> Message-ID: <55E83927.2010502@redhat.com> On 09/03/2015 01:42 PM, Petr Viktorin wrote: > On 09/03/2015 01:01 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5283 >> >> Patch attached. > ACK. > > > This was caused by commit 3bf91ea, specifically the rushed reaction to > Christian's comment: >> Please use sorted(reference) instead of sorted(reference.keys()), >> set(tree) instead of set(tree.keys()) and list(somedict) instead of >> list(somedict.keys()), too. The keys() call is unnecessary and frowned upon. > Turns out python-ldap's cidict is not a propper Mapping, so the keys() > call *is* necessary. > Sorry for missing that. > > Pushed to master: 0c5e41cc79f75e12094773cdf5a296dd06052763 From tbabej at redhat.com Thu Sep 3 12:30:18 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 3 Sep 2015 14:30:18 +0200 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements Message-ID: <55E83D5A.2050804@redhat.com> Hi, this couple of patches fix https://fedorahosted.org/freeipa/ticket/5278 and improve our handling of realmdomains in general. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0362-util-Add-detect_dns_zone_realm_type-helper.patch Type: text/x-patch Size: 2637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0363-realmdomains-Minor-style-and-wording-improvements.patch Type: text/x-patch Size: 5717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0364-realmdomains-Add-validation-that-realmdomain-being-a.patch Type: text/x-patch Size: 5659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0365-realmdomains-Issue-a-warning-when-automated-manageme.patch Type: text/x-patch Size: 4037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0366-realmdomains-Do-not-fail-due-the-ValidationError-whe.patch Type: text/x-patch Size: 1649 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 3 12:32:56 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 3 Sep 2015 14:32:56 +0200 Subject: [Freeipa-devel] [PATCH 0004] Rewrap errors in get_principal to CCacheError In-Reply-To: <55E826E8.7080703@redhat.com> References: <55E826E8.7080703@redhat.com> Message-ID: <55E83DF8.3040201@redhat.com> On 09/03/2015 12:54 PM, Michael ?im??ek wrote: > After porting to gssapi, the ipa command prints ugly traceback when > kerberos credentials are not available. Rewrapping to CCacheError when > getting the principal name results in nicer error message. > > https://fedorahosted.org/freeipa/ticket/5272 > > This fixes the issue, however, I am getting a trailing forward slash in the error message: $ ipa user-find ipa: ERROR: Kerberos error: did not receive Kerberos credentials/ From tbabej at redhat.com Thu Sep 3 12:35:39 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 3 Sep 2015 14:35:39 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55E831C7.1040202@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> Message-ID: <55E83E9B.8070901@redhat.com> On 09/03/2015 01:40 PM, Lenka Doudova wrote: > Hi, > > I took a look at it at Milan's request. > > patch 0008 - tracker looks ok, ACK > patch 0009 - test cases look ok as well, but can't get it to run, 10 out > of 14 tests fail, starting with internal error, which I haven't been > able to track down, nor fix it. You can investigate the internal error by inspecting the /var/log/httpd/error_log on the IPA server that executed the command. There should be a traceback. > > Lenka > > =================================== FAILURES > =================================== > ____________________ TestProfileCRUD.test_create_duplicate > _____________________ > > self = object at 0x7f36459e7110> > user_profile = > at 0x7f36459e73d0> > > def test_create_duplicate(self, user_profile): > msg = u'Certificate Profile with name "{}" already exists' >> user_profile.ensure_exists() > > ipatests/test_xmlrpc/test_certprofile_plugin.py:178: > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ > ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists > self.create(force=True) > ipatests/test_xmlrpc/ldaptracker.py:206: in create > result = command() > ipatests/test_xmlrpc/ldaptracker.py:127: in run_command > result = cmd(*args, **options) > ipalib/frontend.py:443: in __call__ > ret = self.run(*args, **options) > ipalib/frontend.py:761: in run > return self.forward(*args, **options) > ipalib/frontend.py:782: in forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > ipalib/rpc.py:947: in forward > return self._call_command(command, params) > ipalib/rpc.py:924: in _call_command > return command(*params) > ipalib/rpc.py:1075: in _call > return self.__request(name, args) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ > > self = > name = 'certprofile_import' > args = (('caIPAserviceCert_mod',), {'all': False, 'description': > 'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion Default > policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 > ', 'ipacertprofilestoreissued': True, ...}) > > def __request(self, name, args): > payload = {'method': unicode(name), 'params': args, 'id': 0} > version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES) > payload = json_encode_binary(payload, version) > > if self.__verbose >= 2: > root_logger.info('Request: %s', > json.dumps(payload, sort_keys=True, indent=4)) > > response = self.__transport.request( > self.__host, > self.__handler, > json.dumps(payload), > verbose=self.__verbose >= 3, > ) > > try: > response = json_decode_binary(json.loads(response)) > except ValueError as e: > raise JSONError(str(e)) > > if self.__verbose >= 2: > root_logger.info( > 'Response: %s', > json.dumps(json_encode_binary(response, version), > sort_keys=True, indent=4) > ) > error = response.get('error') > if error: > try: > error_class = errors_by_code[error['code']] > except KeyError: > raise UnknownError( > code=error.get('code'), > error=error.get('message'), > server=self.__host, > ) > else: >> raise error_class(message=error['message']) > E InternalError: an internal error has occurred > > > > > On 08/31/2015 03:25 PM, Fraser Tweedale wrote: >> On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote: >>> >>> On 08/18/2015 04:06 PM, Milan Kub?k wrote: >>>> On 08/11/2015 03:17 AM, Fraser Tweedale wrote: >>>>> On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: >>>>>> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>>>>>> Hi list, >>>>>>> >>>>>>> I'm sending the test plan [1] for certificate profiles and preliminary >>>>>>> patches for it. >>>>>>> The plan covers basic CRUD test and some corner cases. I'm open to >>>>>>> more >>>>>>> suggestions. >>>>>>> >>>>>>> More complicated tests involving certificate profiles will require the >>>>>>> code (and tests) >>>>>>> for CA ACLs merged, so it's not there at the moment. >>>>>>> >>>>>>> There are some unfinished test cases in places I wasn't sure what the >>>>>>> result should be. >>>>>>> We need to iterate through these to fix it. >>>>>>> >>>>>>> >>>>>>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>>>>>> >>>>>>> Cheers, >>>>>>> Milan >>>>>> Hi all, >>>>>> >>>>>> have you had some time to look at the code and proposal? >>>>>> Today I want to write a basic CRUD test for the ACLs as well as a few >>>>>> test >>>>>> cases to check if the ACL is being enforced. It should make it into >>>>>> wiki >>>>>> today or by tomorrow. I'll send an update then. >>>>>> >>>>>> Cheers, >>>>>> Milan >>>>>> >>>>> Hi Milan, >>>>> >>>>> I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of >>>>> comments: >>>>> >>>>> - Test case: Import profile with incorrect values >>>>> - Expected result: refused with error. >>>>> - A simple way to provoke this condition is to add a number to >>>>> ``policyset.serverCertSet.list``. >>>>> - A similar test case should exist for certprofile-mod. >>>>> >>>>> - Test case: Delete default profile >>>>> - As discussed elsewhere, expected result should be failure. >>>>> I filed ticket #5198 to make it so :) >>>>> >>>>> I will review the patch soon. >>>>> >>>>> Cheers, >>>>> Fraser >>>> Hello, >>>> >>>> how is the review going? I'd like to have at least the tracker (patch >>>> 0008) >>>> reviewed (and merged :) if possible. It will be needed in CA ACL tests. >>>> >>>> Cheers, >>>> Milan >>>> >>> Fraser, do you review this patchset? >> This fell off my radar, sorry! I eyeballed it a while back and >> everything seemed fine; I have not (successfully) run the tests yet >> though. I will complete the review tomorrow. >> >> Thanks, >> Fraser >> > > > From mbasti at redhat.com Thu Sep 3 12:35:39 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 14:35:39 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55E831C7.1040202@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> Message-ID: <55E83E9B.7000703@redhat.com> On 09/03/2015 01:40 PM, Lenka Doudova wrote: > Hi, > > I took a look at it at Milan's request. > > patch 0008 - tracker looks ok, ACK > patch 0009 - test cases look ok as well, but can't get it to run, 10 > out of 14 tests fail, starting with internal error, which I haven't > been able to track down, nor fix it. Can you check /var/log/httpr/errors_log what the internal error is? Martin^2 > > Lenka > > =================================== FAILURES > =================================== > ____________________ TestProfileCRUD.test_create_duplicate > _____________________ > > self = object at 0x7f36459e7110> > user_profile = > object at 0x7f36459e73d0> > > def test_create_duplicate(self, user_profile): > msg = u'Certificate Profile with name "{}" already exists' > > user_profile.ensure_exists() > > ipatests/test_xmlrpc/test_certprofile_plugin.py:178: > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ > ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists > self.create(force=True) > ipatests/test_xmlrpc/ldaptracker.py:206: in create > result = command() > ipatests/test_xmlrpc/ldaptracker.py:127: in run_command > result = cmd(*args, **options) > ipalib/frontend.py:443: in __call__ > ret = self.run(*args, **options) > ipalib/frontend.py:761: in run > return self.forward(*args, **options) > ipalib/frontend.py:782: in forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > ipalib/rpc.py:947: in forward > return self._call_command(command, params) > ipalib/rpc.py:924: in _call_command > return command(*params) > ipalib/rpc.py:1075: in _call > return self.__request(name, args) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ > > self = > name = 'certprofile_import' > args = (('caIPAserviceCert_mod',), {'all': False, 'description': > 'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion > Default > policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 > ', 'ipacertprofilestoreissued': True, ...}) > > def __request(self, name, args): > payload = {'method': unicode(name), 'params': args, 'id': 0} > version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES) > payload = json_encode_binary(payload, version) > > if self.__verbose >= 2: > root_logger.info('Request: %s', > json.dumps(payload, sort_keys=True, > indent=4)) > > response = self.__transport.request( > self.__host, > self.__handler, > json.dumps(payload), > verbose=self.__verbose >= 3, > ) > > try: > response = json_decode_binary(json.loads(response)) > except ValueError as e: > raise JSONError(str(e)) > > if self.__verbose >= 2: > root_logger.info( > 'Response: %s', > json.dumps(json_encode_binary(response, version), > sort_keys=True, indent=4) > ) > error = response.get('error') > if error: > try: > error_class = errors_by_code[error['code']] > except KeyError: > raise UnknownError( > code=error.get('code'), > error=error.get('message'), > server=self.__host, > ) > else: > > raise error_class(message=error['message']) > E InternalError: an internal error has occurred > > > > > On 08/31/2015 03:25 PM, Fraser Tweedale wrote: >> On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote: >>> On 08/18/2015 04:06 PM, Milan Kub?k wrote: >>>> On 08/11/2015 03:17 AM, Fraser Tweedale wrote: >>>>> On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: >>>>>> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>>>>>> Hi list, >>>>>>> >>>>>>> I'm sending the test plan [1] for certificate profiles and preliminary >>>>>>> patches for it. >>>>>>> The plan covers basic CRUD test and some corner cases. I'm open to >>>>>>> more >>>>>>> suggestions. >>>>>>> >>>>>>> More complicated tests involving certificate profiles will require the >>>>>>> code (and tests) >>>>>>> for CA ACLs merged, so it's not there at the moment. >>>>>>> >>>>>>> There are some unfinished test cases in places I wasn't sure what the >>>>>>> result should be. >>>>>>> We need to iterate through these to fix it. >>>>>>> >>>>>>> >>>>>>> [1]:http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>>>>>> >>>>>>> Cheers, >>>>>>> Milan >>>>>> Hi all, >>>>>> >>>>>> have you had some time to look at the code and proposal? >>>>>> Today I want to write a basic CRUD test for the ACLs as well as a few >>>>>> test >>>>>> cases to check if the ACL is being enforced. It should make it into >>>>>> wiki >>>>>> today or by tomorrow. I'll send an update then. >>>>>> >>>>>> Cheers, >>>>>> Milan >>>>>> >>>>> Hi Milan, >>>>> >>>>> I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of >>>>> comments: >>>>> >>>>> - Test case: Import profile with incorrect values >>>>> - Expected result: refused with error. >>>>> - A simple way to provoke this condition is to add a number to >>>>> ``policyset.serverCertSet.list``. >>>>> - A similar test case should exist for certprofile-mod. >>>>> >>>>> - Test case: Delete default profile >>>>> - As discussed elsewhere, expected result should be failure. >>>>> I filed ticket #5198 to make it so :) >>>>> >>>>> I will review the patch soon. >>>>> >>>>> Cheers, >>>>> Fraser >>>> Hello, >>>> >>>> how is the review going? I'd like to have at least the tracker (patch >>>> 0008) >>>> reviewed (and merged :) if possible. It will be needed in CA ACL tests. >>>> >>>> Cheers, >>>> Milan >>>> >>> Fraser, do you review this patchset? >> This fell off my radar, sorry! I eyeballed it a while back and >> everything seemed fine; I have not (successfully) run the tests yet >> though. I will complete the review tomorrow. >> >> Thanks, >> Fraser >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Sep 3 12:40:17 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 3 Sep 2015 14:40:17 +0200 Subject: [Freeipa-devel] [PATCH] Updated no of legacy permission in ipatests In-Reply-To: <55E7E5A2.2090402@redhat.com> References: <55DE9B0D.6030101@redhat.com> <55E7E5A2.2090402@redhat.com> Message-ID: <55E83FB1.9020800@redhat.com> On 09/03/2015 08:16 AM, Abhijeet Kasurde wrote: > Ping > > On 08/27/2015 10:37 AM, Abhijeet Kasurde wrote: >> Hi All, >> >> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264 >> >> Thanks, >> Abhijeet Kasurde > ACK, the patch needs a minor rebase on master due to python3 refactoring. From simo at redhat.com Thu Sep 3 12:42:05 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Sep 2015 08:42:05 -0400 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <55E80297.20709@redhat.com> References: <55E71C63.1060907@redhat.com> <1441209638.28131.175.camel@willson.usersys.redhat.com> <55E80297.20709@redhat.com> Message-ID: <1441284125.28131.197.camel@willson.usersys.redhat.com> On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote: > On 09/02/2015 06:00 PM, Simo Sorce wrote: > > On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: > >> Client installation is done as "Restarting web server". This step > >> deserve own message. > >> > >> Patch attached > > I've seen various cases like this. And I can't understand why these > > steps aren't embedded in the actual instance install steps that need the > > restart (which implicitly also provide a message). > > > > In the promotion patchset I did move steps like this into the proper > > instances, so I would prefer you do the same with the install path as > > that is more appropriate. > > > > Simo. > > > > We need restart httpd after CA, DNS(optional) installation, so thats why > it is outside of httpd instance. You need to restart httpd always after CA install as it changes the proxy settings, but why do you need to restart it after DNS installation ? (I think it is fine to restart it twice if it is really needed after DNS change). > Client install has no own step yet, it is just call of ipa-client-install. This is fine, ipa-client-install is another ball of wax. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Sep 3 12:57:38 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Sep 2015 08:57:38 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <55E80B88.1080703@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> <1441221748.28131.180.camel@willson.usersys.redhat.com> <1441226268.28131.186.camel@willson.usersys.redhat.com> <55E80B88.1080703@redhat.com> Message-ID: <1441285058.28131.202.camel@willson.usersys.redhat.com> On Thu, 2015-09-03 at 10:57 +0200, Martin Basti wrote: > > On 09/02/2015 10:37 PM, Simo Sorce wrote: > > On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote: > >> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: > >>> On 08/26/2015 11:27 PM, Simo Sorce wrote: > >>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > >>>> and introduces a number of required changes and dependencies to achieve > >>>> this goal. > >>>> This work requires the custodia project to securely transfer keys > >>>> between ipa servers. > >>>> > >>>> This work is not 100% complete, it still misses the ability to install > >>>> kra instances and the ability to install a CA (via ipa-ca-install) with > >>>> externally signed certs. > >>>> > >>>> However it is massive enough that warrants review and pushing, the resat > >>>> of the changes can be applied later as this work should not disrupt the > >>>> classic install methods. > >>>> > >>>> In order to build my previous patches (530-533) are needed as well as a > >>>> number of updated components. > >>>> > >>>> I used the following coprs for testing: > >>>> simo/jwcrypto > >>>> simo/custodia > >>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) > >>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) > >>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > >>>> mkosek/freeipa-4.2-fedora-22 (misc) > >>>> fedora/updates-testing (python-gssapi 1.1.2) > >>>> > >>>> Ludwig's copr is necessary to have a functional DNA plugin in replicas, > >>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when > >>>> it will be released. > >>>> > >>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > >>>> that may cause installation issues in some case (re-install of a > >>>> replica). > >>>> > >>>> The domain must be raised to level 1 in order to use replica promotion. > >>>> > >>>> In order to promote a replica the server must be first joined as a > >>>> regular client to the domain. > >>>> > >>>> This is the flow I usually use for testing: > >>>> > >>>> # ipa-client-install > >>>> # kinit admin > >>>> # ipa-replica-install --promote --setup-ca > >>>> >>>> etc...> > >>>> > >>>> These patches are also available in this git tree rebnase on current > >>>> master: > >>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > >>>> > >>>> Simo. > >>>> > >>>> > >>>> > >>> I'm running in a issue when upgrading RPMs: > >>> > >>> 2015-08-31T10:53:32Z DEBUG File > >>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > >>> execute > >>> return_value = self.run() > >>> File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > >>> line 48, in run > >>> server.upgrade() > >>> File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > >>> line 1596, in upgrade > >>> upgrade_configuration() > >>> File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > >>> line 1508, in upgrade_configuration > >>> custodia.upgrade_instance() > >>> File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > >>> 57, in upgrade_instance > >>> self.__gen_keys() > >>> File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > >>> 51, in __gen_keys > >>> KeyStore.generate_server_keys() > >>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in > >>> generate_server_keys > >>> ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) > >>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in > >>> set_key > >>> conn.modify_s(dn, mods) > >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>> 364, in modify_s > >>> return self.result(msgid,all=1,timeout=self.timeout) > >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>> 465, in result > >>> resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) > >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>> 469, in result2 > >>> resp_type, resp_data, resp_msgid, resp_ctrls = > >>> self.result3(msgid,all,timeout) > >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>> 476, in result3 > >>> resp_ctrl_classes=resp_ctrl_classes > >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>> 483, in result4 > >>> ldap_result = > >>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) > >>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>> 106, in _ldap_call > >>> result = func(*args,**kwargs) > >>> > >>> 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, > >>> exception: NO_SUCH_OBJECT: {'desc': 'No such object'} > >>> 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT > >>> No such object > >> Have you found out what this was about ? > >> > >> I just found a different probelm affecting ipa-server-upgrade on my > >> master, it tracebacks trying to update the schema, which is odd: > >> > >> 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema > >> 2015-09-02T19:06:39Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache > >> 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket conn= > >> 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file /usr/share/ipa/60kerberos.ldif > >> 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last): > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 417, in start_creation > >> run_step(full_msg, method) > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 407, in run_step > >> method() > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 299, in __update_schema > >> dm_password='', ldapi=True) or self.modified > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 131, in update_schema > >> for oids_set in _get_oid_dependency_order(new_schema, cls): > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 59, in _get_oid_dependency_order > >> unordered_oids = set(tree) > >> File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, in __getitem__ > >> return self.data[lower(key)] > >> File "/usr/lib64/python2.7/string.py", line 228, in lower > >> return s.lower() > >> AttributeError: 'int' object has no attribute 'lower' > >> > >> > >> Any ideas about this ? > > FYI: replicated this on the second replica too... > > > > I can plod through by manually hacking the script to skip the schema > > update check, but this never happened before, did some patch recently > > land that changed how schemas are handled ? > > > > Simo. > > > > > We did not change schemaupdater code. > I saw this issue yesterday for first time. > I have to inspect this, python-ldap may be broken or some py3 cahnges > could break it. I bet on py3 changes, somethign cause data to stay as int instead of being converted to string I would guess. I have not updated python-ldap so that is unlikely. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Thu Sep 3 13:18:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 3 Sep 2015 15:18:06 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55E68898.1000300@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> <55E68898.1000300@redhat.com> Message-ID: <55E8488E.5070308@redhat.com> On 2.9.2015 07:26, Endi Sukma Dewata wrote: > On 9/1/2015 10:22 AM, Simo Sorce wrote: >> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >>> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>>> adds commands: >>>>>>> * vaultcontainer-show [--service |--user ] >>>>>>> * vaultcontainer-add-owner >>>>>>> [--service |--user ] >>>>>>> [--users ] [--groups ] [--services >>>>>>> ] >>>>>>> * vaultcontainer-remove-owner >>>>>>> [--service |--user ] >>>>>>> [--users ] [--groups ] [--services >>>>>>> ] >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>>> >>>>>>> Use cases: >>>>>>> 1. When user/service is deleted, associated vault container looses >>>>>>> owner. There was no API command to set the owner. >>>>>>> 2. Change owner of container by admin to manage access. >>>>>>> >>>>>>> Show command was added to show current owners. >>>>>>> >>>>>>> Find command was not added, should it be? >>>>>>> >>>>>>> >>>>>> >>>>>> There is also a design for vault container ownership handling >>>>>> created by >>>>>> Endi - it's for future Vault 2.0. >>>>>> >>>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>>> >>>>>> >>>>>> This patch has a different API than the proposed - different way of >>>>>> specifying the container. The design page uses path e.g. >>>>>> /users/foobar. >>>>>> This patch uses the same way as vaults e.g. --user=foobar. This means >>>>>> that the implementation in this patch cannot manage ownership of >>>>>> parent >>>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>>> >>>>>> Do we want to go with this approach in 4.2? >>>>>> >>>>>> Attaching also new path which removes setting of owner which doesn't >>>>>> exist so that integrity is OK and that it is consistent with >>>>>> removing of >>>>>> user. >>>>>> >>>>>> Updated patch attached - output fix. >>>>> >>>>> We had a long discussion about this with Petr and we think the best >>>>> approach is as follows: >>>>> >>>>> * Add new "Vault administrators" privilege. Vault >>>>> administrators will >>>>> have unrestricted access to vaults and vault containers, including the >>>>> power to add/remove owners of vaults and vault containers. >>>>> >>>>> * Remove the ability of vault owners to add/remove other vault >>>>> owners. If vault owner needs to be changed, vault administrator has to >>>>> do it. Note that vault owners will still have the ability to >>>>> add/remove >>>>> vault members. >>>>> >>>>> * When adding new vault container, set owner to the current >>>>> user. If >>>>> vault container owner needs to be changed, vault administrator has >>>>> to do >>>>> it. >>>>> >>>>> * Allow adding vaults and vault containers only if the owner is >>>>> set >>>>> to the current user. >>>>> >>>>> * Introduce commands to modify vault container owner and to delete >>>>> vault container, so the administrator has a choice between assigning >>>>> ownership or deleting an unowned container. >>>> >>>> Also: >>>> >>>> * Control access to vault data using an ipaProtectedOperation ACI. >>>> Users which have read access to "ipaProtectedOperation;accessKRA" on a >>>> vault can retrieve data from the vault and users which have write >>>> access >>>> to "ipaProtectedOperation;accessKRA" on a vault can archive data in the >>>> vault. >>>> >>>> Honza >>>> >>> >>> +1 >>> >>> CCing Simo and Endi to check the proposal. >>> >>> And Scott (related to #5216, #5215) >> >> Sounds reasonable to me. >> I can see that allowing owners to hand over vaults w/o admin >> intervention may have some appeal in some use cases, but I also see it >> can bring downsides with it, so all in all I think I agree with the >> above points. >> >> Simo. >> > > Not a total objection, but if many people in unrelated groups are using > vaults, and they are sharing the vaults only with members of each group, > having to ask a Vault Administrator for each ownership change sounds a > bit cumbersome. Since the Vault Adminstrator will have access to all > vaults in all groups, only a small number of people can be trusted to > hold that role. If there are many ownership changes the Vault > Administrator will have to handle all those requests, and the vault > users may have to wait until the change is completed. > > If owners are allowed to add others as owners, the vaults will be pretty > much maintenance free to the admin. Owners can still manage members, which is IMO good enough for sharing a vault with other users. > > Regardless, please update the wiki page to describe the new behavior > when it's implemented: > http://www.freeipa.org/page/V4/Password_Vault_1.1 Sure. I have updated and rebased Petr's patch 916. Patch 488 obsoletes Petr's patch 918. Patch for vault data access control is not included, because I was not able to make GER work correctly with "ipaProtectedOperation;accessKRA". -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0916-2-vault-add-vault-container-commands.patch Type: text/x-patch Size: 12790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-488-vault-set-owner-to-current-user-on-container-creatio.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-489-vault-update-access-control.patch Type: text/x-patch Size: 6173 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-490-vault-add-permissions-and-administrator-privilege.patch Type: text/x-patch Size: 11138 bytes Desc: not available URL: From mbasti at redhat.com Thu Sep 3 13:21:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 15:21:13 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1441285058.28131.202.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> <1441221748.28131.180.camel@willson.usersys.redhat.com> <1441226268.28131.186.camel@willson.usersys.redhat.com> <55E80B88.1080703@redhat.com> <1441285058.28131.202.camel@willson.usersys.redhat.com> Message-ID: <55E84949.9020002@redhat.com> On 09/03/2015 02:57 PM, Simo Sorce wrote: > On Thu, 2015-09-03 at 10:57 +0200, Martin Basti wrote: >> On 09/02/2015 10:37 PM, Simo Sorce wrote: >>> On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote: >>>> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: >>>>> On 08/26/2015 11:27 PM, Simo Sorce wrote: >>>>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>>>>> and introduces a number of required changes and dependencies to achieve >>>>>> this goal. >>>>>> This work requires the custodia project to securely transfer keys >>>>>> between ipa servers. >>>>>> >>>>>> This work is not 100% complete, it still misses the ability to install >>>>>> kra instances and the ability to install a CA (via ipa-ca-install) with >>>>>> externally signed certs. >>>>>> >>>>>> However it is massive enough that warrants review and pushing, the resat >>>>>> of the changes can be applied later as this work should not disrupt the >>>>>> classic install methods. >>>>>> >>>>>> In order to build my previous patches (530-533) are needed as well as a >>>>>> number of updated components. >>>>>> >>>>>> I used the following coprs for testing: >>>>>> simo/jwcrypto >>>>>> simo/custodia >>>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>>>> fedora/updates-testing (python-gssapi 1.1.2) >>>>>> >>>>>> Ludwig's copr is necessary to have a functional DNA plugin in replicas, >>>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>>>>> it will be released. >>>>>> >>>>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>>>>> that may cause installation issues in some case (re-install of a >>>>>> replica). >>>>>> >>>>>> The domain must be raised to level 1 in order to use replica promotion. >>>>>> >>>>>> In order to promote a replica the server must be first joined as a >>>>>> regular client to the domain. >>>>>> >>>>>> This is the flow I usually use for testing: >>>>>> >>>>>> # ipa-client-install >>>>>> # kinit admin >>>>>> # ipa-replica-install --promote --setup-ca >>>>>> >>>>> etc...> >>>>>> >>>>>> These patches are also available in this git tree rebnase on current >>>>>> master: >>>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>>>> >>>>>> Simo. >>>>>> >>>>>> >>>>>> >>>>> I'm running in a issue when upgrading RPMs: >>>>> >>>>> 2015-08-31T10:53:32Z DEBUG File >>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in >>>>> execute >>>>> return_value = self.run() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >>>>> line 48, in run >>>>> server.upgrade() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>>>> line 1596, in upgrade >>>>> upgrade_configuration() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>>>> line 1508, in upgrade_configuration >>>>> custodia.upgrade_instance() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line >>>>> 57, in upgrade_instance >>>>> self.__gen_keys() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line >>>>> 51, in __gen_keys >>>>> KeyStore.generate_server_keys() >>>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in >>>>> generate_server_keys >>>>> ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) >>>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in >>>>> set_key >>>>> conn.modify_s(dn, mods) >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>>> 364, in modify_s >>>>> return self.result(msgid,all=1,timeout=self.timeout) >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>>> 465, in result >>>>> resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>>> 469, in result2 >>>>> resp_type, resp_data, resp_msgid, resp_ctrls = >>>>> self.result3(msgid,all,timeout) >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>>> 476, in result3 >>>>> resp_ctrl_classes=resp_ctrl_classes >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>>> 483, in result4 >>>>> ldap_result = >>>>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line >>>>> 106, in _ldap_call >>>>> result = func(*args,**kwargs) >>>>> >>>>> 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, >>>>> exception: NO_SUCH_OBJECT: {'desc': 'No such object'} >>>>> 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT >>>>> No such object >>>> Have you found out what this was about ? >>>> >>>> I just found a different probelm affecting ipa-server-upgrade on my >>>> master, it tracebacks trying to update the schema, which is odd: >>>> >>>> 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema >>>> 2015-09-02T19:06:39Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache >>>> 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket conn= >>>> 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file /usr/share/ipa/60kerberos.ldif >>>> 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 417, in start_creation >>>> run_step(full_msg, method) >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 407, in run_step >>>> method() >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 299, in __update_schema >>>> dm_password='', ldapi=True) or self.modified >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 131, in update_schema >>>> for oids_set in _get_oid_dependency_order(new_schema, cls): >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 59, in _get_oid_dependency_order >>>> unordered_oids = set(tree) >>>> File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, in __getitem__ >>>> return self.data[lower(key)] >>>> File "/usr/lib64/python2.7/string.py", line 228, in lower >>>> return s.lower() >>>> AttributeError: 'int' object has no attribute 'lower' >>>> >>>> >>>> Any ideas about this ? >>> FYI: replicated this on the second replica too... >>> >>> I can plod through by manually hacking the script to skip the schema >>> update check, but this never happened before, did some patch recently >>> land that changed how schemas are handled ? >>> >>> Simo. >>> >>> >> We did not change schemaupdater code. >> I saw this issue yesterday for first time. >> I have to inspect this, python-ldap may be broken or some py3 cahnges >> could break it. > I bet on py3 changes, somethign cause data to stay as int instead of > being converted to string I would guess. > I have not updated python-ldap so that is unlikely. > > Simo. > It is already fixed, it was py3 change From simo at redhat.com Thu Sep 3 13:24:06 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Sep 2015 09:24:06 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <55E84949.9020002@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> <1441221748.28131.180.camel@willson.usersys.redhat.com> <1441226268.28131.186.camel@willson.usersys.redhat.com> <55E80B88.1080703@redhat.com> <1441285058.28131.202.camel@willson.usersys.redhat.com> <55E84949.9020002@redhat.com> Message-ID: <1441286646.28131.211.camel@willson.usersys.redhat.com> On Thu, 2015-09-03 at 15:21 +0200, Martin Basti wrote: > > On 09/03/2015 02:57 PM, Simo Sorce wrote: > > On Thu, 2015-09-03 at 10:57 +0200, Martin Basti wrote: > >> On 09/02/2015 10:37 PM, Simo Sorce wrote: > >>> On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote: > >>>> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: > >>>>> On 08/26/2015 11:27 PM, Simo Sorce wrote: > >>>>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > >>>>>> and introduces a number of required changes and dependencies to achieve > >>>>>> this goal. > >>>>>> This work requires the custodia project to securely transfer keys > >>>>>> between ipa servers. > >>>>>> > >>>>>> This work is not 100% complete, it still misses the ability to install > >>>>>> kra instances and the ability to install a CA (via ipa-ca-install) with > >>>>>> externally signed certs. > >>>>>> > >>>>>> However it is massive enough that warrants review and pushing, the resat > >>>>>> of the changes can be applied later as this work should not disrupt the > >>>>>> classic install methods. > >>>>>> > >>>>>> In order to build my previous patches (530-533) are needed as well as a > >>>>>> number of updated components. > >>>>>> > >>>>>> I used the following coprs for testing: > >>>>>> simo/jwcrypto > >>>>>> simo/custodia > >>>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) > >>>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) > >>>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > >>>>>> mkosek/freeipa-4.2-fedora-22 (misc) > >>>>>> fedora/updates-testing (python-gssapi 1.1.2) > >>>>>> > >>>>>> Ludwig's copr is necessary to have a functional DNA plugin in replicas, > >>>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when > >>>>>> it will be released. > >>>>>> > >>>>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > >>>>>> that may cause installation issues in some case (re-install of a > >>>>>> replica). > >>>>>> > >>>>>> The domain must be raised to level 1 in order to use replica promotion. > >>>>>> > >>>>>> In order to promote a replica the server must be first joined as a > >>>>>> regular client to the domain. > >>>>>> > >>>>>> This is the flow I usually use for testing: > >>>>>> > >>>>>> # ipa-client-install > >>>>>> # kinit admin > >>>>>> # ipa-replica-install --promote --setup-ca > >>>>>> >>>>>> etc...> > >>>>>> > >>>>>> These patches are also available in this git tree rebnase on current > >>>>>> master: > >>>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > >>>>>> > >>>>>> Simo. > >>>>>> > >>>>>> > >>>>>> > >>>>> I'm running in a issue when upgrading RPMs: > >>>>> > >>>>> 2015-08-31T10:53:32Z DEBUG File > >>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > >>>>> execute > >>>>> return_value = self.run() > >>>>> File > >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > >>>>> line 48, in run > >>>>> server.upgrade() > >>>>> File > >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > >>>>> line 1596, in upgrade > >>>>> upgrade_configuration() > >>>>> File > >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > >>>>> line 1508, in upgrade_configuration > >>>>> custodia.upgrade_instance() > >>>>> File > >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > >>>>> 57, in upgrade_instance > >>>>> self.__gen_keys() > >>>>> File > >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > >>>>> 51, in __gen_keys > >>>>> KeyStore.generate_server_keys() > >>>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in > >>>>> generate_server_keys > >>>>> ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) > >>>>> File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in > >>>>> set_key > >>>>> conn.modify_s(dn, mods) > >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>>>> 364, in modify_s > >>>>> return self.result(msgid,all=1,timeout=self.timeout) > >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>>>> 465, in result > >>>>> resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) > >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>>>> 469, in result2 > >>>>> resp_type, resp_data, resp_msgid, resp_ctrls = > >>>>> self.result3(msgid,all,timeout) > >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>>>> 476, in result3 > >>>>> resp_ctrl_classes=resp_ctrl_classes > >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>>>> 483, in result4 > >>>>> ldap_result = > >>>>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) > >>>>> File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > >>>>> 106, in _ldap_call > >>>>> result = func(*args,**kwargs) > >>>>> > >>>>> 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, > >>>>> exception: NO_SUCH_OBJECT: {'desc': 'No such object'} > >>>>> 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT > >>>>> No such object > >>>> Have you found out what this was about ? > >>>> > >>>> I just found a different probelm affecting ipa-server-upgrade on my > >>>> master, it tracebacks trying to update the schema, which is odd: > >>>> > >>>> 2015-09-02T19:06:39Z DEBUG [5/8]: updating schema > >>>> 2015-09-02T19:06:39Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache > >>>> 2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket conn= > >>>> 2015-09-02T19:06:40Z DEBUG Processing schema LDIF file /usr/share/ipa/60kerberos.ldif > >>>> 2015-09-02T19:06:40Z DEBUG Traceback (most recent call last): > >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 417, in start_creation > >>>> run_step(full_msg, method) > >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 407, in run_step > >>>> method() > >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 299, in __update_schema > >>>> dm_password='', ldapi=True) or self.modified > >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 131, in update_schema > >>>> for oids_set in _get_oid_dependency_order(new_schema, cls): > >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 59, in _get_oid_dependency_order > >>>> unordered_oids = set(tree) > >>>> File "/usr/lib64/python2.7/site-packages/ldap/cidict.py", line 27, in __getitem__ > >>>> return self.data[lower(key)] > >>>> File "/usr/lib64/python2.7/string.py", line 228, in lower > >>>> return s.lower() > >>>> AttributeError: 'int' object has no attribute 'lower' > >>>> > >>>> > >>>> Any ideas about this ? > >>> FYI: replicated this on the second replica too... > >>> > >>> I can plod through by manually hacking the script to skip the schema > >>> update check, but this never happened before, did some patch recently > >>> land that changed how schemas are handled ? > >>> > >>> Simo. > >>> > >>> > >> We did not change schemaupdater code. > >> I saw this issue yesterday for first time. > >> I have to inspect this, python-ldap may be broken or some py3 cahnges > >> could break it. > > I bet on py3 changes, somethign cause data to stay as int instead of > > being converted to string I would guess. > > I have not updated python-ldap so that is unlikely. > > > > Simo. > > > It is already fixed, it was py3 change Thanks, I'll rebase on latest master then. Simo. -- Simo Sorce * Red Hat, Inc * New York From dkupka at redhat.com Thu Sep 3 13:31:44 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 3 Sep 2015 15:31:44 +0200 Subject: [Freeipa-devel] [PATCH 0304] Installer: do not modify /etc/hosts before user agreement In-Reply-To: <55E6E794.1090802@redhat.com> References: <55E6E794.1090802@redhat.com> Message-ID: <55E84BC0.3000608@redhat.com> On 02/09/15 14:12, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4561 > > This also fixes: https://fedorahosted.org/freeipa/ticket/5266 > > Patch attached. > > Looks good an works for me, ACK. -- David Kupka From mbasti at redhat.com Thu Sep 3 13:32:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 15:32:58 +0200 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <1441284125.28131.197.camel@willson.usersys.redhat.com> References: <55E71C63.1060907@redhat.com> <1441209638.28131.175.camel@willson.usersys.redhat.com> <55E80297.20709@redhat.com> <1441284125.28131.197.camel@willson.usersys.redhat.com> Message-ID: <55E84C0A.9030702@redhat.com> On 09/03/2015 02:42 PM, Simo Sorce wrote: > On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote: >> On 09/02/2015 06:00 PM, Simo Sorce wrote: >>> On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: >>>> Client installation is done as "Restarting web server". This step >>>> deserve own message. >>>> >>>> Patch attached >>> I've seen various cases like this. And I can't understand why these >>> steps aren't embedded in the actual instance install steps that need the >>> restart (which implicitly also provide a message). >>> >>> In the promotion patchset I did move steps like this into the proper >>> instances, so I would prefer you do the same with the install path as >>> that is more appropriate. >>> >>> Simo. >>> >> We need restart httpd after CA, DNS(optional) installation, so thats why >> it is outside of httpd instance. > You need to restart httpd always after CA install as it changes the > proxy settings, but why do you need to restart it after DNS > installation ? It is needed due changes in resolv.conf > > (I think it is fine to restart it twice if it is really needed after DNS > change). IMO it is waste of time to restart httpd twice in one minute Can we resolve this in 4.4, where might be place to finish improvements in installer? (If this is not blocking replica promotion) Martin^2 > >> Client install has no own step yet, it is just call of ipa-client-install. > This is fine, ipa-client-install is another ball of wax. > > Simo. > From simo at redhat.com Thu Sep 3 13:56:21 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Sep 2015 09:56:21 -0400 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <55E84C0A.9030702@redhat.com> References: <55E71C63.1060907@redhat.com> <1441209638.28131.175.camel@willson.usersys.redhat.com> <55E80297.20709@redhat.com> <1441284125.28131.197.camel@willson.usersys.redhat.com> <55E84C0A.9030702@redhat.com> Message-ID: <1441288581.28131.212.camel@willson.usersys.redhat.com> On Thu, 2015-09-03 at 15:32 +0200, Martin Basti wrote: > > On 09/03/2015 02:42 PM, Simo Sorce wrote: > > On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote: > >> On 09/02/2015 06:00 PM, Simo Sorce wrote: > >>> On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: > >>>> Client installation is done as "Restarting web server". This step > >>>> deserve own message. > >>>> > >>>> Patch attached > >>> I've seen various cases like this. And I can't understand why these > >>> steps aren't embedded in the actual instance install steps that need the > >>> restart (which implicitly also provide a message). > >>> > >>> In the promotion patchset I did move steps like this into the proper > >>> instances, so I would prefer you do the same with the install path as > >>> that is more appropriate. > >>> > >>> Simo. > >>> > >> We need restart httpd after CA, DNS(optional) installation, so thats why > >> it is outside of httpd instance. > > You need to restart httpd always after CA install as it changes the > > proxy settings, but why do you need to restart it after DNS > > installation ? > It is needed due changes in resolv.conf > > > > (I think it is fine to restart it twice if it is really needed after DNS > > change). > IMO it is waste of time to restart httpd twice in one minute > > Can we resolve this in 4.4, where might be place to finish improvements > in installer? (If this is not blocking replica promotion) Ok, it is not important enough to waste time now. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Sep 3 14:02:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 16:02:59 +0200 Subject: [Freeipa-devel] [PATCH 0304] Installer: do not modify /etc/hosts before user agreement In-Reply-To: <55E84BC0.3000608@redhat.com> References: <55E6E794.1090802@redhat.com> <55E84BC0.3000608@redhat.com> Message-ID: <55E85313.7000000@redhat.com> On 09/03/2015 03:31 PM, David Kupka wrote: > On 02/09/15 14:12, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4561 >> >> This also fixes: https://fedorahosted.org/freeipa/ticket/5266 >> >> Patch attached. >> >> > Looks good an works for me, ACK. > Pushed to ipa-4-2: af10e865f7c60e19f6f487968a3ba7018c98a325 Pushed to master: 0bcf0c1be9be99a0301051eef048fac9b178f735 From dkupka at redhat.com Thu Sep 3 14:03:36 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 3 Sep 2015 16:03:36 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <1441196867.28131.159.camel@willson.usersys.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> <1441196867.28131.159.camel@willson.usersys.redhat.com> Message-ID: <55E85338.1040805@redhat.com> On 02/09/15 14:27, Simo Sorce wrote: > On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: >> On 01/09/15 16:53, Simo Sorce wrote: >>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>>> and I would like to clarify what needs to be done in order to make IPA >>>> to fully support multiple aliases per entry. >>>> >>>> So far I have identified these task based on the ticket comments and >>>> discussion with Simo way back in the past: >>>> >>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>> not used in the new code. >>>> >>>> 2.) fix ACIs that do not permit setting multiple values of >>>> 'krbPrincipalName' attribute per entry (see >>>> https://fedorahosted.org/freeipa/ticket/3961) >>>> >>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>> case-insensitively and krbcanonicalname case-sensitively, return >>>> krbcanonicalname when canonicalization is requested. >>>> >>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>> should be covered here (I remember that we should create >>>> krbcanonicalname when we add another aliases to krbprincipalname), so it >>>> would be nice if you could comment on this. >>>> >>>> 5.) write tests which cover all this stuff so that we don't shoot >>>> ourselves in the foot. >>>> >>>> I am not very well versed in Kerberos so I might get some of this stuff >>>> wrong. If that's the case please point me to the right direction. Also >>>> please write me some additional stuff which I have fogot and needs to be >>>> done. >>>> >>> >>> I think the summary is correct, the only thing we need to be careful is >>> to keep handling entries that have only a single valued krbprincipalname >>> correctly as that will happen in upgrade paths and potentially if >>> someone uses external tools. >>> >>> The tricky part for point 3 is to implement it *without* changing the >>> schema. KrbPrincipalName is case-sensitive, however I think we can solve >>> the issue of "searching case-insensitively" by always lower-casing the >>> principal name components and always upper casing the realm part on >>> storage. If we always store a krbCanonicalName we get the "correct" case >>> there anyway so out mucking with the krbPrincipalName case will not be a >>> problem for any new entry. >> >> Or as Honza pointed out we can use case-insensitive search like this: >> (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return >> all variants of casing and reduce the need for fallback code. > > The principal name is not case insensitive, a search like that would > probably cause DS to do a full search through the krbPrincipalName > index, it might quickly become a performance issue. Before choosing a > method please create an install with a 10000 principals, and then > compare the speed of a few thousand search with exact matching case and > a few with specifying caseIgnoreMatch and see the difference. > > Simo. We will add index for caseIgnoreCaseIA5Match matching rule on krbPrincipalName and then the case insensitive match should be as quick as the case sensitive. Without the index it is indeed far slower. I've generated 10k users and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the nonindexed one ~2 minutes. That's by two orders of magnitude worse. When we tried to add the index into DS we uncovered a bug in the way DS handles nsMatchingRule attributes. Thierry investigated it and is filling the ticket for DS right now. Thierry can you please send link? Once it's fixed we should be good. David > >>> This *may* cause issues with upgrades though, so we may need fallback >>> code that searches with the case sent by the client if we determine the >>> entry has no krbCanonicalName attribute (sign that it was created before >>> we started adding krbCanonicalName and never "updated"). >>> >>> Note that we also need to think what will happen during and upgrade when >>> some servers still use the current code and some servers will use the >>> new code. So I guess it would be nice if you could write down a table >>> with all possible forms a principal can be in on rows, and old/new >>> server states in columns, and mark what will happen for various >>> operations in each case. >>> >>> Simo. >>> > > -- David Kupka From abokovoy at redhat.com Thu Sep 3 14:34:18 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 3 Sep 2015 17:34:18 +0300 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <55E83D5A.2050804@redhat.com> References: <55E83D5A.2050804@redhat.com> Message-ID: <20150903143418.GN22106@redhat.com> On Thu, 03 Sep 2015, Tomas Babej wrote: >Hi, > >this couple of patches fix https://fedorahosted.org/freeipa/ticket/5278 >and improve our handling of realmdomains in general. The code looks good to me. I haven't tested it yet, though. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Sep 3 14:42:20 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 3 Sep 2015 17:42:20 +0300 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal Message-ID: <20150903144220.GO22106@redhat.com> Hi, attached patch adds support for issuing client referrals when FreeIPA KDC is asked to give a TGT for a principal from a trusted forest. We return a matching forest name as a realm and KDC then returns an error pointing a client to a direction of that realm. You can see how it looks with http://fpaste.org/263064/14412849/ -- it shows behavior for both 'kinit -E -C' and 'kinit -E'. Note that current MIT Kerberos KDC has a bug that prevents us from responding with a correct client referral. A patched version for Fedora 22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs to Fedora and RHEL versions. With the version in my abbra/krb5-test COPR you can test the patch with the help of kinit like fpaste URL above shows. -- / Alexander Bokovoy -------------- next part -------------- From 22cdeeb87e82b13d518c1514a5a4feb84c5a6e16 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 20 Aug 2015 15:06:12 +0300 Subject: [PATCH] client referral support for trusted domain principals https://fedorahosted.org/freeipa/ticket/3559 --- daemons/ipa-kdb/ipa_kdb.h | 8 +++++ daemons/ipa-kdb/ipa_kdb_mspac.c | 60 ++++++++++++++++++++++++++++++++++++ daemons/ipa-kdb/ipa_kdb_principals.c | 47 ++++++++++++++++++++++++++++ 3 files changed, 115 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index 4abb733..a6f4481 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -274,6 +274,14 @@ krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, const krb5_data *tr_contents, const krb5_data *client_realm, const krb5_data *server_realm); +/* Checks whether a principal's realm is one of trusted domains' realm or NetBIOS name + * and returns the realm of the matched trusted domain in 'trusted_domain' + * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise + * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */ +krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext, + const char *test_realm, size_t size, + char **trusted_realm); + /* DELEGATION CHECKS */ krb5_error_code ipadb_check_allowed_to_delegate(krb5_context kcontext, diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 3c0dca8..8594309 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2790,3 +2790,63 @@ krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, } return ret; } + +/* Checks whether a principal's realm is one of trusted domains' realm or NetBIOS name + * and returns the realm of the matched trusted domain in 'trusted_domain' + * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise + * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */ +krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext, + const char *test_realm, size_t size, + char **trusted_realm) +{ + struct ipadb_context *ipactx; + int i, j, length; + const char *name; + + if (test_realm == NULL || test_realm[0] == '\0') { + return KRB5_KDB_NOENTRY; + } + + ipactx = ipadb_get_context(kcontext); + if (!ipactx || !ipactx->mspac) { + return KRB5_KDB_DBNOTINITED; + } + + /* First, compare realm with ours, it would not be from a trusted realm then */ + if (strncasecmp(test_realm, ipactx->realm, size) == 0) { + return KRB5_KDB_NOENTRY; + } + + if (!ipactx->mspac || !ipactx->mspac->trusts) { + return KRB5_KDB_NOENTRY; + } + + /* Iterate through list of trusts and check if input realm belongs to any of the trust */ + for(i = 0 ; i < ipactx->mspac->num_trusts ; i++) { + if ((strncasecmp(test_realm, + ipactx->mspac->trusts[i].domain_name, + size) == 0) || + (strncasecmp(test_realm, + ipactx->mspac->trusts[i].flat_name, + size) == 0)) { + /* return the realm if caller supplied a place for it */ + if (trusted_realm != NULL) { + name = (ipactx->mspac->trusts[i].parent_name != NULL) ? + ipactx->mspac->trusts[i].parent_name : + ipactx->mspac->trusts[i].domain_name; + length = strlen(name) + 1; + *trusted_realm = calloc(1, length); + if (*trusted_realm != NULL) { + for (j = 0; j < length; j++) { + (*trusted_realm)[j] = toupper(name[j]); + } + } else { + return KRB5_KDB_NOENTRY; + } + } + return 0; + } + } + + return KRB5_KDB_NOENTRY; +} diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index b3f8b1a..d4aa2dd 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -1023,8 +1023,10 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, struct ipadb_context *ipactx; krb5_error_code kerr; char *principal = NULL; + char *trusted_realm = NULL; LDAPMessage *res = NULL; LDAPMessage *lentry; + krb5_db_entry *kentry = NULL; uint32_t pol; ipactx = ipadb_get_context(kcontext); @@ -1044,6 +1046,47 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, kerr = ipadb_find_principal(kcontext, flags, res, &principal, &lentry); if (kerr != 0) { + if ((kerr == KRB5_KDB_NOENTRY) && + ((flags & (KRB5_KDB_FLAG_CANONICALIZE | + KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY)) != 0)) { + + /* First check if we got enterprise principal which looks like + * username\@enterprise_realm at REALM */ + char *realm, *enterprise_realm; + + realm = strrchr(principal, '@'); + enterprise_realm = strchr(principal, '@'); + if ((realm == NULL) || (*realm == '\0') || (realm == enterprise_realm)) { + kerr = KRB5_KDB_NOENTRY; + goto done; + } + + /* skip '@' and use part between '@' and '@' as enterprise realm for comparison */ + enterprise_realm++; + + kerr = ipadb_is_princ_from_trusted_realm(kcontext, + enterprise_realm, + (realm - enterprise_realm), + &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; } @@ -1060,6 +1103,10 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, } done: + free(trusted_realm); + if ((kerr != 0) && (kentry != NULL)) { + ipadb_free_principal(kcontext, kentry); + } ldap_msgfree(res); krb5_free_unparsed_name(kcontext, principal); return kerr; -- 2.4.3 From abokovoy at redhat.com Thu Sep 3 15:22:05 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 3 Sep 2015 18:22:05 +0300 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal In-Reply-To: <20150903144220.GO22106@redhat.com> References: <20150903144220.GO22106@redhat.com> Message-ID: <20150903152205.GP22106@redhat.com> On Thu, 03 Sep 2015, Alexander Bokovoy wrote: > Hi, > > attached patch adds support for issuing client referrals when FreeIPA > KDC is asked to give a TGT for a principal from a trusted forest. > > We return a matching forest name as a realm and KDC then returns an > error pointing a client to a direction of that realm. You can see how it > looks with http://fpaste.org/263064/14412849/ -- it shows behavior for > both 'kinit -E -C' and 'kinit -E'. > > Note that current MIT Kerberos KDC has a bug that prevents us from > responding with a correct client referral. A patched version for Fedora > 22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is > https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs to > Fedora and RHEL versions. > > With the version in my abbra/krb5-test COPR you can test the patch with > the help of kinit like fpaste URL above shows. After discussing with Simo and Sumit, here is updated patch that operates directly on 'search_for' krb5_principal and avoids strchr()/strrchr() and additional memory allocations -- it uses memrchr() to find '@' in the last component of the search_for principal and considers the part of the component after '@' as an enterprise realm to check. -- / Alexander Bokovoy -------------- next part -------------- From af2ce7db9c51b7b058c5077801416f2757eb4896 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 20 Aug 2015 15:06:12 +0300 Subject: [PATCH] client referral support for trusted domain principals https://fedorahosted.org/freeipa/ticket/3559 --- daemons/ipa-kdb/ipa_kdb.h | 8 +++++ daemons/ipa-kdb/ipa_kdb_mspac.c | 60 ++++++++++++++++++++++++++++++++++++ daemons/ipa-kdb/ipa_kdb_principals.c | 55 +++++++++++++++++++++++++++++++++ 3 files changed, 123 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index 4abb733..a6f4481 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -274,6 +274,14 @@ krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, const krb5_data *tr_contents, const krb5_data *client_realm, const krb5_data *server_realm); +/* Checks whether a principal's realm is one of trusted domains' realm or NetBIOS name + * and returns the realm of the matched trusted domain in 'trusted_domain' + * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise + * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */ +krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext, + const char *test_realm, size_t size, + char **trusted_realm); + /* DELEGATION CHECKS */ krb5_error_code ipadb_check_allowed_to_delegate(krb5_context kcontext, diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 3c0dca8..8594309 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2790,3 +2790,63 @@ krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, } return ret; } + +/* Checks whether a principal's realm is one of trusted domains' realm or NetBIOS name + * and returns the realm of the matched trusted domain in 'trusted_domain' + * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise + * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */ +krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext, + const char *test_realm, size_t size, + char **trusted_realm) +{ + struct ipadb_context *ipactx; + int i, j, length; + const char *name; + + if (test_realm == NULL || test_realm[0] == '\0') { + return KRB5_KDB_NOENTRY; + } + + ipactx = ipadb_get_context(kcontext); + if (!ipactx || !ipactx->mspac) { + return KRB5_KDB_DBNOTINITED; + } + + /* First, compare realm with ours, it would not be from a trusted realm then */ + if (strncasecmp(test_realm, ipactx->realm, size) == 0) { + return KRB5_KDB_NOENTRY; + } + + if (!ipactx->mspac || !ipactx->mspac->trusts) { + return KRB5_KDB_NOENTRY; + } + + /* Iterate through list of trusts and check if input realm belongs to any of the trust */ + for(i = 0 ; i < ipactx->mspac->num_trusts ; i++) { + if ((strncasecmp(test_realm, + ipactx->mspac->trusts[i].domain_name, + size) == 0) || + (strncasecmp(test_realm, + ipactx->mspac->trusts[i].flat_name, + size) == 0)) { + /* return the realm if caller supplied a place for it */ + if (trusted_realm != NULL) { + name = (ipactx->mspac->trusts[i].parent_name != NULL) ? + ipactx->mspac->trusts[i].parent_name : + ipactx->mspac->trusts[i].domain_name; + length = strlen(name) + 1; + *trusted_realm = calloc(1, length); + if (*trusted_realm != NULL) { + for (j = 0; j < length; j++) { + (*trusted_realm)[j] = toupper(name[j]); + } + } else { + return KRB5_KDB_NOENTRY; + } + } + return 0; + } + } + + return KRB5_KDB_NOENTRY; +} diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index b3f8b1a..f2a5a41 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -1023,8 +1023,10 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, struct ipadb_context *ipactx; krb5_error_code kerr; char *principal = NULL; + char *trusted_realm = NULL; LDAPMessage *res = NULL; LDAPMessage *lentry; + krb5_db_entry *kentry = NULL; uint32_t pol; ipactx = ipadb_get_context(kcontext); @@ -1044,6 +1046,55 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, kerr = ipadb_find_principal(kcontext, flags, res, &principal, &lentry); if (kerr != 0) { + if ((kerr == KRB5_KDB_NOENTRY) && + ((flags & (KRB5_KDB_FLAG_CANONICALIZE | + KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY)) != 0)) { + + /* First check if we got enterprise principal which looks like + * username\@enterprise_realm at REALM */ + char *realm; + krb5_data *upn; + + upn = krb5_princ_component(kcontext, search_for, + krb5_princ_size(kcontext, search_for) - 1); + + if (upn == NULL) { + kerr = KRB5_KDB_NOENTRY; + goto done; + } + + realm = memrchr(upn->data, '@', upn->length); + if (realm == NULL) { + kerr = KRB5_KDB_NOENTRY; + goto done; + } + + /* 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) { + 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; } @@ -1060,6 +1111,10 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, } done: + free(trusted_realm); + if ((kerr != 0) && (kentry != NULL)) { + ipadb_free_principal(kcontext, kentry); + } ldap_msgfree(res); krb5_free_unparsed_name(kcontext, principal); return kerr; -- 2.4.3 From pspacek at redhat.com Thu Sep 3 15:36:31 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 3 Sep 2015 17:36:31 +0200 Subject: [Freeipa-devel] [PATCH 0305-0306] DNSSEC: better cleanup after uninstall to avoid temporal malfunction In-Reply-To: <55E6F26E.1050708@redhat.com> References: <55E6F26E.1050708@redhat.com> Message-ID: <55E868FF.1080101@redhat.com> On 2.9.2015 14:58, Martin Basti wrote: > Related to ticket https://fedorahosted.org/freeipa/ticket/5273 > > Patches attached. ACK -- Petr^2 Spacek From mbasti at redhat.com Thu Sep 3 15:41:24 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 17:41:24 +0200 Subject: [Freeipa-devel] [PATCH 0057] DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5 In-Reply-To: <55E5CF7B.6080809@redhat.com> References: <55E5CF7B.6080809@redhat.com> Message-ID: <55E86A24.6090902@redhat.com> On 09/01/2015 06:16 PM, Petr Spacek wrote: > Hello, > > DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5. > > This fixes an forgotten TODO in ipa-ods-exporter. > ACK From mbasti at redhat.com Thu Sep 3 15:44:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 17:44:45 +0200 Subject: [Freeipa-devel] [PATCH 0053-0056] DNSSEC: Fix deadlocks & export to LDAP In-Reply-To: <55E80799.7000507@redhat.com> References: <55E485E7.4070803@redhat.com> <55E80799.7000507@redhat.com> Message-ID: <55E86AED.4080901@redhat.com> On 09/03/2015 10:40 AM, Oleg Fayans wrote: > NACK from me. > > 2 out of 5 tests still fail with assertion errors: > https://paste.fedoraproject.org/262926/44126948/ > > Although, I am not sure these failures are caused by the same very > problem. > > On 08/31/2015 06:50 PM, Petr Spacek wrote: >> Hello, >> >> Attached patch set should fix the deadlock you discovered + few more >> issues I >> spotted when testing the original patch. >> >> Known problems (more patches needed): >> - /etc/opendnssec/zonelist.xml should be restored during server >> uninstall >> - ccache for ipa-ods-exporter should be removed during server uninstall >> - timestamps in .private key files do not reflect (?) current key >> state in >> OpenDNSSEC database (I will look into this tomorrow.) >> >> >> > Actually, I did testing and these patches fixing the deadlock. ACK from me. You may hit another issue, which is reproducible only by DNSSEC CI test: named is not able to read keys (we don't know why, because keys are ready and readable) Workaround is just to restart named, and everything will work. From mbasti at redhat.com Thu Sep 3 15:55:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 17:55:03 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests Message-ID: <55E86D57.1050006@redhat.com> Attached patches improve DNSSEC CI tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0309-DNSSEC-improve-CI-test.patch Type: text/x-patch Size: 6022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0310-DNSSEC-CI-test-master-migration.patch Type: text/x-patch Size: 6892 bytes Desc: not available URL: From redhatrises at gmail.com Thu Sep 3 15:55:21 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 3 Sep 2015 09:55:21 -0600 Subject: [Freeipa-devel] [PATCH 0052] Add Chromium configuration note under Chrome section in ssbrowser In-Reply-To: References: Message-ID: Bump for review On Wed, Jul 29, 2015 at 7:49 AM, Gabe Alford wrote: > Hello, > > As Chromium and Chrome are configured similarly but are configured in > different /etc directories, this patch adds a note to the Chrome section in > ssbrowser.html stating that. > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Sep 3 16:18:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 18:18:54 +0200 Subject: [Freeipa-devel] [PATCH 0305-0306] DNSSEC: better cleanup after uninstall to avoid temporal malfunction In-Reply-To: <55E868FF.1080101@redhat.com> References: <55E6F26E.1050708@redhat.com> <55E868FF.1080101@redhat.com> Message-ID: <55E872EE.80409@redhat.com> On 09/03/2015 05:36 PM, Petr Spacek wrote: > On 2.9.2015 14:58, Martin Basti wrote: >> Related to ticket https://fedorahosted.org/freeipa/ticket/5273 >> >> Patches attached. > ACK > Pushed to master: e7a876d88a0ed07de69d9654ebdbf8ebb7bda364 Pushed to ipa-4-2: 8767fff853a68389ed6786abf0b0eea3f4ef6764 From mbasti at redhat.com Thu Sep 3 16:21:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 18:21:20 +0200 Subject: [Freeipa-devel] [PATCH 0053-0056] DNSSEC: Fix deadlocks & export to LDAP In-Reply-To: <55E86AED.4080901@redhat.com> References: <55E485E7.4070803@redhat.com> <55E80799.7000507@redhat.com> <55E86AED.4080901@redhat.com> Message-ID: <55E87380.6010406@redhat.com> On 09/03/2015 05:44 PM, Martin Basti wrote: > > > On 09/03/2015 10:40 AM, Oleg Fayans wrote: >> NACK from me. >> >> 2 out of 5 tests still fail with assertion errors: >> https://paste.fedoraproject.org/262926/44126948/ >> >> Although, I am not sure these failures are caused by the same very >> problem. >> >> On 08/31/2015 06:50 PM, Petr Spacek wrote: >>> Hello, >>> >>> Attached patch set should fix the deadlock you discovered + few more >>> issues I >>> spotted when testing the original patch. >>> >>> Known problems (more patches needed): >>> - /etc/opendnssec/zonelist.xml should be restored during server >>> uninstall >>> - ccache for ipa-ods-exporter should be removed during server uninstall >>> - timestamps in .private key files do not reflect (?) current key >>> state in >>> OpenDNSSEC database (I will look into this tomorrow.) >>> >>> >>> >> > > Actually, I did testing and these patches fixing the deadlock. > > ACK from me. > > You may hit another issue, which is reproducible only by DNSSEC CI test: > named is not able to read keys (we don't know why, because keys are > ready and readable) > Workaround is just to restart named, and everything will work. > Pushed to: master: e84006117637832f63904edeb45b7296151be6ad ipa-4-2: 73058caa625e5e966beff9122cf235cb45d6b0bc From mbasti at redhat.com Thu Sep 3 16:23:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Sep 2015 18:23:25 +0200 Subject: [Freeipa-devel] [PATCH 0057] DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5 In-Reply-To: <55E86A24.6090902@redhat.com> References: <55E5CF7B.6080809@redhat.com> <55E86A24.6090902@redhat.com> Message-ID: <55E873FD.2090305@redhat.com> On 09/03/2015 05:41 PM, Martin Basti wrote: > > > On 09/01/2015 06:16 PM, Petr Spacek wrote: >> Hello, >> >> DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5. >> >> This fixes an forgotten TODO in ipa-ods-exporter. >> > > ACK > Pushed to: master: ecf796e9c021a3b06e670f0602e8a10dcfd6f1f1 ipa-4-2: 5ad806ecf89f1aa4119398e65dff4e986b19b1a6 From ofayans at redhat.com Thu Sep 3 17:21:34 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 3 Sep 2015 19:21:34 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests In-Reply-To: <55E86D57.1050006@redhat.com> References: <55E86D57.1050006@redhat.com> Message-ID: <55E8819E.8020508@redhat.com> Hi Martin, The two functions test_disable_reenable_signing_master and test_disable_reenable_signing_replica the error message for the laste assertion is different, although the assertions are identical: "RRSIG should be different" and "DNSKEY should be different". Other than that, it's fine On 09/03/2015 05:55 PM, Martin Basti wrote: > Attached patches improve DNSSEC CI tests. > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pviktori at redhat.com Thu Sep 3 17:23:10 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 3 Sep 2015 19:23:10 +0200 Subject: [Freeipa-devel] [PATCHES 481-486] Metaclass and str modernization In-Reply-To: <55E5BA6C.2080502@redhat.com> References: <55E5BA6C.2080502@redhat.com> Message-ID: <55E881FE.6010807@redhat.com> On 09/01/2015 04:47 PM, Jan Cholasta wrote: > Hi, > > the attached patches add some more modernization to our code. > > Honza 481: ACK 482: ACK 483: ACK You can push these without waiting on the later ones. 484: To avoid merge conflicts later, perhaps it would be better to have if six.PY3: unicode = str at the start of each affected file, instead of scattering changes in the files? (I can prepare the patch if you agree) 485: six.binary_type is named "bytes" since Python 2.6. I think it would be better to use that, to avoid another change when py2 is dropped. (I can prepare the patch here, too) 486: ACK -- Petr Viktorin From mkosek at redhat.com Fri Sep 4 06:42:47 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 4 Sep 2015 08:42:47 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist Message-ID: <55E93D67.8000109@redhat.com> Hello everyone, It is now only couple days before Fedora 23 Beta freeze [1] and as we discussed, we would like to release FreeIPA 4.2.1, which already contains 148 patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features or upgrade fixes. IIRC, we miss 2 dependencies: 1) pki-ca 10.2.6 This is still waiting in Updates Testing [2]. We need 3 positive karma (only if it works of course) to make it move to stable updates repo and so that we do not have broken deps. 2) sssd 1.13.1 This upstream release does not officially exist, AFAIK, only in a COPR repo. I see 2 options here: - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump the requires and we set the requires in Fedora 23 to 1.13.0. Jakub, any preference? Besides the package requiremenst, What patches do you want to include to do the release in the end of today or the beginning of the next week? [1] https://fedoraproject.org/wiki/Releases/23/Schedule [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From jpazdziora at redhat.com Fri Sep 4 06:57:15 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 4 Sep 2015 08:57:15 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E93D67.8000109@redhat.com> References: <55E93D67.8000109@redhat.com> Message-ID: <20150904065715.GE24631@redhat.com> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: > Hello everyone, > > It is now only couple days before Fedora 23 Beta freeze [1] and as we > discussed, we would like to release FreeIPA 4.2.1, which already contains 148 Looking at https://fedorahosted.org/freeipa/milestone/FreeIPA%204.2.1 it says there are 56 active tickets and clicking that 56 I get to https://fedorahosted.org/freeipa/query?milestone=FreeIPA+4.2.1&status=new&status=assigned&status=reopened&group=status where I can see eight critical defects (besides numerous major). Is that expected? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Fri Sep 4 07:03:27 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 4 Sep 2015 09:03:27 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <20150904065715.GE24631@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904065715.GE24631@redhat.com> Message-ID: <55E9423F.1080805@redhat.com> On 09/04/2015 08:57 AM, Jan Pazdziora wrote: > On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: >> Hello everyone, >> >> It is now only couple days before Fedora 23 Beta freeze [1] and as we >> discussed, we would like to release FreeIPA 4.2.1, which already contains 148 > > Looking at > > https://fedorahosted.org/freeipa/milestone/FreeIPA%204.2.1 > > it says there are 56 active tickets and clicking that 56 I get to > > https://fedorahosted.org/freeipa/query?milestone=FreeIPA+4.2.1&status=new&status=assigned&status=reopened&group=status > > where I can see eight critical defects (besides numerous major). > > Is that expected? Based on how stabilization ticket buckets are organized now, it is expected. Right now, "FreeIPA 4.2.1" milestone rather means "FreeIPA 4.2.1 or later 4.2.x release" as non-closed tickets are simply moved to "FreeIPA 4.2.2" at the release time and we continue working on the stabilization branch. This makes the job easier and less error-prone for people closing the tickets when patches are merged as the Milestone name always refer to the right FreeIPA version (it did not in the past). If this setup is confusing for people, other option would be to have something like "FreeIPA 4.2.x backlog" and move the ticket to the right version milestone ("FreeIPA 4.2.1") at the time the ticket is closed. But without proper tooling, I am afraid people may simply close the ticket within "FreeIPA 4.2.x backlog" and it would then not be clear what version it is fixed in. Martin From abokovoy at redhat.com Fri Sep 4 07:08:18 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Sep 2015 10:08:18 +0300 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E93D67.8000109@redhat.com> References: <55E93D67.8000109@redhat.com> Message-ID: <20150904070818.GQ22106@redhat.com> On Fri, 04 Sep 2015, Martin Kosek wrote: >Hello everyone, > >It is now only couple days before Fedora 23 Beta freeze [1] and as we >discussed, we would like to release FreeIPA 4.2.1, which already contains 148 >patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features >or upgrade fixes. > >IIRC, we miss 2 dependencies: > >1) pki-ca 10.2.6 > >This is still waiting in Updates Testing [2]. We need 3 positive karma (only if >it works of course) to make it move to stable updates repo and so that we do >not have broken deps. 10.2.6-7.f22 works for me well. Didn't test F23 yet. >2) sssd 1.13.1 > >This upstream release does not officially exist, AFAIK, only in a COPR repo. I >see 2 options here: >- SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires >- SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump >the requires and we set the requires in Fedora 23 to 1.13.0. > >Jakub, any preference? I would prefer getting 1.13.1 out. We also need to get krb5 update for KDC client referrals. Robby is working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844 The patch is ready, we just need to push out the packages. >Besides the package requiremenst, What patches do you want to include to do the >release in the end of today or the beginning of the next week? I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches are on the list and require krb5 update. -- / Alexander Bokovoy From mkosek at redhat.com Fri Sep 4 07:11:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 4 Sep 2015 09:11:18 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <20150904070818.GQ22106@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904070818.GQ22106@redhat.com> Message-ID: <55E94416.1080607@redhat.com> On 09/04/2015 09:08 AM, Alexander Bokovoy wrote: > On Fri, 04 Sep 2015, Martin Kosek wrote: ... > We also need to get krb5 update for KDC client referrals. Robby is > working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844 > The patch is ready, we just need to push out the packages. > >> Besides the package requiremenst, What patches do you want to include to do the >> release in the end of today or the beginning of the next week? > I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches > are on the list and require krb5 update. Ok. But I do not see it as something that should postpone 4.2.1 as it is not a regression and this simply never worked (AFAIK). Martin From jhrozek at redhat.com Fri Sep 4 07:12:26 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 4 Sep 2015 09:12:26 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E93D67.8000109@redhat.com> References: <55E93D67.8000109@redhat.com> Message-ID: <20150904071226.GH3481@hendrix> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: > Hello everyone, > > It is now only couple days before Fedora 23 Beta freeze [1] and as we > discussed, we would like to release FreeIPA 4.2.1, which already contains 148 > patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features > or upgrade fixes. > > IIRC, we miss 2 dependencies: > > 1) pki-ca 10.2.6 > > This is still waiting in Updates Testing [2]. We need 3 positive karma (only if > it works of course) to make it move to stable updates repo and so that we do > not have broken deps. > > 2) sssd 1.13.1 > > This upstream release does not officially exist, AFAIK, only in a COPR repo. I > see 2 options here: > - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires > - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump > the requires and we set the requires in Fedora 23 to 1.13.0. I would prefer to release 1.13.1, there's too many patches to backport. The only question is whether we include some patches that I just yesterday finished testing. I'll send them to the list so that we can see if they are digestable in the couple of days, otherwise we include them in .2 and patch downstream later. > > Jakub, any preference? > > Besides the package requiremenst, What patches do you want to include to do the > release in the end of today or the beginning of the next week? The schedule says the Beta freeze is on Wednesday, so we need to release on Tuesday, correct? > > [1] https://fedoraproject.org/wiki/Releases/23/Schedule > [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905 > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. From abokovoy at redhat.com Fri Sep 4 07:15:09 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Sep 2015 10:15:09 +0300 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E94416.1080607@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904070818.GQ22106@redhat.com> <55E94416.1080607@redhat.com> Message-ID: <20150904071509.GR22106@redhat.com> On Fri, 04 Sep 2015, Martin Kosek wrote: >On 09/04/2015 09:08 AM, Alexander Bokovoy wrote: >> On Fri, 04 Sep 2015, Martin Kosek wrote: >... >> We also need to get krb5 update for KDC client referrals. Robby is >> working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844 >> The patch is ready, we just need to push out the packages. >> >>> Besides the package requiremenst, What patches do you want to include to do the >>> release in the end of today or the beginning of the next week? >> I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches >> are on the list and require krb5 update. > >Ok. But I do not see it as something that should postpone 4.2.1 as it is not a >regression and this simply never worked (AFAIK). It is mostly going to create a major confusion when people start using one-way trust with elaborate forest structure. -- / Alexander Bokovoy From mkosek at redhat.com Fri Sep 4 07:19:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 4 Sep 2015 09:19:16 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <20150904071226.GH3481@hendrix> References: <55E93D67.8000109@redhat.com> <20150904071226.GH3481@hendrix> Message-ID: <55E945F4.6030502@redhat.com> On 09/04/2015 09:12 AM, Jakub Hrozek wrote: > On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: >> Hello everyone, >> >> It is now only couple days before Fedora 23 Beta freeze [1] and as we >> discussed, we would like to release FreeIPA 4.2.1, which already contains 148 >> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features >> or upgrade fixes. >> >> IIRC, we miss 2 dependencies: >> >> 1) pki-ca 10.2.6 >> >> This is still waiting in Updates Testing [2]. We need 3 positive karma (only if >> it works of course) to make it move to stable updates repo and so that we do >> not have broken deps. >> >> 2) sssd 1.13.1 >> >> This upstream release does not officially exist, AFAIK, only in a COPR repo. I >> see 2 options here: >> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires >> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump >> the requires and we set the requires in Fedora 23 to 1.13.0. > > I would prefer to release 1.13.1, there's too many patches to backport. Well, an case of FreeIPA and it's requires, we should only need 5 of them: https://fedorahosted.org/sssd/ticket/2558#comment:12 This is the ticket that bumped the FreeIPA SSSD Requires: https://fedorahosted.org/freeipa/ticket/4249 > The only question is whether we include some patches that I just > yesterday finished testing. I'll send them to the list so that we can > see if they are digestable in the couple of days, otherwise we include > them in .2 and patch downstream later. > >> >> Jakub, any preference? >> >> Besides the package requiremenst, What patches do you want to include to do the >> release in the end of today or the beginning of the next week? > > The schedule says the Beta freeze is on Wednesday, so we need to release > on Tuesday, correct? Correct, but on Wednesday, the update should be in stable already, according to: https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes So it would be safer to release upstream on Monday, get the positive karma and request the transition to stable so that the transition is completed before Wednesday. >> [1] https://fedoraproject.org/wiki/Releases/23/Schedule >> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905 >> >> -- >> Martin Kosek >> Supervisor, Software Engineering - Identity Management Team >> Red Hat Inc. From mkosek at redhat.com Fri Sep 4 07:22:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 4 Sep 2015 09:22:13 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <20150904071509.GR22106@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904070818.GQ22106@redhat.com> <55E94416.1080607@redhat.com> <20150904071509.GR22106@redhat.com> Message-ID: <55E946A5.2040709@redhat.com> On 09/04/2015 09:15 AM, Alexander Bokovoy wrote: > On Fri, 04 Sep 2015, Martin Kosek wrote: >> On 09/04/2015 09:08 AM, Alexander Bokovoy wrote: >>> On Fri, 04 Sep 2015, Martin Kosek wrote: >> ... >>> We also need to get krb5 update for KDC client referrals. Robby is >>> working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844 >>> The patch is ready, we just need to push out the packages. >>> >>>> Besides the package requiremenst, What patches do you want to include to do >>>> the >>>> release in the end of today or the beginning of the next week? >>> I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches >>> are on the list and require krb5 update. >> >> Ok. But I do not see it as something that should postpone 4.2.1 as it is not a >> regression and this simply never worked (AFAIK). > It is mostly going to create a major confusion when people start using > one-way trust with elaborate forest structure. Sure. But my point is that we should not miss the Beta deadline so that we have the big stabilization 4.2.1 release in and being tested. This particular Trust change can come in 4.2.2 week or two after, in case it does not make 4.2.1 deadline. Martin From jhrozek at redhat.com Fri Sep 4 07:23:34 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 4 Sep 2015 09:23:34 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E945F4.6030502@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904071226.GH3481@hendrix> <55E945F4.6030502@redhat.com> Message-ID: <20150904072334.GJ3481@hendrix> On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote: > On 09/04/2015 09:12 AM, Jakub Hrozek wrote: > > On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: > >> Hello everyone, > >> > >> It is now only couple days before Fedora 23 Beta freeze [1] and as we > >> discussed, we would like to release FreeIPA 4.2.1, which already contains 148 > >> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features > >> or upgrade fixes. > >> > >> IIRC, we miss 2 dependencies: > >> > >> 1) pki-ca 10.2.6 > >> > >> This is still waiting in Updates Testing [2]. We need 3 positive karma (only if > >> it works of course) to make it move to stable updates repo and so that we do > >> not have broken deps. > >> > >> 2) sssd 1.13.1 > >> > >> This upstream release does not officially exist, AFAIK, only in a COPR repo. I > >> see 2 options here: > >> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires > >> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump > >> the requires and we set the requires in Fedora 23 to 1.13.0. > > > > I would prefer to release 1.13.1, there's too many patches to backport. > > Well, an case of FreeIPA and it's requires, we should only need 5 of them: > https://fedorahosted.org/sssd/ticket/2558#comment:12 But the number of fixes is quite high, there's already close to 50 tickets fixed and if we rebase, we better to it before Beta. > > This is the ticket that bumped the FreeIPA SSSD Requires: > https://fedorahosted.org/freeipa/ticket/4249 > > > The only question is whether we include some patches that I just > > yesterday finished testing. I'll send them to the list so that we can > > see if they are digestable in the couple of days, otherwise we include > > them in .2 and patch downstream later. > > > >> > >> Jakub, any preference? > >> > >> Besides the package requiremenst, What patches do you want to include to do the > >> release in the end of today or the beginning of the next week? > > > > The schedule says the Beta freeze is on Wednesday, so we need to release > > on Tuesday, correct? > > Correct, but on Wednesday, the update should be in stable already, according to: > https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes > > So it would be safer to release upstream on Monday, get the positive karma and > request the transition to stable so that the transition is completed before > Wednesday. OK. > > >> [1] https://fedoraproject.org/wiki/Releases/23/Schedule > >> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905 > >> > >> -- > >> Martin Kosek > >> Supervisor, Software Engineering - Identity Management Team > >> Red Hat Inc. > > -- > 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 mkosek at redhat.com Fri Sep 4 07:25:59 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 4 Sep 2015 09:25:59 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <20150904072334.GJ3481@hendrix> References: <55E93D67.8000109@redhat.com> <20150904071226.GH3481@hendrix> <55E945F4.6030502@redhat.com> <20150904072334.GJ3481@hendrix> Message-ID: <55E94787.1040804@redhat.com> On 09/04/2015 09:23 AM, Jakub Hrozek wrote: > On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote: >> On 09/04/2015 09:12 AM, Jakub Hrozek wrote: >>> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: >>>> Hello everyone, >>>> >>>> It is now only couple days before Fedora 23 Beta freeze [1] and as we >>>> discussed, we would like to release FreeIPA 4.2.1, which already contains 148 >>>> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features >>>> or upgrade fixes. >>>> >>>> IIRC, we miss 2 dependencies: >>>> >>>> 1) pki-ca 10.2.6 >>>> >>>> This is still waiting in Updates Testing [2]. We need 3 positive karma (only if >>>> it works of course) to make it move to stable updates repo and so that we do >>>> not have broken deps. >>>> >>>> 2) sssd 1.13.1 >>>> >>>> This upstream release does not officially exist, AFAIK, only in a COPR repo. I >>>> see 2 options here: >>>> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires >>>> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump >>>> the requires and we set the requires in Fedora 23 to 1.13.0. >>> >>> I would prefer to release 1.13.1, there's too many patches to backport. >> >> Well, an case of FreeIPA and it's requires, we should only need 5 of them: >> https://fedorahosted.org/sssd/ticket/2558#comment:12 > > But the number of fixes is quite high, there's already close to 50 > tickets fixed and if we rebase, we better to it before Beta. I fully agree with SSSD release before Beta. I was now mostly only discussing the unfulfilled FreeIPA requires that has different requirements > >> >> This is the ticket that bumped the FreeIPA SSSD Requires: >> https://fedorahosted.org/freeipa/ticket/4249 >> >>> The only question is whether we include some patches that I just >>> yesterday finished testing. I'll send them to the list so that we can >>> see if they are digestable in the couple of days, otherwise we include >>> them in .2 and patch downstream later. >>> >>>> >>>> Jakub, any preference? >>>> >>>> Besides the package requiremenst, What patches do you want to include to do the >>>> release in the end of today or the beginning of the next week? >>> >>> The schedule says the Beta freeze is on Wednesday, so we need to release >>> on Tuesday, correct? >> >> Correct, but on Wednesday, the update should be in stable already, according to: >> https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes >> >> So it would be safer to release upstream on Monday, get the positive karma and >> request the transition to stable so that the transition is completed before >> Wednesday. > > OK. > >> >>>> [1] https://fedoraproject.org/wiki/Releases/23/Schedule >>>> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905 >>>> >>>> -- >>>> Martin Kosek >>>> Supervisor, Software Engineering - Identity Management Team >>>> Red Hat Inc. >> >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From abokovoy at redhat.com Fri Sep 4 07:29:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Sep 2015 10:29:36 +0300 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E946A5.2040709@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904070818.GQ22106@redhat.com> <55E94416.1080607@redhat.com> <20150904071509.GR22106@redhat.com> <55E946A5.2040709@redhat.com> Message-ID: <20150904072936.GS22106@redhat.com> On Fri, 04 Sep 2015, Martin Kosek wrote: >On 09/04/2015 09:15 AM, Alexander Bokovoy wrote: >> On Fri, 04 Sep 2015, Martin Kosek wrote: >>> On 09/04/2015 09:08 AM, Alexander Bokovoy wrote: >>>> On Fri, 04 Sep 2015, Martin Kosek wrote: >>> ... >>>> We also need to get krb5 update for KDC client referrals. Robby is >>>> working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844 >>>> The patch is ready, we just need to push out the packages. >>>> >>>>> Besides the package requiremenst, What patches do you want to include to do >>>>> the >>>>> release in the end of today or the beginning of the next week? >>>> I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches >>>> are on the list and require krb5 update. >>> >>> Ok. But I do not see it as something that should postpone 4.2.1 as it is not a >>> regression and this simply never worked (AFAIK). >> It is mostly going to create a major confusion when people start using >> one-way trust with elaborate forest structure. > >Sure. But my point is that we should not miss the Beta deadline so that we have >the big stabilization 4.2.1 release in and being tested. > >This particular Trust change can come in 4.2.2 week or two after, in case it >does not make 4.2.1 deadline. Yes, that's fine as long as we are able to put all pieces together before F23 release. -- / Alexander Bokovoy From jhrozek at redhat.com Fri Sep 4 07:30:39 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 4 Sep 2015 09:30:39 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E94787.1040804@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904071226.GH3481@hendrix> <55E945F4.6030502@redhat.com> <20150904072334.GJ3481@hendrix> <55E94787.1040804@redhat.com> Message-ID: <20150904073039.GL3481@hendrix> On Fri, Sep 04, 2015 at 09:25:59AM +0200, Martin Kosek wrote: > On 09/04/2015 09:23 AM, Jakub Hrozek wrote: > > On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote: > >> On 09/04/2015 09:12 AM, Jakub Hrozek wrote: > >>> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: > >>>> Hello everyone, > >>>> > >>>> It is now only couple days before Fedora 23 Beta freeze [1] and as we > >>>> discussed, we would like to release FreeIPA 4.2.1, which already contains 148 > >>>> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features > >>>> or upgrade fixes. > >>>> > >>>> IIRC, we miss 2 dependencies: > >>>> > >>>> 1) pki-ca 10.2.6 > >>>> > >>>> This is still waiting in Updates Testing [2]. We need 3 positive karma (only if > >>>> it works of course) to make it move to stable updates repo and so that we do > >>>> not have broken deps. > >>>> > >>>> 2) sssd 1.13.1 > >>>> > >>>> This upstream release does not officially exist, AFAIK, only in a COPR repo. I > >>>> see 2 options here: > >>>> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires > >>>> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump > >>>> the requires and we set the requires in Fedora 23 to 1.13.0. > >>> > >>> I would prefer to release 1.13.1, there's too many patches to backport. > >> > >> Well, an case of FreeIPA and it's requires, we should only need 5 of them: > >> https://fedorahosted.org/sssd/ticket/2558#comment:12 > > > > But the number of fixes is quite high, there's already close to 50 > > tickets fixed and if we rebase, we better to it before Beta. > > I fully agree with SSSD release before Beta. I was now mostly only discussing > the unfulfilled FreeIPA requires that has different requirements Noted; we will release 1.13.1 on Monday, then. From jpazdziora at redhat.com Fri Sep 4 08:10:55 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 4 Sep 2015 10:10:55 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <55E9423F.1080805@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904065715.GE24631@redhat.com> <55E9423F.1080805@redhat.com> Message-ID: <20150904081055.GG24631@redhat.com> On Fri, Sep 04, 2015 at 09:03:27AM +0200, Martin Kosek wrote: > ticket to the right version milestone ("FreeIPA 4.2.1") at the time the ticket > is closed. But without proper tooling, I am afraid people may simply close the > ticket within "FreeIPA 4.2.x backlog" and it would then not be clear what > version it is fixed in. Moving all resolved "FreeIPA 4.2.x backlog" to the correct milestone at the point that release is released and/or branched might be reasonable approximation. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Fri Sep 4 08:28:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 4 Sep 2015 10:28:16 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests In-Reply-To: <55E8819E.8020508@redhat.com> References: <55E86D57.1050006@redhat.com> <55E8819E.8020508@redhat.com> Message-ID: <55E95620.6060202@redhat.com> On 09/03/2015 07:21 PM, Oleg Fayans wrote: > Hi Martin, > > The two functions > test_disable_reenable_signing_master and > test_disable_reenable_signing_replica > the error message for the laste assertion is different, although the > assertions are identical: > "RRSIG should be different" and "DNSKEY should be different". > Other than that, it's fine > > > On 09/03/2015 05:55 PM, Martin Basti wrote: >> Attached patches improve DNSSEC CI tests. >> >> > Thank you for review. Updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0309.2-DNSSEC-improve-CI-test.patch Type: text/x-patch Size: 6023 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0310.2-DNSSEC-CI-test-master-migration.patch Type: text/x-patch Size: 6892 bytes Desc: not available URL: From ldoudova at redhat.com Fri Sep 4 09:06:09 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 4 Sep 2015 11:06:09 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55E83E9B.8070901@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> Message-ID: <55E95F01.10809@redhat.com> Hi, there's no traceback in the file you mentioned, but I'm running it through lite-server, so here's the traceback from there: http://pastebin.test.redhat.com/310598 I can't really get to the problem. What I forgot to mention in the previous email was that the tests fail when attempting to add a certprofile, but if I try to do is manually using 'ipa certprofile-import' command with the exact same data as used in the test, it works fine. Lenka On 09/03/2015 02:35 PM, Tomas Babej wrote: > > On 09/03/2015 01:40 PM, Lenka Doudova wrote: >> Hi, >> >> I took a look at it at Milan's request. >> >> patch 0008 - tracker looks ok, ACK >> patch 0009 - test cases look ok as well, but can't get it to run, 10 out >> of 14 tests fail, starting with internal error, which I haven't been >> able to track down, nor fix it. > You can investigate the internal error by inspecting the > /var/log/httpd/error_log on the IPA server that executed the command. > > There should be a traceback. > >> Lenka >> >> =================================== FAILURES >> =================================== >> ____________________ TestProfileCRUD.test_create_duplicate >> _____________________ >> >> self = > object at 0x7f36459e7110> >> user_profile = >> > at 0x7f36459e73d0> >> >> def test_create_duplicate(self, user_profile): >> msg = u'Certificate Profile with name "{}" already exists' >>> user_profile.ensure_exists() >> ipatests/test_xmlrpc/test_certprofile_plugin.py:178: >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ >> ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists >> self.create(force=True) >> ipatests/test_xmlrpc/ldaptracker.py:206: in create >> result = command() >> ipatests/test_xmlrpc/ldaptracker.py:127: in run_command >> result = cmd(*args, **options) >> ipalib/frontend.py:443: in __call__ >> ret = self.run(*args, **options) >> ipalib/frontend.py:761: in run >> return self.forward(*args, **options) >> ipalib/frontend.py:782: in forward >> return self.Backend.rpcclient.forward(self.name, *args, **kw) >> ipalib/rpc.py:947: in forward >> return self._call_command(command, params) >> ipalib/rpc.py:924: in _call_command >> return command(*params) >> ipalib/rpc.py:1075: in _call >> return self.__request(name, args) >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> _ _ _ _ >> >> self = >> name = 'certprofile_import' >> args = (('caIPAserviceCert_mod',), {'all': False, 'description': >> 'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion Default >> policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 >> ', 'ipacertprofilestoreissued': True, ...}) >> >> def __request(self, name, args): >> payload = {'method': unicode(name), 'params': args, 'id': 0} >> version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES) >> payload = json_encode_binary(payload, version) >> >> if self.__verbose >= 2: >> root_logger.info('Request: %s', >> json.dumps(payload, sort_keys=True, indent=4)) >> >> response = self.__transport.request( >> self.__host, >> self.__handler, >> json.dumps(payload), >> verbose=self.__verbose >= 3, >> ) >> >> try: >> response = json_decode_binary(json.loads(response)) >> except ValueError as e: >> raise JSONError(str(e)) >> >> if self.__verbose >= 2: >> root_logger.info( >> 'Response: %s', >> json.dumps(json_encode_binary(response, version), >> sort_keys=True, indent=4) >> ) >> error = response.get('error') >> if error: >> try: >> error_class = errors_by_code[error['code']] >> except KeyError: >> raise UnknownError( >> code=error.get('code'), >> error=error.get('message'), >> server=self.__host, >> ) >> else: >>> raise error_class(message=error['message']) >> E InternalError: an internal error has occurred >> >> >> >> >> On 08/31/2015 03:25 PM, Fraser Tweedale wrote: >>> On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote: >>>> On 08/18/2015 04:06 PM, Milan Kub?k wrote: >>>>> On 08/11/2015 03:17 AM, Fraser Tweedale wrote: >>>>>> On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: >>>>>>> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>>>>>>> Hi list, >>>>>>>> >>>>>>>> I'm sending the test plan [1] for certificate profiles and preliminary >>>>>>>> patches for it. >>>>>>>> The plan covers basic CRUD test and some corner cases. I'm open to >>>>>>>> more >>>>>>>> suggestions. >>>>>>>> >>>>>>>> More complicated tests involving certificate profiles will require the >>>>>>>> code (and tests) >>>>>>>> for CA ACLs merged, so it's not there at the moment. >>>>>>>> >>>>>>>> There are some unfinished test cases in places I wasn't sure what the >>>>>>>> result should be. >>>>>>>> We need to iterate through these to fix it. >>>>>>>> >>>>>>>> >>>>>>>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Milan >>>>>>> Hi all, >>>>>>> >>>>>>> have you had some time to look at the code and proposal? >>>>>>> Today I want to write a basic CRUD test for the ACLs as well as a few >>>>>>> test >>>>>>> cases to check if the ACL is being enforced. It should make it into >>>>>>> wiki >>>>>>> today or by tomorrow. I'll send an update then. >>>>>>> >>>>>>> Cheers, >>>>>>> Milan >>>>>>> >>>>>> Hi Milan, >>>>>> >>>>>> I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of >>>>>> comments: >>>>>> >>>>>> - Test case: Import profile with incorrect values >>>>>> - Expected result: refused with error. >>>>>> - A simple way to provoke this condition is to add a number to >>>>>> ``policyset.serverCertSet.list``. >>>>>> - A similar test case should exist for certprofile-mod. >>>>>> >>>>>> - Test case: Delete default profile >>>>>> - As discussed elsewhere, expected result should be failure. >>>>>> I filed ticket #5198 to make it so :) >>>>>> >>>>>> I will review the patch soon. >>>>>> >>>>>> Cheers, >>>>>> Fraser >>>>> Hello, >>>>> >>>>> how is the review going? I'd like to have at least the tracker (patch >>>>> 0008) >>>>> reviewed (and merged :) if possible. It will be needed in CA ACL tests. >>>>> >>>>> Cheers, >>>>> Milan >>>>> >>>> Fraser, do you review this patchset? >>> This fell off my radar, sorry! I eyeballed it a while back and >>> everything seemed fine; I have not (successfully) run the tests yet >>> though. I will complete the review tomorrow. >>> >>> Thanks, >>> Fraser >>> >> >> From tbordaz at redhat.com Fri Sep 4 10:49:37 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 04 Sep 2015 12:49:37 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E85338.1040805@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> <1441196867.28131.159.camel@willson.usersys.redhat.com> <55E85338.1040805@redhat.com> Message-ID: <55E97741.3060704@redhat.com> On 09/03/2015 04:03 PM, David Kupka wrote: > On 02/09/15 14:27, Simo Sorce wrote: >> On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: >>> On 01/09/15 16:53, Simo Sorce wrote: >>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>>> Hi list, >>>>> >>>>> I own the following ticket >>>>> https://fedorahosted.org/freeipa/ticket/3864 >>>>> and I would like to clarify what needs to be done in order to make >>>>> IPA >>>>> to fully support multiple aliases per entry. >>>>> >>>>> So far I have identified these task based on the ticket comments and >>>>> discussion with Simo way back in the past: >>>>> >>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>>> not used in the new code. >>>>> >>>>> 2.) fix ACIs that do not permit setting multiple values of >>>>> 'krbPrincipalName' attribute per entry (see >>>>> https://fedorahosted.org/freeipa/ticket/3961) >>>>> >>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>>> case-insensitively and krbcanonicalname case-sensitively, return >>>>> krbcanonicalname when canonicalization is requested. >>>>> >>>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>>> should be covered here (I remember that we should create >>>>> krbcanonicalname when we add another aliases to krbprincipalname), >>>>> so it >>>>> would be nice if you could comment on this. >>>>> >>>>> 5.) write tests which cover all this stuff so that we don't shoot >>>>> ourselves in the foot. >>>>> >>>>> I am not very well versed in Kerberos so I might get some of this >>>>> stuff >>>>> wrong. If that's the case please point me to the right direction. >>>>> Also >>>>> please write me some additional stuff which I have fogot and needs >>>>> to be >>>>> done. >>>>> >>>> >>>> I think the summary is correct, the only thing we need to be >>>> careful is >>>> to keep handling entries that have only a single valued >>>> krbprincipalname >>>> correctly as that will happen in upgrade paths and potentially if >>>> someone uses external tools. >>>> >>>> The tricky part for point 3 is to implement it *without* changing the >>>> schema. KrbPrincipalName is case-sensitive, however I think we can >>>> solve >>>> the issue of "searching case-insensitively" by always lower-casing the >>>> principal name components and always upper casing the realm part on >>>> storage. If we always store a krbCanonicalName we get the "correct" >>>> case >>>> there anyway so out mucking with the krbPrincipalName case will not >>>> be a >>>> problem for any new entry. >>> >>> Or as Honza pointed out we can use case-insensitive search like this: >>> (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return >>> all variants of casing and reduce the need for fallback code. >> >> The principal name is not case insensitive, a search like that would >> probably cause DS to do a full search through the krbPrincipalName >> index, it might quickly become a performance issue. Before choosing a >> method please create an install with a 10000 principals, and then >> compare the speed of a few thousand search with exact matching case and >> a few with specifying caseIgnoreMatch and see the difference. >> >> Simo. > > We will add index for caseIgnoreCaseIA5Match matching rule on > krbPrincipalName and then the case insensitive match should be as > quick as the case sensitive. > > Without the index it is indeed far slower. I've generated 10k users > and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and > the nonindexed one ~2 minutes. That's by two orders of magnitude worse. > > When we tried to add the index into DS we uncovered a bug in the way > DS handles nsMatchingRule attributes. Thierry investigated it and is > filling the ticket for DS right now. Thierry can you please send link? The ticket is https://fedorahosted.org/389/ticket/48270. I think understand where the problem is but I have no fix yet. David, when you said the unindexed search was slow, did you index 'krbPrincipalName' but added a matching rule to your filter ? I would like to also verify the fix against that perf hit. thanks thierry > > Once it's fixed we should be good. > > David > >> >>>> This *may* cause issues with upgrades though, so we may need fallback >>>> code that searches with the case sent by the client if we determine >>>> the >>>> entry has no krbCanonicalName attribute (sign that it was created >>>> before >>>> we started adding krbCanonicalName and never "updated"). >>>> >>>> Note that we also need to think what will happen during and upgrade >>>> when >>>> some servers still use the current code and some servers will use the >>>> new code. So I guess it would be nice if you could write down a table >>>> with all possible forms a principal can be in on rows, and old/new >>>> server states in columns, and mark what will happen for various >>>> operations in each case. >>>> >>>> Simo. >>>> >> >> > > From mkosek at redhat.com Fri Sep 4 11:14:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 4 Sep 2015 13:14:44 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <20150904081055.GG24631@redhat.com> References: <55E93D67.8000109@redhat.com> <20150904065715.GE24631@redhat.com> <55E9423F.1080805@redhat.com> <20150904081055.GG24631@redhat.com> Message-ID: <55E97D24.7080409@redhat.com> On 09/04/2015 10:10 AM, Jan Pazdziora wrote: > On Fri, Sep 04, 2015 at 09:03:27AM +0200, Martin Kosek wrote: >> ticket to the right version milestone ("FreeIPA 4.2.1") at the time the ticket >> is closed. But without proper tooling, I am afraid people may simply close the >> ticket within "FreeIPA 4.2.x backlog" and it would then not be clear what >> version it is fixed in. > > Moving all resolved "FreeIPA 4.2.x backlog" to the correct milestone > at the point that release is released and/or branched might be > reasonable approximation. Good idea, that could work. From tbabej at redhat.com Fri Sep 4 11:30:57 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 4 Sep 2015 13:30:57 +0200 Subject: [Freeipa-devel] [PATCH 487] ldap: Make ldap2 connection management thread-safe again In-Reply-To: <55E70C09.4060607@redhat.com> References: <55E6EC61.7020104@redhat.com> <55E6F0ED.60200@redhat.com> <55E6F6A3.6060400@redhat.com> <55E705A6.10007@redhat.com> <55E70C09.4060607@redhat.com> Message-ID: <55E980F1.6080101@redhat.com> On 09/02/2015 04:47 PM, Jan Cholasta wrote: > On 2.9.2015 16:20, thierry bordaz wrote: >> On 09/02/2015 03:16 PM, Jan Cholasta wrote: >>> On 2.9.2015 14:51, Martin Basti wrote: >>>> >>>> >>>> On 09/02/2015 02:32 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>>> >>>>> >>>>> >>>> >>>> This patch needs a big rebase to ipa-4-2 branch >>> >>> Patch attached. >>> >>> >>> >> Hello, >> >> Two minors questions. LDAPClient close/__del__/__exit__ are now just >> resetting self._conn without disconnecting the connection. > > They do the same even without the patch, "object.__setattr__(self, > '_conn', None)" is effectively the same as "self._conn = None". > >> Only ldap2.close() disconnect the connection. Could it be a risk to see >> connection leaks with __del__ or __exit__ ? > > This behavior is unchanged, and so far no one complained about > connection leaks. > >> >> Also in the fix there is: >> >> @@ -118,10 +115,11 @@ class ldap2(CrudBackend, LDAPClient): >> if debug_level: >> _ldap.set_option(_ldap.OPT_DEBUG_LEVEL, debug_level) >> >> - LDAPClient._connect(self) >> - conn = self._conn >> + client = LDAPClient(self.ldap_uri, >> + >> force_schema_updates=self._force_schema_updates) >> + conn = client._conn >> >> >> Is it the same as 'conn = client.conn()' ? > > No. It's the same as "conn = client.conn", but I'd like to get rid of > LDAPClient.conn in the future (internal attributes should not be > public), hence the use of self._conn. > >> >> Thanks >> thierry >> > This fixes the connection issue, ACK. Tomas From tbabej at redhat.com Fri Sep 4 11:33:43 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 4 Sep 2015 13:33:43 +0200 Subject: [Freeipa-devel] [PATCH 487] ldap: Make ldap2 connection management thread-safe again In-Reply-To: <55E980F1.6080101@redhat.com> References: <55E6EC61.7020104@redhat.com> <55E6F0ED.60200@redhat.com> <55E6F6A3.6060400@redhat.com> <55E705A6.10007@redhat.com> <55E70C09.4060607@redhat.com> <55E980F1.6080101@redhat.com> Message-ID: <55E98197.60001@redhat.com> On 09/04/2015 01:30 PM, Tomas Babej wrote: > > > On 09/02/2015 04:47 PM, Jan Cholasta wrote: >> On 2.9.2015 16:20, thierry bordaz wrote: >>> On 09/02/2015 03:16 PM, Jan Cholasta wrote: >>>> On 2.9.2015 14:51, Martin Basti wrote: >>>>> >>>>> >>>>> On 09/02/2015 02:32 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes >>>>>> . >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> >>>>> >>>>> This patch needs a big rebase to ipa-4-2 branch >>>> >>>> Patch attached. >>>> >>>> >>>> >>> Hello, >>> >>> Two minors questions. LDAPClient close/__del__/__exit__ are now just >>> resetting self._conn without disconnecting the connection. >> >> They do the same even without the patch, "object.__setattr__(self, >> '_conn', None)" is effectively the same as "self._conn = None". >> >>> Only ldap2.close() disconnect the connection. Could it be a risk to see >>> connection leaks with __del__ or __exit__ ? >> >> This behavior is unchanged, and so far no one complained about >> connection leaks. >> >>> >>> Also in the fix there is: >>> >>> @@ -118,10 +115,11 @@ class ldap2(CrudBackend, LDAPClient): >>> if debug_level: >>> _ldap.set_option(_ldap.OPT_DEBUG_LEVEL, debug_level) >>> >>> - LDAPClient._connect(self) >>> - conn = self._conn >>> + client = LDAPClient(self.ldap_uri, >>> + >>> force_schema_updates=self._force_schema_updates) >>> + conn = client._conn >>> >>> >>> Is it the same as 'conn = client.conn()' ? >> >> No. It's the same as "conn = client.conn", but I'd like to get rid of >> LDAPClient.conn in the future (internal attributes should not be >> public), hence the use of self._conn. >> >>> >>> Thanks >>> thierry >>> >> > > This fixes the connection issue, ACK. > > Tomas > Pushed to master: 198908ec78b9a2dbdb802c3a094ec8f54b931d7a Pushed to ipa-4-2: fa1529779de85a589dfa12ca30dcdfe7a1146c83 From mbasti at redhat.com Fri Sep 4 11:35:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 4 Sep 2015 13:35:05 +0200 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E67E39.3090907@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> <55E53265.4010400@redhat.com> <55E54B22.1050508@redhat.com> <55E67E39.3090907@redhat.com> Message-ID: <55E981E9.5050400@redhat.com> On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote: > On 9/1/2015 1:52 AM, Martin Basti wrote: >>>>>> The CA and KRA installation code has been modified to use LDAPI >>>>>> to create the CA and KRA agents directly in the CA and KRA >>>>>> database. This way it's no longer necessary to use the Directory >>>>>> Manager password or CA and KRA admin certificate. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5257 >>>>>> >>>>>> >>>>>> >>>>> >>>>> Thank you. >>>>> >>>>> 1) Can you use following code instead of direct call of >>>>> ldap2.ldap2()? >>>>> >>>>> if not api.Backend.ldap2.is_connected(): >>>>> api.Backend.ldap2.connect(autobind=True) >>>>> >>>>> conn = api.Backend.ldap2 >>> >>> Why would you want to do that? The original code is fine, except the >>> connection check is not necessary (it is a new instance of ldap2, so >>> .isconnected() will always return False). >>> >>>> >>>> It's actually isconnected() instead of is_connected(), but even so, >>>> the >>>> proposed code doesn't work: >>>> >>>> ipa.ipapython.install.cli.install_tool(Server): DEBUG The >>>> ipa-server-install command failed, exception: TypeError: 'ldap2' >>>> object >>>> is not callable >>>> ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object >>>> is not callable >>>> >>>>> 2) Patch needs rebase to master branch. >>>> >>>> The original patch does apply cleanly to master. Did you see a >>>> conflict? >> Sorry my bad. >> >> Martin^2 >>>> >>>>> 3) >>>>> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), >>>>> self.basedn) >>>>> + conn.create( >>>>> + dn=user_dn, >>>>> >>>>> can you use add entry() instead of create()? We don't use native >>>>> python-ldap, but rather ipaldap methods >>>> >>>> It's actually calling the ldap2.create() defined in >>>> ipaserver/plugins/ldap2.py, which calls add_entry(). >>> >>> NACK. We don't use ldap2.create(). Use add_entry(). >>> >>>> >>>> So my original patch still stands. > > New patch attached. > ACK, but IMO that comments is not necessary and I would like to push the patch without it. Martin^2 From redhatrises at gmail.com Fri Sep 4 12:43:21 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 4 Sep 2015 06:43:21 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> Message-ID: Bump for review. On Wed, Aug 12, 2015 at 9:32 AM, Gabe Alford wrote: > On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta wrote: > >> On 6.8.2015 21:43, Gabe Alford wrote: >> >>> Hello, >>> >>> Updated patch attached. >>> >>> - Time limit is -1 for unlimited. I found this >>> https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html >>> in reference to keeping the time limit as -1 for unlimited. >>> >> >> This patch does two conflicting things: it coerces time limit of 0 to -1 >> and at the same time prohibits the user to use 0 for time limit. We should >> do just one of these and IMHO it should be the coercion of 0 to -1. >> >> Sure enough, testing time limit at 0 did not work for unlimited as well >>> as appeared to have negative effects on IPA. >>> >> >> This is because the time limit read from ipa config is not converted to >> int in ldap2.find_entries(), so the coercion does not work. Fix this and 0 >> will work just fine. >> >> Also, I believe that >>> >>> http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s >>> specifies unlimited for time limit as -1. (Please correct me if I am >>> wrong.) >>> >> >> python-ldap is layers below our API and should not determine what we use >> for unlimited time limit. I would prefer if we were self-consistent and use >> 0 for both time limit and size limit. >> > > A misunderstanding on my part as I thought it was higher up in the API for > some reason. Updated patch attached. > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Fri Sep 4 13:27:18 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 4 Sep 2015 15:27:18 +0200 Subject: [Freeipa-devel] [PATCH 0063] fix crash during standalone CA installation on CA-less master Message-ID: <55E99C36.4050106@redhat.com> A quick fix for https://fedorahosted.org/freeipa/ticket/5288 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0063-load-RA-backend-plugins-during-standalone-CA-install.patch Type: text/x-patch Size: 1316 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Sep 4 13:57:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 4 Sep 2015 15:57:34 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55E95F01.10809@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> Message-ID: <55E9A34E.3010808@redhat.com> On 09/04/2015 11:06 AM, Lenka Doudova wrote: > Hi, > > there's no traceback in the file you mentioned, but I'm running it > through lite-server, so here's the traceback from there: > http://pastebin.test.redhat.com/310598 > > I can't really get to the problem. What I forgot to mention in the > previous email was that the tests fail when attempting to add a > certprofile, but if I try to do is manually using 'ipa > certprofile-import' command with the exact same data as used in the > test, it works fine. > > Lenka > Do you get the traceback also when you run the tests using 'ipa-run-tests' with installed IPA master? -- Martin^3 Babinsky From edewata at redhat.com Fri Sep 4 14:03:43 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 4 Sep 2015 09:03:43 -0500 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E981E9.5050400@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> <55E53265.4010400@redhat.com> <55E54B22.1050508@redhat.com> <55E67E39.3090907@redhat.com> <55E981E9.5050400@redhat.com> Message-ID: <55E9A4BF.8080106@redhat.com> On 9/4/2015 6:35 AM, Martin Basti wrote: > > > On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote: >> On 9/1/2015 1:52 AM, Martin Basti wrote: >>>>>>> The CA and KRA installation code has been modified to use LDAPI >>>>>>> to create the CA and KRA agents directly in the CA and KRA >>>>>>> database. This way it's no longer necessary to use the Directory >>>>>>> Manager password or CA and KRA admin certificate. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5257 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> 1) Can you use following code instead of direct call of >>>>>> ldap2.ldap2()? >>>>>> >>>>>> if not api.Backend.ldap2.is_connected(): >>>>>> api.Backend.ldap2.connect(autobind=True) >>>>>> >>>>>> conn = api.Backend.ldap2 >>>> >>>> Why would you want to do that? The original code is fine, except the >>>> connection check is not necessary (it is a new instance of ldap2, so >>>> .isconnected() will always return False). >>>> >>>>> >>>>> It's actually isconnected() instead of is_connected(), but even so, >>>>> the >>>>> proposed code doesn't work: >>>>> >>>>> ipa.ipapython.install.cli.install_tool(Server): DEBUG The >>>>> ipa-server-install command failed, exception: TypeError: 'ldap2' >>>>> object >>>>> is not callable >>>>> ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object >>>>> is not callable >>>>> >>>>>> 2) Patch needs rebase to master branch. >>>>> >>>>> The original patch does apply cleanly to master. Did you see a >>>>> conflict? >>> Sorry my bad. >>> >>> Martin^2 >>>>> >>>>>> 3) >>>>>> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), >>>>>> self.basedn) >>>>>> + conn.create( >>>>>> + dn=user_dn, >>>>>> >>>>>> can you use add entry() instead of create()? We don't use native >>>>>> python-ldap, but rather ipaldap methods >>>>> >>>>> It's actually calling the ldap2.create() defined in >>>>> ipaserver/plugins/ldap2.py, which calls add_entry(). >>>> >>>> NACK. We don't use ldap2.create(). Use add_entry(). >>>> >>>>> >>>>> So my original patch still stands. >> >> New patch attached. >> > ACK, but IMO that comments is not necessary and I would like to push the > patch without it. > > Martin^2 It is necessary if we don't want people to use it. Otherwise someone could make the same mistake. Or better yet, just remove the method. -- Endi S. Dewata From jhrozek at redhat.com Fri Sep 4 14:50:41 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 4 Sep 2015 16:50:41 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 checklist In-Reply-To: <20150904073039.GL3481@hendrix> References: <55E93D67.8000109@redhat.com> <20150904071226.GH3481@hendrix> <55E945F4.6030502@redhat.com> <20150904072334.GJ3481@hendrix> <55E94787.1040804@redhat.com> <20150904073039.GL3481@hendrix> Message-ID: <20150904145041.GU3481@hendrix> On Fri, Sep 04, 2015 at 09:30:39AM +0200, Jakub Hrozek wrote: > On Fri, Sep 04, 2015 at 09:25:59AM +0200, Martin Kosek wrote: > > On 09/04/2015 09:23 AM, Jakub Hrozek wrote: > > > On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote: > > >> On 09/04/2015 09:12 AM, Jakub Hrozek wrote: > > >>> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote: > > >>>> Hello everyone, > > >>>> > > >>>> It is now only couple days before Fedora 23 Beta freeze [1] and as we > > >>>> discussed, we would like to release FreeIPA 4.2.1, which already contains 148 > > >>>> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features > > >>>> or upgrade fixes. > > >>>> > > >>>> IIRC, we miss 2 dependencies: > > >>>> > > >>>> 1) pki-ca 10.2.6 > > >>>> > > >>>> This is still waiting in Updates Testing [2]. We need 3 positive karma (only if > > >>>> it works of course) to make it move to stable updates repo and so that we do > > >>>> not have broken deps. > > >>>> > > >>>> 2) sssd 1.13.1 > > >>>> > > >>>> This upstream release does not officially exist, AFAIK, only in a COPR repo. I > > >>>> see 2 options here: > > >>>> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the Requires > > >>>> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump > > >>>> the requires and we set the requires in Fedora 23 to 1.13.0. > > >>> > > >>> I would prefer to release 1.13.1, there's too many patches to backport. > > >> > > >> Well, an case of FreeIPA and it's requires, we should only need 5 of them: > > >> https://fedorahosted.org/sssd/ticket/2558#comment:12 > > > > > > But the number of fixes is quite high, there's already close to 50 > > > tickets fixed and if we rebase, we better to it before Beta. > > > > I fully agree with SSSD release before Beta. I was now mostly only discussing > > the unfulfilled FreeIPA requires that has different requirements > > Noted; we will release 1.13.1 on Monday, then. Actually... There is a late regression (no ticket yet), so please ping us before releasing freeipa version that requires 1.13.1, maybe we'll need to use .0+patches for F-23. We'll sort in out on Monday From pvoborni at redhat.com Fri Sep 4 14:53:07 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 4 Sep 2015 16:53:07 +0200 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E9A4BF.8080106@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> <55E53265.4010400@redhat.com> <55E54B22.1050508@redhat.com> <55E67E39.3090907@redhat.com> <55E981E9.5050400@redhat.com> <55E9A4BF.8080106@redhat.com> Message-ID: <55E9B053.6080705@redhat.com> On 09/04/2015 04:03 PM, Endi Sukma Dewata wrote: > On 9/4/2015 6:35 AM, Martin Basti wrote: >> >> >> On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote: >>> On 9/1/2015 1:52 AM, Martin Basti wrote: >>>>>>>> The CA and KRA installation code has been modified to use LDAPI >>>>>>>> to create the CA and KRA agents directly in the CA and KRA >>>>>>>> database. This way it's no longer necessary to use the Directory >>>>>>>> Manager password or CA and KRA admin certificate. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/5257 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> 1) Can you use following code instead of direct call of >>>>>>> ldap2.ldap2()? >>>>>>> >>>>>>> if not api.Backend.ldap2.is_connected(): >>>>>>> api.Backend.ldap2.connect(autobind=True) >>>>>>> >>>>>>> conn = api.Backend.ldap2 >>>>> >>>>> Why would you want to do that? The original code is fine, except the >>>>> connection check is not necessary (it is a new instance of ldap2, so >>>>> .isconnected() will always return False). >>>>> >>>>>> >>>>>> It's actually isconnected() instead of is_connected(), but even so, >>>>>> the >>>>>> proposed code doesn't work: >>>>>> >>>>>> ipa.ipapython.install.cli.install_tool(Server): DEBUG The >>>>>> ipa-server-install command failed, exception: TypeError: 'ldap2' >>>>>> object >>>>>> is not callable >>>>>> ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object >>>>>> is not callable >>>>>> >>>>>>> 2) Patch needs rebase to master branch. >>>>>> >>>>>> The original patch does apply cleanly to master. Did you see a >>>>>> conflict? >>>> Sorry my bad. >>>> >>>> Martin^2 >>>>>> >>>>>>> 3) >>>>>>> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), >>>>>>> self.basedn) >>>>>>> + conn.create( >>>>>>> + dn=user_dn, >>>>>>> >>>>>>> can you use add entry() instead of create()? We don't use native >>>>>>> python-ldap, but rather ipaldap methods >>>>>> >>>>>> It's actually calling the ldap2.create() defined in >>>>>> ipaserver/plugins/ldap2.py, which calls add_entry(). >>>>> >>>>> NACK. We don't use ldap2.create(). Use add_entry(). >>>>> >>>>>> >>>>>> So my original patch still stands. >>> >>> New patch attached. >>> >> ACK, but IMO that comments is not necessary and I would like to push the >> patch without it. >> >> Martin^2 > > It is necessary if we don't want people to use it. Otherwise someone > could make the same mistake. Or better yet, just remove the method. > + + NOTE: Do not use this method. I agree that the comment should not be in this patch - it is not relevant to vaults. The comment or a removal of the method(if it is really useless) should be in a different patch. If comment is the way than please also add why it should not be used. -- Petr Vobornik From msimacek at redhat.com Fri Sep 4 15:07:12 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Fri, 4 Sep 2015 17:07:12 +0200 Subject: [Freeipa-devel] [PATCH 0004] Rewrap errors in get_principal to CCacheError In-Reply-To: <55E83DF8.3040201@redhat.com> References: <55E826E8.7080703@redhat.com> <55E83DF8.3040201@redhat.com> Message-ID: <55E9B3A0.7080803@redhat.com> On 2015-09-03 14:32, Tomas Babej wrote: > > > On 09/03/2015 12:54 PM, Michael ?im??ek wrote: >> After porting to gssapi, the ipa command prints ugly traceback when >> kerberos credentials are not available. Rewrapping to CCacheError when >> getting the principal name results in nicer error message. >> >> https://fedorahosted.org/freeipa/ticket/5272 >> >> > > This fixes the issue, however, I am getting a trailing forward slash in > the error message: > > $ ipa user-find > ipa: ERROR: Kerberos error: did not receive Kerberos credentials/ > Attaching updated revision. I altered more places where kerberos errors were used. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0004-2-Rewrap-errors-in-get_principal-to-CCacheError.patch Type: text/x-patch Size: 4661 bytes Desc: not available URL: From simo at redhat.com Fri Sep 4 17:55:44 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 04 Sep 2015 13:55:44 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E85338.1040805@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> <1441196867.28131.159.camel@willson.usersys.redhat.com> <55E85338.1040805@redhat.com> Message-ID: <1441389344.3048.20.camel@willson.usersys.redhat.com> On Thu, 2015-09-03 at 16:03 +0200, David Kupka wrote: > On 02/09/15 14:27, Simo Sorce wrote: > > On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: > >> On 01/09/15 16:53, Simo Sorce wrote: > >>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >>>> Hi list, > >>>> > >>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 > >>>> and I would like to clarify what needs to be done in order to make IPA > >>>> to fully support multiple aliases per entry. > >>>> > >>>> So far I have identified these task based on the ticket comments and > >>>> discussion with Simo way back in the past: > >>>> > >>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >>>> not used in the new code. > >>>> > >>>> 2.) fix ACIs that do not permit setting multiple values of > >>>> 'krbPrincipalName' attribute per entry (see > >>>> https://fedorahosted.org/freeipa/ticket/3961) > >>>> > >>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >>>> 'ipadb_find_principal' functions) to correctly perform lookup of > >>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >>>> case-insensitively and krbcanonicalname case-sensitively, return > >>>> krbcanonicalname when canonicalization is requested. > >>>> > >>>> 4.) Modify KDB backend and IPA framework to handle creation of both > >>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >>>> should be covered here (I remember that we should create > >>>> krbcanonicalname when we add another aliases to krbprincipalname), so it > >>>> would be nice if you could comment on this. > >>>> > >>>> 5.) write tests which cover all this stuff so that we don't shoot > >>>> ourselves in the foot. > >>>> > >>>> I am not very well versed in Kerberos so I might get some of this stuff > >>>> wrong. If that's the case please point me to the right direction. Also > >>>> please write me some additional stuff which I have fogot and needs to be > >>>> done. > >>>> > >>> > >>> I think the summary is correct, the only thing we need to be careful is > >>> to keep handling entries that have only a single valued krbprincipalname > >>> correctly as that will happen in upgrade paths and potentially if > >>> someone uses external tools. > >>> > >>> The tricky part for point 3 is to implement it *without* changing the > >>> schema. KrbPrincipalName is case-sensitive, however I think we can solve > >>> the issue of "searching case-insensitively" by always lower-casing the > >>> principal name components and always upper casing the realm part on > >>> storage. If we always store a krbCanonicalName we get the "correct" case > >>> there anyway so out mucking with the krbPrincipalName case will not be a > >>> problem for any new entry. > >> > >> Or as Honza pointed out we can use case-insensitive search like this: > >> (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return > >> all variants of casing and reduce the need for fallback code. > > > > The principal name is not case insensitive, a search like that would > > probably cause DS to do a full search through the krbPrincipalName > > index, it might quickly become a performance issue. Before choosing a > > method please create an install with a 10000 principals, and then > > compare the speed of a few thousand search with exact matching case and > > a few with specifying caseIgnoreMatch and see the difference. > > > > Simo. > > We will add index for caseIgnoreCaseIA5Match matching rule on > krbPrincipalName and then the case insensitive match should be as quick > as the case sensitive. > > Without the index it is indeed far slower. I've generated 10k users and > compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the > nonindexed one ~2 minutes. That's by two orders of magnitude worse. > > When we tried to add the index into DS we uncovered a bug in the way DS > handles nsMatchingRule attributes. Thierry investigated it and is > filling the ticket for DS right now. Thierry can you please send link? > > Once it's fixed we should be good. > > David > > > > >>> This *may* cause issues with upgrades though, so we may need fallback > >>> code that searches with the case sent by the client if we determine the > >>> entry has no krbCanonicalName attribute (sign that it was created before > >>> we started adding krbCanonicalName and never "updated"). Another "upgrade" issue came to mind. Will the referential integrity plugin properly handle a rename of service entries should they be referenced in some object ? Simo. > >>> Note that we also need to think what will happen during and upgrade when > >>> some servers still use the current code and some servers will use the > >>> new code. So I guess it would be nice if you could write down a table > >>> with all possible forms a principal can be in on rows, and old/new > >>> server states in columns, and mark what will happen for various > >>> operations in each case. > >>> > >>> Simo. > >>> > > > > > > -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Sep 7 05:32:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 7 Sep 2015 07:32:06 +0200 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E9B053.6080705@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> <55E53265.4010400@redhat.com> <55E54B22.1050508@redhat.com> <55E67E39.3090907@redhat.com> <55E981E9.5050400@redhat.com> <55E9A4BF.8080106@redhat.com> <55E9B053.6080705@redhat.com> Message-ID: <55ED2156.10901@redhat.com> On 4.9.2015 16:53, Petr Vobornik wrote: > On 09/04/2015 04:03 PM, Endi Sukma Dewata wrote: >> On 9/4/2015 6:35 AM, Martin Basti wrote: >>> >>> >>> On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote: >>>> On 9/1/2015 1:52 AM, Martin Basti wrote: >>>>>>>>> The CA and KRA installation code has been modified to use LDAPI >>>>>>>>> to create the CA and KRA agents directly in the CA and KRA >>>>>>>>> database. This way it's no longer necessary to use the Directory >>>>>>>>> Manager password or CA and KRA admin certificate. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5257 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> 1) Can you use following code instead of direct call of >>>>>>>> ldap2.ldap2()? >>>>>>>> >>>>>>>> if not api.Backend.ldap2.is_connected(): >>>>>>>> api.Backend.ldap2.connect(autobind=True) >>>>>>>> >>>>>>>> conn = api.Backend.ldap2 >>>>>> >>>>>> Why would you want to do that? The original code is fine, except the >>>>>> connection check is not necessary (it is a new instance of ldap2, so >>>>>> .isconnected() will always return False). >>>>>> >>>>>>> >>>>>>> It's actually isconnected() instead of is_connected(), but even so, >>>>>>> the >>>>>>> proposed code doesn't work: >>>>>>> >>>>>>> ipa.ipapython.install.cli.install_tool(Server): DEBUG The >>>>>>> ipa-server-install command failed, exception: TypeError: 'ldap2' >>>>>>> object >>>>>>> is not callable >>>>>>> ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object >>>>>>> is not callable >>>>>>> >>>>>>>> 2) Patch needs rebase to master branch. >>>>>>> >>>>>>> The original patch does apply cleanly to master. Did you see a >>>>>>> conflict? >>>>> Sorry my bad. >>>>> >>>>> Martin^2 >>>>>>> >>>>>>>> 3) >>>>>>>> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), >>>>>>>> self.basedn) >>>>>>>> + conn.create( >>>>>>>> + dn=user_dn, >>>>>>>> >>>>>>>> can you use add entry() instead of create()? We don't use native >>>>>>>> python-ldap, but rather ipaldap methods >>>>>>> >>>>>>> It's actually calling the ldap2.create() defined in >>>>>>> ipaserver/plugins/ldap2.py, which calls add_entry(). >>>>>> >>>>>> NACK. We don't use ldap2.create(). Use add_entry(). >>>>>> >>>>>>> >>>>>>> So my original patch still stands. >>>> >>>> New patch attached. >>>> >>> ACK, but IMO that comments is not necessary and I would like to push the >>> patch without it. >>> >>> Martin^2 >> >> It is necessary if we don't want people to use it. Otherwise someone >> could make the same mistake. Or better yet, just remove the method. >> > > + > + NOTE: Do not use this method. > > I agree that the comment should not be in this patch - it is not > relevant to vaults. > > The comment or a removal of the method(if it is really useless) should > be in a different patch. If comment is the way than please also add why > it should not be used. The method was intended to be used with frontend objects, but they never happened in IPA, so it was left unused (instead we have no clean interface between frontend and backend and call backend-specific methods ad-hoc, what a great design /sarcasm). I personally would like to revive the concept, so I would not remove the methods. I don't think a comment is necessary either, because up until now, nobody tried to use the method. -- Jan Cholasta From jcholast at redhat.com Mon Sep 7 06:02:12 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 7 Sep 2015 08:02:12 +0200 Subject: [Freeipa-devel] [PATCHES 481-486] Metaclass and str modernization In-Reply-To: <55E881FE.6010807@redhat.com> References: <55E5BA6C.2080502@redhat.com> <55E881FE.6010807@redhat.com> Message-ID: <55ED2864.1010404@redhat.com> On 3.9.2015 19:23, Petr Viktorin wrote: > On 09/01/2015 04:47 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches add some more modernization to our code. >> >> Honza > > 481: ACK > 482: ACK > 483: ACK > > You can push these without waiting on the later ones. Pushed to master: cc53526fd21d3faa7b90cd873713279c3ce049f5 > > > 484: > To avoid merge conflicts later, perhaps it would be better to have > > if six.PY3: > unicode = str > > at the start of each affected file, instead of scattering changes in the > files? > (I can prepare the patch if you agree) (Be my guest) > > > 485: > six.binary_type is named "bytes" since Python 2.6. I think it would be > better to use that, to avoid another change when py2 is dropped. > (I can prepare the patch here, too) (OK) > > > 486: ACK > -- Jan Cholasta From dkupka at redhat.com Mon Sep 7 07:20:50 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 7 Sep 2015 09:20:50 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55E97741.3060704@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> <1441196867.28131.159.camel@willson.usersys.redhat.com> <55E85338.1040805@redhat.com> <55E97741.3060704@redhat.com> Message-ID: <55ED3AD2.4000400@redhat.com> On 04/09/15 12:49, thierry bordaz wrote: > On 09/03/2015 04:03 PM, David Kupka wrote: >> On 02/09/15 14:27, Simo Sorce wrote: >>> On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: >>>> On 01/09/15 16:53, Simo Sorce wrote: >>>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>>>> Hi list, >>>>>> >>>>>> I own the following ticket >>>>>> https://fedorahosted.org/freeipa/ticket/3864 >>>>>> and I would like to clarify what needs to be done in order to make >>>>>> IPA >>>>>> to fully support multiple aliases per entry. >>>>>> >>>>>> So far I have identified these task based on the ticket comments and >>>>>> discussion with Simo way back in the past: >>>>>> >>>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>>>> not used in the new code. >>>>>> >>>>>> 2.) fix ACIs that do not permit setting multiple values of >>>>>> 'krbPrincipalName' attribute per entry (see >>>>>> https://fedorahosted.org/freeipa/ticket/3961) >>>>>> >>>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>>>> case-insensitively and krbcanonicalname case-sensitively, return >>>>>> krbcanonicalname when canonicalization is requested. >>>>>> >>>>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>>>> should be covered here (I remember that we should create >>>>>> krbcanonicalname when we add another aliases to krbprincipalname), >>>>>> so it >>>>>> would be nice if you could comment on this. >>>>>> >>>>>> 5.) write tests which cover all this stuff so that we don't shoot >>>>>> ourselves in the foot. >>>>>> >>>>>> I am not very well versed in Kerberos so I might get some of this >>>>>> stuff >>>>>> wrong. If that's the case please point me to the right direction. >>>>>> Also >>>>>> please write me some additional stuff which I have fogot and needs >>>>>> to be >>>>>> done. >>>>>> >>>>> >>>>> I think the summary is correct, the only thing we need to be >>>>> careful is >>>>> to keep handling entries that have only a single valued >>>>> krbprincipalname >>>>> correctly as that will happen in upgrade paths and potentially if >>>>> someone uses external tools. >>>>> >>>>> The tricky part for point 3 is to implement it *without* changing the >>>>> schema. KrbPrincipalName is case-sensitive, however I think we can >>>>> solve >>>>> the issue of "searching case-insensitively" by always lower-casing the >>>>> principal name components and always upper casing the realm part on >>>>> storage. If we always store a krbCanonicalName we get the "correct" >>>>> case >>>>> there anyway so out mucking with the krbPrincipalName case will not >>>>> be a >>>>> problem for any new entry. >>>> >>>> Or as Honza pointed out we can use case-insensitive search like this: >>>> (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return >>>> all variants of casing and reduce the need for fallback code. >>> >>> The principal name is not case insensitive, a search like that would >>> probably cause DS to do a full search through the krbPrincipalName >>> index, it might quickly become a performance issue. Before choosing a >>> method please create an install with a 10000 principals, and then >>> compare the speed of a few thousand search with exact matching case and >>> a few with specifying caseIgnoreMatch and see the difference. >>> >>> Simo. >> >> We will add index for caseIgnoreCaseIA5Match matching rule on >> krbPrincipalName and then the case insensitive match should be as >> quick as the case sensitive. >> >> Without the index it is indeed far slower. I've generated 10k users >> and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and >> the nonindexed one ~2 minutes. That's by two orders of magnitude worse. >> >> When we tried to add the index into DS we uncovered a bug in the way >> DS handles nsMatchingRule attributes. Thierry investigated it and is >> filling the ticket for DS right now. Thierry can you please send link? > > The ticket is https://fedorahosted.org/389/ticket/48270. > I think understand where the problem is but I have no fix yet. > David, when you said the unindexed search was slow, did you index > 'krbPrincipalName' but added a matching rule to your filter ? > I would like to also verify the fix against that perf hit. > > thanks > thierry I've tried these 3 searches: 1) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname:caseIgnoreIA5Match:=user1005000 at EXAMPLE.COM)" 2) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname:caseExactIA5Match:=user1005000 at EXAMPLE.COM)"' 3) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname=user1005000 at EXAMPLE.COM)" The first two was slow and only the last one was quick. >> >> Once it's fixed we should be good. >> >> David >> >>> >>>>> This *may* cause issues with upgrades though, so we may need fallback >>>>> code that searches with the case sent by the client if we determine >>>>> the >>>>> entry has no krbCanonicalName attribute (sign that it was created >>>>> before >>>>> we started adding krbCanonicalName and never "updated"). >>>>> >>>>> Note that we also need to think what will happen during and upgrade >>>>> when >>>>> some servers still use the current code and some servers will use the >>>>> new code. So I guess it would be nice if you could write down a table >>>>> with all possible forms a principal can be in on rows, and old/new >>>>> server states in columns, and mark what will happen for various >>>>> operations in each case. >>>>> >>>>> Simo. >>>>> >>> >>> >> >> > -- David Kupka From jcholast at redhat.com Mon Sep 7 16:01:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 7 Sep 2015 18:01:38 +0200 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55ED2156.10901@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> <55E4B5DD.5060206@redhat.com> <55E53265.4010400@redhat.com> <55E54B22.1050508@redhat.com> <55E67E39.3090907@redhat.com> <55E981E9.5050400@redhat.com> <55E9A4BF.8080106@redhat.com> <55E9B053.6080705@redhat.com> <55ED2156.10901@redhat.com> Message-ID: <55EDB4E2.2030101@redhat.com> On 7.9.2015 07:32, Jan Cholasta wrote: > On 4.9.2015 16:53, Petr Vobornik wrote: >> On 09/04/2015 04:03 PM, Endi Sukma Dewata wrote: >>> On 9/4/2015 6:35 AM, Martin Basti wrote: >>>> >>>> >>>> On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote: >>>>> On 9/1/2015 1:52 AM, Martin Basti wrote: >>>>>>>>>> The CA and KRA installation code has been modified to use LDAPI >>>>>>>>>> to create the CA and KRA agents directly in the CA and KRA >>>>>>>>>> database. This way it's no longer necessary to use the Directory >>>>>>>>>> Manager password or CA and KRA admin certificate. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5257 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> 1) Can you use following code instead of direct call of >>>>>>>>> ldap2.ldap2()? >>>>>>>>> >>>>>>>>> if not api.Backend.ldap2.is_connected(): >>>>>>>>> api.Backend.ldap2.connect(autobind=True) >>>>>>>>> >>>>>>>>> conn = api.Backend.ldap2 >>>>>>> >>>>>>> Why would you want to do that? The original code is fine, except the >>>>>>> connection check is not necessary (it is a new instance of ldap2, so >>>>>>> .isconnected() will always return False). >>>>>>> >>>>>>>> >>>>>>>> It's actually isconnected() instead of is_connected(), but even so, >>>>>>>> the >>>>>>>> proposed code doesn't work: >>>>>>>> >>>>>>>> ipa.ipapython.install.cli.install_tool(Server): DEBUG The >>>>>>>> ipa-server-install command failed, exception: TypeError: 'ldap2' >>>>>>>> object >>>>>>>> is not callable >>>>>>>> ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' >>>>>>>> object >>>>>>>> is not callable >>>>>>>> >>>>>>>>> 2) Patch needs rebase to master branch. >>>>>>>> >>>>>>>> The original patch does apply cleanly to master. Did you see a >>>>>>>> conflict? >>>>>> Sorry my bad. >>>>>> >>>>>> Martin^2 >>>>>>>> >>>>>>>>> 3) >>>>>>>>> + user_dn = DN(('uid', "ipara"), ('ou', 'People'), >>>>>>>>> self.basedn) >>>>>>>>> + conn.create( >>>>>>>>> + dn=user_dn, >>>>>>>>> >>>>>>>>> can you use add entry() instead of create()? We don't use native >>>>>>>>> python-ldap, but rather ipaldap methods >>>>>>>> >>>>>>>> It's actually calling the ldap2.create() defined in >>>>>>>> ipaserver/plugins/ldap2.py, which calls add_entry(). >>>>>>> >>>>>>> NACK. We don't use ldap2.create(). Use add_entry(). >>>>>>> >>>>>>>> >>>>>>>> So my original patch still stands. >>>>> >>>>> New patch attached. >>>>> >>>> ACK, but IMO that comments is not necessary and I would like to push >>>> the >>>> patch without it. >>>> >>>> Martin^2 >>> >>> It is necessary if we don't want people to use it. Otherwise someone >>> could make the same mistake. Or better yet, just remove the method. >>> >> >> + >> + NOTE: Do not use this method. >> >> I agree that the comment should not be in this patch - it is not >> relevant to vaults. >> >> The comment or a removal of the method(if it is really useless) should >> be in a different patch. If comment is the way than please also add why >> it should not be used. > > The method was intended to be used with frontend objects, but they never > happened in IPA, so it was left unused (instead we have no clean > interface between frontend and backend and call backend-specific methods > ad-hoc, what a great design /sarcasm). I personally would like to revive > the concept, so I would not remove the methods. I don't think a comment > is necessary either, because up until now, nobody tried to use the method. > Pushed to: master: 72cfcfa0bd1e867537fcc788512e5fca20708b83 ipa-4-2: 3973da56d334040d9fee88d52c38265066debd56 -- Jan Cholasta From simo at redhat.com Mon Sep 7 19:47:44 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Sep 2015 15:47:44 -0400 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <55ED3AD2.4000400@redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> <1441196867.28131.159.camel@willson.usersys.redhat.com> <55E85338.1040805@redhat.com> <55E97741.3060704@redhat.com> <55ED3AD2.4000400@redhat.com> Message-ID: <1441655264.3048.116.camel@willson.usersys.redhat.com> On Mon, 2015-09-07 at 09:20 +0200, David Kupka wrote: > On 04/09/15 12:49, thierry bordaz wrote: > > On 09/03/2015 04:03 PM, David Kupka wrote: > >> On 02/09/15 14:27, Simo Sorce wrote: > >>> On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: > >>>> On 01/09/15 16:53, Simo Sorce wrote: > >>>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: > >>>>>> Hi list, > >>>>>> > >>>>>> I own the following ticket > >>>>>> https://fedorahosted.org/freeipa/ticket/3864 > >>>>>> and I would like to clarify what needs to be done in order to make > >>>>>> IPA > >>>>>> to fully support multiple aliases per entry. > >>>>>> > >>>>>> So far I have identified these task based on the ticket comments and > >>>>>> discussion with Simo way back in the past: > >>>>>> > >>>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is > >>>>>> not used in the new code. > >>>>>> > >>>>>> 2.) fix ACIs that do not permit setting multiple values of > >>>>>> 'krbPrincipalName' attribute per entry (see > >>>>>> https://fedorahosted.org/freeipa/ticket/3961) > >>>>>> > >>>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and > >>>>>> 'ipadb_find_principal' functions) to correctly perform lookup of > >>>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname > >>>>>> case-insensitively and krbcanonicalname case-sensitively, return > >>>>>> krbcanonicalname when canonicalization is requested. > >>>>>> > >>>>>> 4.) Modify KDB backend and IPA framework to handle creation of both > >>>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases > >>>>>> should be covered here (I remember that we should create > >>>>>> krbcanonicalname when we add another aliases to krbprincipalname), > >>>>>> so it > >>>>>> would be nice if you could comment on this. > >>>>>> > >>>>>> 5.) write tests which cover all this stuff so that we don't shoot > >>>>>> ourselves in the foot. > >>>>>> > >>>>>> I am not very well versed in Kerberos so I might get some of this > >>>>>> stuff > >>>>>> wrong. If that's the case please point me to the right direction. > >>>>>> Also > >>>>>> please write me some additional stuff which I have fogot and needs > >>>>>> to be > >>>>>> done. > >>>>>> > >>>>> > >>>>> I think the summary is correct, the only thing we need to be > >>>>> careful is > >>>>> to keep handling entries that have only a single valued > >>>>> krbprincipalname > >>>>> correctly as that will happen in upgrade paths and potentially if > >>>>> someone uses external tools. > >>>>> > >>>>> The tricky part for point 3 is to implement it *without* changing the > >>>>> schema. KrbPrincipalName is case-sensitive, however I think we can > >>>>> solve > >>>>> the issue of "searching case-insensitively" by always lower-casing the > >>>>> principal name components and always upper casing the realm part on > >>>>> storage. If we always store a krbCanonicalName we get the "correct" > >>>>> case > >>>>> there anyway so out mucking with the krbPrincipalName case will not > >>>>> be a > >>>>> problem for any new entry. > >>>> > >>>> Or as Honza pointed out we can use case-insensitive search like this: > >>>> (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return > >>>> all variants of casing and reduce the need for fallback code. > >>> > >>> The principal name is not case insensitive, a search like that would > >>> probably cause DS to do a full search through the krbPrincipalName > >>> index, it might quickly become a performance issue. Before choosing a > >>> method please create an install with a 10000 principals, and then > >>> compare the speed of a few thousand search with exact matching case and > >>> a few with specifying caseIgnoreMatch and see the difference. > >>> > >>> Simo. > >> > >> We will add index for caseIgnoreCaseIA5Match matching rule on > >> krbPrincipalName and then the case insensitive match should be as > >> quick as the case sensitive. > >> > >> Without the index it is indeed far slower. I've generated 10k users > >> and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and > >> the nonindexed one ~2 minutes. That's by two orders of magnitude worse. > >> > >> When we tried to add the index into DS we uncovered a bug in the way > >> DS handles nsMatchingRule attributes. Thierry investigated it and is > >> filling the ticket for DS right now. Thierry can you please send link? > > > > The ticket is https://fedorahosted.org/389/ticket/48270. > > I think understand where the problem is but I have no fix yet. > > David, when you said the unindexed search was slow, did you index > > 'krbPrincipalName' but added a matching rule to your filter ? > > I would like to also verify the fix against that perf hit. > > > > thanks > > thierry > > I've tried these 3 searches: > > 1) ldapsearch -h localhost -D "cn=Directory Manager" -b > cn=users,cn=accounts,dc=example,dc=com -w freeipa8 > "(krbprincipalname:caseIgnoreIA5Match:=user1005000 at EXAMPLE.COM)" > > 2) ldapsearch -h localhost -D "cn=Directory Manager" -b > cn=users,cn=accounts,dc=example,dc=com -w freeipa8 > "(krbprincipalname:caseExactIA5Match:=user1005000 at EXAMPLE.COM)"' > > 3) ldapsearch -h localhost -D "cn=Directory Manager" -b > cn=users,cn=accounts,dc=example,dc=com -w freeipa8 > "(krbprincipalname=user1005000 at EXAMPLE.COM)" > > The first two was slow and only the last one was quick. Sounds like DS do a full search instead of indexed searches when you specify a matching rule ? We should either make sure DS can use indexed searches in this case or go with the plan I proposed earlier. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Tue Sep 8 06:45:21 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 08 Sep 2015 08:45:21 +0200 Subject: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA In-Reply-To: <1441655264.3048.116.camel@willson.usersys.redhat.com> References: <55E5B8BF.4080101@redhat.com> <1441119222.28131.125.camel@willson.usersys.redhat.com> <55E69314.9070804@redhat.com> <1441196867.28131.159.camel@willson.usersys.redhat.com> <55E85338.1040805@redhat.com> <55E97741.3060704@redhat.com> <55ED3AD2.4000400@redhat.com> <1441655264.3048.116.camel@willson.usersys.redhat.com> Message-ID: <55EE8401.3040305@redhat.com> On 09/07/2015 09:47 PM, Simo Sorce wrote: > On Mon, 2015-09-07 at 09:20 +0200, David Kupka wrote: >> On 04/09/15 12:49, thierry bordaz wrote: >>> On 09/03/2015 04:03 PM, David Kupka wrote: >>>> On 02/09/15 14:27, Simo Sorce wrote: >>>>> On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: >>>>>> On 01/09/15 16:53, Simo Sorce wrote: >>>>>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>>>>>> Hi list, >>>>>>>> >>>>>>>> I own the following ticket >>>>>>>> https://fedorahosted.org/freeipa/ticket/3864 >>>>>>>> and I would like to clarify what needs to be done in order to make >>>>>>>> IPA >>>>>>>> to fully support multiple aliases per entry. >>>>>>>> >>>>>>>> So far I have identified these task based on the ticket comments and >>>>>>>> discussion with Simo way back in the past: >>>>>>>> >>>>>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>>>>>> not used in the new code. >>>>>>>> >>>>>>>> 2.) fix ACIs that do not permit setting multiple values of >>>>>>>> 'krbPrincipalName' attribute per entry (see >>>>>>>> https://fedorahosted.org/freeipa/ticket/3961) >>>>>>>> >>>>>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>>>>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>>>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>>>>>> case-insensitively and krbcanonicalname case-sensitively, return >>>>>>>> krbcanonicalname when canonicalization is requested. >>>>>>>> >>>>>>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>>>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>>>>>> should be covered here (I remember that we should create >>>>>>>> krbcanonicalname when we add another aliases to krbprincipalname), >>>>>>>> so it >>>>>>>> would be nice if you could comment on this. >>>>>>>> >>>>>>>> 5.) write tests which cover all this stuff so that we don't shoot >>>>>>>> ourselves in the foot. >>>>>>>> >>>>>>>> I am not very well versed in Kerberos so I might get some of this >>>>>>>> stuff >>>>>>>> wrong. If that's the case please point me to the right direction. >>>>>>>> Also >>>>>>>> please write me some additional stuff which I have fogot and needs >>>>>>>> to be >>>>>>>> done. >>>>>>>> >>>>>>> I think the summary is correct, the only thing we need to be >>>>>>> careful is >>>>>>> to keep handling entries that have only a single valued >>>>>>> krbprincipalname >>>>>>> correctly as that will happen in upgrade paths and potentially if >>>>>>> someone uses external tools. >>>>>>> >>>>>>> The tricky part for point 3 is to implement it *without* changing the >>>>>>> schema. KrbPrincipalName is case-sensitive, however I think we can >>>>>>> solve >>>>>>> the issue of "searching case-insensitively" by always lower-casing the >>>>>>> principal name components and always upper casing the realm part on >>>>>>> storage. If we always store a krbCanonicalName we get the "correct" >>>>>>> case >>>>>>> there anyway so out mucking with the krbPrincipalName case will not >>>>>>> be a >>>>>>> problem for any new entry. >>>>>> Or as Honza pointed out we can use case-insensitive search like this: >>>>>> (krbPrincipalName:caseIgnoreMatch:=ADMIN at EXAMPLE.COM). This will return >>>>>> all variants of casing and reduce the need for fallback code. >>>>> The principal name is not case insensitive, a search like that would >>>>> probably cause DS to do a full search through the krbPrincipalName >>>>> index, it might quickly become a performance issue. Before choosing a >>>>> method please create an install with a 10000 principals, and then >>>>> compare the speed of a few thousand search with exact matching case and >>>>> a few with specifying caseIgnoreMatch and see the difference. >>>>> >>>>> Simo. >>>> We will add index for caseIgnoreCaseIA5Match matching rule on >>>> krbPrincipalName and then the case insensitive match should be as >>>> quick as the case sensitive. >>>> >>>> Without the index it is indeed far slower. I've generated 10k users >>>> and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and >>>> the nonindexed one ~2 minutes. That's by two orders of magnitude worse. >>>> >>>> When we tried to add the index into DS we uncovered a bug in the way >>>> DS handles nsMatchingRule attributes. Thierry investigated it and is >>>> filling the ticket for DS right now. Thierry can you please send link? >>> The ticket is https://fedorahosted.org/389/ticket/48270. >>> I think understand where the problem is but I have no fix yet. >>> David, when you said the unindexed search was slow, did you index >>> 'krbPrincipalName' but added a matching rule to your filter ? >>> I would like to also verify the fix against that perf hit. >>> >>> thanks >>> thierry >> I've tried these 3 searches: >> >> 1) ldapsearch -h localhost -D "cn=Directory Manager" -b >> cn=users,cn=accounts,dc=example,dc=com -w freeipa8 >> "(krbprincipalname:caseIgnoreIA5Match:=user1005000 at EXAMPLE.COM)" >> >> 2) ldapsearch -h localhost -D "cn=Directory Manager" -b >> cn=users,cn=accounts,dc=example,dc=com -w freeipa8 >> "(krbprincipalname:caseExactIA5Match:=user1005000 at EXAMPLE.COM)"' >> >> 3) ldapsearch -h localhost -D "cn=Directory Manager" -b >> cn=users,cn=accounts,dc=example,dc=com -w freeipa8 >> "(krbprincipalname=user1005000 at EXAMPLE.COM)" >> >> The first two was slow and only the last one was quick. > Sounds like DS do a full search instead of indexed searches when you > specify a matching rule ? > We should either make sure DS can use indexed searches in this case or > go with the plan I proposed earlier. > > Simo. > Yes that is correct, those searches with matching rule are unindexed. I think the reason is #48270 that reject the configuration of the index with such MR. Once it will be fixed it should do an indexed search with the MR specified in the filter. Storing lower case/upper case principal/realm will work with new database but if we have to handle old database we should fix DS. thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Sep 8 10:46:57 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Sep 2015 13:46:57 +0300 Subject: [Freeipa-devel] Slow email responses this week from FreeIPA/SSSD teams at Red Hat Message-ID: <20150908104657.GU22106@redhat.com> Hi everyone! We have a gathering of Red Hat members of FreeIPA and SSSD teams in Brno, Czech Republic this week with a lot of design and discussion meetings. Naturally, we try to lock ourselves down in dungeons without wifi access and without laptops (not!) to avoid distractions and great weather of early autumn in Southern Moravia. This has unfortunate effect of reducing our availability on the mailing lists and IRC channels. We are apologizing in case you have something urgent to help with and hope that someone will be able to help as time permits. Once we re-emerge from the dungeons of Red Hat Brno offices, there will be wiki updates and blog posts about what is discussed and reflected on. At least, I have plans to do so on a number of topics. On a brighter note, FreeIPA 4.2.1 is on its way to Fedora 23 repositories. It is currently pending the acceptance to updates-testing repository so we most likely miss Fedora 23 beta release but it gives us chances to test FreeIPA 4.1 to 4.2.1 upgrade path before final Fedora 23 release later this autumn. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15284 Once packages are in the repositories, we'll send a proper announcement of FreeIPA 4.2.1 release. -- / Alexander Bokovoy From dkupka at redhat.com Tue Sep 8 14:00:13 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 8 Sep 2015 16:00:13 +0200 Subject: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55E015DA.902@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> <55DC2951.60508@redhat.com> <55DC61EB.4050205@redhat.com> <55DF0117.3010800@redhat.com> <55E015DA.902@redhat.com> Message-ID: <55EEE9ED.4030209@redhat.com> On 28/08/15 10:03, Petr Spacek wrote: > On 27.8.2015 14:22, David Kupka wrote: >> @@ -2101,11 +2101,25 @@ class DNSZoneBase(LDAPObject): >> >> class DNSZoneBase_add(LDAPCreate): >> >> + takes_options = LDAPCreate.takes_options + ( >> + Flag('force', >> + label=_('Force'), >> + doc=_('Force DNS zone creation.') >> + ), >> + Flag('skip_overlap_check', >> + doc=_('Force DNS zone creation even if it will overlap with ' >> + 'existing zone.') >> + ), >> + ) >> + >> has_output_params = LDAPCreate.has_output_params + dnszone_output_params >> >> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): >> assert isinstance(dn, DN) >> >> + if options['force']: >> + options['skip_overlap_check'] = True >> + >> try: >> entry = ldap.get_entry(dn) >> except errors.NotFound: >> @@ -2120,6 +2134,12 @@ class DNSZoneBase_add(LDAPCreate): >> >> entry_attrs['idnszoneactive'] = 'TRUE' >> >> + if not options['skip_overlap_check']: >> + try: >> + check_zone_overlap(keys[-1]) >> + except RuntimeError as e: >> + raise errors.InvocationError(e.message) >> + >> return dn >> >> >> @@ -2673,9 +2693,9 @@ class dnszone_add(DNSZoneBase_add): >> __doc__ = _('Create new DNS zone (SOA record).') >> >> takes_options = DNSZoneBase_add.takes_options + ( >> - Flag('force', >> - label=_('Force'), >> - doc=_('Force DNS zone creation even if nameserver is not resolvable.'), >> + Flag('skip_nameserver_check', >> + doc=_('Force DNS zone creation even if nameserver is not ' >> + 'resolvable.') >> ), >> >> # Deprecated >> @@ -2699,6 +2719,9 @@ class dnszone_add(DNSZoneBase_add): >> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): >> assert isinstance(dn, DN) >> >> + if options['force']: >> + options['skip_nameserver_check'] = True > > Why is it in DNSZoneBase_add.pre_callback? > > Shouldn't the equation force = (skip_nameserver_check + skip_nameserver_check) > be handled in parameter parsing & validation? (Again, I do not know the IPA > framework :-)) > IIUC it is usually handled in pre_callback because framework does not provide any other mechanism preprocess and validate options. >> + >> dn = super(dnszone_add, self).pre_callback( >> ldap, dn, entry_attrs, attrs_list, *keys, **options) >> >> @@ -2713,7 +2736,7 @@ class dnszone_add(DNSZoneBase_add): >> error=_("Nameserver for reverse zone cannot be a relative DNS name")) >> >> # verify if user specified server is resolvable >> - if not options['force']: >> + if not options['skip_nameserver_check']: >> check_ns_rec_resolvable(keys[0], entry_attrs['idnssoamname']) >> # show warning about --name-server option >> context.show_warning_nameserver_option = True >> diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py >> index d959bb369d946217acd080e78483cc9013dda4c7..18f477d4fb6620090b7073689c8df51b65a8307a 100644 >> --- a/ipapython/ipautil.py >> +++ b/ipapython/ipautil.py >> @@ -924,6 +924,20 @@ def host_exists(host): >> else: >> return True >> >> +def check_zone_overlap(zone): >> + if resolver.zone_for_name(zone) == zone: >> + try: >> + ns = [ans.to_text() for ans in resolver.query(zone, 'NS')] >> + except DNSException as e: >> + root_logger.debug("Failed to resolve nameserver(s) for domain" >> + " {0}: {1}".format(zone, e)) >> + ns = [] >> + >> + msg = u"DNS zone {0} already exists".format(zone) > > Nitpick: I would say "already exists in DNS" to make it absolutely clear. Just > 'already exists' might be confusing because ipa dnszone-show will say that the > zone does not exist ... Ok, will update this. > >> + if ns: >> + msg += u" and is handled by server(s): {0}".format(', '.join(ns)) >> + raise RuntimeError(msg) >> + >> def get_ipa_basedn(conn): >> """ >> Get base DN of IPA suffix in given LDAP server. > -- David Kupka From dkupka at redhat.com Tue Sep 8 14:30:06 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 8 Sep 2015 16:30:06 +0200 Subject: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55E047BE.5000507@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> <55DC2951.60508@redhat.com> <55DC61EB.4050205@redhat.com> <55DF0117.3010800@redhat.com> <55E015DA.902@redhat.com> <55E047BE.5000507@redhat.com> Message-ID: <55EEF0EE.2020208@redhat.com> On 28/08/15 13:36, Martin Basti wrote: > > > On 08/28/2015 10:03 AM, Petr Spacek wrote: >> On 27.8.2015 14:22, David Kupka wrote: >>> @@ -2101,11 +2101,25 @@ class DNSZoneBase(LDAPObject): >>> class DNSZoneBase_add(LDAPCreate): >>> + takes_options = LDAPCreate.takes_options + ( >>> + Flag('force', >>> + label=_('Force'), >>> + doc=_('Force DNS zone creation.') >>> + ), >>> + Flag('skip_overlap_check', >>> + doc=_('Force DNS zone creation even if it will overlap >>> with ' >>> + 'existing zone.') >>> + ), >>> + ) >>> + >>> has_output_params = LDAPCreate.has_output_params + >>> dnszone_output_params >>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, >>> *keys, **options): >>> assert isinstance(dn, DN) >>> + if options['force']: >>> + options['skip_overlap_check'] = True >>> + >>> try: >>> entry = ldap.get_entry(dn) >>> except errors.NotFound: >>> @@ -2120,6 +2134,12 @@ class DNSZoneBase_add(LDAPCreate): >>> entry_attrs['idnszoneactive'] = 'TRUE' >>> + if not options['skip_overlap_check']: >>> + try: >>> + check_zone_overlap(keys[-1]) >>> + except RuntimeError as e: >>> + raise errors.InvocationError(e.message) >>> + >>> return dn >>> @@ -2673,9 +2693,9 @@ class dnszone_add(DNSZoneBase_add): >>> __doc__ = _('Create new DNS zone (SOA record).') >>> takes_options = DNSZoneBase_add.takes_options + ( >>> - Flag('force', >>> - label=_('Force'), >>> - doc=_('Force DNS zone creation even if nameserver is >>> not resolvable.'), >>> + Flag('skip_nameserver_check', >>> + doc=_('Force DNS zone creation even if nameserver is not ' >>> + 'resolvable.') >>> ), >>> # Deprecated >>> @@ -2699,6 +2719,9 @@ class dnszone_add(DNSZoneBase_add): >>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, >>> *keys, **options): >>> assert isinstance(dn, DN) >>> + if options['force']: >>> + options['skip_nameserver_check'] = True >> Why is it in DNSZoneBase_add.pre_callback? >> >> Shouldn't the equation force = (skip_nameserver_check + >> skip_nameserver_check) >> be handled in parameter parsing & validation? (Again, I do not know >> the IPA >> framework :-)) >> >>> + >>> dn = super(dnszone_add, self).pre_callback( >>> ldap, dn, entry_attrs, attrs_list, *keys, **options) >>> @@ -2713,7 +2736,7 @@ class dnszone_add(DNSZoneBase_add): >>> error=_("Nameserver for reverse zone cannot be >>> a relative DNS name")) >>> # verify if user specified server is resolvable >>> - if not options['force']: >>> + if not options['skip_nameserver_check']: >>> check_ns_rec_resolvable(keys[0], >>> entry_attrs['idnssoamname']) >>> # show warning about --name-server option >>> context.show_warning_nameserver_option = True >>> diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py >>> index >>> d959bb369d946217acd080e78483cc9013dda4c7..18f477d4fb6620090b7073689c8df51b65a8307a >>> 100644 >>> --- a/ipapython/ipautil.py >>> +++ b/ipapython/ipautil.py >>> @@ -924,6 +924,20 @@ def host_exists(host): >>> else: >>> return True >>> +def check_zone_overlap(zone): >>> + if resolver.zone_for_name(zone) == zone: >>> + try: >>> + ns = [ans.to_text() for ans in resolver.query(zone, 'NS')] >>> + except DNSException as e: >>> + root_logger.debug("Failed to resolve nameserver(s) for >>> domain" >>> + " {0}: {1}".format(zone, e)) >>> + ns = [] >>> + >>> + msg = u"DNS zone {0} already exists".format(zone) >> Nitpick: I would say "already exists in DNS" to make it absolutely >> clear. Just >> 'already exists' might be confusing because ipa dnszone-show will say >> that the >> zone does not exist ... >> >>> + if ns: >>> + msg += u" and is handled by server(s): {0}".format(', >>> '.join(ns)) >>> + raise RuntimeError(msg) >>> + >>> def get_ipa_basedn(conn): >>> """ >>> Get base DN of IPA suffix in given LDAP server. > 0064 > NACK > > ipa-replica-install should have the --skip-overlap-check too, because > any replica can be the first DNS server. Thanks for the catch, added. > > 0064+0058 > Can be the options --allow-zone-overlap and --skip-overlap-check merged > into an one name, to have just one name for same thing? > Each option has bit different behavior: The '--skip-overlap-check' option in API call prevent the check to be performed and thus no error or warning is raised. This is the way '--force' option was originally working. The '--allow-zone-overlap' options in installers do not skip the check but change the error to warning instead and let the installation continue. If you think that this can confuse users we need to change the names or even the logic. Updated patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0064.2-dns-Check-if-domain-already-exists.patch Type: text/x-patch Size: 4940 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0058.4-dns-do-not-add-forward-zone-if-it-is-already-resolva.patch Type: text/x-patch Size: 7584 bytes Desc: not available URL: From mbasti at redhat.com Tue Sep 8 15:45:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 8 Sep 2015 17:45:16 +0200 Subject: [Freeipa-devel] [PATCH 0311] tests: fix vault tests Message-ID: <55EF028C.2040605@redhat.com> Attached patch fixes vault tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0311-FIX-vault-tests.patch Type: text/x-patch Size: 9367 bytes Desc: not available URL: From pvoborni at redhat.com Tue Sep 8 21:06:30 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 8 Sep 2015 23:06:30 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55E8488E.5070308@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> <55E68898.1000300@redhat.com> <55E8488E.5070308@redhat.com> Message-ID: <55EF4DD6.5010706@redhat.com> On 09/03/2015 03:18 PM, Jan Cholasta wrote: > On 2.9.2015 07:26, Endi Sukma Dewata wrote: >> On 9/1/2015 10:22 AM, Simo Sorce wrote: >>> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >>>> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>>>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>>>> adds commands: >>>>>>>> * vaultcontainer-show [--service |--user ] >>>>>>>> * vaultcontainer-add-owner >>>>>>>> [--service |--user ] >>>>>>>> [--users ] [--groups ] [--services >>>>>>>> ] >>>>>>>> * vaultcontainer-remove-owner >>>>>>>> [--service |--user ] >>>>>>>> [--users ] [--groups ] [--services >>>>>>>> ] >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>>>> >>>>>>>> Use cases: >>>>>>>> 1. When user/service is deleted, associated vault container looses >>>>>>>> owner. There was no API command to set the owner. >>>>>>>> 2. Change owner of container by admin to manage access. >>>>>>>> >>>>>>>> Show command was added to show current owners. >>>>>>>> >>>>>>>> Find command was not added, should it be? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> There is also a design for vault container ownership handling >>>>>>> created by >>>>>>> Endi - it's for future Vault 2.0. >>>>>>> >>>>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>>>> >>>>>>> >>>>>>> >>>>>>> This patch has a different API than the proposed - different way of >>>>>>> specifying the container. The design page uses path e.g. >>>>>>> /users/foobar. >>>>>>> This patch uses the same way as vaults e.g. --user=foobar. This >>>>>>> means >>>>>>> that the implementation in this patch cannot manage ownership of >>>>>>> parent >>>>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>>>> >>>>>>> Do we want to go with this approach in 4.2? >>>>>>> >>>>>>> Attaching also new path which removes setting of owner which doesn't >>>>>>> exist so that integrity is OK and that it is consistent with >>>>>>> removing of >>>>>>> user. >>>>>>> >>>>>>> Updated patch attached - output fix. >>>>>> >>>>>> We had a long discussion about this with Petr and we think the best >>>>>> approach is as follows: >>>>>> >>>>>> * Add new "Vault administrators" privilege. Vault >>>>>> administrators will >>>>>> have unrestricted access to vaults and vault containers, including >>>>>> the >>>>>> power to add/remove owners of vaults and vault containers. >>>>>> >>>>>> * Remove the ability of vault owners to add/remove other vault >>>>>> owners. If vault owner needs to be changed, vault administrator >>>>>> has to >>>>>> do it. Note that vault owners will still have the ability to >>>>>> add/remove >>>>>> vault members. >>>>>> >>>>>> * When adding new vault container, set owner to the current >>>>>> user. If >>>>>> vault container owner needs to be changed, vault administrator has >>>>>> to do >>>>>> it. >>>>>> >>>>>> * Allow adding vaults and vault containers only if the owner is >>>>>> set >>>>>> to the current user. >>>>>> >>>>>> * Introduce commands to modify vault container owner and to >>>>>> delete >>>>>> vault container, so the administrator has a choice between assigning >>>>>> ownership or deleting an unowned container. >>>>> >>>>> Also: >>>>> >>>>> * Control access to vault data using an ipaProtectedOperation ACI. >>>>> Users which have read access to "ipaProtectedOperation;accessKRA" on a >>>>> vault can retrieve data from the vault and users which have write >>>>> access >>>>> to "ipaProtectedOperation;accessKRA" on a vault can archive data in >>>>> the >>>>> vault. >>>>> >>>>> Honza >>>>> >>>> >>>> +1 >>>> >>>> CCing Simo and Endi to check the proposal. >>>> >>>> And Scott (related to #5216, #5215) >>> >>> Sounds reasonable to me. >>> I can see that allowing owners to hand over vaults w/o admin >>> intervention may have some appeal in some use cases, but I also see it >>> can bring downsides with it, so all in all I think I agree with the >>> above points. >>> >>> Simo. >>> >> >> Not a total objection, but if many people in unrelated groups are using >> vaults, and they are sharing the vaults only with members of each group, >> having to ask a Vault Administrator for each ownership change sounds a >> bit cumbersome. Since the Vault Adminstrator will have access to all >> vaults in all groups, only a small number of people can be trusted to >> hold that role. If there are many ownership changes the Vault >> Administrator will have to handle all those requests, and the vault >> users may have to wait until the change is completed. >> >> If owners are allowed to add others as owners, the vaults will be pretty >> much maintenance free to the admin. > > Owners can still manage members, which is IMO good enough for sharing a > vault with other users. > >> >> Regardless, please update the wiki page to describe the new behavior >> when it's implemented: >> http://www.freeipa.org/page/V4/Password_Vault_1.1 > > Sure. > > I have updated and rebased Petr's patch 916. > > Patch 488 obsoletes Petr's patch 918. > > Patch for vault data access control is not included, because I was not > able to make GER work correctly with "ipaProtectedOperation;accessKRA". > I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question (#4). 1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a blocker. [pvoborni at vm-063 ~]$ ipa vaultcontainer-del --user=fbar -------------------------- Deleted vault container "" -------------------------- 2. Invalid description of vaultcontainer-show "Display information about a vault." 3. Something which needs to be fixed: Setting password for first vault without a vault container fails(here run as vault admin but the same issue is present when it's run as the user). [pvoborni at vm-063 ~]$ ipa vault-add f1 --user=fbar New password: Verify password: ipa: ERROR: Invalid credentials [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar --------------- 1 vault matched --------------- Vault name: f1 Type: symmetric Vault user: fbar ---------------------------- Number of entries returned 1 ---------------------------- Second works: [pvoborni at vm-063 ~]$ ipa vault-add f2 --user=fbar New password: Verify password: ** Passwords do not match! ** New password: Verify password: ---------------- Added vault "f2" ---------------- Vault name: f2 Type: symmetric Salt: w4tnrjW/Ra2jGS8lI6Frfg== Owner users: va Vault user: fbar [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar ---------------- 2 vaults matched ---------------- Vault name: f1 Type: symmetric Vault user: fbar Vault name: f2 Type: symmetric Vault user: fbar ---------------------------- Number of entries returned 2 ---------------------------- 4. Q: Should vault container owner delete all its vault? As fbar when there is a vault without fbar as owner [root at vm-063 pvoborni]# ipa vaultcontainer-del ipa: ERROR: Not allowed on non-leaf entry when fbar is added as owner to all vaults [root at vm-063 pvoborni]# ipa vaultcontainer-del -------------------------- Deleted vault container "" -------------------------- [root at vm-063 pvoborni]# ipa vault-add f1 New password: Verify password: ipa: ERROR: Invalid credentials [root at vm-063 pvoborni]# ipa vault-del f1 ------------------ Deleted vault "f1" ------------------ [root at vm-063 pvoborni]# ipa vault-add f1 New password: Verify password: ---------------- Added vault "f1" ---------------- Vault name: f1 Type: symmetric Salt: bkHxRIipkaeX+H/fOnZdBw== Owner users: fbar Vault user: fbar -- Petr Vobornik From jcholast at redhat.com Wed Sep 9 06:21:51 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 9 Sep 2015 08:21:51 +0200 Subject: [Freeipa-devel] [PATCH 0063] fix crash during standalone CA installation on CA-less master In-Reply-To: <55E99C36.4050106@redhat.com> References: <55E99C36.4050106@redhat.com> Message-ID: <55EFCFFF.9020501@redhat.com> Hi, On 4.9.2015 15:27, Martin Babinsky wrote: > A quick fix for https://fedorahosted.org/freeipa/ticket/5288 > ACK. Pushed to: master: ff7969852d0469535a6b7639cde52ca68bb271ec ipa-4-2: eef88c5a5c2435d9dadc2c9f62b7054de9a2be4c Honza -- Jan Cholasta From andreas.calminder at nordnet.se Wed Sep 9 08:35:05 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Wed, 9 Sep 2015 10:35:05 +0200 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory Message-ID: <55EFEF39.8080808@nordnet.se> Hi, I've asked in #freeipa on freenode but to no avail, figured I'll ask here as well, since I think I've actually hit a bug or (quite) possibly I've done something moronic configuration/migration -wise. I've got an existing FreeIPA 3.0.0 environment running with a fully functioning winsync agreement and passsync service with the windows environments active directory, I'm trying to migrate the 3.0.0 environments users into a freshly installed 4.1 (rhel7) environment, after migration I setup a winsync agreement and make it bi-directional (one-way sync from windows) everything seems to be working alright until I delete a migrated user from the Active Directory, after the winsync picks up on the change it'll break and suggests a re-initialize. After the re-initialization the agreement seems to be fine, however the deleted user are still present in the ipa 4.1 environment and cannot be deleted. The webgui and ipa cli says: ipauser1: user not found. ipa user-find ipauser1 finds the user and it's visible in the ui. Anyone had the same problem or anything similar or any pointers on where to start looking? Regards, Andreas From andreas.calminder at nordnet.se Wed Sep 9 08:50:55 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Wed, 9 Sep 2015 10:50:55 +0200 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55EFEF39.8080808@nordnet.se> References: <55EFEF39.8080808@nordnet.se> Message-ID: <55EFF2EF.8020709@nordnet.se> Forgot to write that deleting users in active directory not migrated with the migrate-ds command works fine, it's only migrated users present in the ad that breaks the winsync agreement on deletion. On 09/09/2015 10:35 AM, Andreas Calminder wrote: > Hi, > I've asked in #freeipa on freenode but to no avail, figured I'll ask > here as well, since I think I've actually hit a bug or (quite) > possibly I've done something moronic configuration/migration -wise. > > I've got an existing FreeIPA 3.0.0 environment running with a fully > functioning winsync agreement and passsync service with the windows > environments active directory, I'm trying to migrate the 3.0.0 > environments users into a freshly installed 4.1 (rhel7) environment, > after migration I setup a winsync agreement and make it > bi-directional (one-way sync from windows) everything seems to be > working alright until I delete a migrated user from the Active > Directory, after the winsync picks up on the change it'll break and > suggests a re-initialize. After the re-initialization the agreement > seems to be fine, however the deleted user are still present in the > ipa 4.1 environment and cannot be deleted. The webgui and ipa cli > says: ipauser1: user not found. ipa user-find ipauser1 finds the user > and it's visible in the ui. > > Anyone had the same problem or anything similar or any pointers on > where to start looking? > > Regards, > Andreas > From jcholast at redhat.com Wed Sep 9 08:52:44 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 9 Sep 2015 10:52:44 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55EF4DD6.5010706@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> <55E68898.1000300@redhat.com> <55E8488E.5070308@redhat.com> <55EF4DD6.5010706@redhat.com> Message-ID: <55EFF35C.3050007@redhat.com> On 8.9.2015 23:06, Petr Vobornik wrote: > On 09/03/2015 03:18 PM, Jan Cholasta wrote: >> On 2.9.2015 07:26, Endi Sukma Dewata wrote: >>> On 9/1/2015 10:22 AM, Simo Sorce wrote: >>>> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >>>>> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>>>>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>>>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>>>>> adds commands: >>>>>>>>> * vaultcontainer-show [--service |--user ] >>>>>>>>> * vaultcontainer-add-owner >>>>>>>>> [--service |--user ] >>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>> ] >>>>>>>>> * vaultcontainer-remove-owner >>>>>>>>> [--service |--user ] >>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>> ] >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>>>>> >>>>>>>>> Use cases: >>>>>>>>> 1. When user/service is deleted, associated vault container looses >>>>>>>>> owner. There was no API command to set the owner. >>>>>>>>> 2. Change owner of container by admin to manage access. >>>>>>>>> >>>>>>>>> Show command was added to show current owners. >>>>>>>>> >>>>>>>>> Find command was not added, should it be? >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> There is also a design for vault container ownership handling >>>>>>>> created by >>>>>>>> Endi - it's for future Vault 2.0. >>>>>>>> >>>>>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This patch has a different API than the proposed - different way of >>>>>>>> specifying the container. The design page uses path e.g. >>>>>>>> /users/foobar. >>>>>>>> This patch uses the same way as vaults e.g. --user=foobar. This >>>>>>>> means >>>>>>>> that the implementation in this patch cannot manage ownership of >>>>>>>> parent >>>>>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>>>>> >>>>>>>> Do we want to go with this approach in 4.2? >>>>>>>> >>>>>>>> Attaching also new path which removes setting of owner which >>>>>>>> doesn't >>>>>>>> exist so that integrity is OK and that it is consistent with >>>>>>>> removing of >>>>>>>> user. >>>>>>>> >>>>>>>> Updated patch attached - output fix. >>>>>>> >>>>>>> We had a long discussion about this with Petr and we think the best >>>>>>> approach is as follows: >>>>>>> >>>>>>> * Add new "Vault administrators" privilege. Vault >>>>>>> administrators will >>>>>>> have unrestricted access to vaults and vault containers, including >>>>>>> the >>>>>>> power to add/remove owners of vaults and vault containers. >>>>>>> >>>>>>> * Remove the ability of vault owners to add/remove other vault >>>>>>> owners. If vault owner needs to be changed, vault administrator >>>>>>> has to >>>>>>> do it. Note that vault owners will still have the ability to >>>>>>> add/remove >>>>>>> vault members. >>>>>>> >>>>>>> * When adding new vault container, set owner to the current >>>>>>> user. If >>>>>>> vault container owner needs to be changed, vault administrator has >>>>>>> to do >>>>>>> it. >>>>>>> >>>>>>> * Allow adding vaults and vault containers only if the owner is >>>>>>> set >>>>>>> to the current user. >>>>>>> >>>>>>> * Introduce commands to modify vault container owner and to >>>>>>> delete >>>>>>> vault container, so the administrator has a choice between assigning >>>>>>> ownership or deleting an unowned container. >>>>>> >>>>>> Also: >>>>>> >>>>>> * Control access to vault data using an ipaProtectedOperation >>>>>> ACI. >>>>>> Users which have read access to "ipaProtectedOperation;accessKRA" >>>>>> on a >>>>>> vault can retrieve data from the vault and users which have write >>>>>> access >>>>>> to "ipaProtectedOperation;accessKRA" on a vault can archive data in >>>>>> the >>>>>> vault. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> +1 >>>>> >>>>> CCing Simo and Endi to check the proposal. >>>>> >>>>> And Scott (related to #5216, #5215) >>>> >>>> Sounds reasonable to me. >>>> I can see that allowing owners to hand over vaults w/o admin >>>> intervention may have some appeal in some use cases, but I also see it >>>> can bring downsides with it, so all in all I think I agree with the >>>> above points. >>>> >>>> Simo. >>>> >>> >>> Not a total objection, but if many people in unrelated groups are using >>> vaults, and they are sharing the vaults only with members of each group, >>> having to ask a Vault Administrator for each ownership change sounds a >>> bit cumbersome. Since the Vault Adminstrator will have access to all >>> vaults in all groups, only a small number of people can be trusted to >>> hold that role. If there are many ownership changes the Vault >>> Administrator will have to handle all those requests, and the vault >>> users may have to wait until the change is completed. >>> >>> If owners are allowed to add others as owners, the vaults will be pretty >>> much maintenance free to the admin. >> >> Owners can still manage members, which is IMO good enough for sharing a >> vault with other users. >> >>> >>> Regardless, please update the wiki page to describe the new behavior >>> when it's implemented: >>> http://www.freeipa.org/page/V4/Password_Vault_1.1 >> >> Sure. >> >> I have updated and rebased Petr's patch 916. >> >> Patch 488 obsoletes Petr's patch 918. >> >> Patch for vault data access control is not included, because I was not >> able to make GER work correctly with "ipaProtectedOperation;accessKRA". >> > > I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question > (#4). > > 1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a > blocker. > > [pvoborni at vm-063 ~]$ ipa vaultcontainer-del --user=fbar > -------------------------- > Deleted vault container "" > -------------------------- Fixed. > > > 2. Invalid description of vaultcontainer-show > "Display information about a vault." Fixed. > > 3. Something which needs to be fixed: > > Setting password for first vault without a vault container fails(here > run as vault admin but the same issue is present when it's run as the > user). > > [pvoborni at vm-063 ~]$ ipa vault-add f1 --user=fbar > New password: > Verify password: > ipa: ERROR: Invalid credentials > [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar > --------------- > 1 vault matched > --------------- > Vault name: f1 > Type: symmetric > Vault user: fbar > ---------------------------- > Number of entries returned 1 > ---------------------------- Works for me. Are you testing on master or ipa-4-2? > > Second works: > > [pvoborni at vm-063 ~]$ ipa vault-add f2 --user=fbar > New password: > Verify password: > ** Passwords do not match! ** > New password: > Verify password: > ---------------- > Added vault "f2" > ---------------- > Vault name: f2 > Type: symmetric > Salt: w4tnrjW/Ra2jGS8lI6Frfg== > Owner users: va > Vault user: fbar > > > > [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar > ---------------- > 2 vaults matched > ---------------- > Vault name: f1 > Type: symmetric > Vault user: fbar > > Vault name: f2 > Type: symmetric > Vault user: fbar > ---------------------------- > Number of entries returned 2 > ---------------------------- > > > 4. Q: Should vault container owner delete all its vault? I don't know, should it? IMO it shouldn't, at least not by default. > > As fbar when there is a vault without fbar as owner > > [root at vm-063 pvoborni]# ipa vaultcontainer-del > ipa: ERROR: Not allowed on non-leaf entry > > when fbar is added as owner to all vaults > > [root at vm-063 pvoborni]# ipa vaultcontainer-del > -------------------------- > Deleted vault container "" > -------------------------- > [root at vm-063 pvoborni]# ipa vault-add f1 > New password: > Verify password: > ipa: ERROR: Invalid credentials > [root at vm-063 pvoborni]# ipa vault-del f1 > ------------------ > Deleted vault "f1" > ------------------ > [root at vm-063 pvoborni]# ipa vault-add f1 > New password: > Verify password: > ---------------- > Added vault "f1" > ---------------- > Vault name: f1 > Type: symmetric > Salt: bkHxRIipkaeX+H/fOnZdBw== > Owner users: fbar > Vault user: fbar > -- Jan Cholasta From mbabinsk at redhat.com Wed Sep 9 08:52:43 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 9 Sep 2015 10:52:43 +0200 Subject: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases Message-ID: <55EFF35B.1090807@redhat.com> Work-in-progress patchset for https://fedorahosted.org/freeipa/ticket/3864 I didn't even format the patches according to guidelines since I will certainly get many comments from Simo/Alexander and do a lot of reworking. But I hope I'm at least on a right track. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-add-case-insensitive-matching-rule-to-krbprincipalna.patch Type: text/x-patch Size: 1626 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-always-set-krbcanonicalname-attribute-on-new-princip.patch Type: text/x-patch Size: 4066 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-ipa-enrollment-set-krbCanonicalName-attribute-on-enr.patch Type: text/x-patch Size: 1959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-kdb-set-krbCanonicalName-attribute-when-creating.patch Type: text/x-patch Size: 982 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-do-not-set-ipakrbprincipal-ipakrbprincipalalias-when.patch Type: text/x-patch Size: 1307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-do-not-set-ipakrbprincipal-and-ipakrbprinicipalalias.patch Type: text/x-patch Size: 1380 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-mark-ipaKrbPrincipalAlias-attribute-as-deprecated-in.patch Type: text/x-patch Size: 1387 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-perform-case-insensitive-principal-search-when-canon.patch Type: text/x-patch Size: 2240 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 9 09:39:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Sep 2015 11:39:51 +0200 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55EFF2EF.8020709@nordnet.se> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> Message-ID: <55EFFE67.4060406@redhat.com> On 09/09/2015 10:50 AM, Andreas Calminder wrote: > Forgot to write that deleting users in active directory not migrated > with the migrate-ds command works fine, it's only migrated users > present in the ad that breaks the winsync agreement on deletion. > > On 09/09/2015 10:35 AM, Andreas Calminder wrote: >> Hi, >> I've asked in #freeipa on freenode but to no avail, figured I'll ask >> here as well, since I think I've actually hit a bug or (quite) >> possibly I've done something moronic configuration/migration -wise. >> >> I've got an existing FreeIPA 3.0.0 environment running with a fully >> functioning winsync agreement and passsync service with the windows >> environments active directory, I'm trying to migrate the 3.0.0 >> environments users into a freshly installed 4.1 (rhel7) environment, >> after migration I setup a winsync agreement and make it >> bi-directional (one-way sync from windows) everything seems to be >> working alright until I delete a migrated user from the Active >> Directory, after the winsync picks up on the change it'll break and >> suggests a re-initialize. After the re-initialization the agreement >> seems to be fine, however the deleted user are still present in the >> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >> says: ipauser1: user not found. ipa user-find ipauser1 finds the user >> and it's visible in the ui. >> >> Anyone had the same problem or anything similar or any pointers on >> where to start looking? >> >> Regards, >> Andreas >> > Hello, this might be a replication conflict. Can you list that user via ldapsearch to check if this is replication conflict? https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html From pspacek at redhat.com Wed Sep 9 11:39:12 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 9 Sep 2015 13:39:12 +0200 Subject: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55EEF0EE.2020208@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> <55DC2951.60508@redhat.com> <55DC61EB.4050205@redhat.com> <55DF0117.3010800@redhat.com> <55E015DA.902@redhat.com> <55E047BE.5000507@redhat.com> <55EEF0EE.2020208@redhat.com> Message-ID: <55F01A60.9010506@redhat.com> On 8.9.2015 16:30, David Kupka wrote: > On 28/08/15 13:36, Martin Basti wrote: >> >> >> On 08/28/2015 10:03 AM, Petr Spacek wrote: >>> On 27.8.2015 14:22, David Kupka wrote: >>>> @@ -2101,11 +2101,25 @@ class DNSZoneBase(LDAPObject): >>>> class DNSZoneBase_add(LDAPCreate): >>>> + takes_options = LDAPCreate.takes_options + ( >>>> + Flag('force', >>>> + label=_('Force'), >>>> + doc=_('Force DNS zone creation.') >>>> + ), >>>> + Flag('skip_overlap_check', >>>> + doc=_('Force DNS zone creation even if it will overlap >>>> with ' >>>> + 'existing zone.') >>>> + ), >>>> + ) >>>> + >>>> has_output_params = LDAPCreate.has_output_params + >>>> dnszone_output_params >>>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, >>>> *keys, **options): >>>> assert isinstance(dn, DN) >>>> + if options['force']: >>>> + options['skip_overlap_check'] = True >>>> + >>>> try: >>>> entry = ldap.get_entry(dn) >>>> except errors.NotFound: >>>> @@ -2120,6 +2134,12 @@ class DNSZoneBase_add(LDAPCreate): >>>> entry_attrs['idnszoneactive'] = 'TRUE' >>>> + if not options['skip_overlap_check']: >>>> + try: >>>> + check_zone_overlap(keys[-1]) >>>> + except RuntimeError as e: >>>> + raise errors.InvocationError(e.message) >>>> + >>>> return dn >>>> @@ -2673,9 +2693,9 @@ class dnszone_add(DNSZoneBase_add): >>>> __doc__ = _('Create new DNS zone (SOA record).') >>>> takes_options = DNSZoneBase_add.takes_options + ( >>>> - Flag('force', >>>> - label=_('Force'), >>>> - doc=_('Force DNS zone creation even if nameserver is >>>> not resolvable.'), >>>> + Flag('skip_nameserver_check', >>>> + doc=_('Force DNS zone creation even if nameserver is not ' >>>> + 'resolvable.') >>>> ), >>>> # Deprecated >>>> @@ -2699,6 +2719,9 @@ class dnszone_add(DNSZoneBase_add): >>>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, >>>> *keys, **options): >>>> assert isinstance(dn, DN) >>>> + if options['force']: >>>> + options['skip_nameserver_check'] = True >>> Why is it in DNSZoneBase_add.pre_callback? >>> >>> Shouldn't the equation force = (skip_nameserver_check + >>> skip_nameserver_check) >>> be handled in parameter parsing & validation? (Again, I do not know >>> the IPA >>> framework :-)) >>> >>>> + >>>> dn = super(dnszone_add, self).pre_callback( >>>> ldap, dn, entry_attrs, attrs_list, *keys, **options) >>>> @@ -2713,7 +2736,7 @@ class dnszone_add(DNSZoneBase_add): >>>> error=_("Nameserver for reverse zone cannot be >>>> a relative DNS name")) >>>> # verify if user specified server is resolvable >>>> - if not options['force']: >>>> + if not options['skip_nameserver_check']: >>>> check_ns_rec_resolvable(keys[0], >>>> entry_attrs['idnssoamname']) >>>> # show warning about --name-server option >>>> context.show_warning_nameserver_option = True >>>> diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py >>>> index >>>> d959bb369d946217acd080e78483cc9013dda4c7..18f477d4fb6620090b7073689c8df51b65a8307a >>>> >>>> 100644 >>>> --- a/ipapython/ipautil.py >>>> +++ b/ipapython/ipautil.py >>>> @@ -924,6 +924,20 @@ def host_exists(host): >>>> else: >>>> return True >>>> +def check_zone_overlap(zone): >>>> + if resolver.zone_for_name(zone) == zone: >>>> + try: >>>> + ns = [ans.to_text() for ans in resolver.query(zone, 'NS')] >>>> + except DNSException as e: >>>> + root_logger.debug("Failed to resolve nameserver(s) for >>>> domain" >>>> + " {0}: {1}".format(zone, e)) >>>> + ns = [] >>>> + >>>> + msg = u"DNS zone {0} already exists".format(zone) >>> Nitpick: I would say "already exists in DNS" to make it absolutely >>> clear. Just >>> 'already exists' might be confusing because ipa dnszone-show will say >>> that the >>> zone does not exist ... >>> >>>> + if ns: >>>> + msg += u" and is handled by server(s): {0}".format(', >>>> '.join(ns)) >>>> + raise RuntimeError(msg) >>>> + >>>> def get_ipa_basedn(conn): >>>> """ >>>> Get base DN of IPA suffix in given LDAP server. >> 0064 >> NACK >> >> ipa-replica-install should have the --skip-overlap-check too, because >> any replica can be the first DNS server. > > Thanks for the catch, added. > >> >> 0064+0058 >> Can be the options --allow-zone-overlap and --skip-overlap-check merged >> into an one name, to have just one name for same thing? >> > > Each option has bit different behavior: > The '--skip-overlap-check' option in API call prevent the check to be > performed and thus no error or warning is raised. This is the way '--force' > option was originally working. > > The '--allow-zone-overlap' options in installers do not skip the check but > change the error to warning instead and let the installation continue. > > If you think that this can confuse users we need to change the names or even > the logic. > > Updated patches attached. Hello, thank you very much for updating the patch. Unfortunately it is not yet ready, but we are getting there. * Serious problems: a) ipa-server/replica/dns-install by default creates reverse zones even if these zones exist. The check which is done for main IPA domain should be done for all reverse zones, too. If a zone exists user should use --no-reverse or --allow-zone-overlap if necessary. I believe that this is in scope of https://fedorahosted.org/freeipa/ticket/3681 . b) ipa-server/replica/dns-install by default always add DNS zone which contains hostname of the IPA server, even if the IPA domain is different and even if the DNS zone already exists. If the hostname of the server does not belong to IPA domain we should not add anything. Just check that the hostname is resolvable. Theoretically we could add an option which explicitly asks for creating zone which encloses the hostnmame. I believe that this is in scope of https://fedorahosted.org/freeipa/ticket/5087 . c) I did not realize that checks in ipa dns*zone-add will break zone addition for automatic empty zones. There is list of special-case DNS zones which need special handling: https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=bin/named/server.c;h=1a25531df354f6f0593bfb86e5aa3e3c9b9c80e5;hb=HEAD#l272 Feel free to copy&paste list of the domains to IPA code - list comes from RFCs, so it should be pretty stable. It would be good If one of these zones is detected as "already existing" we need to further check values in SOA record and automatically override the check if: (SOA mname = zone name) & (SOA rname = .) In that case we should print informational message "automatic empty zone will be overridden by the zone you defined now". d) ipa-server/replica/dns-install fails when attempt to resolve main IPA domain name fails with DNS timeout. This might easily happen if the domain name is already delegated to IPA server which is being installed. In that case we should print a warning and allow to continue. """ Warning: DNS check for domain failed with error . Please make sure that the domain is properly delegated to this IPA server. """ * Nitpicks - can be handled in separate patches: 1) Interactive ipa-server-install tells the user that the zone name he entered exists too late in the process. I.e. user has to enter DM and admin password (twice!) and only after that he will receive an error, which may be frustrating :-) Please move the check right after DNS zone name input so user does not waste his time and nerves :-) Even better, in an interactive mode it could make sense to ask the user again if the previous input was not acceptable. 2) I found out that ipa-server-install prints message "Warning: skipping DNS resolution of host vm-206.abc.idm.lab.eng.brq.redhat.com" even if the host name does not belong to IPA domain. That is a mistake - the check should be skipped only in case when IPA server is part of the IPA domain. 3) When adding an forward as an override for automatic empty zones we should throw a warning if forward policy is not 'only'. It does not make sense to use policy 'forward' in these cases. """ Warning: It is strongly recommended to use forward policy 'only' for the forward zones defined for private use. """ -- Petr^2 Spacek From mbabinsk at redhat.com Wed Sep 9 12:21:40 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 9 Sep 2015 14:21:40 +0200 Subject: [Freeipa-devel] [PATCH 0311] tests: fix vault tests In-Reply-To: <55EF028C.2040605@redhat.com> References: <55EF028C.2040605@redhat.com> Message-ID: <55F02454.5020808@redhat.com> On 09/08/2015 05:45 PM, Martin Basti wrote: > Attached patch fixes vault tests. > > Tests work for me, ACK. -- Martin^3 Babinsky From mbasti at redhat.com Wed Sep 9 12:28:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Sep 2015 14:28:49 +0200 Subject: [Freeipa-devel] [PATCH 0311] tests: fix vault tests In-Reply-To: <55F02454.5020808@redhat.com> References: <55EF028C.2040605@redhat.com> <55F02454.5020808@redhat.com> Message-ID: <55F02601.9000606@redhat.com> On 09/09/2015 02:21 PM, Martin Babinsky wrote: > On 09/08/2015 05:45 PM, Martin Basti wrote: >> Attached patch fixes vault tests. >> >> > Tests work for me, ACK. > pushed to master: * 9ffe7f49987bf788449a2007a33f0a3d83ea4553 FIX vault tests ipa-4-2: * 72ba3777ca8c58dbbb912a19f81fd2bb2983b8d6 FIX vault tests From simo at redhat.com Wed Sep 9 13:59:17 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 09 Sep 2015 09:59:17 -0400 Subject: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases In-Reply-To: <55EFF35B.1090807@redhat.com> References: <55EFF35B.1090807@redhat.com> Message-ID: <1441807157.3048.237.camel@willson.usersys.redhat.com> On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote: > if (found) { > + /* replace the incoming principal with the value got > from LDAP > + * search. This is needed so that correctly case > principal is > + * returned in the case when canonicalization is > switched on > + * and no krbcanonicalname attribute is present in > the entry. > + */ > + free(*principal); > + *principal = strdup(vals[i]->bv_val); > + if (!(*principal)) { > + return KRB5_KDB_INTERNAL_ERROR; > + } > break; This unconditionally replaces the principal even when canonicalization is not requested. Shouldn't this replace be conditional on KRB5_KDB_FLAGS_ALIAS_OK being set ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 9 14:08:50 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 09 Sep 2015 10:08:50 -0400 Subject: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases In-Reply-To: <55EFF35B.1090807@redhat.com> References: <55EFF35B.1090807@redhat.com> Message-ID: <1441807730.3048.240.camel@willson.usersys.redhat.com> On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote: > Work-in-progress patchset for https://fedorahosted.org/freeipa/ticket/3864 > > I didn't even format the patches according to guidelines since I will > certainly get many comments from Simo/Alexander and do a lot of > reworking. But I hope I'm at least on a right track. The direction looks good, keep in mind you have to change also install/share/modrdn-krbprinc.ldif (and related update file) to add a 'cn=Kerberos Canonical Name' rule. Simo. -- Simo Sorce * Red Hat, Inc * New York From dkupka at redhat.com Wed Sep 9 14:21:22 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 9 Sep 2015 16:21:22 +0200 Subject: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases In-Reply-To: <1441807157.3048.237.camel@willson.usersys.redhat.com> References: <55EFF35B.1090807@redhat.com> <1441807157.3048.237.camel@willson.usersys.redhat.com> Message-ID: <55F04062.70500@redhat.com> On 09/09/15 15:59, Simo Sorce wrote: > On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote: >> if (found) { >> + /* replace the incoming principal with the value got >> from LDAP >> + * search. This is needed so that correctly case >> principal is >> + * returned in the case when canonicalization is >> switched on >> + * and no krbcanonicalname attribute is present in >> the entry. >> + */ >> + free(*principal); >> + *principal = strdup(vals[i]->bv_val); >> + if (!(*principal)) { >> + return KRB5_KDB_INTERNAL_ERROR; >> + } >> break; > > > This unconditionally replaces the principal even when canonicalization > is not requested. Shouldn't this replace be conditional on > KRB5_KDB_FLAGS_ALIAS_OK being set ? > > Simo. > It's not obvious from first look but it actually depends on the KRB5_KDB_FLAGS_ALIAS_OK. When KRB5_KDB_FLAGS_ALIAS_OK is true the 'found' variable is the result of case-insensitive comparison. When it's false 'found' variable is the result of case-sensitive comparison. In case of case-sensitive match we're replacing the principal with the exactly same value though effectively not changing it. -- David Kupka From rmeggins at redhat.com Wed Sep 9 14:29:23 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 9 Sep 2015 08:29:23 -0600 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55EFFE67.4060406@redhat.com> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> Message-ID: <55F04243.1060205@redhat.com> On 09/09/2015 03:39 AM, Martin Basti wrote: > > > On 09/09/2015 10:50 AM, Andreas Calminder wrote: >> Forgot to write that deleting users in active directory not migrated >> with the migrate-ds command works fine, it's only migrated users >> present in the ad that breaks the winsync agreement on deletion. >> >> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>> Hi, >>> I've asked in #freeipa on freenode but to no avail, figured I'll ask >>> here as well, since I think I've actually hit a bug or (quite) >>> possibly I've done something moronic configuration/migration -wise. >>> >>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>> functioning winsync agreement and passsync service with the windows >>> environments active directory, I'm trying to migrate the 3.0.0 >>> environments users into a freshly installed 4.1 (rhel7) environment, >>> after migration I setup a winsync agreement and make it >>> bi-directional (one-way sync from windows) everything seems to be >>> working alright until I delete a migrated user from the Active >>> Directory, after the winsync picks up on the change it'll break and >>> suggests a re-initialize. After the re-initialization the agreement >>> seems to be fine, however the deleted user are still present in the >>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>> user and it's visible in the ui. >>> >>> Anyone had the same problem or anything similar or any pointers on >>> where to start looking? >>> >>> Regards, >>> Andreas >>> >> > > Hello, this might be a replication conflict. > > Can you list that user via ldapsearch to check if this is replication > conflict? > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > Use the latest docs, just in case they are more accurate: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Sep 9 14:35:46 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 09 Sep 2015 10:35:46 -0400 Subject: [Freeipa-devel] [PATCH PoC] proper support of kerberos principal aliases In-Reply-To: <55F04062.70500@redhat.com> References: <55EFF35B.1090807@redhat.com> <1441807157.3048.237.camel@willson.usersys.redhat.com> <55F04062.70500@redhat.com> Message-ID: <1441809346.3048.243.camel@willson.usersys.redhat.com> On Wed, 2015-09-09 at 16:21 +0200, David Kupka wrote: > On 09/09/15 15:59, Simo Sorce wrote: > > On Wed, 2015-09-09 at 10:52 +0200, Martin Babinsky wrote: > >> if (found) { > >> + /* replace the incoming principal with the value got > >> from LDAP > >> + * search. This is needed so that correctly case > >> principal is > >> + * returned in the case when canonicalization is > >> switched on > >> + * and no krbcanonicalname attribute is present in > >> the entry. > >> + */ > >> + free(*principal); > >> + *principal = strdup(vals[i]->bv_val); > >> + if (!(*principal)) { > >> + return KRB5_KDB_INTERNAL_ERROR; > >> + } > >> break; > > > > > > This unconditionally replaces the principal even when canonicalization > > is not requested. Shouldn't this replace be conditional on > > KRB5_KDB_FLAGS_ALIAS_OK being set ? > > > > Simo. > > > > It's not obvious from first look but it actually depends on the > KRB5_KDB_FLAGS_ALIAS_OK. > When KRB5_KDB_FLAGS_ALIAS_OK is true the 'found' variable is the result > of case-insensitive comparison. > When it's false 'found' variable is the result of case-sensitive comparison. > In case of case-sensitive match we're replacing the principal with the > exactly same value though effectively not changing it. > Yeah I saw that, but you just said it, it is not obvious. You should just move this chunk of code, as is, 2 blocks above where the insensitive comparison is done. This will make it clear that it is done only for canonicalization and following changes won't break stuff. It will also avoid unnecessry free and replace with the same value when canonicalization is not used. Simo. -- Simo Sorce * Red Hat, Inc * New York From andreas.calminder at nordnet.se Wed Sep 9 14:44:19 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Wed, 9 Sep 2015 16:44:19 +0200 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55F04243.1060205@redhat.com> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> Message-ID: <55F045C3.5040808@nordnet.se> Hi, thanks for your reply, I'm able to list the user with ldapsearch and I can't find any conflict entries described in the article. The 4.1 environment is only 1 server connected to active directory. Forgot to reply to the list before, doh! I've noticed a difference between users in 3.0 and 4.1 though, migrated users in the 4.1 does not have an entry in " cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this. Example: FreeIPA 4.1 environment: # ldapsearch -xLLL -D "cn=directory manager" -W -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" Enter LDAP Password: No such object (32) Matched DN: cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld FreeIPA 3.0 environment: # ldapsearch -xLLL -D "cn=directory manager" -W -b "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" Enter LDAP Password: dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top cn: batman gidNumber: 1486600065 description: User private group for batman mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c /andreas On 09/09/2015 04:29 PM, Rich Megginson wrote: > On 09/09/2015 03:39 AM, Martin Basti wrote: >> >> >> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>> Forgot to write that deleting users in active directory not migrated >>> with the migrate-ds command works fine, it's only migrated users >>> present in the ad that breaks the winsync agreement on deletion. >>> >>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>> Hi, >>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>> ask here as well, since I think I've actually hit a bug or (quite) >>>> possibly I've done something moronic configuration/migration -wise. >>>> >>>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>>> functioning winsync agreement and passsync service with the windows >>>> environments active directory, I'm trying to migrate the 3.0.0 >>>> environments users into a freshly installed 4.1 (rhel7) >>>> environment, after migration I setup a winsync agreement and make >>>> it bi-directional (one-way sync from windows) everything seems to >>>> be working alright until I delete a migrated user from the Active >>>> Directory, after the winsync picks up on the change it'll break and >>>> suggests a re-initialize. After the re-initialization the agreement >>>> seems to be fine, however the deleted user are still present in the >>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>> user and it's visible in the ui. >>>> >>>> Anyone had the same problem or anything similar or any pointers on >>>> where to start looking? >>>> >>>> Regards, >>>> Andreas >>>> >>> >> >> Hello, this might be a replication conflict. >> >> Can you list that user via ldapsearch to check if this is replication >> conflict? >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> >> > Use the latest docs, just in case they are more accurate: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Sep 9 14:49:17 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Sep 2015 10:49:17 -0400 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55F045C3.5040808@nordnet.se> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> <55F045C3.5040808@nordnet.se> Message-ID: <55F046ED.3010602@redhat.com> Andreas Calminder wrote: > Hi, > thanks for your reply, I'm able to list the user with ldapsearch and I > can't find any conflict entries described in the article. The 4.1 > environment is only 1 server connected to active directory. Forgot to > reply to the list before, doh! > > I've noticed a difference between users in 3.0 and 4.1 though, migrated > users in the 4.1 does not have an entry in " > cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this. > Example: > > FreeIPA 4.1 environment: > # ldapsearch -xLLL -D "cn=directory manager" -W > -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" > Enter LDAP Password: > No such object (32) Matched DN: > cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld > > FreeIPA 3.0 environment: > # ldapsearch -xLLL -D "cn=directory manager" -W -b > "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" > Enter LDAP Password: > dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld > objectClass: posixgroup > objectClass: ipaobject > objectClass: mepManagedEntry > objectClass: top > cn: batman > gidNumber: 1486600065 > description: User private group for batman > mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld > ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c Migrated users don't get user-private groups created. Is there a reason you migrated from 3.0 to 4.1 rather than just adding a 4.1 master to the existing pool? rob > > /andreas > > On 09/09/2015 04:29 PM, Rich Megginson wrote: >> On 09/09/2015 03:39 AM, Martin Basti wrote: >>> >>> >>> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>>> Forgot to write that deleting users in active directory not migrated >>>> with the migrate-ds command works fine, it's only migrated users >>>> present in the ad that breaks the winsync agreement on deletion. >>>> >>>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>>> Hi, >>>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>>> ask here as well, since I think I've actually hit a bug or (quite) >>>>> possibly I've done something moronic configuration/migration -wise. >>>>> >>>>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>>>> functioning winsync agreement and passsync service with the windows >>>>> environments active directory, I'm trying to migrate the 3.0.0 >>>>> environments users into a freshly installed 4.1 (rhel7) >>>>> environment, after migration I setup a winsync agreement and make >>>>> it bi-directional (one-way sync from windows) everything seems to >>>>> be working alright until I delete a migrated user from the Active >>>>> Directory, after the winsync picks up on the change it'll break and >>>>> suggests a re-initialize. After the re-initialization the agreement >>>>> seems to be fine, however the deleted user are still present in the >>>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>>> user and it's visible in the ui. >>>>> >>>>> Anyone had the same problem or anything similar or any pointers on >>>>> where to start looking? >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>> >>> >>> Hello, this might be a replication conflict. >>> >>> Can you list that user via ldapsearch to check if this is replication >>> conflict? >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>> >>> >> Use the latest docs, just in case they are more accurate: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> >> > > > From Andreas.Calminder at nordnet.se Wed Sep 9 15:15:58 2015 From: Andreas.Calminder at nordnet.se (Andreas Calminder) Date: Wed, 9 Sep 2015 15:15:58 +0000 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55F046ED.3010602@redhat.com> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> <55F045C3.5040808@nordnet.se>,<55F046ED.3010602@redhat.com> Message-ID: <2c69d075-4339-4b15-b2b0-5b1dbd84ed4c@email.android.com> Yes, kind of. I wanted a new environment with a proper certificate authority setup with only the old users and groups from the IPA 3.0 environment. The old environment use a self signed ca, I thought it would be easier to just migrate my users and groups. On 9 Sep 2015 4:49 pm, Rob Crittenden wrote: Andreas Calminder wrote: > Hi, > thanks for your reply, I'm able to list the user with ldapsearch and I > can't find any conflict entries described in the article. The 4.1 > environment is only 1 server connected to active directory. Forgot to > reply to the list before, doh! > > I've noticed a difference between users in 3.0 and 4.1 though, migrated > users in the 4.1 does not have an entry in " > cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this. > Example: > > FreeIPA 4.1 environment: > # ldapsearch -xLLL -D "cn=directory manager" -W > -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" > Enter LDAP Password: > No such object (32) Matched DN: > cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld > > FreeIPA 3.0 environment: > # ldapsearch -xLLL -D "cn=directory manager" -W -b > "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" > Enter LDAP Password: > dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld > objectClass: posixgroup > objectClass: ipaobject > objectClass: mepManagedEntry > objectClass: top > cn: batman > gidNumber: 1486600065 > description: User private group for batman > mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld > ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c Migrated users don't get user-private groups created. Is there a reason you migrated from 3.0 to 4.1 rather than just adding a 4.1 master to the existing pool? rob > > /andreas > > On 09/09/2015 04:29 PM, Rich Megginson wrote: >> On 09/09/2015 03:39 AM, Martin Basti wrote: >>> >>> >>> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>>> Forgot to write that deleting users in active directory not migrated >>>> with the migrate-ds command works fine, it's only migrated users >>>> present in the ad that breaks the winsync agreement on deletion. >>>> >>>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>>> Hi, >>>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>>> ask here as well, since I think I've actually hit a bug or (quite) >>>>> possibly I've done something moronic configuration/migration -wise. >>>>> >>>>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>>>> functioning winsync agreement and passsync service with the windows >>>>> environments active directory, I'm trying to migrate the 3.0.0 >>>>> environments users into a freshly installed 4.1 (rhel7) >>>>> environment, after migration I setup a winsync agreement and make >>>>> it bi-directional (one-way sync from windows) everything seems to >>>>> be working alright until I delete a migrated user from the Active >>>>> Directory, after the winsync picks up on the change it'll break and >>>>> suggests a re-initialize. After the re-initialization the agreement >>>>> seems to be fine, however the deleted user are still present in the >>>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>>> user and it's visible in the ui. >>>>> >>>>> Anyone had the same problem or anything similar or any pointers on >>>>> where to start looking? >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>> >>> >>> Hello, this might be a replication conflict. >>> >>> Can you list that user via ldapsearch to check if this is replication >>> conflict? >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>> >>> >> Use the latest docs, just in case they are more accurate: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Sep 9 16:39:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 9 Sep 2015 18:39:26 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55EFF35C.3050007@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> <55E68898.1000300@redhat.com> <55E8488E.5070308@redhat.com> <55EF4DD6.5010706@redhat.com> <55EFF35C.3050007@redhat.com> Message-ID: <55F060BE.6030403@redhat.com> On 09/09/2015 10:52 AM, Jan Cholasta wrote: > On 8.9.2015 23:06, Petr Vobornik wrote: >> On 09/03/2015 03:18 PM, Jan Cholasta wrote: >>> On 2.9.2015 07:26, Endi Sukma Dewata wrote: >>>> On 9/1/2015 10:22 AM, Simo Sorce wrote: >>>>> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >>>>>> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>>>>>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>>>>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>>>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>>>>>> adds commands: >>>>>>>>>> * vaultcontainer-show [--service |--user ] >>>>>>>>>> * vaultcontainer-add-owner >>>>>>>>>> [--service |--user ] >>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>> ] >>>>>>>>>> * vaultcontainer-remove-owner >>>>>>>>>> [--service |--user ] >>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>> ] >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>>>>>> >>>>>>>>>> Use cases: >>>>>>>>>> 1. When user/service is deleted, associated vault container >>>>>>>>>> looses >>>>>>>>>> owner. There was no API command to set the owner. >>>>>>>>>> 2. Change owner of container by admin to manage access. >>>>>>>>>> >>>>>>>>>> Show command was added to show current owners. >>>>>>>>>> >>>>>>>>>> Find command was not added, should it be? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> There is also a design for vault container ownership handling >>>>>>>>> created by >>>>>>>>> Endi - it's for future Vault 2.0. >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This patch has a different API than the proposed - different >>>>>>>>> way of >>>>>>>>> specifying the container. The design page uses path e.g. >>>>>>>>> /users/foobar. >>>>>>>>> This patch uses the same way as vaults e.g. --user=foobar. This >>>>>>>>> means >>>>>>>>> that the implementation in this patch cannot manage ownership of >>>>>>>>> parent >>>>>>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>>>>>> >>>>>>>>> Do we want to go with this approach in 4.2? >>>>>>>>> >>>>>>>>> Attaching also new path which removes setting of owner which >>>>>>>>> doesn't >>>>>>>>> exist so that integrity is OK and that it is consistent with >>>>>>>>> removing of >>>>>>>>> user. >>>>>>>>> >>>>>>>>> Updated patch attached - output fix. >>>>>>>> >>>>>>>> We had a long discussion about this with Petr and we think the best >>>>>>>> approach is as follows: >>>>>>>> >>>>>>>> * Add new "Vault administrators" privilege. Vault >>>>>>>> administrators will >>>>>>>> have unrestricted access to vaults and vault containers, including >>>>>>>> the >>>>>>>> power to add/remove owners of vaults and vault containers. >>>>>>>> >>>>>>>> * Remove the ability of vault owners to add/remove other vault >>>>>>>> owners. If vault owner needs to be changed, vault administrator >>>>>>>> has to >>>>>>>> do it. Note that vault owners will still have the ability to >>>>>>>> add/remove >>>>>>>> vault members. >>>>>>>> >>>>>>>> * When adding new vault container, set owner to the current >>>>>>>> user. If >>>>>>>> vault container owner needs to be changed, vault administrator has >>>>>>>> to do >>>>>>>> it. >>>>>>>> >>>>>>>> * Allow adding vaults and vault containers only if the owner is >>>>>>>> set >>>>>>>> to the current user. >>>>>>>> >>>>>>>> * Introduce commands to modify vault container owner and to >>>>>>>> delete >>>>>>>> vault container, so the administrator has a choice between >>>>>>>> assigning >>>>>>>> ownership or deleting an unowned container. >>>>>>> >>>>>>> Also: >>>>>>> >>>>>>> * Control access to vault data using an ipaProtectedOperation >>>>>>> ACI. >>>>>>> Users which have read access to "ipaProtectedOperation;accessKRA" >>>>>>> on a >>>>>>> vault can retrieve data from the vault and users which have write >>>>>>> access >>>>>>> to "ipaProtectedOperation;accessKRA" on a vault can archive data in >>>>>>> the >>>>>>> vault. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> CCing Simo and Endi to check the proposal. >>>>>> >>>>>> And Scott (related to #5216, #5215) >>>>> >>>>> Sounds reasonable to me. >>>>> I can see that allowing owners to hand over vaults w/o admin >>>>> intervention may have some appeal in some use cases, but I also see it >>>>> can bring downsides with it, so all in all I think I agree with the >>>>> above points. >>>>> >>>>> Simo. >>>>> >>>> >>>> Not a total objection, but if many people in unrelated groups are using >>>> vaults, and they are sharing the vaults only with members of each >>>> group, >>>> having to ask a Vault Administrator for each ownership change sounds a >>>> bit cumbersome. Since the Vault Adminstrator will have access to all >>>> vaults in all groups, only a small number of people can be trusted to >>>> hold that role. If there are many ownership changes the Vault >>>> Administrator will have to handle all those requests, and the vault >>>> users may have to wait until the change is completed. >>>> >>>> If owners are allowed to add others as owners, the vaults will be >>>> pretty >>>> much maintenance free to the admin. >>> >>> Owners can still manage members, which is IMO good enough for sharing a >>> vault with other users. >>> >>>> >>>> Regardless, please update the wiki page to describe the new behavior >>>> when it's implemented: >>>> http://www.freeipa.org/page/V4/Password_Vault_1.1 >>> >>> Sure. >>> >>> I have updated and rebased Petr's patch 916. >>> >>> Patch 488 obsoletes Petr's patch 918. >>> >>> Patch for vault data access control is not included, because I was not >>> able to make GER work correctly with "ipaProtectedOperation;accessKRA". >>> >> >> I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question >> (#4). >> >> 1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a >> blocker. >> >> [pvoborni at vm-063 ~]$ ipa vaultcontainer-del --user=fbar >> -------------------------- >> Deleted vault container "" >> -------------------------- > > Fixed. > >> >> >> 2. Invalid description of vaultcontainer-show >> "Display information about a vault." > > Fixed > >> >> 3. Something which needs to be fixed: >> >> Setting password for first vault without a vault container fails(here >> run as vault admin but the same issue is present when it's run as the >> user). >> >> [pvoborni at vm-063 ~]$ ipa vault-add f1 --user=fbar >> New password: >> Verify password: >> ipa: ERROR: Invalid credentials >> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >> --------------- >> 1 vault matched >> --------------- >> Vault name: f1 >> Type: symmetric >> Vault user: fbar >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- > > Works for me. Are you testing on master or ipa-4-2? I might have not copied a required file during the testing. It works for me now as well. > >> >> Second works: >> >> [pvoborni at vm-063 ~]$ ipa vault-add f2 --user=fbar >> New password: >> Verify password: >> ** Passwords do not match! ** >> New password: >> Verify password: >> ---------------- >> Added vault "f2" >> ---------------- >> Vault name: f2 >> Type: symmetric >> Salt: w4tnrjW/Ra2jGS8lI6Frfg== >> Owner users: va >> Vault user: fbar >> >> >> >> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >> ---------------- >> 2 vaults matched >> ---------------- >> Vault name: f1 >> Type: symmetric >> Vault user: fbar >> >> Vault name: f2 >> Type: symmetric >> Vault user: fbar >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> >> 4. Q: Should vault container owner delete all its vault? > > I don't know, should it? IMO it shouldn't, at least not by default. > >> >> As fbar when there is a vault without fbar as owner >> >> [root at vm-063 pvoborni]# ipa vaultcontainer-del >> ipa: ERROR: Not allowed on non-leaf entry >> >> when fbar is added as owner to all vaults >> >> [root at vm-063 pvoborni]# ipa vaultcontainer-del >> -------------------------- >> Deleted vault container "" >> -------------------------- >> [root at vm-063 pvoborni]# ipa vault-add f1 >> New password: >> Verify password: >> ipa: ERROR: Invalid credentials >> [root at vm-063 pvoborni]# ipa vault-del f1 >> ------------------ >> Deleted vault "f1" >> ------------------ >> [root at vm-063 pvoborni]# ipa vault-add f1 >> New password: >> Verify password: >> ---------------- >> Added vault "f1" >> ---------------- >> Vault name: f1 >> Type: symmetric >> Salt: bkHxRIipkaeX+H/fOnZdBw== >> Owner users: fbar >> Vault user: fbar >> > > -- Petr Vobornik From simo at redhat.com Wed Sep 9 18:25:42 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 09 Sep 2015 14:25:42 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1440624432.8138.130.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> Message-ID: <1441823142.3048.250.camel@willson.usersys.redhat.com> On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: > This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > and introduces a number of required changes and dependencies to achieve > this goal. > This work requires the custodia project to securely transfer keys > between ipa servers. > > This work is not 100% complete, it still misses the ability to install > kra instances and the ability to install a CA (via ipa-ca-install) with > externally signed certs. > > However it is massive enough that warrants review and pushing, the resat > of the changes can be applied later as this work should not disrupt the > classic install methods. > > In order to build my previous patches (530-533) are needed as well as a > number of updated components. > > I used the following coprs for testing: > simo/jwcrypto > simo/custodia > abbra/sssd-kkdcproxy (for sssd 1.13.1) > lkrispen/389-ds-current (for 389 > 1.3.4.4) > vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > mkosek/freeipa-4.2-fedora-22 (misc) > fedora/updates-testing (python-gssapi 1.1.2) > > Ludwig's copr is necessary to have a functional DNA plugin in replicas, > eventually his patches should be committed in 389-ds-base 1.3.4.4 when > it will be released. > > We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > that may cause installation issues in some case (re-install of a > replica). > > The domain must be raised to level 1 in order to use replica promotion. > > In order to promote a replica the server must be first joined as a > regular client to the domain. > > This is the flow I usually use for testing: > > # ipa-client-install > # kinit admin > # ipa-replica-install --promote --setup-ca > etc...> > > These patches are also available in this git tree rebnase on current > master: > https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review FYI: I rebased this branch on top of master and applied minor changes to one of the DNS patches. I also added the missing support to install KRA. DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not needed anymore. Dogtag's ticket is not fixed yet so running both --setup-ca and --setup-kra at the same time will still yield an error and install will fail. Please let me know if there are any major issues with this patchset, I'd like to push it to master and attack the remaining issues as add ons (install with external certs not supported yet for example) Simo. -- Simo Sorce * Red Hat, Inc * New York From Andreas.Calminder at nordnet.se Wed Sep 9 19:40:48 2015 From: Andreas.Calminder at nordnet.se (Andreas Calminder) Date: Wed, 9 Sep 2015 19:40:48 +0000 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <2c69d075-4339-4b15-b2b0-5b1dbd84ed4c@email.android.com> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> <55F045C3.5040808@nordnet.se>,<55F046ED.3010602@redhat.com> <2c69d075-4339-4b15-b2b0-5b1dbd84ed4c@email.android.com> Message-ID: <0B2EB1D0E2109A4CBD60C63A19995FB60123EB7EB5@EXCHDBALV1.Pilen.nordnet.se> Hi, I just wanted to post the solution for this, I've reported this to Redhat and a bug has been filed (https://bugzilla.redhat.com/1261536). The problem was that migrate-ds copied the attribute mepManagedEntry on migration, the suggested workaround, running migrate-ds with --user-ignore-attribute=mepManagedEntry --user-ignore-objectclass=mepOriginEntry worked like a charm (Thanks Rob!), deleting users in active directory doesn't break the winsync agreement and I'm able to delete migrated users directly in ipa. As mentioned in the bug comments, migrate-ds isn't really for ipa to ipa migration. However, it kind of worked... /andreas From: freeipa-devel-bounces at redhat.com [mailto:freeipa-devel-bounces at redhat.com] On Behalf Of Andreas Calminder Sent: den 9 september 2015 17:16 To: freeipa-devel at redhat.com Subject: Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory Yes, kind of. I wanted a new environment with a proper certificate authority setup with only the old users and groups from the IPA 3.0 environment. The old environment use a self signed ca, I thought it would be easier to just migrate my users and groups. On 9 Sep 2015 4:49 pm, Rob Crittenden wrote: Andreas Calminder wrote: > Hi, > thanks for your reply, I'm able to list the user with ldapsearch and I > can't find any conflict entries described in the article. The 4.1 > environment is only 1 server connected to active directory. Forgot to > reply to the list before, doh! > > I've noticed a difference between users in 3.0 and 4.1 though, migrated > users in the 4.1 does not have an entry in " > cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this. > Example: > > FreeIPA 4.1 environment: > # ldapsearch -xLLL -D "cn=directory manager" -W > -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" > Enter LDAP Password: > No such object (32) Matched DN: > cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld > > FreeIPA 3.0 environment: > # ldapsearch -xLLL -D "cn=directory manager" -W -b > "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" > Enter LDAP Password: > dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld > objectClass: posixgroup > objectClass: ipaobject > objectClass: mepManagedEntry > objectClass: top > cn: batman > gidNumber: 1486600065 > description: User private group for batman > mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld > ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c Migrated users don't get user-private groups created. Is there a reason you migrated from 3.0 to 4.1 rather than just adding a 4.1 master to the existing pool? rob > > /andreas > > On 09/09/2015 04:29 PM, Rich Megginson wrote: >> On 09/09/2015 03:39 AM, Martin Basti wrote: >>> >>> >>> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>>> Forgot to write that deleting users in active directory not migrated >>>> with the migrate-ds command works fine, it's only migrated users >>>> present in the ad that breaks the winsync agreement on deletion. >>>> >>>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>>> Hi, >>>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>>> ask here as well, since I think I've actually hit a bug or (quite) >>>>> possibly I've done something moronic configuration/migration -wise. >>>>> >>>>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>>>> functioning winsync agreement and passsync service with the windows >>>>> environments active directory, I'm trying to migrate the 3.0.0 >>>>> environments users into a freshly installed 4.1 (rhel7) >>>>> environment, after migration I setup a winsync agreement and make >>>>> it bi-directional? (one-way sync from windows) everything seems to >>>>> be working alright until I delete a migrated user from the Active >>>>> Directory, after the winsync picks up on the change it'll break and >>>>> suggests a re-initialize. After the re-initialization the agreement >>>>> seems to be fine, however the deleted user are still present in the >>>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>>> user and it's visible in the ui. >>>>> >>>>> Anyone had the same problem or anything similar or any pointers on >>>>> where to start looking? >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>> >>> >>> Hello, this might be a replication conflict. >>> >>> Can you list that user via ldapsearch to check if this is replication >>> conflict? >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>> >>> >> Use the latest docs, just in case they are more accurate: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> >> > > > From akasurde at redhat.com Thu Sep 10 06:22:36 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 10 Sep 2015 11:52:36 +0530 Subject: [Freeipa-devel] [PATCH] Updated no of legacy permission in ipatests In-Reply-To: <55E83FB1.9020800@redhat.com> References: <55DE9B0D.6030101@redhat.com> <55E7E5A2.2090402@redhat.com> <55E83FB1.9020800@redhat.com> Message-ID: <55F121AC.50306@redhat.com> Hi List, Please find the following patch with review comments. Thanks, Abhijeet Kasurde On 09/03/2015 06:10 PM, Tomas Babej wrote: > > On 09/03/2015 08:16 AM, Abhijeet Kasurde wrote: >> Ping >> >> On 08/27/2015 10:37 AM, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264 >>> >>> Thanks, >>> Abhijeet Kasurde > ACK, the patch needs a minor rebase on master due to python3 refactoring. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-2-Updated-no-of-legacy-permission-in-ipatests.patch Type: text/x-patch Size: 1292 bytes Desc: not available URL: From jcholast at redhat.com Thu Sep 10 07:41:33 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Sep 2015 09:41:33 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> Message-ID: <55F1342D.90307@redhat.com> On 4.9.2015 14:43, Gabe Alford wrote: > Bump for review. > > On Wed, Aug 12, 2015 at 9:32 AM, Gabe Alford > wrote: > > On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta > wrote: > > On 6.8.2015 21:43, Gabe Alford wrote: > > Hello, > > Updated patch attached. > > - Time limit is -1 for unlimited. I found this > https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html > in reference to keeping the time limit as -1 for unlimited. > > > This patch does two conflicting things: it coerces time limit of > 0 to -1 and at the same time prohibits the user to use 0 for > time limit. We should do just one of these and IMHO it should be > the coercion of 0 to -1. > > Sure enough, testing time limit at 0 did not work for > unlimited as well > as appeared to have negative effects on IPA. > > > This is because the time limit read from ipa config is not > converted to int in ldap2.find_entries(), so the coercion does > not work. Fix this and 0 will work just fine. > > Also, I believe that > http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s > specifies unlimited for time limit as -1. (Please correct me > if I am wrong.) > > > python-ldap is layers below our API and should not determine > what we use for unlimited time limit. I would prefer if we were > self-consistent and use 0 for both time limit and size limit. > > > A misunderstanding on my part as I thought it was higher up in the > API for some reason. Updated patch attached. Thanks, this is better, but it turns out I was wrong about coercing -1 to 0 in config-mod: in a topology with different versions of IPA servers, setting the limits in LDAP to 0 on a newer server with your patch will break older servers without your patch: [user at old]$ ipa user-find -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1364800000 GID: 1364800000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ---------------------------- [user at new]$ ipa config-mod --searchtimelimit=0 --searchrecordslimit=0 ... [user at old]$ ipa user-find --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ---------------------------- To fix this, we actually need to do the opposite and store -1 in LDAP when 0 is specified in config-mod options. Honza -- Jan Cholasta From mbasti at redhat.com Thu Sep 10 08:21:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 10 Sep 2015 10:21:56 +0200 Subject: [Freeipa-devel] [PATCH 0312] CI: extend backup restore tests with DNS/DNSSEC Message-ID: <55F13DA4.7050800@redhat.com> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0312-backup-CI-test-DNS-DNSSEC-after-backup-and-restore.patch Type: text/x-patch Size: 5309 bytes Desc: not available URL: From mbasti at redhat.com Thu Sep 10 08:48:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 10 Sep 2015 10:48:05 +0200 Subject: [Freeipa-devel] [PATCH 0312] CI: extend backup restore tests with DNS/DNSSEC In-Reply-To: <55F13DA4.7050800@redhat.com> References: <55F13DA4.7050800@redhat.com> Message-ID: <55F143C5.2070802@redhat.com> Self NACK On 09/10/2015 10:21 AM, Martin Basti wrote: > Patch attached. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheimes at redhat.com Thu Sep 10 09:58:55 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 10 Sep 2015 11:58:55 +0200 Subject: [Freeipa-devel] [PATCH 0024] Handle timeout error in ipa-httpd-kdcproxy Message-ID: <55F1545F.1030107@redhat.com> The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. A timeout does no longer result into an Apache startup error. https://fedorahosted.org/freeipa/ticket/5292 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0024-Handle-timeout-error-in-ipa-httpd-kdcproxy.patch Type: text/x-patch Size: 1426 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 mbasti at redhat.com Thu Sep 10 11:29:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 10 Sep 2015 13:29:17 +0200 Subject: [Freeipa-devel] [PATCH 0024] Handle timeout error in ipa-httpd-kdcproxy In-Reply-To: <55F1545F.1030107@redhat.com> References: <55F1545F.1030107@redhat.com> Message-ID: <55F1698D.5060309@redhat.com> ACK On 09/10/2015 11:58 AM, Christian Heimes wrote: > The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. > A timeout does no longer result into an Apache startup error. > > https://fedorahosted.org/freeipa/ticket/5292 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Sep 10 11:30:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 10 Sep 2015 13:30:41 +0200 Subject: [Freeipa-devel] [PATCH 0024] Handle timeout error in ipa-httpd-kdcproxy In-Reply-To: <55F1698D.5060309@redhat.com> References: <55F1545F.1030107@redhat.com> <55F1698D.5060309@redhat.com> Message-ID: <55F169E1.4020703@redhat.com> On 09/10/2015 01:29 PM, Martin Basti wrote: > ACK > > On 09/10/2015 11:58 AM, Christian Heimes wrote: >> The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. >> A timeout does no longer result into an Apache startup error. >> >> https://fedorahosted.org/freeipa/ticket/5292 >> >> >> >> > > > Pushed to: master: a3d077443fc7f15c005f86aeed40443d0a0843a1 ipa-4-2: 1464437ca2a1bb18fd6468e673ae7589e4d4216f -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Thu Sep 10 12:11:04 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 10 Sep 2015 14:11:04 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55E9A34E.3010808@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> Message-ID: <55F17358.4080601@redhat.com> On 09/04/2015 03:57 PM, Martin Babinsky wrote: > On 09/04/2015 11:06 AM, Lenka Doudova wrote: > >> Hi, >> >> >> >> there's no traceback in the file you mentioned, but I'm running it >> >> through lite-server, so here's the traceback from there: >> >> http://pastebin.test.redhat.com/310598 >> >> >> >> I can't really get to the problem. What I forgot to mention in the >> >> previous email was that the tests fail when attempting to add a >> >> certprofile, but if I try to do is manually using 'ipa >> >> certprofile-import' command with the exact same data as used in the >> >> test, it works fine. >> >> >> >> Lenka >> >> >> > Do you get the traceback also when you run the tests using > 'ipa-run-tests' with installed IPA master? > > > > > Hello, I don't think it is possible to run these tests against the lite server. Please do it on regular installation. Anyway, sorry for the long delay. I send the updated patches. I updated them to reflect the fix for rename option and extended about test with importing a profile from XML file. The test case may need to be updated, based on the resolution of [1]. This at the moment raises remote retrieve error (400 from dogtag), I think there should be more clear message (detecting xml). [1]: https://fedorahosted.org/freeipa/ticket/5294 Cheers, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0008.2-ipatests-Add-Certprofile-tracker-class-implementatio.patch Type: text/x-patch Size: 5922 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0009.2-ipatests-Add-basic-tests-for-certificate-profile-plu.patch Type: text/x-patch Size: 64603 bytes Desc: not available URL: From rcritten at redhat.com Thu Sep 10 12:58:26 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2015 08:58:26 -0400 Subject: [Freeipa-devel] [PATCH 0024] Handle timeout error in ipa-httpd-kdcproxy In-Reply-To: <55F1545F.1030107@redhat.com> References: <55F1545F.1030107@redhat.com> Message-ID: <55F17E72.5050107@redhat.com> Christian Heimes wrote: > The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. > A timeout does no longer result into an Apache startup error. > > https://fedorahosted.org/freeipa/ticket/5292 > > > > Since this is related to IPA not being configured yet would it make sense to call ipaserver.install.installutils.is_ipa_configured() and exit early and gracefully, doing no work, if it isn't? IMHO it should happen before the api is initialized. rob From cheimes at redhat.com Thu Sep 10 13:25:04 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 10 Sep 2015 15:25:04 +0200 Subject: [Freeipa-devel] [PATCH 0024] Handle timeout error in ipa-httpd-kdcproxy In-Reply-To: <55F17E72.5050107@redhat.com> References: <55F1545F.1030107@redhat.com> <55F17E72.5050107@redhat.com> Message-ID: <55F184B0.30409@redhat.com> On 2015-09-10 14:58, Rob Crittenden wrote: > Christian Heimes wrote: >> The ipa-httpd-kdcproxy script now handles LDAP timeout errors correctly. >> A timeout does no longer result into an Apache startup error. >> >> https://fedorahosted.org/freeipa/ticket/5292 >> >> >> >> > > > Since this is related to IPA not being configured yet would it make > sense to call ipaserver.install.installutils.is_ipa_configured() and > exit early and gracefully, doing no work, if it isn't? IMHO it should > happen before the api is initialized. That sounds like a very good idea! I didn't know about that API function. 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 redhatrises at gmail.com Thu Sep 10 14:08:22 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 10 Sep 2015 08:08:22 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: <55F1342D.90307@redhat.com> References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> Message-ID: Makes sense. I also changed the doc string to reflect -1 as well. Updated patch attached. Thanks, Gabe On Thu, Sep 10, 2015 at 1:41 AM, Jan Cholasta wrote: > On 4.9.2015 14:43, Gabe Alford wrote: > >> Bump for review. >> >> On Wed, Aug 12, 2015 at 9:32 AM, Gabe Alford > > wrote: >> >> On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta > > wrote: >> >> On 6.8.2015 21:43, Gabe Alford wrote: >> >> Hello, >> >> Updated patch attached. >> >> - Time limit is -1 for unlimited. I found this >> >> https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html >> in reference to keeping the time limit as -1 for unlimited. >> >> >> This patch does two conflicting things: it coerces time limit of >> 0 to -1 and at the same time prohibits the user to use 0 for >> time limit. We should do just one of these and IMHO it should be >> the coercion of 0 to -1. >> >> Sure enough, testing time limit at 0 did not work for >> unlimited as well >> as appeared to have negative effects on IPA. >> >> >> This is because the time limit read from ipa config is not >> converted to int in ldap2.find_entries(), so the coercion does >> not work. Fix this and 0 will work just fine. >> >> Also, I believe that >> >> http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s >> specifies unlimited for time limit as -1. (Please correct me >> if I am wrong.) >> >> >> python-ldap is layers below our API and should not determine >> what we use for unlimited time limit. I would prefer if we were >> self-consistent and use 0 for both time limit and size limit. >> >> >> A misunderstanding on my part as I thought it was higher up in the >> API for some reason. Updated patch attached. >> > > Thanks, this is better, but it turns out I was wrong about coercing -1 to > 0 in config-mod: in a topology with different versions of IPA servers, > setting the limits in LDAP to 0 on a newer server with your patch will > break older servers without your patch: > > [user at old]$ ipa user-find > -------------- > 1 user matched > -------------- > User login: admin > Last name: Administrator > Home directory: /home/admin > Login shell: /bin/bash > UID: 1364800000 > GID: 1364800000 > Account disabled: False > Password: True > Kerberos keys available: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > > [user at new]$ ipa config-mod --searchtimelimit=0 --searchrecordslimit=0 > ... > > [user at old]$ ipa user-find > --------------- > 0 users matched > --------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- > > To fix this, we actually need to do the opposite and store -1 in LDAP when > 0 is specified in config-mod options. > > Honza > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0053-6-Standardize-minvalue-for-ipasearchrecordlimit-and.patch Type: text/x-patch Size: 6835 bytes Desc: not available URL: From jcholast at redhat.com Thu Sep 10 14:15:33 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Sep 2015 16:15:33 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> Message-ID: <55F19085.3010106@redhat.com> I'm not sure about that, I think it should still say 0, because that's what we want to use as the unlimited value. If you insist on including -1 in the docs, maybe we can say "<= 0 is unlimited"? On 10.9.2015 16:08, Gabe Alford wrote: > Makes sense. I also changed the doc string to reflect -1 as well. > Updated patch attached. > > Thanks, > > Gabe > > On Thu, Sep 10, 2015 at 1:41 AM, Jan Cholasta > wrote: > > On 4.9.2015 14:43, Gabe Alford wrote: > > Bump for review. > > On Wed, Aug 12, 2015 at 9:32 AM, Gabe Alford > > >> > wrote: > > On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta > > >> > wrote: > > On 6.8.2015 21:43, Gabe Alford wrote: > > Hello, > > Updated patch attached. > > - Time limit is -1 for unlimited. I found this > https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html > in reference to keeping the time limit as -1 for > unlimited. > > > This patch does two conflicting things: it coerces time > limit of > 0 to -1 and at the same time prohibits the user to use > 0 for > time limit. We should do just one of these and IMHO it > should be > the coercion of 0 to -1. > > Sure enough, testing time limit at 0 did not work for > unlimited as well > as appeared to have negative effects on IPA. > > > This is because the time limit read from ipa config is not > converted to int in ldap2.find_entries(), so the > coercion does > not work. Fix this and 0 will work just fine. > > Also, I believe that > http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s > specifies unlimited for time limit as -1. (Please > correct me > if I am wrong.) > > > python-ldap is layers below our API and should not > determine > what we use for unlimited time limit. I would prefer if > we were > self-consistent and use 0 for both time limit and size > limit. > > > A misunderstanding on my part as I thought it was higher up > in the > API for some reason. Updated patch attached. > > > Thanks, this is better, but it turns out I was wrong about coercing > -1 to 0 in config-mod: in a topology with different versions of IPA > servers, setting the limits in LDAP to 0 on a newer server with your > patch will break older servers without your patch: > > [user at old]$ ipa user-find > -------------- > 1 user matched > -------------- > User login: admin > Last name: Administrator > Home directory: /home/admin > Login shell: /bin/bash > UID: 1364800000 > GID: 1364800000 > Account disabled: False > Password: True > Kerberos keys available: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > > [user at new]$ ipa config-mod --searchtimelimit=0 > --searchrecordslimit=0 > ... > > [user at old]$ ipa user-find > --------------- > 0 users matched > --------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- > > To fix this, we actually need to do the opposite and store -1 in > LDAP when 0 is specified in config-mod options. > > Honza > > -- > Jan Cholasta > > -- Jan Cholasta From mkosek at redhat.com Thu Sep 10 14:41:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Sep 2015 16:41:44 +0200 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <0B2EB1D0E2109A4CBD60C63A19995FB60123EB7EB5@EXCHDBALV1.Pilen.nordnet.se> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> <55F045C3.5040808@nordnet.se> <55F046ED.3010602@redhat.com> <2c69d075-4339-4b15-b2b0-5b1dbd84ed4c@email.android.com> <0B2EB1D0E2109A4CBD60C63A19995FB60123EB7EB5@EXCHDBALV1.Pilen.nordnet.se> Message-ID: <55F196A8.5060804@redhat.com> Hmm, does this mean we need to update our HowTo on migrating FreeIPA to FreeIPA via migrate-ds? It is already quite long command, mostly due to the need of removing Kerberos attributes: http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA Martin On 09/09/2015 09:40 PM, Andreas Calminder wrote: > Hi, > I just wanted to post the solution for this, I've reported this to Redhat and a bug has been filed (https://bugzilla.redhat.com/1261536). The problem was that migrate-ds copied the attribute mepManagedEntry on migration, the suggested workaround, running migrate-ds with --user-ignore-attribute=mepManagedEntry --user-ignore-objectclass=mepOriginEntry worked like a charm (Thanks Rob!), deleting users in active directory doesn't break the winsync agreement and I'm able to delete migrated users directly in ipa. As mentioned in the bug comments, migrate-ds isn't really for ipa to ipa migration. However, it kind of worked... > > /andreas > > From: freeipa-devel-bounces at redhat.com [mailto:freeipa-devel-bounces at redhat.com] On Behalf Of Andreas Calminder > Sent: den 9 september 2015 17:16 > To: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory > > Yes, kind of. I wanted a new environment with a proper certificate authority setup with only the old users and groups from the IPA 3.0 environment. The old environment use a self signed ca, I thought it would be easier to just migrate my users and groups. > On 9 Sep 2015 4:49 pm, Rob Crittenden wrote: > Andreas Calminder wrote: >> Hi, >> thanks for your reply, I'm able to list the user with ldapsearch and I >> can't find any conflict entries described in the article. The 4.1 >> environment is only 1 server connected to active directory. Forgot to >> reply to the list before, doh! >> >> I've noticed a difference between users in 3.0 and 4.1 though, migrated >> users in the 4.1 does not have an entry in " >> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this. >> Example: >> >> FreeIPA 4.1 environment: >> # ldapsearch -xLLL -D "cn=directory manager" -W >> -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >> Enter LDAP Password: >> No such object (32) Matched DN: >> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld >> >> FreeIPA 3.0 environment: >> # ldapsearch -xLLL -D "cn=directory manager" -W -b >> "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >> Enter LDAP Password: >> dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld >> objectClass: posixgroup >> objectClass: ipaobject >> objectClass: mepManagedEntry >> objectClass: top >> cn: batman >> gidNumber: 1486600065 >> description: User private group for batman >> mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld >> ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c > > Migrated users don't get user-private groups created. > > Is there a reason you migrated from 3.0 to 4.1 rather than just adding a > 4.1 master to the existing pool? > > rob > >> >> /andreas >> >> On 09/09/2015 04:29 PM, Rich Megginson wrote: >>> On 09/09/2015 03:39 AM, Martin Basti wrote: >>>> >>>> >>>> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>>>> Forgot to write that deleting users in active directory not migrated >>>>> with the migrate-ds command works fine, it's only migrated users >>>>> present in the ad that breaks the winsync agreement on deletion. >>>>> >>>>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>>>> Hi, >>>>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>>>> ask here as well, since I think I've actually hit a bug or (quite) >>>>>> possibly I've done something moronic configuration/migration -wise. >>>>>> >>>>>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>>>>> functioning winsync agreement and passsync service with the windows >>>>>> environments active directory, I'm trying to migrate the 3.0.0 >>>>>> environments users into a freshly installed 4.1 (rhel7) >>>>>> environment, after migration I setup a winsync agreement and make >>>>>> it bi-directional (one-way sync from windows) everything seems to >>>>>> be working alright until I delete a migrated user from the Active >>>>>> Directory, after the winsync picks up on the change it'll break and >>>>>> suggests a re-initialize. After the re-initialization the agreement >>>>>> seems to be fine, however the deleted user are still present in the >>>>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>>>> user and it's visible in the ui. >>>>>> >>>>>> Anyone had the same problem or anything similar or any pointers on >>>>>> where to start looking? >>>>>> >>>>>> Regards, >>>>>> Andreas >>>>>> >>>>> >>>> >>>> Hello, this might be a replication conflict. >>>> >>>> Can you list that user via ldapsearch to check if this is replication >>>> conflict? >>>> >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>> >>>> >>> Use the latest docs, just in case they are more accurate: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>> >>> >> >> >> > From rcritten at redhat.com Thu Sep 10 15:00:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2015 11:00:32 -0400 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55F196A8.5060804@redhat.com> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> <55F045C3.5040808@nordnet.se> <55F046ED.3010602@redhat.com> <2c69d075-4339-4b15-b2b0-5b1dbd84ed4c@email.android.com> <0B2EB1D0E2109A4CBD60C63A19995FB60123EB7EB5@EXCHDBALV1.Pilen.nordnet.se> <55F196A8.5060804@redhat.com> Message-ID: <55F19B10.30208@redhat.com> Martin Kosek wrote: > Hmm, does this mean we need to update our HowTo on migrating FreeIPA to FreeIPA > via migrate-ds? It is already quite long command, mostly due to the need of > removing Kerberos attributes: > > http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA I think it should. I haven't updated it because I never actually tested it to see that it worked as expected. It seems to be working for Andreas though. rob > > Martin > > On 09/09/2015 09:40 PM, Andreas Calminder wrote: >> Hi, >> I just wanted to post the solution for this, I've reported this to Redhat and a bug has been filed (https://bugzilla.redhat.com/1261536). The problem was that migrate-ds copied the attribute mepManagedEntry on migration, the suggested workaround, running migrate-ds with --user-ignore-attribute=mepManagedEntry --user-ignore-objectclass=mepOriginEntry worked like a charm (Thanks Rob!), deleting users in active directory doesn't break the winsync agreement and I'm able to delete migrated users directly in ipa. As mentioned in the bug comments, migrate-ds isn't really for ipa to ipa migration. However, it kind of worked... >> >> /andreas >> >> From: freeipa-devel-bounces at redhat.com [mailto:freeipa-devel-bounces at redhat.com] On Behalf Of Andreas Calminder >> Sent: den 9 september 2015 17:16 >> To: freeipa-devel at redhat.com >> Subject: Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory >> >> Yes, kind of. I wanted a new environment with a proper certificate authority setup with only the old users and groups from the IPA 3.0 environment. The old environment use a self signed ca, I thought it would be easier to just migrate my users and groups. >> On 9 Sep 2015 4:49 pm, Rob Crittenden wrote: >> Andreas Calminder wrote: >>> Hi, >>> thanks for your reply, I'm able to list the user with ldapsearch and I >>> can't find any conflict entries described in the article. The 4.1 >>> environment is only 1 server connected to active directory. Forgot to >>> reply to the list before, doh! >>> >>> I've noticed a difference between users in 3.0 and 4.1 though, migrated >>> users in the 4.1 does not have an entry in " >>> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this. >>> Example: >>> >>> FreeIPA 4.1 environment: >>> # ldapsearch -xLLL -D "cn=directory manager" -W >>> -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >>> Enter LDAP Password: >>> No such object (32) Matched DN: >>> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld >>> >>> FreeIPA 3.0 environment: >>> # ldapsearch -xLLL -D "cn=directory manager" -W -b >>> "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >>> Enter LDAP Password: >>> dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld >>> objectClass: posixgroup >>> objectClass: ipaobject >>> objectClass: mepManagedEntry >>> objectClass: top >>> cn: batman >>> gidNumber: 1486600065 >>> description: User private group for batman >>> mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld >>> ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c >> >> Migrated users don't get user-private groups created. >> >> Is there a reason you migrated from 3.0 to 4.1 rather than just adding a >> 4.1 master to the existing pool? >> >> rob >> >>> >>> /andreas >>> >>> On 09/09/2015 04:29 PM, Rich Megginson wrote: >>>> On 09/09/2015 03:39 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>>>>> Forgot to write that deleting users in active directory not migrated >>>>>> with the migrate-ds command works fine, it's only migrated users >>>>>> present in the ad that breaks the winsync agreement on deletion. >>>>>> >>>>>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>>>>> Hi, >>>>>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>>>>> ask here as well, since I think I've actually hit a bug or (quite) >>>>>>> possibly I've done something moronic configuration/migration -wise. >>>>>>> >>>>>>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>>>>>> functioning winsync agreement and passsync service with the windows >>>>>>> environments active directory, I'm trying to migrate the 3.0.0 >>>>>>> environments users into a freshly installed 4.1 (rhel7) >>>>>>> environment, after migration I setup a winsync agreement and make >>>>>>> it bi-directional (one-way sync from windows) everything seems to >>>>>>> be working alright until I delete a migrated user from the Active >>>>>>> Directory, after the winsync picks up on the change it'll break and >>>>>>> suggests a re-initialize. After the re-initialization the agreement >>>>>>> seems to be fine, however the deleted user are still present in the >>>>>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>>>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>>>>> user and it's visible in the ui. >>>>>>> >>>>>>> Anyone had the same problem or anything similar or any pointers on >>>>>>> where to start looking? >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>>>>> >>>>>> >>>>> >>>>> Hello, this might be a replication conflict. >>>>> >>>>> Can you list that user via ldapsearch to check if this is replication >>>>> conflict? >>>>> >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>>> >>>>> >>>> Use the latest docs, just in case they are more accurate: >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>> >>>> >>> >>> >>> >> > From pvoborni at redhat.com Thu Sep 10 15:06:40 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Sep 2015 17:06:40 +0200 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55F19B10.30208@redhat.com> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> <55F045C3.5040808@nordnet.se> <55F046ED.3010602@redhat.com> <2c69d075-4339-4b15-b2b0-5b1dbd84ed4c@email.android.com> <0B2EB1D0E2109A4CBD60C63A19995FB60123EB7EB5@EXCHDBALV1.Pilen.nordnet.se> <55F196A8.5060804@redhat.com> <55F19B10.30208@redhat.com> Message-ID: <55F19C80.3040201@redhat.com> On 09/10/2015 05:00 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> Hmm, does this mean we need to update our HowTo on migrating FreeIPA to FreeIPA >> via migrate-ds? It is already quite long command, mostly due to the need of >> removing Kerberos attributes: >> >> http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA > > I think it should. I haven't updated it because I never actually tested > it to see that it worked as expected. It seems to be working for Andreas > though. > > rob It works for me. I have updated the page. > >> >> Martin >> >> On 09/09/2015 09:40 PM, Andreas Calminder wrote: >>> Hi, >>> I just wanted to post the solution for this, I've reported this to Redhat and a bug has been filed (https://bugzilla.redhat.com/1261536). The problem was that migrate-ds copied the attribute mepManagedEntry on migration, the suggested workaround, running migrate-ds with --user-ignore-attribute=mepManagedEntry --user-ignore-objectclass=mepOriginEntry worked like a charm (Thanks Rob!), deleting users in active directory doesn't break the winsync agreement and I'm able to delete migrated users directly in ipa. As mentioned in the bug comments, migrate-ds isn't really for ipa to ipa migration. However, it kind of worked... >>> >>> /andreas >>> >>> From: freeipa-devel-bounces at redhat.com [mailto:freeipa-devel-bounces at redhat.com] On Behalf Of Andreas Calminder >>> Sent: den 9 september 2015 17:16 >>> To: freeipa-devel at redhat.com >>> Subject: Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory >>> >>> Yes, kind of. I wanted a new environment with a proper certificate authority setup with only the old users and groups from the IPA 3.0 environment. The old environment use a self signed ca, I thought it would be easier to just migrate my users and groups. >>> On 9 Sep 2015 4:49 pm, Rob Crittenden wrote: >>> Andreas Calminder wrote: >>>> Hi, >>>> thanks for your reply, I'm able to list the user with ldapsearch and I >>>> can't find any conflict entries described in the article. The 4.1 >>>> environment is only 1 server connected to active directory. Forgot to >>>> reply to the list before, doh! >>>> >>>> I've noticed a difference between users in 3.0 and 4.1 though, migrated >>>> users in the 4.1 does not have an entry in " >>>> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 have this. >>>> Example: >>>> >>>> FreeIPA 4.1 environment: >>>> # ldapsearch -xLLL -D "cn=directory manager" -W >>>> -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >>>> Enter LDAP Password: >>>> No such object (32) Matched DN: >>>> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld >>>> >>>> FreeIPA 3.0 environment: >>>> # ldapsearch -xLLL -D "cn=directory manager" -W -b >>>> "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >>>> Enter LDAP Password: >>>> dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld >>>> objectClass: posixgroup >>>> objectClass: ipaobject >>>> objectClass: mepManagedEntry >>>> objectClass: top >>>> cn: batman >>>> gidNumber: 1486600065 >>>> description: User private group for batman >>>> mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld >>>> ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c >>> >>> Migrated users don't get user-private groups created. >>> >>> Is there a reason you migrated from 3.0 to 4.1 rather than just adding a >>> 4.1 master to the existing pool? >>> >>> rob >>> >>>> >>>> /andreas >>>> >>>> On 09/09/2015 04:29 PM, Rich Megginson wrote: >>>>> On 09/09/2015 03:39 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>>>>>> Forgot to write that deleting users in active directory not migrated >>>>>>> with the migrate-ds command works fine, it's only migrated users >>>>>>> present in the ad that breaks the winsync agreement on deletion. >>>>>>> >>>>>>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>>>>>> Hi, >>>>>>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>>>>>> ask here as well, since I think I've actually hit a bug or (quite) >>>>>>>> possibly I've done something moronic configuration/migration -wise. >>>>>>>> >>>>>>>> I've got an existing FreeIPA 3.0.0 environment running with a fully >>>>>>>> functioning winsync agreement and passsync service with the windows >>>>>>>> environments active directory, I'm trying to migrate the 3.0.0 >>>>>>>> environments users into a freshly installed 4.1 (rhel7) >>>>>>>> environment, after migration I setup a winsync agreement and make >>>>>>>> it bi-directional (one-way sync from windows) everything seems to >>>>>>>> be working alright until I delete a migrated user from the Active >>>>>>>> Directory, after the winsync picks up on the change it'll break and >>>>>>>> suggests a re-initialize. After the re-initialization the agreement >>>>>>>> seems to be fine, however the deleted user are still present in the >>>>>>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>>>>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>>>>>> user and it's visible in the ui. >>>>>>>> >>>>>>>> Anyone had the same problem or anything similar or any pointers on >>>>>>>> where to start looking? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andreas >>>>>>>> >>>>>>> >>>>>> >>>>>> Hello, this might be a replication conflict. >>>>>> >>>>>> Can you list that user via ldapsearch to check if this is replication >>>>>> conflict? >>>>>> >>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>>>> >>>>>> >>>>> Use the latest docs, just in case they are more accurate: >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>>> >>>>> >>>> -- Petr Vobornik From mbasti at redhat.com Thu Sep 10 15:34:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 10 Sep 2015 17:34:50 +0200 Subject: [Freeipa-devel] [PATCH 0313] IPA Restore: allow to specify dirs/files which should be removed before restore Message-ID: <55F1A31A.7040302@redhat.com> https://fedorahosted.org/freeipa/ticket/5293 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0313-IPA-Restore-allows-to-specify-files-that-should-be-r.patch Type: text/x-patch Size: 2245 bytes Desc: not available URL: From mkubik at redhat.com Thu Sep 10 16:13:09 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 10 Sep 2015 18:13:09 +0200 Subject: [Freeipa-devel] INFO: CA ACL test and kerberos usage in functional tests Message-ID: <55F1AC15.6010205@redhat.com> Hi list, before my PTO, I was trying to write a functional test for CA ACLs with the tracker along all other acceptance/functional tests. I wasn't successful, the approach doesn't seem to work for CA ACLs as they have specific requirements for kerberos credentials that none of my attempts were able to met. I have tried several approaches and the memo I got out of this is that currently, there seems to be no way how to conveniently run a test that changes the user identity during the functional test (xmlrpc tests). I haven't had much time to write an integration test that should solve these problems with changing identity. The approaches I have tried include, in no particular order: * switch the default ccache to the identity desired, before calls made on an API object - in case of FILE ccache, moving it back and forth - in case of kernel keyring, using kswitch * instantiating another API instance in the process running the test, while the other ccache is active - the API object internals seem to prevent this as there is still a lot of shared state between the API instances * running the command supposed to have different identity as a subprocess after switching the identity - this attempt seemed to have inherited the opened connection to the backend from the parent python process, creating a conflict during the client bootstrap * injecting the KRB5CCNAME environment variable with second identity into the python process - the API instance doesn't seem to be affected by this value half of the times. - randomly, the new credentials are used, breaking all the things. Unable to change the user during the test, the code I wrote for this wasn't doing what I intended it to do because the admin user used in the tests overrides all CA ACLs. The patches implement the CA ACL tracker and, at the moment, one simple test. This can (and will) be extended to full CRUD test that will be run as a part of the acceptance suite, while functional test will be written as an integration test. I include the code that doesn't work as an example of what will be in the integration test. The patch 0013 needs to be applied after the certprofile tracker patch (0008). Cheers, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0012-ipatests-add-fuzzy-instances-for-CA-ACL-DN-and-RDN.patch Type: text/x-patch Size: 1096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0013-ipatests-Add-initial-CAACLTracker-implementation.patch Type: text/x-patch Size: 12251 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0014-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 1289 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: noapply-ipatests-CA-ACL-and-cert-profile-functional-test.patch Type: text/x-patch Size: 8149 bytes Desc: not available URL: From abokovoy at redhat.com Thu Sep 10 16:36:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 10 Sep 2015 19:36:52 +0300 Subject: [Freeipa-devel] INFO: CA ACL test and kerberos usage in functional tests In-Reply-To: <55F1AC15.6010205@redhat.com> References: <55F1AC15.6010205@redhat.com> Message-ID: <20150910163652.GF6168@redhat.com> On Thu, 10 Sep 2015, Milan Kub?k wrote: >Hi list, > >before my PTO, I was trying to write a functional test for CA ACLs >with the tracker along all other acceptance/functional tests. > >I wasn't successful, the approach doesn't seem to work for CA ACLs as >they have specific requirements for kerberos credentials >that none of my attempts were able to met. I have tried several >approaches and the memo I got out of this is that currently, there >seems to be no way how to conveniently run a test that changes the >user identity during the functional test (xmlrpc tests). > >I haven't had much time to write an integration test that should solve >these problems with changing identity. > >The approaches I have tried include, in no particular order: > >* switch the default ccache to the identity desired, before calls made >on an API object > - in case of FILE ccache, moving it back and forth > - in case of kernel keyring, using kswitch > >* instantiating another API instance in the process running the test, >while the other ccache is active > - the API object internals seem to prevent this as there is still >a lot of shared state between the API instances > >* running the command supposed to have different identity as a >subprocess after switching the identity > - this attempt seemed to have inherited the opened connection to >the backend from the parent python process, > creating a conflict during the client bootstrap > >* injecting the KRB5CCNAME environment variable with second identity >into the python process > - the API instance doesn't seem to be affected by this value half >of the times. > - randomly, the new credentials are used, breaking all the things. > >Unable to change the user during the test, the code I wrote for this >wasn't doing what I intended it to do >because the admin user used in the tests overrides all CA ACLs. One way to do it is to use keyctl to create subsessions for different authenticated users and switch between subsessions for the separate calls. See keyctl manual page and 'keyctl session ' part. -- / Alexander Bokovoy From mkubik at redhat.com Thu Sep 10 16:41:30 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 10 Sep 2015 18:41:30 +0200 Subject: [Freeipa-devel] INFO: CA ACL test and kerberos usage in functional tests In-Reply-To: <20150910163652.GF6168@redhat.com> References: <55F1AC15.6010205@redhat.com> <20150910163652.GF6168@redhat.com> Message-ID: <55F1B2BA.6080809@redhat.com> On 09/10/2015 06:36 PM, Alexander Bokovoy wrote: > On Thu, 10 Sep 2015, Milan Kub?k wrote: >> Hi list, >> >> before my PTO, I was trying to write a functional test for CA ACLs >> with the tracker along all other acceptance/functional tests. >> >> I wasn't successful, the approach doesn't seem to work for CA ACLs as >> they have specific requirements for kerberos credentials >> that none of my attempts were able to met. I have tried several >> approaches and the memo I got out of this is that currently, there >> seems to be no way how to conveniently run a test that changes the >> user identity during the functional test (xmlrpc tests). >> >> I haven't had much time to write an integration test that should >> solve these problems with changing identity. >> >> The approaches I have tried include, in no particular order: >> >> * switch the default ccache to the identity desired, before calls >> made on an API object >> - in case of FILE ccache, moving it back and forth >> - in case of kernel keyring, using kswitch >> >> * instantiating another API instance in the process running the test, >> while the other ccache is active >> - the API object internals seem to prevent this as there is still >> a lot of shared state between the API instances >> >> * running the command supposed to have different identity as a >> subprocess after switching the identity >> - this attempt seemed to have inherited the opened connection to >> the backend from the parent python process, >> creating a conflict during the client bootstrap >> >> * injecting the KRB5CCNAME environment variable with second identity >> into the python process >> - the API instance doesn't seem to be affected by this value half >> of the times. >> - randomly, the new credentials are used, breaking all the things. >> >> Unable to change the user during the test, the code I wrote for this >> wasn't doing what I intended it to do >> because the admin user used in the tests overrides all CA ACLs. > One way to do it is to use keyctl to create subsessions for different > authenticated users and switch between subsessions for the separate > calls. > > See keyctl manual page and 'keyctl session ' part. Thanks, I'll take a look at this next week. From mbasti at redhat.com Thu Sep 10 16:50:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 10 Sep 2015 18:50:41 +0200 Subject: [Freeipa-devel] [PATCH 0314] Server Upgrade: backup CS.cfg when dogtag is turnend off Message-ID: <55F1B4E1.6010705@redhat.com> https://fedorahosted.org/freeipa/ticket/5287 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0314-Server-Upgrade-backup-CS.cfg-when-dogtag-is-turned-o.patch Type: text/x-patch Size: 1246 bytes Desc: not available URL: From redhatrises at gmail.com Thu Sep 10 16:39:01 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 10 Sep 2015 10:39:01 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> Message-ID: Oops.. replied without the list. Reason I said -1 is because users might be confused if they enter `ipa config-mod --searchtimelimit=0`, and both `ipa user-show` and the webui show -1 instead of 0. I wonder if -1 makes more sense in that regard? Thoughts? Does "<= 0 is unlimited" make more sense? Thanks, Gabe On Thu, Sep 10, 2015 at 8:15 AM, Jan Cholasta wrote: > I'm not sure about that, I think it should still say 0, because that's > what we want to use as the unlimited value. If you insist on including -1 > in the docs, maybe we can say "<= 0 is unlimited"? > > On 10.9.2015 16:08, Gabe Alford wrote: > >> Makes sense. I also changed the doc string to reflect -1 as well. >> Updated patch attached. >> >> Thanks, >> >> Gabe >> >> On Thu, Sep 10, 2015 at 1:41 AM, Jan Cholasta > > wrote: >> >> On 4.9.2015 14:43, Gabe Alford wrote: >> >> Bump for review. >> >> On Wed, Aug 12, 2015 at 9:32 AM, Gabe Alford >> >> >> >> wrote: >> >> On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta >> >> >> >> >> wrote: >> >> On 6.8.2015 21:43, Gabe Alford wrote: >> >> Hello, >> >> Updated patch attached. >> >> - Time limit is -1 for unlimited. I found this >> >> https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html >> in reference to keeping the time limit as -1 for >> unlimited. >> >> >> This patch does two conflicting things: it coerces time >> limit of >> 0 to -1 and at the same time prohibits the user to use >> 0 for >> time limit. We should do just one of these and IMHO it >> should be >> the coercion of 0 to -1. >> >> Sure enough, testing time limit at 0 did not work for >> unlimited as well >> as appeared to have negative effects on IPA. >> >> >> This is because the time limit read from ipa config is >> not >> converted to int in ldap2.find_entries(), so the >> coercion does >> not work. Fix this and 0 will work just fine. >> >> Also, I believe that >> >> http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s >> specifies unlimited for time limit as -1. (Please >> correct me >> if I am wrong.) >> >> >> python-ldap is layers below our API and should not >> determine >> what we use for unlimited time limit. I would prefer if >> we were >> self-consistent and use 0 for both time limit and size >> limit. >> >> >> A misunderstanding on my part as I thought it was higher up >> in the >> API for some reason. Updated patch attached. >> >> >> Thanks, this is better, but it turns out I was wrong about coercing >> -1 to 0 in config-mod: in a topology with different versions of IPA >> servers, setting the limits in LDAP to 0 on a newer server with your >> patch will break older servers without your patch: >> >> [user at old]$ ipa user-find >> -------------- >> 1 user matched >> -------------- >> User login: admin >> Last name: Administrator >> Home directory: /home/admin >> Login shell: /bin/bash >> UID: 1364800000 >> GID: 1364800000 >> Account disabled: False >> Password: True >> Kerberos keys available: True >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> [user at new]$ ipa config-mod --searchtimelimit=0 >> --searchrecordslimit=0 >> ... >> >> [user at old]$ ipa user-find >> --------------- >> 0 users matched >> --------------- >> ---------------------------- >> Number of entries returned 0 >> ---------------------------- >> >> To fix this, we actually need to do the opposite and store -1 in >> LDAP when 0 is specified in config-mod options. >> >> Honza >> >> -- >> Jan Cholasta >> >> >> > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.calminder at nordnet.se Fri Sep 11 05:26:59 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Fri, 11 Sep 2015 07:26:59 +0200 Subject: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break winsync agreement when deleted in active directory In-Reply-To: <55F19C80.3040201@redhat.com> References: <55EFEF39.8080808@nordnet.se> <55EFF2EF.8020709@nordnet.se> <55EFFE67.4060406@redhat.com> <55F04243.1060205@redhat.com> <55F045C3.5040808@nordnet.se> <55F046ED.3010602@redhat.com> <2c69d075-4339-4b15-b2b0-5b1dbd84ed4c@email.android.com> <0B2EB1D0E2109A4CBD60C63A19995FB60123EB7EB5@EXCHDBALV1.Pilen.nordnet.se> <55F196A8.5060804@redhat.com> <55F19B10.30208@redhat.com> <55F19C80.3040201@redhat.com> Message-ID: <55F26623.8000800@nordnet.se> Can confirm, works well for me too. Thanks! On 09/10/2015 05:06 PM, Petr Vobornik wrote: > On 09/10/2015 05:00 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Hmm, does this mean we need to update our HowTo on migrating FreeIPA >>> to FreeIPA >>> via migrate-ds? It is already quite long command, mostly due to the >>> need of >>> removing Kerberos attributes: >>> >>> http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA >>> >> >> I think it should. I haven't updated it because I never actually tested >> it to see that it worked as expected. It seems to be working for Andreas >> though. >> >> rob > > It works for me. I have updated the page. > >> >>> >>> Martin >>> >>> On 09/09/2015 09:40 PM, Andreas Calminder wrote: >>>> Hi, >>>> I just wanted to post the solution for this, I've reported this to >>>> Redhat and a bug has been filed >>>> (https://bugzilla.redhat.com/1261536). The problem was that >>>> migrate-ds copied the attribute mepManagedEntry on migration, the >>>> suggested workaround, running migrate-ds with >>>> --user-ignore-attribute=mepManagedEntry >>>> --user-ignore-objectclass=mepOriginEntry worked like a charm >>>> (Thanks Rob!), deleting users in active directory doesn't break the >>>> winsync agreement and I'm able to delete migrated users directly in >>>> ipa. As mentioned in the bug comments, migrate-ds isn't really for >>>> ipa to ipa migration. However, it kind of worked... >>>> >>>> /andreas >>>> >>>> From: freeipa-devel-bounces at redhat.com >>>> [mailto:freeipa-devel-bounces at redhat.com] On Behalf Of Andreas >>>> Calminder >>>> Sent: den 9 september 2015 17:16 >>>> To: freeipa-devel at redhat.com >>>> Subject: Re: [Freeipa-devel] IPA 3.0 migrated to 4.1 users break >>>> winsync agreement when deleted in active directory >>>> >>>> Yes, kind of. I wanted a new environment with a proper certificate >>>> authority setup with only the old users and groups from the IPA 3.0 >>>> environment. The old environment use a self signed ca, I thought it >>>> would be easier to just migrate my users and groups. >>>> On 9 Sep 2015 4:49 pm, Rob Crittenden wrote: >>>> Andreas Calminder wrote: >>>>> Hi, >>>>> thanks for your reply, I'm able to list the user with ldapsearch >>>>> and I >>>>> can't find any conflict entries described in the article. The 4.1 >>>>> environment is only 1 server connected to active directory. Forgot to >>>>> reply to the list before, doh! >>>>> >>>>> I've noticed a difference between users in 3.0 and 4.1 though, >>>>> migrated >>>>> users in the 4.1 does not have an entry in " >>>>> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" while users in 3.0 >>>>> have this. >>>>> Example: >>>>> >>>>> FreeIPA 4.1 environment: >>>>> # ldapsearch -xLLL -D "cn=directory manager" -W >>>>> -b"cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >>>>> Enter LDAP Password: >>>>> No such object (32) Matched DN: >>>>> cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld >>>>> >>>>> FreeIPA 3.0 environment: >>>>> # ldapsearch -xLLL -D "cn=directory manager" -W -b >>>>> "cn=batman,cn=groups,cn=accounts,dc=sub,dc=domain,dc=tld" >>>>> Enter LDAP Password: >>>>> dn: cn=batman,cn=groups,cn=accounts,dc=dev,dc=sub,dc=domain,dc=tld >>>>> objectClass: posixgroup >>>>> objectClass: ipaobject >>>>> objectClass: mepManagedEntry >>>>> objectClass: top >>>>> cn: batman >>>>> gidNumber: 1486600065 >>>>> description: User private group for batman >>>>> mepManagedBy: uid=batman,cn=users,cn=accounts,dc=sub,dc=domain,dc=tld >>>>> ipaUniqueID: 139f6140-5074-11e5-a09d-005056914c0c >>>> >>>> Migrated users don't get user-private groups created. >>>> >>>> Is there a reason you migrated from 3.0 to 4.1 rather than just >>>> adding a >>>> 4.1 master to the existing pool? >>>> >>>> rob >>>> >>>>> >>>>> /andreas >>>>> >>>>> On 09/09/2015 04:29 PM, Rich Megginson wrote: >>>>>> On 09/09/2015 03:39 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 09/09/2015 10:50 AM, Andreas Calminder wrote: >>>>>>>> Forgot to write that deleting users in active directory not >>>>>>>> migrated >>>>>>>> with the migrate-ds command works fine, it's only migrated users >>>>>>>> present in the ad that breaks the winsync agreement on deletion. >>>>>>>> >>>>>>>> On 09/09/2015 10:35 AM, Andreas Calminder wrote: >>>>>>>>> Hi, >>>>>>>>> I've asked in #freeipa on freenode but to no avail, figured I'll >>>>>>>>> ask here as well, since I think I've actually hit a bug or >>>>>>>>> (quite) >>>>>>>>> possibly I've done something moronic configuration/migration >>>>>>>>> -wise. >>>>>>>>> >>>>>>>>> I've got an existing FreeIPA 3.0.0 environment running with a >>>>>>>>> fully >>>>>>>>> functioning winsync agreement and passsync service with the >>>>>>>>> windows >>>>>>>>> environments active directory, I'm trying to migrate the 3.0.0 >>>>>>>>> environments users into a freshly installed 4.1 (rhel7) >>>>>>>>> environment, after migration I setup a winsync agreement and make >>>>>>>>> it bi-directional (one-way sync from windows) everything >>>>>>>>> seems to >>>>>>>>> be working alright until I delete a migrated user from the Active >>>>>>>>> Directory, after the winsync picks up on the change it'll >>>>>>>>> break and >>>>>>>>> suggests a re-initialize. After the re-initialization the >>>>>>>>> agreement >>>>>>>>> seems to be fine, however the deleted user are still present >>>>>>>>> in the >>>>>>>>> ipa 4.1 environment and cannot be deleted. The webgui and ipa cli >>>>>>>>> says: ipauser1: user not found. ipa user-find ipauser1 finds the >>>>>>>>> user and it's visible in the ui. >>>>>>>>> >>>>>>>>> Anyone had the same problem or anything similar or any >>>>>>>>> pointers on >>>>>>>>> where to start looking? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Andreas >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hello, this might be a replication conflict. >>>>>>> >>>>>>> Can you list that user via ldapsearch to check if this is >>>>>>> replication >>>>>>> conflict? >>>>>>> >>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>>>>> >>>>>>> >>>>>>> >>>>>> Use the latest docs, just in case they are more accurate: >>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>>>> >>>>>> >>>>>> >>>>> > > > From ldoudova at redhat.com Fri Sep 11 07:51:24 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 11 Sep 2015 09:51:24 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F17358.4080601@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> Message-ID: <55F287FC.2030707@redhat.com> On 09/10/2015 02:11 PM, Milan Kub?k wrote: > On 09/04/2015 03:57 PM, Martin Babinsky wrote: >> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >> >>> Hi, >>> >>> >>> >>> there's no traceback in the file you mentioned, but I'm running it >>> >>> through lite-server, so here's the traceback from there: >>> >>> http://pastebin.test.redhat.com/310598 >>> >>> >>> >>> I can't really get to the problem. What I forgot to mention in the >>> >>> previous email was that the tests fail when attempting to add a >>> >>> certprofile, but if I try to do is manually using 'ipa >>> >>> certprofile-import' command with the exact same data as used in the >>> >>> test, it works fine. >>> >>> >>> >>> Lenka >>> >>> >>> >> Do you get the traceback also when you run the tests using >> 'ipa-run-tests' with installed IPA master? >> >> >> >> >> > Hello, > > I don't think it is possible to run these tests against the lite > server. Please do it on regular installation. > > Anyway, sorry for the long delay. I send the updated patches. > I updated them to reflect the fix for rename option and extended about > test with importing a profile from XML file. The test case may need to > be updated, based on the resolution of [1]. > This at the moment raises remote retrieve error (400 from dogtag), I > think there should be more clear message (detecting xml). > > [1]: https://fedorahosted.org/freeipa/ticket/5294 > > > Cheers, > Milan Hi, can't build rpms after applying the patches (namely patch 0009.2): Module ipatests.test_xmlrpc.utils ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] Module 'py' has no 'path' member) Lenka From mbasti at redhat.com Fri Sep 11 08:23:39 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 10:23:39 +0200 Subject: [Freeipa-devel] [PATCH 0312] CI: extend backup restore tests with DNS/DNSSEC In-Reply-To: <55F143C5.2070802@redhat.com> References: <55F13DA4.7050800@redhat.com> <55F143C5.2070802@redhat.com> Message-ID: <55F28F8B.8080904@redhat.com> On 09/10/2015 10:48 AM, Martin Basti wrote: > Self NACK > > On 09/10/2015 10:21 AM, Martin Basti wrote: >> Patch attached. >> >> > > > Updated patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0312.2-backup-CI-test-DNS-DNSSEC-after-backup-and-restore.patch Type: text/x-patch Size: 7212 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 11 08:27:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 10:27:03 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F287FC.2030707@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> Message-ID: <55F29057.5050800@redhat.com> On 09/11/2015 09:51 AM, Lenka Doudova wrote: > > > On 09/10/2015 02:11 PM, Milan Kub?k wrote: >> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> there's no traceback in the file you mentioned, but I'm running it >>>> >>>> through lite-server, so here's the traceback from there: >>>> >>>> http://pastebin.test.redhat.com/310598 >>>> >>>> >>>> >>>> I can't really get to the problem. What I forgot to mention in the >>>> >>>> previous email was that the tests fail when attempting to add a >>>> >>>> certprofile, but if I try to do is manually using 'ipa >>>> >>>> certprofile-import' command with the exact same data as used in the >>>> >>>> test, it works fine. >>>> >>>> >>>> >>>> Lenka >>>> >>>> >>>> >>> Do you get the traceback also when you run the tests using >>> 'ipa-run-tests' with installed IPA master? >>> >>> >>> >>> >>> >> Hello, >> >> I don't think it is possible to run these tests against the lite >> server. Please do it on regular installation. >> >> Anyway, sorry for the long delay. I send the updated patches. >> I updated them to reflect the fix for rename option and extended >> about test with importing a profile from XML file. The test case may >> need to be updated, based on the resolution of [1]. >> This at the moment raises remote retrieve error (400 from dogtag), I >> think there should be more clear message (detecting xml). >> >> [1]: https://fedorahosted.org/freeipa/ticket/5294 >> >> >> Cheers, >> Milan > > Hi, > > can't build rpms after applying the patches (namely patch 0009.2): > > Module ipatests.test_xmlrpc.utils > ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] > Module 'py' has no 'path' member) > > > Lenka > Do we need new util.py in test_xmlrpc? Why not just add it into existing ipatests/util.py? From mkubik at redhat.com Fri Sep 11 08:52:15 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 11 Sep 2015 10:52:15 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F29057.5050800@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> Message-ID: <55F2963F.8040902@redhat.com> On 09/11/2015 10:27 AM, Martin Basti wrote: > > > On 09/11/2015 09:51 AM, Lenka Doudova wrote: >> >> >> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> there's no traceback in the file you mentioned, but I'm running it >>>>> >>>>> through lite-server, so here's the traceback from there: >>>>> >>>>> http://pastebin.test.redhat.com/310598 >>>>> >>>>> >>>>> >>>>> I can't really get to the problem. What I forgot to mention in the >>>>> >>>>> previous email was that the tests fail when attempting to add a >>>>> >>>>> certprofile, but if I try to do is manually using 'ipa >>>>> >>>>> certprofile-import' command with the exact same data as used in the >>>>> >>>>> test, it works fine. >>>>> >>>>> >>>>> >>>>> Lenka >>>>> >>>>> >>>>> >>>> Do you get the traceback also when you run the tests using >>>> 'ipa-run-tests' with installed IPA master? >>>> >>>> >>>> >>>> >>>> >>> Hello, >>> >>> I don't think it is possible to run these tests against the lite >>> server. Please do it on regular installation. >>> >>> Anyway, sorry for the long delay. I send the updated patches. >>> I updated them to reflect the fix for rename option and extended >>> about test with importing a profile from XML file. The test case may >>> need to be updated, based on the resolution of [1]. >>> This at the moment raises remote retrieve error (400 from dogtag), I >>> think there should be more clear message (detecting xml). >>> >>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>> >>> >>> Cheers, >>> Milan >> >> Hi, >> >> can't build rpms after applying the patches (namely patch 0009.2): >> >> Module ipatests.test_xmlrpc.utils >> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] >> Module 'py' has no 'path' member) >> >> >> Lenka >> > Do we need new util.py in test_xmlrpc? Why not just add it into > existing ipatests/util.py? > > I will move it there. From mkubik at redhat.com Fri Sep 11 09:45:24 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 11 Sep 2015 11:45:24 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F29057.5050800@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> Message-ID: <55F2A2B4.7090705@redhat.com> On 09/11/2015 10:27 AM, Martin Basti wrote: > > > On 09/11/2015 09:51 AM, Lenka Doudova wrote: >> >> >> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> there's no traceback in the file you mentioned, but I'm running it >>>>> >>>>> through lite-server, so here's the traceback from there: >>>>> >>>>> http://pastebin.test.redhat.com/310598 >>>>> >>>>> >>>>> >>>>> I can't really get to the problem. What I forgot to mention in the >>>>> >>>>> previous email was that the tests fail when attempting to add a >>>>> >>>>> certprofile, but if I try to do is manually using 'ipa >>>>> >>>>> certprofile-import' command with the exact same data as used in the >>>>> >>>>> test, it works fine. >>>>> >>>>> >>>>> >>>>> Lenka >>>>> >>>>> >>>>> >>>> Do you get the traceback also when you run the tests using >>>> 'ipa-run-tests' with installed IPA master? >>>> >>>> >>>> >>>> >>>> >>> Hello, >>> >>> I don't think it is possible to run these tests against the lite >>> server. Please do it on regular installation. >>> >>> Anyway, sorry for the long delay. I send the updated patches. >>> I updated them to reflect the fix for rename option and extended >>> about test with importing a profile from XML file. The test case may >>> need to be updated, based on the resolution of [1]. >>> This at the moment raises remote retrieve error (400 from dogtag), I >>> think there should be more clear message (detecting xml). >>> >>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>> >>> >>> Cheers, >>> Milan >> >> Hi, >> >> can't build rpms after applying the patches (namely patch 0009.2): >> >> Module ipatests.test_xmlrpc.utils >> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] >> Module 'py' has no 'path' member) >> >> >> Lenka >> > Do we need new util.py in test_xmlrpc? Why not just add it into > existing ipatests/util.py? > > Updated patch attached. Changes: content of ipatests.test_xmlrpc.utils moved to ipatests.utils make-lint updated to ignore py.path submodule -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0009.3-ipatests-Add-basic-tests-for-certificate-profile-plu.patch Type: text/x-patch Size: 65226 bytes Desc: not available URL: From ldoudova at redhat.com Fri Sep 11 10:43:56 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 11 Sep 2015 12:43:56 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F2A2B4.7090705@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> Message-ID: <55F2B06C.2070801@redhat.com> On 09/11/2015 11:45 AM, Milan Kub?k wrote: > On 09/11/2015 10:27 AM, Martin Basti wrote: >> >> >> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>> >>> >>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> there's no traceback in the file you mentioned, but I'm running it >>>>>> >>>>>> through lite-server, so here's the traceback from there: >>>>>> >>>>>> http://pastebin.test.redhat.com/310598 >>>>>> >>>>>> >>>>>> >>>>>> I can't really get to the problem. What I forgot to mention in the >>>>>> >>>>>> previous email was that the tests fail when attempting to add a >>>>>> >>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>> >>>>>> certprofile-import' command with the exact same data as used in the >>>>>> >>>>>> test, it works fine. >>>>>> >>>>>> >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>>> >>>>> Do you get the traceback also when you run the tests using >>>>> 'ipa-run-tests' with installed IPA master? >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Hello, >>>> >>>> I don't think it is possible to run these tests against the lite >>>> server. Please do it on regular installation. >>>> >>>> Anyway, sorry for the long delay. I send the updated patches. >>>> I updated them to reflect the fix for rename option and extended >>>> about test with importing a profile from XML file. The test case >>>> may need to be updated, based on the resolution of [1]. >>>> This at the moment raises remote retrieve error (400 from dogtag), >>>> I think there should be more clear message (detecting xml). >>>> >>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>> >>>> >>>> Cheers, >>>> Milan >>> >>> Hi, >>> >>> can't build rpms after applying the patches (namely patch 0009.2): >>> >>> Module ipatests.test_xmlrpc.utils >>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] >>> Module 'py' has no 'path' member) >>> >>> >>> Lenka >>> >> Do we need new util.py in test_xmlrpc? Why not just add it into >> existing ipatests/util.py? >> >> > Updated patch attached. > Changes: > content of ipatests.test_xmlrpc.utils moved to ipatests.utils > make-lint updated to ignore py.path submodule Again got an error: Module ipatests.test_xmlrpc.test_certprofile_plugin ipatests/test_xmlrpc/test_certprofile_plugin.py:16: [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') Probably just extra 's' in: from ipatests.utils import prepare_config Lenka From mkubik at redhat.com Fri Sep 11 11:47:15 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 11 Sep 2015 13:47:15 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F2B06C.2070801@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> <55F2B06C.2070801@redhat.com> Message-ID: <55F2BF43.4080903@redhat.com> On 09/11/2015 12:43 PM, Lenka Doudova wrote: > > > > > On 09/11/2015 11:45 AM, Milan Kub?k wrote: > >> On 09/11/2015 10:27 AM, Martin Basti wrote: >> >>> >>> >>> >>> >>> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>> >>>> >>>> >>>> >>>> >>>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>> >>>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>> >>>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> there's no traceback in the file you mentioned, but I'm running it >>>>>>> >>>>>>> >>>>>>> >>>>>>> through lite-server, so here's the traceback from there: >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://pastebin.test.redhat.com/310598 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I can't really get to the problem. What I forgot to mention in the >>>>>>> >>>>>>> >>>>>>> >>>>>>> previous email was that the tests fail when attempting to add a >>>>>>> >>>>>>> >>>>>>> >>>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>>> >>>>>>> >>>>>>> >>>>>>> certprofile-import' command with the exact same data as used in the >>>>>>> >>>>>>> >>>>>>> >>>>>>> test, it works fine. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Do you get the traceback also when you run the tests using >>>>>> >>>>>> 'ipa-run-tests' with installed IPA master? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> I don't think it is possible to run these tests against the lite >>>>> server. Please do it on regular installation. >>>>> >>>>> >>>>> >>>>> Anyway, sorry for the long delay. I send the updated patches. >>>>> >>>>> I updated them to reflect the fix for rename option and extended >>>>> about test with importing a profile from XML file. The test case >>>>> may need to be updated, based on the resolution of [1]. >>>>> >>>>> This at the moment raises remote retrieve error (400 from dogtag), >>>>> I think there should be more clear message (detecting xml). >>>>> >>>>> >>>>> >>>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Milan >>>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> can't build rpms after applying the patches (namely patch 0009.2): >>>> >>>> >>>> >>>> Module ipatests.test_xmlrpc.utils >>>> >>>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] >>>> Module 'py' has no 'path' member) >>>> >>>> >>>> >>>> >>>> >>>> Lenka >>>> >>>> >>>> >>> Do we need new util.py in test_xmlrpc? Why not just add it into >>> existing ipatests/util.py? >>> >>> >>> >>> >>> >> Updated patch attached. >> >> Changes: >> >> content of ipatests.test_xmlrpc.utils moved to ipatests.utils >> >> make-lint updated to ignore py.path submodule >> > > > Again got an error: > > > > Module ipatests.test_xmlrpc.test_certprofile_plugin > > > > ipatests/test_xmlrpc/test_certprofile_plugin.py:16: > [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') > > > > > > Probably just extra 's' in: > > > > from ipatests.utils import prepare_config > > > > Lenka > > > Typo fixed. Removed the py module from the code after an offline discussion. Patch attached. Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0009.4-ipatests-Add-basic-tests-for-certificate-profile-plu.patch Type: text/x-patch Size: 64483 bytes Desc: not available URL: From dkupka at redhat.com Fri Sep 11 11:50:58 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 11 Sep 2015 13:50:58 +0200 Subject: [Freeipa-devel] [PATCH 0314] Server Upgrade: backup CS.cfg when dogtag is turnend off In-Reply-To: <55F1B4E1.6010705@redhat.com> References: <55F1B4E1.6010705@redhat.com> Message-ID: <55F2C022.3060306@redhat.com> On 10/09/15 18:50, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5287 > > Patch attached. > > Works for me, ACK. -- David Kupka From mbasti at redhat.com Fri Sep 11 11:57:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 13:57:20 +0200 Subject: [Freeipa-devel] [PATCH 0314] Server Upgrade: backup CS.cfg when dogtag is turnend off In-Reply-To: <55F2C022.3060306@redhat.com> References: <55F1B4E1.6010705@redhat.com> <55F2C022.3060306@redhat.com> Message-ID: <55F2C1A0.20009@redhat.com> On 09/11/2015 01:50 PM, David Kupka wrote: > On 10/09/15 18:50, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5287 >> >> Patch attached. >> >> > Works for me, ACK. > Pushed to: master: 5762ad951fca025f17d00095bd7d89a14536ae85 ipa-4-2: c3d8a138aaad52af9c10ef8816b23cc81d79a680 From mbabinsk at redhat.com Fri Sep 11 12:40:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 11 Sep 2015 14:40:05 +0200 Subject: [Freeipa-devel] INFO: CA ACL test and kerberos usage in functional tests In-Reply-To: <55F1B2BA.6080809@redhat.com> References: <55F1AC15.6010205@redhat.com> <20150910163652.GF6168@redhat.com> <55F1B2BA.6080809@redhat.com> Message-ID: <55F2CBA5.6010908@redhat.com> On 09/10/2015 06:41 PM, Milan Kub?k wrote: > On 09/10/2015 06:36 PM, Alexander Bokovoy wrote: >> On Thu, 10 Sep 2015, Milan Kub?k wrote: >>> Hi list, >>> >>> before my PTO, I was trying to write a functional test for CA ACLs >>> with the tracker along all other acceptance/functional tests. >>> >>> I wasn't successful, the approach doesn't seem to work for CA ACLs as >>> they have specific requirements for kerberos credentials >>> that none of my attempts were able to met. I have tried several >>> approaches and the memo I got out of this is that currently, there >>> seems to be no way how to conveniently run a test that changes the >>> user identity during the functional test (xmlrpc tests). >>> >>> I haven't had much time to write an integration test that should >>> solve these problems with changing identity. >>> >>> The approaches I have tried include, in no particular order: >>> >>> * switch the default ccache to the identity desired, before calls >>> made on an API object >>> - in case of FILE ccache, moving it back and forth >>> - in case of kernel keyring, using kswitch >>> >>> * instantiating another API instance in the process running the test, >>> while the other ccache is active >>> - the API object internals seem to prevent this as there is still >>> a lot of shared state between the API instances >>> >>> * running the command supposed to have different identity as a >>> subprocess after switching the identity >>> - this attempt seemed to have inherited the opened connection to >>> the backend from the parent python process, >>> creating a conflict during the client bootstrap >>> >>> * injecting the KRB5CCNAME environment variable with second identity >>> into the python process >>> - the API instance doesn't seem to be affected by this value half >>> of the times. >>> - randomly, the new credentials are used, breaking all the things. >>> >>> Unable to change the user during the test, the code I wrote for this >>> wasn't doing what I intended it to do >>> because the admin user used in the tests overrides all CA ACLs. >> One way to do it is to use keyctl to create subsessions for different >> authenticated users and switch between subsessions for the separate >> calls. >> >> See keyctl manual page and 'keyctl session ' part. > Thanks, I'll take a look at this next week. > Maybe you can also try to wrap the user auth, connection and API calls in 'ipapython.ipautil.private_ccache' context manager like this: """ from ipalib import api from ipapython.ipautil import private_ccache, kinit_password, run api.bootstrap() api.finalize() tmp_ccache='krb5cc_jdoe' run(['klist']) # should list admin as default principal with private_ccache(tmp_ccache): kinit_password(u'jdoe', u'jdoepasswd', tmp_ccache) run(['klist']) # lists jdoe as default principal api.Backend.rpcclient.connect(ccache=tmp_ccache) api.Command.ping() api.backend.rpcclient.disconnect() run(['klist']) # KRB5CCNAME should be reset back to admin ccache """ I have tested it and it seems to work. I haven't played with it very extensively, though. -- Martin^3 Babinsky From mbasti at redhat.com Fri Sep 11 12:44:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 14:44:50 +0200 Subject: [Freeipa-devel] [PATCH 0313] IPA Restore: allow to specify dirs/files which should be removed before restore In-Reply-To: <55F1A31A.7040302@redhat.com> References: <55F1A31A.7040302@redhat.com> Message-ID: <55F2CCC2.308@redhat.com> On 09/10/2015 05:34 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5293 > > Patch attached. > > Updated patch attached. * list of dirs/files was moved to class (the same way is in ipa-backup) * log errors if dir/file cannot be removed (errors other than dir/file does not exist) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0313.2-IPA-Restore-allows-to-specify-files-that-should-be-r.patch Type: text/x-patch Size: 2690 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 11 12:49:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 14:49:26 +0200 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <1441288581.28131.212.camel@willson.usersys.redhat.com> References: <55E71C63.1060907@redhat.com> <1441209638.28131.175.camel@willson.usersys.redhat.com> <55E80297.20709@redhat.com> <1441284125.28131.197.camel@willson.usersys.redhat.com> <55E84C0A.9030702@redhat.com> <1441288581.28131.212.camel@willson.usersys.redhat.com> Message-ID: <55F2CDD6.4040401@redhat.com> On 09/03/2015 03:56 PM, Simo Sorce wrote: > On Thu, 2015-09-03 at 15:32 +0200, Martin Basti wrote: >> On 09/03/2015 02:42 PM, Simo Sorce wrote: >>> On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote: >>>> On 09/02/2015 06:00 PM, Simo Sorce wrote: >>>>> On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: >>>>>> Client installation is done as "Restarting web server". This step >>>>>> deserve own message. >>>>>> >>>>>> Patch attached >>>>> I've seen various cases like this. And I can't understand why these >>>>> steps aren't embedded in the actual instance install steps that need the >>>>> restart (which implicitly also provide a message). >>>>> >>>>> In the promotion patchset I did move steps like this into the proper >>>>> instances, so I would prefer you do the same with the install path as >>>>> that is more appropriate. >>>>> >>>>> Simo. >>>>> >>>> We need restart httpd after CA, DNS(optional) installation, so thats why >>>> it is outside of httpd instance. >>> You need to restart httpd always after CA install as it changes the >>> proxy settings, but why do you need to restart it after DNS >>> installation ? >> It is needed due changes in resolv.conf >>> (I think it is fine to restart it twice if it is really needed after DNS >>> change). >> IMO it is waste of time to restart httpd twice in one minute >> >> Can we resolve this in 4.4, where might be place to finish improvements >> in installer? (If this is not blocking replica promotion) > Ok, it is not important enough to waste time now. > > Simo. > Can be this patch pushed to master then? Martin^2 From dkupka at redhat.com Fri Sep 11 12:56:24 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 11 Sep 2015 14:56:24 +0200 Subject: [Freeipa-devel] [PATCH 0313] IPA Restore: allow to specify dirs/files which should be removed before restore In-Reply-To: <55F2CCC2.308@redhat.com> References: <55F1A31A.7040302@redhat.com> <55F2CCC2.308@redhat.com> Message-ID: <55F2CF78.1090202@redhat.com> On 11/09/15 14:44, Martin Basti wrote: > > > On 09/10/2015 05:34 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5293 >> >> Patch attached. >> >> > > Updated patch attached. > > * list of dirs/files was moved to class (the same way is in ipa-backup) > * log errors if dir/file cannot be removed (errors other than dir/file > does not exist) > Looks good to me and works as expected, ACK. -- David Kupka From mbasti at redhat.com Fri Sep 11 12:58:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 14:58:59 +0200 Subject: [Freeipa-devel] [PATCH 0313] IPA Restore: allow to specify dirs/files which should be removed before restore In-Reply-To: <55F2CF78.1090202@redhat.com> References: <55F1A31A.7040302@redhat.com> <55F2CCC2.308@redhat.com> <55F2CF78.1090202@redhat.com> Message-ID: <55F2D013.9090506@redhat.com> On 09/11/2015 02:56 PM, David Kupka wrote: > On 11/09/15 14:44, Martin Basti wrote: >> >> >> On 09/10/2015 05:34 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5293 >>> >>> Patch attached. >>> >>> >> >> Updated patch attached. >> >> * list of dirs/files was moved to class (the same way is in ipa-backup) >> * log errors if dir/file cannot be removed (errors other than dir/file >> does not exist) >> > Looks good to me and works as expected, ACK. > Pushed to: master: f8f5bd644aee5c54acc857061868e659ae449e48 ipa-4-2: 21f2a3d1731a43551cc130356329bcadba7ffdfe From pviktori at redhat.com Fri Sep 11 13:24:01 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 11 Sep 2015 15:24:01 +0200 Subject: [Freeipa-devel] [PATCHES 481-486] Metaclass and str modernization In-Reply-To: <55ED2864.1010404@redhat.com> References: <55E5BA6C.2080502@redhat.com> <55E881FE.6010807@redhat.com> <55ED2864.1010404@redhat.com> Message-ID: <55F2D5F1.9090900@redhat.com> On 09/07/2015 08:02 AM, Jan Cholasta wrote: > On 3.9.2015 19:23, Petr Viktorin wrote: >> On 09/01/2015 04:47 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches add some more modernization to our code. [...] >> 484: >> To avoid merge conflicts later, perhaps it would be better to have >> >> if six.PY3: >> unicode = str >> >> at the start of each affected file, instead of scattering changes in the >> files? >> (I can prepare the patch if you agree) > > (Be my guest) > >> >> >> 485: >> six.binary_type is named "bytes" since Python 2.6. I think it would be >> better to use that, to avoid another change when py2 is dropped. >> (I can prepare the patch here, too) > > (OK) > >> >> >> 486: ACK Here are the two patches updated to use "unicode" and "bytes". -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-484.2-Alias-unicode-to-str-under-Python-3.patch Type: text/x-patch Size: 58517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-485.2-Use-bytes-instead-of-str-where-appropriate.patch Type: text/x-patch Size: 11213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-486.2-Use-byte-literals-where-appropriate.patch Type: text/x-patch Size: 11559 bytes Desc: not available URL: From simo at redhat.com Fri Sep 11 14:00:40 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 11 Sep 2015 10:00:40 -0400 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <55F2CDD6.4040401@redhat.com> References: <55E71C63.1060907@redhat.com> <1441209638.28131.175.camel@willson.usersys.redhat.com> <55E80297.20709@redhat.com> <1441284125.28131.197.camel@willson.usersys.redhat.com> <55E84C0A.9030702@redhat.com> <1441288581.28131.212.camel@willson.usersys.redhat.com> <55F2CDD6.4040401@redhat.com> Message-ID: <1441980040.29376.19.camel@willson.usersys.redhat.com> On Fri, 2015-09-11 at 14:49 +0200, Martin Basti wrote: > > On 09/03/2015 03:56 PM, Simo Sorce wrote: > > On Thu, 2015-09-03 at 15:32 +0200, Martin Basti wrote: > >> On 09/03/2015 02:42 PM, Simo Sorce wrote: > >>> On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote: > >>>> On 09/02/2015 06:00 PM, Simo Sorce wrote: > >>>>> On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: > >>>>>> Client installation is done as "Restarting web server". This step > >>>>>> deserve own message. > >>>>>> > >>>>>> Patch attached > >>>>> I've seen various cases like this. And I can't understand why these > >>>>> steps aren't embedded in the actual instance install steps that need the > >>>>> restart (which implicitly also provide a message). > >>>>> > >>>>> In the promotion patchset I did move steps like this into the proper > >>>>> instances, so I would prefer you do the same with the install path as > >>>>> that is more appropriate. > >>>>> > >>>>> Simo. > >>>>> > >>>> We need restart httpd after CA, DNS(optional) installation, so thats why > >>>> it is outside of httpd instance. > >>> You need to restart httpd always after CA install as it changes the > >>> proxy settings, but why do you need to restart it after DNS > >>> installation ? > >> It is needed due changes in resolv.conf > >>> (I think it is fine to restart it twice if it is really needed after DNS > >>> change). > >> IMO it is waste of time to restart httpd twice in one minute > >> > >> Can we resolve this in 4.4, where might be place to finish improvements > >> in installer? (If this is not blocking replica promotion) > > Ok, it is not important enough to waste time now. > > > > Simo. > > > > Can be this patch pushed to master then? Yes -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Sep 11 14:07:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 16:07:00 +0200 Subject: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed In-Reply-To: <1441980040.29376.19.camel@willson.usersys.redhat.com> References: <55E71C63.1060907@redhat.com> <1441209638.28131.175.camel@willson.usersys.redhat.com> <55E80297.20709@redhat.com> <1441284125.28131.197.camel@willson.usersys.redhat.com> <55E84C0A.9030702@redhat.com> <1441288581.28131.212.camel@willson.usersys.redhat.com> <55F2CDD6.4040401@redhat.com> <1441980040.29376.19.camel@willson.usersys.redhat.com> Message-ID: <55F2E004.9050903@redhat.com> On 09/11/2015 04:00 PM, Simo Sorce wrote: > On Fri, 2015-09-11 at 14:49 +0200, Martin Basti wrote: >> On 09/03/2015 03:56 PM, Simo Sorce wrote: >>> On Thu, 2015-09-03 at 15:32 +0200, Martin Basti wrote: >>>> On 09/03/2015 02:42 PM, Simo Sorce wrote: >>>>> On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote: >>>>>> On 09/02/2015 06:00 PM, Simo Sorce wrote: >>>>>>> On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote: >>>>>>>> Client installation is done as "Restarting web server". This step >>>>>>>> deserve own message. >>>>>>>> >>>>>>>> Patch attached >>>>>>> I've seen various cases like this. And I can't understand why these >>>>>>> steps aren't embedded in the actual instance install steps that need the >>>>>>> restart (which implicitly also provide a message). >>>>>>> >>>>>>> In the promotion patchset I did move steps like this into the proper >>>>>>> instances, so I would prefer you do the same with the install path as >>>>>>> that is more appropriate. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> We need restart httpd after CA, DNS(optional) installation, so thats why >>>>>> it is outside of httpd instance. >>>>> You need to restart httpd always after CA install as it changes the >>>>> proxy settings, but why do you need to restart it after DNS >>>>> installation ? >>>> It is needed due changes in resolv.conf >>>>> (I think it is fine to restart it twice if it is really needed after DNS >>>>> change). >>>> IMO it is waste of time to restart httpd twice in one minute >>>> >>>> Can we resolve this in 4.4, where might be place to finish improvements >>>> in installer? (If this is not blocking replica promotion) >>> Ok, it is not important enough to waste time now. >>> >>> Simo. >>> >> Can be this patch pushed to master then? > Yes > Pushed to master: 7f0076b9a5f2aced1f27b976217309be2eec0b1c From mbasti at redhat.com Fri Sep 11 14:42:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Sep 2015 16:42:51 +0200 Subject: [Freeipa-devel] [PATCH 0315] CI: backup&restore with KRA installed Message-ID: <55F2E86B.7040904@redhat.com> Patch mbasti-0312-2 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0315-CI-backup-and-restore-with-KRA.patch Type: text/x-patch Size: 3534 bytes Desc: not available URL: From jcholast at redhat.com Mon Sep 14 05:23:09 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Sep 2015 07:23:09 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> Message-ID: <55F659BD.5040507@redhat.com> IMO it does, because saying just "-1 is default" is not entirely correct and "0 is default" would be confusing, as you pointed out. You might say "0 or -1 is unlimited" if you think it's clearer. On 10.9.2015 18:39, Gabe Alford wrote: > Oops.. replied without the list. > > Reason I said -1 is because users might be confused if they enter `ipa > config-mod --searchtimelimit=0`, and both `ipa user-show` and the webui > show -1 instead of 0. I wonder if -1 makes more sense in that regard? > Thoughts? Does "<= 0 is unlimited" make more sense? > > Thanks, > > Gabe > > > On Thu, Sep 10, 2015 at 8:15 AM, Jan Cholasta > wrote: > > I'm not sure about that, I think it should still say 0, because > that's what we want to use as the unlimited value. If you insist on > including -1 in the docs, maybe we can say "<= 0 is unlimited"? > > On 10.9.2015 16:08, Gabe Alford wrote: > > Makes sense. I also changed the doc string to reflect -1 as well. > Updated patch attached. > > Thanks, > > Gabe > > On Thu, Sep 10, 2015 at 1:41 AM, Jan Cholasta > > >> wrote: > > On 4.9.2015 14:43, Gabe Alford wrote: > > Bump for review. > > On Wed, Aug 12, 2015 at 9:32 AM, Gabe Alford > > > > >>> > wrote: > > On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta > > > > >>> > > wrote: > > On 6.8.2015 21:43, Gabe Alford wrote: > > Hello, > > Updated patch attached. > > - Time limit is -1 for unlimited. I found this > https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html > in reference to keeping the time limit as > -1 for > unlimited. > > > This patch does two conflicting things: it > coerces time > limit of > 0 to -1 and at the same time prohibits the > user to use > 0 for > time limit. We should do just one of these and > IMHO it > should be > the coercion of 0 to -1. > > Sure enough, testing time limit at 0 did > not work for > unlimited as well > as appeared to have negative effects on IPA. > > > This is because the time limit read from ipa > config is not > converted to int in ldap2.find_entries(), so the > coercion does > not work. Fix this and 0 will work just fine. > > Also, I believe that > http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s > specifies unlimited for time limit as -1. > (Please > correct me > if I am wrong.) > > > python-ldap is layers below our API and should not > determine > what we use for unlimited time limit. I would > prefer if > we were > self-consistent and use 0 for both time limit > and size > limit. > > > A misunderstanding on my part as I thought it was > higher up > in the > API for some reason. Updated patch attached. > > > Thanks, this is better, but it turns out I was wrong about > coercing > -1 to 0 in config-mod: in a topology with different > versions of IPA > servers, setting the limits in LDAP to 0 on a newer server > with your > patch will break older servers without your patch: > > [user at old]$ ipa user-find > -------------- > 1 user matched > -------------- > User login: admin > Last name: Administrator > Home directory: /home/admin > Login shell: /bin/bash > UID: 1364800000 > GID: 1364800000 > Account disabled: False > Password: True > Kerberos keys available: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > > [user at new]$ ipa config-mod --searchtimelimit=0 > --searchrecordslimit=0 > ... > > [user at old]$ ipa user-find > --------------- > 0 users matched > --------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- > > To fix this, we actually need to do the opposite and store > -1 in > LDAP when 0 is specified in config-mod options. > > Honza > > -- > Jan Cholasta > > > > > -- > Jan Cholasta > > > -- Jan Cholasta From pspacek at redhat.com Mon Sep 14 07:34:31 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 14 Sep 2015 09:34:31 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: <55F659BD.5040507@redhat.com> References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> <55F659BD.5040507@redhat.com> Message-ID: <55F67887.2000905@redhat.com> On 14.9.2015 07:23, Jan Cholasta wrote: > IMO it does, because saying just "-1 is default" is not entirely correct and > "0 is default" would be confusing, as you pointed out. You might say "0 or -1 > is unlimited" if you think it's clearer. my +1 to "0 or -1 is unlimited" variant Petr^2 Spacek > On 10.9.2015 18:39, Gabe Alford wrote: >> Oops.. replied without the list. >> >> Reason I said -1 is because users might be confused if they enter `ipa >> config-mod --searchtimelimit=0`, and both `ipa user-show` and the webui >> show -1 instead of 0. I wonder if -1 makes more sense in that regard? >> Thoughts? Does "<= 0 is unlimited" make more sense? >> >> Thanks, >> >> Gabe From jcholast at redhat.com Mon Sep 14 07:44:04 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Sep 2015 09:44:04 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55F060BE.6030403@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> <55E68898.1000300@redhat.com> <55E8488E.5070308@redhat.com> <55EF4DD6.5010706@redhat.com> <55EFF35C.3050007@redhat.com> <55F060BE.6030403@redhat.com> Message-ID: <55F67AC4.8080300@redhat.com> On 9.9.2015 18:39, Petr Vobornik wrote: > On 09/09/2015 10:52 AM, Jan Cholasta wrote: >> On 8.9.2015 23:06, Petr Vobornik wrote: >>> On 09/03/2015 03:18 PM, Jan Cholasta wrote: >>>> On 2.9.2015 07:26, Endi Sukma Dewata wrote: >>>>> On 9/1/2015 10:22 AM, Simo Sorce wrote: >>>>>> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >>>>>>> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>>>>>>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>>>>>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>>>>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>>>>>>> adds commands: >>>>>>>>>>> * vaultcontainer-show [--service |--user ] >>>>>>>>>>> * vaultcontainer-add-owner >>>>>>>>>>> [--service |--user ] >>>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>>> ] >>>>>>>>>>> * vaultcontainer-remove-owner >>>>>>>>>>> [--service |--user ] >>>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>>> ] >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>>>>>>> >>>>>>>>>>> Use cases: >>>>>>>>>>> 1. When user/service is deleted, associated vault container >>>>>>>>>>> looses >>>>>>>>>>> owner. There was no API command to set the owner. >>>>>>>>>>> 2. Change owner of container by admin to manage access. >>>>>>>>>>> >>>>>>>>>>> Show command was added to show current owners. >>>>>>>>>>> >>>>>>>>>>> Find command was not added, should it be? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There is also a design for vault container ownership handling >>>>>>>>>> created by >>>>>>>>>> Endi - it's for future Vault 2.0. >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This patch has a different API than the proposed - different >>>>>>>>>> way of >>>>>>>>>> specifying the container. The design page uses path e.g. >>>>>>>>>> /users/foobar. >>>>>>>>>> This patch uses the same way as vaults e.g. --user=foobar. This >>>>>>>>>> means >>>>>>>>>> that the implementation in this patch cannot manage ownership of >>>>>>>>>> parent >>>>>>>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>>>>>>> >>>>>>>>>> Do we want to go with this approach in 4.2? >>>>>>>>>> >>>>>>>>>> Attaching also new path which removes setting of owner which >>>>>>>>>> doesn't >>>>>>>>>> exist so that integrity is OK and that it is consistent with >>>>>>>>>> removing of >>>>>>>>>> user. >>>>>>>>>> >>>>>>>>>> Updated patch attached - output fix. >>>>>>>>> >>>>>>>>> We had a long discussion about this with Petr and we think the >>>>>>>>> best >>>>>>>>> approach is as follows: >>>>>>>>> >>>>>>>>> * Add new "Vault administrators" privilege. Vault >>>>>>>>> administrators will >>>>>>>>> have unrestricted access to vaults and vault containers, including >>>>>>>>> the >>>>>>>>> power to add/remove owners of vaults and vault containers. >>>>>>>>> >>>>>>>>> * Remove the ability of vault owners to add/remove other vault >>>>>>>>> owners. If vault owner needs to be changed, vault administrator >>>>>>>>> has to >>>>>>>>> do it. Note that vault owners will still have the ability to >>>>>>>>> add/remove >>>>>>>>> vault members. >>>>>>>>> >>>>>>>>> * When adding new vault container, set owner to the current >>>>>>>>> user. If >>>>>>>>> vault container owner needs to be changed, vault administrator has >>>>>>>>> to do >>>>>>>>> it. >>>>>>>>> >>>>>>>>> * Allow adding vaults and vault containers only if the >>>>>>>>> owner is >>>>>>>>> set >>>>>>>>> to the current user. >>>>>>>>> >>>>>>>>> * Introduce commands to modify vault container owner and to >>>>>>>>> delete >>>>>>>>> vault container, so the administrator has a choice between >>>>>>>>> assigning >>>>>>>>> ownership or deleting an unowned container. >>>>>>>> >>>>>>>> Also: >>>>>>>> >>>>>>>> * Control access to vault data using an ipaProtectedOperation >>>>>>>> ACI. >>>>>>>> Users which have read access to "ipaProtectedOperation;accessKRA" >>>>>>>> on a >>>>>>>> vault can retrieve data from the vault and users which have write >>>>>>>> access >>>>>>>> to "ipaProtectedOperation;accessKRA" on a vault can archive data in >>>>>>>> the >>>>>>>> vault. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> CCing Simo and Endi to check the proposal. >>>>>>> >>>>>>> And Scott (related to #5216, #5215) >>>>>> >>>>>> Sounds reasonable to me. >>>>>> I can see that allowing owners to hand over vaults w/o admin >>>>>> intervention may have some appeal in some use cases, but I also >>>>>> see it >>>>>> can bring downsides with it, so all in all I think I agree with the >>>>>> above points. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> Not a total objection, but if many people in unrelated groups are >>>>> using >>>>> vaults, and they are sharing the vaults only with members of each >>>>> group, >>>>> having to ask a Vault Administrator for each ownership change sounds a >>>>> bit cumbersome. Since the Vault Adminstrator will have access to all >>>>> vaults in all groups, only a small number of people can be trusted to >>>>> hold that role. If there are many ownership changes the Vault >>>>> Administrator will have to handle all those requests, and the vault >>>>> users may have to wait until the change is completed. >>>>> >>>>> If owners are allowed to add others as owners, the vaults will be >>>>> pretty >>>>> much maintenance free to the admin. >>>> >>>> Owners can still manage members, which is IMO good enough for sharing a >>>> vault with other users. >>>> >>>>> >>>>> Regardless, please update the wiki page to describe the new behavior >>>>> when it's implemented: >>>>> http://www.freeipa.org/page/V4/Password_Vault_1.1 >>>> >>>> Sure. >>>> >>>> I have updated and rebased Petr's patch 916. >>>> >>>> Patch 488 obsoletes Petr's patch 918. >>>> >>>> Patch for vault data access control is not included, because I was not >>>> able to make GER work correctly with "ipaProtectedOperation;accessKRA". >>>> >>> >>> I found 1 major issue(#3), one easy fix(#2), optional(#1) and a question >>> (#4). >>> >>> 1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a >>> blocker. >>> >>> [pvoborni at vm-063 ~]$ ipa vaultcontainer-del --user=fbar >>> -------------------------- >>> Deleted vault container "" >>> -------------------------- >> >> Fixed. >> >>> >>> >>> 2. Invalid description of vaultcontainer-show >>> "Display information about a vault." >> >> Fixed >> >>> >>> 3. Something which needs to be fixed: >>> >>> Setting password for first vault without a vault container fails(here >>> run as vault admin but the same issue is present when it's run as the >>> user). >>> >>> [pvoborni at vm-063 ~]$ ipa vault-add f1 --user=fbar >>> New password: >>> Verify password: >>> ipa: ERROR: Invalid credentials >>> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >>> --------------- >>> 1 vault matched >>> --------------- >>> Vault name: f1 >>> Type: symmetric >>> Vault user: fbar >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >> >> Works for me. Are you testing on master or ipa-4-2? > > I might have not copied a required file during the testing. It works for > me now as well. > >> >>> >>> Second works: >>> >>> [pvoborni at vm-063 ~]$ ipa vault-add f2 --user=fbar >>> New password: >>> Verify password: >>> ** Passwords do not match! ** >>> New password: >>> Verify password: >>> ---------------- >>> Added vault "f2" >>> ---------------- >>> Vault name: f2 >>> Type: symmetric >>> Salt: w4tnrjW/Ra2jGS8lI6Frfg== >>> Owner users: va >>> Vault user: fbar >>> >>> >>> >>> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >>> ---------------- >>> 2 vaults matched >>> ---------------- >>> Vault name: f1 >>> Type: symmetric >>> Vault user: fbar >>> >>> Vault name: f2 >>> Type: symmetric >>> Vault user: fbar >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >>> >>> >>> 4. Q: Should vault container owner delete all its vault? >> >> I don't know, should it? IMO it shouldn't, at least not by default. >> >>> >>> As fbar when there is a vault without fbar as owner >>> >>> [root at vm-063 pvoborni]# ipa vaultcontainer-del >>> ipa: ERROR: Not allowed on non-leaf entry >>> >>> when fbar is added as owner to all vaults >>> >>> [root at vm-063 pvoborni]# ipa vaultcontainer-del >>> -------------------------- >>> Deleted vault container "" >>> -------------------------- >>> [root at vm-063 pvoborni]# ipa vault-add f1 >>> New password: >>> Verify password: >>> ipa: ERROR: Invalid credentials >>> [root at vm-063 pvoborni]# ipa vault-del f1 >>> ------------------ >>> Deleted vault "f1" >>> ------------------ >>> [root at vm-063 pvoborni]# ipa vault-add f1 >>> New password: >>> Verify password: >>> ---------------- >>> Added vault "f1" >>> ---------------- >>> Vault name: f1 >>> Type: symmetric >>> Salt: bkHxRIipkaeX+H/fOnZdBw== >>> Owner users: fbar >>> Vault user: fbar >>> >> >> > > Updated and rebased patches attached. Added new patch 491 to support KRA updates. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0916-3-vault-add-vault-container-commands.patch Type: text/x-patch Size: 12788 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-488.1-vault-set-owner-to-current-user-on-container-creatio.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-489.1-vault-update-access-control.patch Type: text/x-patch Size: 6173 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-490.1-vault-add-permissions-and-administrator-privilege.patch Type: text/x-patch Size: 11138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-491-install-support-KRA-update.patch Type: text/x-patch Size: 14508 bytes Desc: not available URL: From pspacek at redhat.com Mon Sep 14 08:00:00 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 14 Sep 2015 10:00:00 +0200 Subject: [Freeipa-devel] Fwd: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02: service->realm mapping In-Reply-To: <55E868E8.6050504@openfortress.nl> References: <55E868E8.6050504@openfortress.nl> Message-ID: <55F67E80.7000107@redhat.com> Hello, Kerberos experts might be interested in this draft. I did not have time to go through this yet. Discussion continues on dnsext at ietf.org, please reply there. Petr^2 Spacek -------- Forwarded Message -------- Subject: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt Date: Thu, 03 Sep 2015 17:36:08 +0200 From: Rick van Rein To: dnsext at ietf.org Hello, I am working on an I-D that allocates a new RRtype in DNS, named KREALM. This RR is meant to store Kerberos realm descriptions in DNS; this has hitherto been desired but impossible to do securely, but nowadays the broad acceptance of DNSSEC permits this facility. Please let me know if you have any feedback or questions! Cheers, Rick van Rein for ARPA2.net > A new version of I-D, draft-vanrein-dnstxt-krb1-02.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-dnstxt-krb1 > Revision: 02 > Title: Kerberos Realm Descriptors in DNS (KREALM) > Document date: 2015-09-03 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-dnstxt-krb1-02.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-dnstxt-krb1-02 > > Abstract: > This specification defines methods to determine Kerberos realm > descriptive information for services that are known by their DNS > name. Currently, finding such information is done through static > mappings or educated guessing. DNS can make this process more > dynamic, provided that DNSSEC is used to ensure authenticity of > resource records. > _______________________________________________ dnsext mailing list dnsext at ietf.org https://www.ietf.org/mailman/listinfo/dnsext -- Petr^2 Spacek From ldoudova at redhat.com Mon Sep 14 08:10:30 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 14 Sep 2015 10:10:30 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F2BF43.4080903@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> <55F2B06C.2070801@redhat.com> <55F2BF43.4080903@redhat.com> Message-ID: <55F680F6.7040203@redhat.com> NACK because: $ pep8 ipatests/test_xmlrpc/test_certprofile_plugin.py ipatests/test_xmlrpc/test_certprofile_plugin.py:213:8: E121 continuation line under-indented for hanging indent (just a missing space in the indent) Lenka On 09/11/2015 01:47 PM, Milan Kub?k wrote: > On 09/11/2015 12:43 PM, Lenka Doudova wrote: >> >> >> >> >> On 09/11/2015 11:45 AM, Milan Kub?k wrote: >> >>> On 09/11/2015 10:27 AM, Martin Basti wrote: >>> >>>> >>>> >>>> >>>> >>>> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>>> >>>>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>>> >>>>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> there's no traceback in the file you mentioned, but I'm running it >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> through lite-server, so here's the traceback from there: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://pastebin.test.redhat.com/310598 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I can't really get to the problem. What I forgot to mention in the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> previous email was that the tests fail when attempting to add a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> certprofile-import' command with the exact same data as used in >>>>>>>> the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> test, it works fine. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Lenka >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Do you get the traceback also when you run the tests using >>>>>>> >>>>>>> 'ipa-run-tests' with installed IPA master? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> I don't think it is possible to run these tests against the lite >>>>>> server. Please do it on regular installation. >>>>>> >>>>>> >>>>>> >>>>>> Anyway, sorry for the long delay. I send the updated patches. >>>>>> >>>>>> I updated them to reflect the fix for rename option and extended >>>>>> about test with importing a profile from XML file. The test case >>>>>> may need to be updated, based on the resolution of [1]. >>>>>> >>>>>> This at the moment raises remote retrieve error (400 from dogtag), >>>>>> I think there should be more clear message (detecting xml). >>>>>> >>>>>> >>>>>> >>>>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Milan >>>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> can't build rpms after applying the patches (namely patch 0009.2): >>>>> >>>>> >>>>> >>>>> Module ipatests.test_xmlrpc.utils >>>>> >>>>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] >>>>> Module 'py' has no 'path' member) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Lenka >>>>> >>>>> >>>>> >>>> Do we need new util.py in test_xmlrpc? Why not just add it into >>>> existing ipatests/util.py? >>>> >>>> >>>> >>>> >>>> >>> Updated patch attached. >>> >>> Changes: >>> >>> content of ipatests.test_xmlrpc.utils moved to ipatests.utils >>> >>> make-lint updated to ignore py.path submodule >>> >> >> >> Again got an error: >> >> >> >> Module ipatests.test_xmlrpc.test_certprofile_plugin >> >> >> >> ipatests/test_xmlrpc/test_certprofile_plugin.py:16: >> [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') >> >> >> >> >> >> Probably just extra 's' in: >> >> >> >> from ipatests.utils import prepare_config >> >> >> >> Lenka >> >> >> > Typo fixed. Removed the py module from the code after an offline > discussion. > Patch attached. > > Milan > From mkubik at redhat.com Mon Sep 14 09:54:00 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 14 Sep 2015 11:54:00 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F680F6.7040203@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> <55F2B06C.2070801@redhat.com> <55F2BF43.4080903@redhat.com> <55F680F6.7040203@redhat.com> Message-ID: <55F69938.6000101@redhat.com> On 09/14/2015 10:10 AM, Lenka Doudova wrote: > NACK because: > > $ pep8 ipatests/test_xmlrpc/test_certprofile_plugin.py > ipatests/test_xmlrpc/test_certprofile_plugin.py:213:8: E121 > continuation line under-indented for hanging indent > > (just a missing space in the indent) > > Lenka > > On 09/11/2015 01:47 PM, Milan Kub?k wrote: >> On 09/11/2015 12:43 PM, Lenka Doudova wrote: >>> >>> >>> >>> >>> On 09/11/2015 11:45 AM, Milan Kub?k wrote: >>> >>>> On 09/11/2015 10:27 AM, Martin Basti wrote: >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>>>> >>>>>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>>>> >>>>>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> there's no traceback in the file you mentioned, but I'm >>>>>>>>> running it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> through lite-server, so here's the traceback from there: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://pastebin.test.redhat.com/310598 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I can't really get to the problem. What I forgot to mention in >>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> previous email was that the tests fail when attempting to add a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> certprofile-import' command with the exact same data as used >>>>>>>>> in the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> test, it works fine. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Lenka >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Do you get the traceback also when you run the tests using >>>>>>>> >>>>>>>> 'ipa-run-tests' with installed IPA master? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't think it is possible to run these tests against the lite >>>>>>> server. Please do it on regular installation. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Anyway, sorry for the long delay. I send the updated patches. >>>>>>> >>>>>>> I updated them to reflect the fix for rename option and extended >>>>>>> about test with importing a profile from XML file. The test case >>>>>>> may need to be updated, based on the resolution of [1]. >>>>>>> >>>>>>> This at the moment raises remote retrieve error (400 from dogtag), >>>>>>> I think there should be more clear message (detecting xml). >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Milan >>>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> can't build rpms after applying the patches (namely patch 0009.2): >>>>>> >>>>>> >>>>>> >>>>>> Module ipatests.test_xmlrpc.utils >>>>>> >>>>>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), prepare_config] >>>>>> Module 'py' has no 'path' member) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>>> >>>>> Do we need new util.py in test_xmlrpc? Why not just add it into >>>>> existing ipatests/util.py? >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Updated patch attached. >>>> >>>> Changes: >>>> >>>> content of ipatests.test_xmlrpc.utils moved to ipatests.utils >>>> >>>> make-lint updated to ignore py.path submodule >>>> >>> >>> >>> Again got an error: >>> >>> >>> >>> Module ipatests.test_xmlrpc.test_certprofile_plugin >>> >>> >>> >>> ipatests/test_xmlrpc/test_certprofile_plugin.py:16: >>> [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') >>> >>> >>> >>> >>> >>> Probably just extra 's' in: >>> >>> >>> >>> from ipatests.utils import prepare_config >>> >>> >>> >>> Lenka >>> >>> >>> >> Typo fixed. Removed the py module from the code after an offline >> discussion. >> Patch attached. >> >> Milan >> > Fixed. Patch attached. Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0009.5-ipatests-Add-basic-tests-for-certificate-profile-plu.patch Type: text/x-patch Size: 64487 bytes Desc: not available URL: From ldoudova at redhat.com Mon Sep 14 11:49:50 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 14 Sep 2015 13:49:50 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F69938.6000101@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> <55F2B06C.2070801@redhat.com> <55F2BF43.4080903@redhat.com> <55F680F6.7040203@redhat.com> <55F69938.6000101@redhat.com> Message-ID: <55F6B45E.2020404@redhat.com> All good, ACK On 09/14/2015 11:54 AM, Milan Kub?k wrote: > On 09/14/2015 10:10 AM, Lenka Doudova wrote: >> NACK because: >> >> $ pep8 ipatests/test_xmlrpc/test_certprofile_plugin.py >> ipatests/test_xmlrpc/test_certprofile_plugin.py:213:8: E121 >> continuation line under-indented for hanging indent >> >> (just a missing space in the indent) >> >> Lenka >> >> On 09/11/2015 01:47 PM, Milan Kub?k wrote: >>> On 09/11/2015 12:43 PM, Lenka Doudova wrote: >>>> >>>> >>>> >>>> >>>> On 09/11/2015 11:45 AM, Milan Kub?k wrote: >>>> >>>>> On 09/11/2015 10:27 AM, Martin Basti wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>>>>> >>>>>>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>>>>> >>>>>>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> there's no traceback in the file you mentioned, but I'm >>>>>>>>>> running it >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> through lite-server, so here's the traceback from there: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://pastebin.test.redhat.com/310598 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can't really get to the problem. What I forgot to mention >>>>>>>>>> in the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> previous email was that the tests fail when attempting to add a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> certprofile-import' command with the exact same data as used >>>>>>>>>> in the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test, it works fine. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Lenka >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Do you get the traceback also when you run the tests using >>>>>>>>> >>>>>>>>> 'ipa-run-tests' with installed IPA master? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I don't think it is possible to run these tests against the lite >>>>>>>> server. Please do it on regular installation. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Anyway, sorry for the long delay. I send the updated patches. >>>>>>>> >>>>>>>> I updated them to reflect the fix for rename option and extended >>>>>>>> about test with importing a profile from XML file. The test case >>>>>>>> may need to be updated, based on the resolution of [1]. >>>>>>>> >>>>>>>> This at the moment raises remote retrieve error (400 from dogtag), >>>>>>>> I think there should be more clear message (detecting xml). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Milan >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> can't build rpms after applying the patches (namely patch 0009.2): >>>>>>> >>>>>>> >>>>>>> >>>>>>> Module ipatests.test_xmlrpc.utils >>>>>>> >>>>>>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), >>>>>>> prepare_config] >>>>>>> Module 'py' has no 'path' member) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> >>>>>>> >>>>>> Do we need new util.py in test_xmlrpc? Why not just add it into >>>>>> existing ipatests/util.py? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Updated patch attached. >>>>> >>>>> Changes: >>>>> >>>>> content of ipatests.test_xmlrpc.utils moved to ipatests.utils >>>>> >>>>> make-lint updated to ignore py.path submodule >>>>> >>>> >>>> >>>> Again got an error: >>>> >>>> >>>> >>>> Module ipatests.test_xmlrpc.test_certprofile_plugin >>>> >>>> >>>> >>>> ipatests/test_xmlrpc/test_certprofile_plugin.py:16: >>>> [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') >>>> >>>> >>>> >>>> >>>> >>>> Probably just extra 's' in: >>>> >>>> >>>> >>>> from ipatests.utils import prepare_config >>>> >>>> >>>> >>>> Lenka >>>> >>>> >>>> >>> Typo fixed. Removed the py module from the code after an offline >>> discussion. >>> Patch attached. >>> >>> Milan >>> >> > Fixed. Patch attached. > > Milan From redhatrises at gmail.com Mon Sep 14 12:58:10 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 14 Sep 2015 06:58:10 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: <55F67887.2000905@redhat.com> References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> <55F659BD.5040507@redhat.com> <55F67887.2000905@redhat.com> Message-ID: Sounds good to me. Updated patch attached. On Mon, Sep 14, 2015 at 1:34 AM, Petr Spacek wrote: > On 14.9.2015 07:23, Jan Cholasta wrote: > > IMO it does, because saying just "-1 is default" is not entirely correct > and > > "0 is default" would be confusing, as you pointed out. You might say "0 > or -1 > > is unlimited" if you think it's clearer. > > my +1 to "0 or -1 is unlimited" variant > > Petr^2 Spacek > > > > On 10.9.2015 18:39, Gabe Alford wrote: > >> Oops.. replied without the list. > >> > >> Reason I said -1 is because users might be confused if they enter `ipa > >> config-mod --searchtimelimit=0`, and both `ipa user-show` and the webui > >> show -1 instead of 0. I wonder if -1 makes more sense in that regard? > >> Thoughts? Does "<= 0 is unlimited" make more sense? > >> > >> Thanks, > >> > >> Gabe > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0053-7-Standardize-minvalue-for-ipasearchrecordlimit-and.patch Type: text/x-patch Size: 8247 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 14 15:47:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 14 Sep 2015 17:47:47 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F6B45E.2020404@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> <55F2B06C.2070801@redhat.com> <55F2BF43.4080903@redhat.com> <55F680F6.7040203@redhat.com> <55F69938.6000101@redhat.com> <55F6B45E.2020404@redhat.com> Message-ID: <55F6EC23.9090801@redhat.com> On 09/14/2015 01:49 PM, Lenka Doudova wrote: > All good, > ACK > > On 09/14/2015 11:54 AM, Milan Kub?k wrote: >> On 09/14/2015 10:10 AM, Lenka Doudova wrote: >>> NACK because: >>> >>> $ pep8 ipatests/test_xmlrpc/test_certprofile_plugin.py >>> ipatests/test_xmlrpc/test_certprofile_plugin.py:213:8: E121 >>> continuation line under-indented for hanging indent >>> >>> (just a missing space in the indent) >>> >>> Lenka >>> >>> On 09/11/2015 01:47 PM, Milan Kub?k wrote: >>>> On 09/11/2015 12:43 PM, Lenka Doudova wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On 09/11/2015 11:45 AM, Milan Kub?k wrote: >>>>> >>>>>> On 09/11/2015 10:27 AM, Martin Basti wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>>>>>> >>>>>>>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>>>>>> >>>>>>>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> there's no traceback in the file you mentioned, but I'm >>>>>>>>>>> running it >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> through lite-server, so here's the traceback from there: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://pastebin.test.redhat.com/310598 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I can't really get to the problem. What I forgot to mention >>>>>>>>>>> in the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> previous email was that the tests fail when attempting to add a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> certprofile-import' command with the exact same data as used >>>>>>>>>>> in the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> test, it works fine. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Lenka >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Do you get the traceback also when you run the tests using >>>>>>>>>> >>>>>>>>>> 'ipa-run-tests' with installed IPA master? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't think it is possible to run these tests against the lite >>>>>>>>> server. Please do it on regular installation. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Anyway, sorry for the long delay. I send the updated patches. >>>>>>>>> >>>>>>>>> I updated them to reflect the fix for rename option and extended >>>>>>>>> about test with importing a profile from XML file. The test case >>>>>>>>> may need to be updated, based on the resolution of [1]. >>>>>>>>> >>>>>>>>> This at the moment raises remote retrieve error (400 from >>>>>>>>> dogtag), >>>>>>>>> I think there should be more clear message (detecting xml). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Milan >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> can't build rpms after applying the patches (namely patch 0009.2): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Module ipatests.test_xmlrpc.utils >>>>>>>> >>>>>>>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), >>>>>>>> prepare_config] >>>>>>>> Module 'py' has no 'path' member) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Lenka >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Do we need new util.py in test_xmlrpc? Why not just add it into >>>>>>> existing ipatests/util.py? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> Changes: >>>>>> >>>>>> content of ipatests.test_xmlrpc.utils moved to ipatests.utils >>>>>> >>>>>> make-lint updated to ignore py.path submodule >>>>>> >>>>> >>>>> >>>>> Again got an error: >>>>> >>>>> >>>>> >>>>> Module ipatests.test_xmlrpc.test_certprofile_plugin >>>>> >>>>> >>>>> >>>>> ipatests/test_xmlrpc/test_certprofile_plugin.py:16: >>>>> [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Probably just extra 's' in: >>>>> >>>>> >>>>> >>>>> from ipatests.utils import prepare_config >>>>> >>>>> >>>>> >>>>> Lenka >>>>> >>>>> >>>>> >>>> Typo fixed. Removed the py module from the code after an offline >>>> discussion. >>>> Patch attached. >>>> >>>> Milan >>>> >>> >> Fixed. Patch attached. >> >> Milan > I cannot apply this patch on master branch even with 3-way merge, thus I cannot push this, please send rebased patch. From jcholast at redhat.com Tue Sep 15 05:22:43 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 15 Sep 2015 07:22:43 +0200 Subject: [Freeipa-devel] [PATCHES 466-468] install: Add common base class for server and replica install In-Reply-To: <55C8BBFF.7090907@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> Message-ID: <55F7AB23.5040805@redhat.com> On 10.8.2015 16:58, Martin Babinsky wrote: > On 08/06/2015 08:22 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes part of >> . >> >> See also Martin Babinsky's patch 51: >> . >> >> >> Honza >> > > Sorry but NACK, see below: > > 1.) it seems that passing kwargs to Server components doesn't work as > expected. See these logs (install on fresh F22 VM): > > http://fpaste.org/253416/21363814/ > http://fpaste.org/253419/43921374/ Fixed. > > 2.) the following code blows up in BaseServers' __init__: > (http://fpaste.org/253400/21225314/) > > 392 if not self.dns.setup_dns: > 393 if self.dns.forwarders: > 394 raise RuntimeError( > 395 "You cannot specify a --forwarder option without > the " > 396 "--setup-dns option") > > > I think that the check should be: > > 392 if not self.setup_dns: > 393 if self.dns.forwarders: Fixed. > > IMHO BaseServerDNS class shouldn't have setup_dns knob, that should be > set in the parent class (BaseServer) Fixed. > > 3.) Is there any reason why BaseServer doesn't have 'master_password', > 'idmax' and 'idstart' knobs? I know that these are then brought in by > the derived Server class, but the check for them is in parent's > __init__() method and it is IMHO a bit confusing The check should be in Server, fixed. > > 4.) please add license header to the beginning of > 'ipaserver/install/server/common.py' file Added. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-466.1-install-Support-overriding-knobs-in-subclasses.patch Type: text/x-patch Size: 12966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-467.1-install-Add-common-base-class-for-server-and-replica.patch Type: text/x-patch Size: 42003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-468.1-install-Move-unattended-option-to-the-general-help-s.patch Type: text/x-patch Size: 2023 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 15 06:46:50 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 15 Sep 2015 08:46:50 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> <55F659BD.5040507@redhat.com> <55F67887.2000905@redhat.com> Message-ID: <55F7BEDA.4010908@redhat.com> On 14.9.2015 14:58, Gabe Alford wrote: > Sounds good to me. Updated patch attached. > > On Mon, Sep 14, 2015 at 1:34 AM, Petr Spacek > wrote: > > On 14.9.2015 07:23, Jan Cholasta wrote: > > IMO it does, because saying just "-1 is default" is not entirely correct and > > "0 is default" would be confusing, as you pointed out. You might say "0 or -1 > > is unlimited" if you think it's clearer. > > my +1 to "0 or -1 is unlimited" variant > > Petr^2 Spacek > > > > On 10.9.2015 18:39, Gabe Alford wrote: > >> Oops.. replied without the list. > >> > >> Reason I said -1 is because users might be confused if they > enter `ipa > >> config-mod --searchtimelimit=0`, and both `ipa user-show` and > the webui > >> show -1 instead of 0. I wonder if -1 makes more sense in that > regard? > >> Thoughts? Does "<= 0 is unlimited" make more sense? > >> > >> Thanks, > >> > >> Gabe > The doc for ipasearchtimelimit and ipasearchrecordslimit says "-1 is unlimited", but both 0 and -1 is unlimited for them, and the doc for timelimit and sizelimit says "-1 or 0 is unlimited", but only 0 is unlimited for them. Looks like a mistake. -- Jan Cholasta From dkupka at redhat.com Tue Sep 15 08:18:54 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 15 Sep 2015 10:18:54 +0200 Subject: [Freeipa-devel] [PATCH 0291, 0292] Limit max age of replication changelog In-Reply-To: <55AFB0CE.3020508@redhat.com> References: <55AD0976.4070402@redhat.com> <55AD129D.8020608@redhat.com> <55AD1857.8090209@redhat.com> <55AD26EB.5030303@redhat.com> <55AD2A09.9070101@redhat.com> <55AFB0CE.3020508@redhat.com> Message-ID: <55F7D46E.7060003@redhat.com> On 22/07/15 17:03, Martin Basti wrote: > On 20/07/15 19:04, Mark Reynolds wrote: >> >> >> On 07/20/2015 12:50 PM, Martin Basti wrote: >>> On 20/07/15 17:48, Petr Vobornik wrote: >>>> On 07/20/2015 05:24 PM, Rob Crittenden wrote: >>>>> Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5086 >>>>>> >>>>>> Patch attached. >>>>> >>>>> Is this going to be a shock on upgrades for people who until now >>>>> may be >>>>> relying on the fact that there is no limit? >>>> >>>> Not making any point, but have to note: Ludwig raised a question on >>>> users list but there was no feedback from users. >>>> >>>> https://www.redhat.com/archives/freeipa-users/2015-July/msg00022.html >>>> >>>>> >>>>> Should there be a way for an admin to manage this, via the config >>>>> module >>>>> perhaps? >>>>> >>>>> IMHO this is a significant change and red flags need to be raised so >>>>> users are aware of it. >>>>> >>>>> rob >>>>> >>>> >>>> >>> >>> IIUC there is purge delay 7 days, so if changelog max age is 7 or >>> more days, it will not break replication. >>> The issue is if somebody uses changelog for different purpose, right? >> Well the replication changelog can not be used for anything else but >> the multimaster replication plugin. If a customer increased the >> replication purge delay you could potentially run into issues, but >> again this only comes into play when a replica is down for a very long >> time. I'm not sure if IPA even provides the option to adjust the >> replication purge delay, but that doesn't mean a customer can not >> adjust these settings on their own. >> >> Mark >> > > I'm attaching new patch, that modifies behavior of 'addifnew' keyword in > update files. > addifnew will no create new entry if doesn't exist. > This is required for proper working of patch 292 > > Rob are you okay with these patches, as Mark wrote, changelog is used > only for replication plugins, so it should not cause any issues to users. > > Martin^2 > > > Works as expected, ACK. -- David Kupka From tbabej at redhat.com Tue Sep 15 08:23:48 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 15 Sep 2015 10:23:48 +0200 Subject: [Freeipa-devel] MemberOf and Referential Integrity plugin failures cause abort of operation Message-ID: <55F7D594.6040904@redhat.com> Hi, from DS 1.3.3, the memberOf and referential integrity plugins have been converted to backend transaction plugins, which means that failures in these plugins will propagate and cause abort of the operation that triggered them. [1] I.e. in case of memberOf plugin, if a operation triggered an addition of memberOf attribute, and that addition failed, the operation itself did succeed in spite of this failure. This is no longer the case. We have been already hit by this issue in winsync agreement setup: https://bugzilla.redhat.com/show_bug.cgi?id=1262315 However, there is little special about this case and there might be multiple such entries in IPA which are added as group members, but do not contain an objectclass which allows memberOf attribute. So we need to step back and think - are there any other entries where this change of behaviour will hit us? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1250177 A nice explanation: https://bugzilla.redhat.com/show_bug.cgi?id=1258624 From mkubik at redhat.com Tue Sep 15 09:18:47 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 15 Sep 2015 11:18:47 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F6EC23.9090801@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> <55F2B06C.2070801@redhat.com> <55F2BF43.4080903@redhat.com> <55F680F6.7040203@redhat.com> <55F69938.6000101@redhat.com> <55F6B45E.2020404@redhat.com> <55F6EC23.9090801@redhat.com> Message-ID: <55F7E277.3070800@redhat.com> On 09/14/2015 05:47 PM, Martin Basti wrote: > > > On 09/14/2015 01:49 PM, Lenka Doudova wrote: >> All good, >> ACK >> >> On 09/14/2015 11:54 AM, Milan Kub?k wrote: >>> On 09/14/2015 10:10 AM, Lenka Doudova wrote: >>>> NACK because: >>>> >>>> $ pep8 ipatests/test_xmlrpc/test_certprofile_plugin.py >>>> ipatests/test_xmlrpc/test_certprofile_plugin.py:213:8: E121 >>>> continuation line under-indented for hanging indent >>>> >>>> (just a missing space in the indent) >>>> >>>> Lenka >>>> >>>> On 09/11/2015 01:47 PM, Milan Kub?k wrote: >>>>> On 09/11/2015 12:43 PM, Lenka Doudova wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 09/11/2015 11:45 AM, Milan Kub?k wrote: >>>>>> >>>>>>> On 09/11/2015 10:27 AM, Martin Basti wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>>>>>>> >>>>>>>>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>>>>>>> >>>>>>>>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> there's no traceback in the file you mentioned, but I'm >>>>>>>>>>>> running it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> through lite-server, so here's the traceback from there: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://pastebin.test.redhat.com/310598 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I can't really get to the problem. What I forgot to mention >>>>>>>>>>>> in the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> previous email was that the tests fail when attempting to >>>>>>>>>>>> add a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> certprofile-import' command with the exact same data as >>>>>>>>>>>> used in the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> test, it works fine. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Lenka >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Do you get the traceback also when you run the tests using >>>>>>>>>>> >>>>>>>>>>> 'ipa-run-tests' with installed IPA master? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't think it is possible to run these tests against the lite >>>>>>>>>> server. Please do it on regular installation. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Anyway, sorry for the long delay. I send the updated patches. >>>>>>>>>> >>>>>>>>>> I updated them to reflect the fix for rename option and extended >>>>>>>>>> about test with importing a profile from XML file. The test case >>>>>>>>>> may need to be updated, based on the resolution of [1]. >>>>>>>>>> >>>>>>>>>> This at the moment raises remote retrieve error (400 from >>>>>>>>>> dogtag), >>>>>>>>>> I think there should be more clear message (detecting xml). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Milan >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> can't build rpms after applying the patches (namely patch >>>>>>>>> 0009.2): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Module ipatests.test_xmlrpc.utils >>>>>>>>> >>>>>>>>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), >>>>>>>>> prepare_config] >>>>>>>>> Module 'py' has no 'path' member) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Lenka >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Do we need new util.py in test_xmlrpc? Why not just add it into >>>>>>>> existing ipatests/util.py? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>>> Changes: >>>>>>> >>>>>>> content of ipatests.test_xmlrpc.utils moved to ipatests.utils >>>>>>> >>>>>>> make-lint updated to ignore py.path submodule >>>>>>> >>>>>> >>>>>> >>>>>> Again got an error: >>>>>> >>>>>> >>>>>> >>>>>> Module ipatests.test_xmlrpc.test_certprofile_plugin >>>>>> >>>>>> >>>>>> >>>>>> ipatests/test_xmlrpc/test_certprofile_plugin.py:16: >>>>>> [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Probably just extra 's' in: >>>>>> >>>>>> >>>>>> >>>>>> from ipatests.utils import prepare_config >>>>>> >>>>>> >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>>> >>>>> Typo fixed. Removed the py module from the code after an offline >>>>> discussion. >>>>> Patch attached. >>>>> >>>>> Milan >>>>> >>>> >>> Fixed. Patch attached. >>> >>> Milan >> > > I cannot apply this patch on master branch even with 3-way merge, thus > I cannot push this, please send rebased patch. Hi, rebased patches attached. Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0008.3-ipatests-Add-Certprofile-tracker-class-implementatio.patch Type: text/x-patch Size: 5922 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0009.6-ipatests-Add-basic-tests-for-certificate-profile-plu.patch Type: text/x-patch Size: 64491 bytes Desc: not available URL: From tbabej at redhat.com Tue Sep 15 09:30:08 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 15 Sep 2015 11:30:08 +0200 Subject: [Freeipa-devel] [PATCH 0367] winsync: Add inetUser objectclass to the passsync sysaccount Message-ID: <55F7E520.8020101@redhat.com> Hi, attached patch fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1262315 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0367-winsync-Add-inetUser-objectclass-to-the-passsync-sys.patch Type: text/x-patch Size: 1548 bytes Desc: not available URL: From tbabej at redhat.com Tue Sep 15 09:37:05 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 15 Sep 2015 11:37:05 +0200 Subject: [Freeipa-devel] [PATCH 0367] winsync: Add inetUser objectclass to the passsync sysaccount In-Reply-To: <55F7E520.8020101@redhat.com> References: <55F7E520.8020101@redhat.com> Message-ID: <55F7E6C1.6040903@redhat.com> On 09/15/2015 11:30 AM, Tomas Babej wrote: > Hi, > > attached patch fixes: > > https://bugzilla.redhat.com/show_bug.cgi?id=1262315 > > Tomas > > > The previous version is for ipa-4-2, attaching a patch for master as well. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-master-0367-winsync-Add-inetUser-objectclass-to-the-passsync-sys.patch Type: text/x-patch Size: 1549 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 15 10:58:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 15 Sep 2015 12:58:14 +0200 Subject: [Freeipa-devel] MemberOf and Referential Integrity plugin failures cause abort of operation In-Reply-To: <55F7D594.6040904@redhat.com> References: <55F7D594.6040904@redhat.com> Message-ID: <55F7F9C6.1090901@redhat.com> On 15.9.2015 10:23, Tomas Babej wrote: > Hi, > > from DS 1.3.3, the memberOf and referential integrity plugins have been > converted to backend transaction plugins, which means that failures in > these plugins will propagate and cause abort of the operation that > triggered them. [1] > > I.e. in case of memberOf plugin, if a operation triggered an addition of > memberOf attribute, and that addition failed, the operation itself did > succeed in spite of this failure. This is no longer the case. > > We have been already hit by this issue in winsync agreement setup: > > https://bugzilla.redhat.com/show_bug.cgi?id=1262315 > > However, there is little special about this case and there might be > multiple such entries in IPA which are added as group members, > but do not contain an objectclass which allows memberOf attribute. > > So we need to step back and think - are there any other entries where > this change of behaviour will hit us? As far as ipalib is concerned, these are the objects which may have the memberOf attribute (with object class providing it in parentheses): group (netstedGroup) hbacsvc (ipaHBACService) host (ipaHost) hostgroup (netstedGroup) netgroup (ipaNISNetgroup) privilege (nestedGroup) role (nestedGroup) service (ipaService) sudocmd (NONE) user (inetUser) so memberOf needs to be added to ipaSudoCmd. The config plugin lists memberOf as an operational attribute, which I guess is no longer the case? Also, memberOf is excluded from replication in ipaserver/install/replication.py. -- Jan Cholasta From lhellebr at redhat.com Tue Sep 15 11:01:11 2015 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Tue, 15 Sep 2015 13:01:11 +0200 Subject: [Freeipa-devel] in-tree webUI Message-ID: <55F7FA77.5080903@redhat.com> Hello, I am learning FreeIPA development and looking for a way to test my changes in code: so far, I have to compile, build RPMs, copy them to the machine desired, uninstall old version, install new version from RPMs - that, for every change I want to test. Which takes way too long. I know about possibility to run FreeIPA "in-tree". Does webUI work in this mode? So far, I wasn't able to connect, neither by using the public hostname or localhost (port 8888 as it says after installation). Am I doing something wrong (how to discover what?) or does FreeIPA just run without webUI in in-tree mode? Is there any better way to test my changes? From pvoborni at redhat.com Tue Sep 15 11:15:43 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 15 Sep 2015 13:15:43 +0200 Subject: [Freeipa-devel] in-tree webUI In-Reply-To: <55F7FA77.5080903@redhat.com> References: <55F7FA77.5080903@redhat.com> Message-ID: <55F7FDDF.6000107@redhat.com> On 09/15/2015 01:01 PM, Luk?? Hellebrandt wrote: > Hello, > > I am learning FreeIPA development and looking for a way to test my > changes in code: so far, I have to compile, build RPMs, copy them to the > machine desired, uninstall old version, install new version from RPMs - > that, for every change I want to test. Which takes way too long. > > I know about possibility to run FreeIPA "in-tree". Does webUI work in > this mode? So far, I wasn't able to connect, neither by using the public > hostname or localhost (port 8888 as it says after installation). Am I > doing something wrong (how to discover what?) or does FreeIPA just run > without webUI in in-tree mode? Is there any better way to test my changes? > It runs without Web UI. Check "Debugging with source codes" section in https://pvoborni.fedorapeople.org/doc/#!/guide/Debugging -- Petr Vobornik From mkosek at redhat.com Tue Sep 15 12:10:57 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Sep 2015 14:10:57 +0200 Subject: [Freeipa-devel] Scope of ECC support in FreeIPA/Dogtag Message-ID: <55F80AD1.9060005@redhat.com> Hi Nathan and others, I am now going through FreeIPA 4.4 items and I am thinking about ECC support in FreeIPA: https://fedorahosted.org/freeipa/ticket/3951 AFAIK, ECC should be already supported in Dogtag. Could you please advise what is the scope of expected changes in FreeIPA? My understanding is that following parts are required: 1) Generating ECC signing certificate for FreeIPA CA. This is not clear to me though, if this task can be easily done during upgrade. 2) Updating FreeIPA Certificate Profiles (which should be now in LDAP) and adding respective EC algorithms support to "signingAlgsAllowed", as noted in https://fedorahosted.org/freeipa/ticket/3951#comment:1. Is that correct or more is needed to make that working and supported in FreeIPA? -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From redhatrises at gmail.com Tue Sep 15 12:42:14 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 15 Sep 2015 06:42:14 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: <55F7BEDA.4010908@redhat.com> References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> <55F659BD.5040507@redhat.com> <55F67887.2000905@redhat.com> <55F7BEDA.4010908@redhat.com> Message-ID: Yup. You are right. It was a mistake. Updated patch attached. On Tue, Sep 15, 2015 at 12:46 AM, Jan Cholasta wrote: > On 14.9.2015 14:58, Gabe Alford wrote: > >> Sounds good to me. Updated patch attached. >> >> On Mon, Sep 14, 2015 at 1:34 AM, Petr Spacek > > wrote: >> >> On 14.9.2015 07:23, Jan Cholasta wrote: >> > IMO it does, because saying just "-1 is default" is not entirely >> correct and >> > "0 is default" would be confusing, as you pointed out. You might >> say "0 or -1 >> > is unlimited" if you think it's clearer. >> >> my +1 to "0 or -1 is unlimited" variant >> >> Petr^2 Spacek >> >> >> > On 10.9.2015 18:39, Gabe Alford wrote: >> >> Oops.. replied without the list. >> >> >> >> Reason I said -1 is because users might be confused if they >> enter `ipa >> >> config-mod --searchtimelimit=0`, and both `ipa user-show` and >> the webui >> >> show -1 instead of 0. I wonder if -1 makes more sense in that >> regard? >> >> Thoughts? Does "<= 0 is unlimited" make more sense? >> >> >> >> Thanks, >> >> >> >> Gabe >> >> > The doc for ipasearchtimelimit and ipasearchrecordslimit says "-1 is > unlimited", but both 0 and -1 is unlimited for them, and the doc for > timelimit and sizelimit says "-1 or 0 is unlimited", but only 0 is > unlimited for them. Looks like a mistake. > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0053-8-Standardize-minvalue-for-ipasearchrecordlimit-and-ip.patch Type: text/x-patch Size: 8577 bytes Desc: not available URL: From akasurde at redhat.com Tue Sep 15 13:01:55 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Tue, 15 Sep 2015 18:31:55 +0530 Subject: [Freeipa-devel] [PATCH] Updated no of legacy permission in ipatests In-Reply-To: <55F121AC.50306@redhat.com> References: <55DE9B0D.6030101@redhat.com> <55E7E5A2.2090402@redhat.com> <55E83FB1.9020800@redhat.com> <55F121AC.50306@redhat.com> Message-ID: <55F816C3.6020805@redhat.com> Ping On 09/10/2015 11:52 AM, Abhijeet Kasurde wrote: > Hi List, > > Please find the following patch with review comments. > > Thanks, > Abhijeet Kasurde > > On 09/03/2015 06:10 PM, Tomas Babej wrote: >> >> On 09/03/2015 08:16 AM, Abhijeet Kasurde wrote: >>> Ping >>> >>> On 08/27/2015 10:37 AM, Abhijeet Kasurde wrote: >>>> Hi All, >>>> >>>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264 >>>> >>>> Thanks, >>>> Abhijeet Kasurde >> ACK, the patch needs a minor rebase on master due to python3 >> refactoring. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Sep 15 13:18:50 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 15 Sep 2015 07:18:50 -0600 Subject: [Freeipa-devel] MemberOf and Referential Integrity plugin failures cause abort of operation In-Reply-To: <55F7F9C6.1090901@redhat.com> References: <55F7D594.6040904@redhat.com> <55F7F9C6.1090901@redhat.com> Message-ID: <55F81ABA.2060108@redhat.com> On 09/15/2015 04:58 AM, Jan Cholasta wrote: > On 15.9.2015 10:23, Tomas Babej wrote: >> Hi, >> >> from DS 1.3.3, the memberOf and referential integrity plugins have been >> converted to backend transaction plugins, which means that failures in >> these plugins will propagate and cause abort of the operation that >> triggered them. [1] >> >> I.e. in case of memberOf plugin, if a operation triggered an addition of >> memberOf attribute, and that addition failed, the operation itself did >> succeed in spite of this failure. This is no longer the case. IMO the new transacted behavior is correct - the original operation and all of the triggered operations should succeed or fail together. >> >> We have been already hit by this issue in winsync agreement setup: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1262315 >> >> However, there is little special about this case and there might be >> multiple such entries in IPA which are added as group members, >> but do not contain an objectclass which allows memberOf attribute. >> >> So we need to step back and think - are there any other entries where >> this change of behaviour will hit us? > > As far as ipalib is concerned, these are the objects which may have > the memberOf attribute (with object class providing it in parentheses): > > group (netstedGroup) > hbacsvc (ipaHBACService) > host (ipaHost) > hostgroup (netstedGroup) > netgroup (ipaNISNetgroup) > privilege (nestedGroup) > role (nestedGroup) > service (ipaService) > sudocmd (NONE) > user (inetUser) > > so memberOf needs to be added to ipaSudoCmd. > > The config plugin lists memberOf as an operational attribute, which I > guess is no longer the case? It should never have been an operational attribute. Perhaps this was a "hack" to workaround the fact that there were objects/objectclasses missing memberOf? > > Also, memberOf is excluded from replication in > ipaserver/install/replication.py. > By design - all servers are expected to have the same memberOf plugin configuration, and add memberOf locally. From ftweedal at redhat.com Tue Sep 15 13:26:55 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 15 Sep 2015 23:26:55 +1000 Subject: [Freeipa-devel] Scope of ECC support in FreeIPA/Dogtag In-Reply-To: <55F80AD1.9060005@redhat.com> References: <55F80AD1.9060005@redhat.com> Message-ID: <20150915132655.GJ16937@dhcp-40-8.bne.redhat.com> On Tue, Sep 15, 2015 at 02:10:57PM +0200, Martin Kosek wrote: > Hi Nathan and others, > > I am now going through FreeIPA 4.4 items and I am thinking about ECC support in > FreeIPA: > > https://fedorahosted.org/freeipa/ticket/3951 > > AFAIK, ECC should be already supported in Dogtag. Could you please advise what > is the scope of expected changes in FreeIPA? > > My understanding is that following parts are required: > 1) Generating ECC signing certificate for FreeIPA CA. This is not clear to me > though, if this task can be easily done during upgrade. > Lightweight (sub)CAs should allow it easily - once they support specifying the key type and size/curve (currently subCAs are hardcoded to rsa2048 but the subCAs are still a WIP; there is a separate ticket[1] to track it). There will also be a small amount of work on the IPA side - and maybe some on Dogtag side - to allow new installation to use ECC root. [1] https://fedorahosted.org/pki/ticket/1589 > 2) Updating FreeIPA Certificate Profiles (which should be now in LDAP) and > adding respective EC algorithms support to "signingAlgsAllowed", as noted in > https://fedorahosted.org/freeipa/ticket/3951#comment:1. > Yes, we will need to update the included profiles. I have been thinking about how to get more flexibility for profile updates; I think versioning profiles is desirable but that will be a separate design proposal. Anyhow, I am happy to own these efforts. Cheers, Fraser > Is that correct or more is needed to make that working and supported in FreeIPA? > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. From jcholast at redhat.com Wed Sep 16 06:11:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Sep 2015 08:11:06 +0200 Subject: [Freeipa-devel] [PATCHES 466-468] install: Add common base class for server and replica install In-Reply-To: <55F7AB23.5040805@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> <55F7AB23.5040805@redhat.com> Message-ID: <55F907FA.40202@redhat.com> On 15.9.2015 07:22, Jan Cholasta wrote: > On 10.8.2015 16:58, Martin Babinsky wrote: >> On 08/06/2015 08:22 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes part of >>> . >>> >>> See also Martin Babinsky's patch 51: >>> . >>> >>> >>> >>> Honza >>> >> >> Sorry but NACK, see below: >> >> 1.) it seems that passing kwargs to Server components doesn't work as >> expected. See these logs (install on fresh F22 VM): >> >> http://fpaste.org/253416/21363814/ >> http://fpaste.org/253419/43921374/ > > Fixed. > >> >> 2.) the following code blows up in BaseServers' __init__: >> (http://fpaste.org/253400/21225314/) >> >> 392 if not self.dns.setup_dns: >> 393 if self.dns.forwarders: >> 394 raise RuntimeError( >> 395 "You cannot specify a --forwarder option without >> the " >> 396 "--setup-dns option") >> >> >> I think that the check should be: >> >> 392 if not self.setup_dns: >> 393 if self.dns.forwarders: > > Fixed. > >> >> IMHO BaseServerDNS class shouldn't have setup_dns knob, that should be >> set in the parent class (BaseServer) > > Fixed. > >> >> 3.) Is there any reason why BaseServer doesn't have 'master_password', >> 'idmax' and 'idstart' knobs? I know that these are then brought in by >> the derived Server class, but the check for them is in parent's >> __init__() method and it is IMHO a bit confusing > > The check should be in Server, fixed. > >> >> 4.) please add license header to the beginning of >> 'ipaserver/install/server/common.py' file > > Added. > > Updated patches attached. Self-NACK, I broke ipa-server-install --uninstall. -- Jan Cholasta From jcholast at redhat.com Wed Sep 16 06:23:13 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Sep 2015 08:23:13 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> <55F659BD.5040507@redhat.com> <55F67887.2000905@redhat.com> <55F7BEDA.4010908@redhat.com> Message-ID: <55F90AD1.5000400@redhat.com> On 15.9.2015 14:42, Gabe Alford wrote: > Yup. You are right. It was a mistake. Updated patch attached. > > On Tue, Sep 15, 2015 at 12:46 AM, Jan Cholasta > wrote: > > On 14.9.2015 14:58, Gabe Alford wrote: > > Sounds good to me. Updated patch attached. > > On Mon, Sep 14, 2015 at 1:34 AM, Petr Spacek > >> wrote: > > On 14.9.2015 07:23, Jan Cholasta wrote: > > IMO it does, because saying just "-1 is default" is not > entirely correct and > > "0 is default" would be confusing, as you pointed out. > You might say "0 or -1 > > is unlimited" if you think it's clearer. > > my +1 to "0 or -1 is unlimited" variant > > Petr^2 Spacek > > > > On 10.9.2015 18:39, Gabe Alford wrote: > >> Oops.. replied without the list. > >> > >> Reason I said -1 is because users might be confused if they > enter `ipa > >> config-mod --searchtimelimit=0`, and both `ipa > user-show` and > the webui > >> show -1 instead of 0. I wonder if -1 makes more sense > in that > regard? > >> Thoughts? Does "<= 0 is unlimited" make more sense? > >> > >> Thanks, > >> > >> Gabe > > > The doc for ipasearchtimelimit and ipasearchrecordslimit says "-1 is > unlimited", but both 0 and -1 is unlimited for them, and the doc for > timelimit and sizelimit says "-1 or 0 is unlimited", but only 0 is > unlimited for them. Looks like a mistake. > > -- > Jan Cholasta > > This hasn't changed since the previous patch and is still wrong, as -1 is not supported here: Int('timelimit?', label=_('Time Limit'), - doc=_('Time limit of search in seconds'), + doc=_('Time limit of search in seconds (-1 or 0 is unlimited)'), flags=['no_display'], minvalue=0, autofill=False, ), Int('sizelimit?', label=_('Size Limit'), - doc=_('Maximum number of entries returned'), + doc=_('Maximum number of entries returned (-1 or 0 is unlimited)'), flags=['no_display'], minvalue=0, autofill=False, -- Jan Cholasta From ofayans at redhat.com Wed Sep 16 06:26:38 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 16 Sep 2015 08:26:38 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests In-Reply-To: <55E95620.6060202@redhat.com> References: <55E86D57.1050006@redhat.com> <55E8819E.8020508@redhat.com> <55E95620.6060202@redhat.com> Message-ID: <55F90B9E.8000800@redhat.com> I ran the tests with these patches included in RHEL and they keep failing at the same assertions as it was last time. Test stdout is attached On 09/04/2015 10:28 AM, Martin Basti wrote: > > > On 09/03/2015 07:21 PM, Oleg Fayans wrote: >> Hi Martin, >> >> The two functions >> test_disable_reenable_signing_master and >> test_disable_reenable_signing_replica >> the error message for the laste assertion is different, although the >> assertions are identical: >> "RRSIG should be different" and "DNSKEY should be different". >> Other than that, it's fine >> >> >> On 09/03/2015 05:55 PM, Martin Basti wrote: >>> Attached patches improve DNSSEC CI tests. >>> >>> >> > > Thank you for review. > > Updated patches attached. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- ============================= test session starts ============================== platform linux2 -- Python 2.7.5 -- py-1.4.27 -- pytest-2.7.0 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: multihost, sourceorder collected 8 items test_integration/test_dnssec.py .FFFFFFs =================================== FAILURES =================================== _____________ TestInstallDNSSECLast.test_if_zone_is_signed_master ______________ self = def test_if_zone_is_signed_master(self): # add zone with enabled DNSSEC signing on master args = [ "ipa", "dnszone-add", test_zone, "--dnssec", "true", ] self.master.run_command(args) # test master > assert wait_until_record_is_signed( self.master.ip, test_zone, self.log, timeout=100 ), "Zone %s is not signed (master)" % test_zone E AssertionError: Zone dnssec.test. is not signed (master) E assert wait_until_record_is_signed('10.40.128.105', 'dnssec.test.', , timeout=100) E + where '10.40.128.105' = .ip E + where = .master E + and = .log test_integration/test_dnssec.py:109: AssertionError _____________ TestInstallDNSSECLast.test_if_zone_is_signed_replica _____________ self = def test_if_zone_is_signed_replica(self): # add zone with enabled DNSSEC signing on replica args = [ "ipa", "dnszone-add", test_zone_repl, "--dnssec", "true", ] self.replicas[0].run_command(args) # test replica > assert wait_until_record_is_signed( self.replicas[0].ip, test_zone_repl, self.log, timeout=300 ), "Zone %s is not signed (replica)" % test_zone_repl E AssertionError: Zone dnssec-replica.test. is not signed (replica) E assert wait_until_record_is_signed('10.40.128.108', 'dnssec-replica.test.', , timeout=300) E + where '10.40.128.108' = .ip E + and = .log test_integration/test_dnssec.py:128: AssertionError __________ TestInstallDNSSECLast.test_disable_reenable_signing_master __________ self = def test_disable_reenable_signing_master(self): dnskey_old = resolve_with_dnssec(self.master.ip, test_zone, > self.log, rtype="DNSKEY").rrset test_integration/test_dnssec.py:142: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ test_integration/test_dnssec.py:32: in resolve_with_dnssec ans = res.query(query, rtype) ../dns/resolver.py:958: in query raise_on_no_answer) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = qname = , rdtype = 48, rdclass = 1 response = , raise_on_no_answer = True def __init__(self, qname, rdtype, rdclass, response, raise_on_no_answer=True): self.qname = qname self.rdtype = rdtype self.rdclass = rdclass self.response = response min_ttl = -1 rrset = None for count in xrange(0, 15): try: rrset = response.find_rrset(response.answer, qname, rdclass, rdtype) if min_ttl == -1 or rrset.ttl < min_ttl: min_ttl = rrset.ttl break except KeyError: if rdtype != dns.rdatatype.CNAME: try: crrset = response.find_rrset(response.answer, qname, rdclass, dns.rdatatype.CNAME) if min_ttl == -1 or crrset.ttl < min_ttl: min_ttl = crrset.ttl for rd in crrset: qname = rd.target break continue except KeyError: if raise_on_no_answer: > raise NoAnswer(response=response) E NoAnswer: The DNS response does not contain an answer to the question: dnssec.test. IN DNSKEY ../dns/resolver.py:173: NoAnswer _________ TestInstallDNSSECLast.test_disable_reenable_signing_replica __________ self = def test_disable_reenable_signing_replica(self): dnskey_old = resolve_with_dnssec(self.replicas[0].ip, test_zone_repl, > self.log, rtype="DNSKEY").rrset test_integration/test_dnssec.py:191: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ test_integration/test_dnssec.py:32: in resolve_with_dnssec ans = res.query(query, rtype) ../dns/resolver.py:958: in query raise_on_no_answer) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = qname = , rdtype = 48, rdclass = 1 response = , raise_on_no_answer = True def __init__(self, qname, rdtype, rdclass, response, raise_on_no_answer=True): self.qname = qname self.rdtype = rdtype self.rdclass = rdclass self.response = response min_ttl = -1 rrset = None for count in xrange(0, 15): try: rrset = response.find_rrset(response.answer, qname, rdclass, rdtype) if min_ttl == -1 or rrset.ttl < min_ttl: min_ttl = rrset.ttl break except KeyError: if rdtype != dns.rdatatype.CNAME: try: crrset = response.find_rrset(response.answer, qname, rdclass, dns.rdatatype.CNAME) if min_ttl == -1 or crrset.ttl < min_ttl: min_ttl = crrset.ttl for rd in crrset: qname = rd.target break continue except KeyError: if raise_on_no_answer: > raise NoAnswer(response=response) E NoAnswer: The DNS response does not contain an answer to the question: dnssec-replica.test. IN DNSKEY ../dns/resolver.py:173: NoAnswer __________________ TestInstallDNSSECFirst.test_sign_root_zone __________________ self = def test_sign_root_zone(self): args = [ "ipa", "dnszone-add", root_zone, "--dnssec", "true" ] self.master.run_command(args) # make BIND happy, and delegate zone which contains A record of master args = [ "ipa", "dnsrecord-add", root_zone, self.master.domain.name, "--ns-rec=" + self.master.hostname ] self.master.run_command(args) # test master > assert wait_until_record_is_signed( self.master.ip, root_zone, self.log, timeout=100 ), "Zone %s is not signed (master)" % root_zone E AssertionError: Zone . is not signed (master) E assert wait_until_record_is_signed('10.40.128.105', '.', , timeout=100) E + where '10.40.128.105' = .ip E + where = .master E + and = .log test_integration/test_dnssec.py:285: AssertionError ---------------------------- Captured stdout setup ----------------------------- __________________ TestInstallDNSSECFirst.test_chain_of_trust __________________ self = def test_chain_of_trust(self): """ Validate signed DNS records, using our own signed root zone :return: """ # add test zone args = [ "ipa", "dnszone-add", example_test_zone, "--dnssec", "true" ] self.master.run_command(args) # wait until zone is signed > assert wait_until_record_is_signed( self.master.ip, example_test_zone, self.log, timeout=100 ), "Zone %s is not signed (master)" % example_test_zone E AssertionError: Zone example.test. is not signed (master) E assert wait_until_record_is_signed('10.40.128.105', 'example.test.', , timeout=100) E + where '10.40.128.105' = .ip E + where = .master E + and = .log test_integration/test_dnssec.py:308: AssertionError =============== 6 failed, 1 passed, 1 skipped in 2563.38 seconds =============== From mbasti at redhat.com Wed Sep 16 06:30:31 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 08:30:31 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests In-Reply-To: <55F90B9E.8000800@redhat.com> References: <55E86D57.1050006@redhat.com> <55E8819E.8020508@redhat.com> <55E95620.6060202@redhat.com> <55F90B9E.8000800@redhat.com> Message-ID: <55F90C87.6040702@redhat.com> On 09/16/2015 08:26 AM, Oleg Fayans wrote: > I ran the tests with these patches included in RHEL and they keep > failing at the same assertions as it was last time. Test stdout is > attached > > On 09/04/2015 10:28 AM, Martin Basti wrote: >> >> >> On 09/03/2015 07:21 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> The two functions >>> test_disable_reenable_signing_master and >>> test_disable_reenable_signing_replica >>> the error message for the laste assertion is different, although the >>> assertions are identical: >>> "RRSIG should be different" and "DNSKEY should be different". >>> Other than that, it's fine >>> >>> >>> On 09/03/2015 05:55 PM, Martin Basti wrote: >>>> Attached patches improve DNSSEC CI tests. >>>> >>>> >>> >> >> Thank you for review. >> >> Updated patches attached. > Can you run test with --pdb option to pause test execution and send journalctl logs (named-pkcs11, ipa-dnskeysyncd, ipa-ods-exporter)? Test passes for me except the one, that we are currently debugging. I'm curious what happend in your test suite. From jcholast at redhat.com Wed Sep 16 08:44:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Sep 2015 10:44:35 +0200 Subject: [Freeipa-devel] [PATCHES 466-468] install: Add common base class for server and replica install In-Reply-To: <55F907FA.40202@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> <55F7AB23.5040805@redhat.com> <55F907FA.40202@redhat.com> Message-ID: <55F92BF3.6010604@redhat.com> On 16.9.2015 08:11, Jan Cholasta wrote: > On 15.9.2015 07:22, Jan Cholasta wrote: >> On 10.8.2015 16:58, Martin Babinsky wrote: >>> On 08/06/2015 08:22 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes part of >>>> . >>>> >>>> See also Martin Babinsky's patch 51: >>>> . >>>> >>>> >>>> >>>> >>>> Honza >>>> >>> >>> Sorry but NACK, see below: >>> >>> 1.) it seems that passing kwargs to Server components doesn't work as >>> expected. See these logs (install on fresh F22 VM): >>> >>> http://fpaste.org/253416/21363814/ >>> http://fpaste.org/253419/43921374/ >> >> Fixed. >> >>> >>> 2.) the following code blows up in BaseServers' __init__: >>> (http://fpaste.org/253400/21225314/) >>> >>> 392 if not self.dns.setup_dns: >>> 393 if self.dns.forwarders: >>> 394 raise RuntimeError( >>> 395 "You cannot specify a --forwarder option without >>> the " >>> 396 "--setup-dns option") >>> >>> >>> I think that the check should be: >>> >>> 392 if not self.setup_dns: >>> 393 if self.dns.forwarders: >> >> Fixed. >> >>> >>> IMHO BaseServerDNS class shouldn't have setup_dns knob, that should be >>> set in the parent class (BaseServer) >> >> Fixed. >> >>> >>> 3.) Is there any reason why BaseServer doesn't have 'master_password', >>> 'idmax' and 'idstart' knobs? I know that these are then brought in by >>> the derived Server class, but the check for them is in parent's >>> __init__() method and it is IMHO a bit confusing >> >> The check should be in Server, fixed. >> >>> >>> 4.) please add license header to the beginning of >>> 'ipaserver/install/server/common.py' file >> >> Added. >> >> Updated patches attached. > > Self-NACK, I broke ipa-server-install --uninstall. Fixed. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-467.2-install-Add-common-base-class-for-server-and-replica.patch Type: text/x-patch Size: 42029 bytes Desc: not available URL: From jcholast at redhat.com Wed Sep 16 09:01:24 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Sep 2015 11:01:24 +0200 Subject: [Freeipa-devel] [PATCH 492] config: allow user/host attributes with tagging options Message-ID: <55F92FE4.3070705@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-492-config-allow-user-host-attributes-with-tagging-optio.patch Type: text/x-patch Size: 1399 bytes Desc: not available URL: From ofayans at redhat.com Wed Sep 16 09:09:46 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 16 Sep 2015 11:09:46 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests In-Reply-To: <55F90B9E.8000800@redhat.com> References: <55E86D57.1050006@redhat.com> <55E8819E.8020508@redhat.com> <55E95620.6060202@redhat.com> <55F90B9E.8000800@redhat.com> Message-ID: <55F931DA.2020108@redhat.com> I guess the problem is caused by the old version of ipa-server, used for testing (without DNSSec-related changes), not tests. The tests are ok, ACK from me. On 09/16/2015 08:26 AM, Oleg Fayans wrote: > I ran the tests with these patches included in RHEL and they keep > failing at the same assertions as it was last time. Test stdout is attached > > On 09/04/2015 10:28 AM, Martin Basti wrote: >> >> >> On 09/03/2015 07:21 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> The two functions >>> test_disable_reenable_signing_master and >>> test_disable_reenable_signing_replica >>> the error message for the laste assertion is different, although the >>> assertions are identical: >>> "RRSIG should be different" and "DNSKEY should be different". >>> Other than that, it's fine >>> >>> >>> On 09/03/2015 05:55 PM, Martin Basti wrote: >>>> Attached patches improve DNSSEC CI tests. >>>> >>>> >>> >> >> Thank you for review. >> >> Updated patches attached. > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pvoborni at redhat.com Wed Sep 16 11:00:18 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 16 Sep 2015 13:00:18 +0200 Subject: [Freeipa-devel] [PATCH] Updated no of legacy permission in ipatests In-Reply-To: <55F816C3.6020805@redhat.com> References: <55DE9B0D.6030101@redhat.com> <55E7E5A2.2090402@redhat.com> <55E83FB1.9020800@redhat.com> <55F121AC.50306@redhat.com> <55F816C3.6020805@redhat.com> Message-ID: <55F94BC2.2040801@redhat.com> On 09/15/2015 03:01 PM, Abhijeet Kasurde wrote: > Ping > > On 09/10/2015 11:52 AM, Abhijeet Kasurde wrote: >> Hi List, >> >> Please find the following patch with review comments. >> >> Thanks, >> Abhijeet Kasurde >> >> On 09/03/2015 06:10 PM, Tomas Babej wrote: >>> >>> On 09/03/2015 08:16 AM, Abhijeet Kasurde wrote: >>>> Ping >>>> >>>> On 08/27/2015 10:37 AM, Abhijeet Kasurde wrote: >>>>> Hi All, >>>>> >>>>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264 >>>>> >>>>> Thanks, >>>>> Abhijeet Kasurde >>> ACK, the patch needs a minor rebase on master due to python3 >>> refactoring. >> Pushed to master: 1b70521e6b9a16fc0d06b798b8cc1f8b943c476a Pushed to ipa-4-2: 72e87e8c33d3aa7d777e3a097bdefc95a52e014e -- Petr Vobornik From pvoborni at redhat.com Wed Sep 16 11:22:46 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 16 Sep 2015 13:22:46 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 release notes draft Message-ID: <55F95106.1060808@redhat.com> FreeIPA 4.2.1 was released last week but it was not fully announced yet. The release notes draft is prepared, updates welcome: http://www.freeipa.org/page/Releases/4.2.1 -- Petr Vobornik From mkosek at redhat.com Wed Sep 16 11:46:05 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Sep 2015 13:46:05 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 release notes draft In-Reply-To: <55F95106.1060808@redhat.com> References: <55F95106.1060808@redhat.com> Message-ID: <55F9567D.2020508@redhat.com> On 09/16/2015 01:22 PM, Petr Vobornik wrote: > FreeIPA 4.2.1 was released last week but it was not fully announced yet. > > The release notes draft is prepared, updates welcome: > http://www.freeipa.org/page/Releases/4.2.1 IIRC, Martin Basti also did pretty critical fixes to the upgrade, so it can be mentioned. From dkupka at redhat.com Wed Sep 16 12:32:40 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 16 Sep 2015 14:32:40 +0200 Subject: [Freeipa-devel] [PATCH 492] config: allow user/host attributes with tagging options In-Reply-To: <55F92FE4.3070705@redhat.com> References: <55F92FE4.3070705@redhat.com> Message-ID: <55F96168.2010604@redhat.com> On 16/09/15 11:01, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > Works for me, ACK. -- David Kupka From pvoborni at redhat.com Wed Sep 16 13:17:48 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 16 Sep 2015 15:17:48 +0200 Subject: [Freeipa-devel] [PATCH 0367] winsync: Add inetUser objectclass to the passsync sysaccount In-Reply-To: <55F7E6C1.6040903@redhat.com> References: <55F7E520.8020101@redhat.com> <55F7E6C1.6040903@redhat.com> Message-ID: <55F96BFC.6020702@redhat.com> On 09/15/2015 11:37 AM, Tomas Babej wrote: > > > On 09/15/2015 11:30 AM, Tomas Babej wrote: >> Hi, >> >> attached patch fixes: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1262315 >> >> Tomas >> >> >> > > The previous version is for ipa-4-2, attaching a patch for master as well. > > Tomas > The update file should be added to makefile.am -- Petr Vobornik From tbabej at redhat.com Wed Sep 16 13:22:07 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 16 Sep 2015 15:22:07 +0200 Subject: [Freeipa-devel] [PATCH 0367] winsync: Add inetUser objectclass to the passsync sysaccount In-Reply-To: <55F96BFC.6020702@redhat.com> References: <55F7E520.8020101@redhat.com> <55F7E6C1.6040903@redhat.com> <55F96BFC.6020702@redhat.com> Message-ID: <55F96CFF.5060407@redhat.com> On 09/16/2015 03:17 PM, Petr Vobornik wrote: > On 09/15/2015 11:37 AM, Tomas Babej wrote: >> >> >> On 09/15/2015 11:30 AM, Tomas Babej wrote: >>> Hi, >>> >>> attached patch fixes: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1262315 >>> >>> Tomas >>> >>> >>> >> >> The previous version is for ipa-4-2, attaching a patch for master as >> well. >> >> Tomas >> > > The update file should be added to makefile.am > Right, fixed patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-4-2-0367-2-winsync-Add-inetUser-objectclass-to-the-passsync-sys.patch Type: text/x-patch Size: 2001 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0367-2-winsync-Add-inetUser-objectclass-to-the-passsync-sys.patch Type: text/x-patch Size: 2002 bytes Desc: not available URL: From mkubik at redhat.com Wed Sep 16 14:18:47 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 16 Sep 2015 16:18:47 +0200 Subject: [Freeipa-devel] [PATCH 0312] CI: extend backup restore tests with DNS/DNSSEC In-Reply-To: <55F28F8B.8080904@redhat.com> References: <55F13DA4.7050800@redhat.com> <55F143C5.2070802@redhat.com> <55F28F8B.8080904@redhat.com> Message-ID: <55F97A47.3090400@redhat.com> On 09/11/2015 10:23 AM, Martin Basti wrote: > > > On 09/10/2015 10:48 AM, Martin Basti wrote: >> Self NACK >> >> On 09/10/2015 10:21 AM, Martin Basti wrote: >>> Patch attached. >>> >>> >> >> >> > Updated patch attached. Looks good to me. The reinstall tests are failing. Is this known? Apart from that, ACK for the code. Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Wed Sep 16 14:26:05 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 16 Sep 2015 16:26:05 +0200 Subject: [Freeipa-devel] [PATCH 0312] CI: extend backup restore tests with DNS/DNSSEC In-Reply-To: <55F97A47.3090400@redhat.com> References: <55F13DA4.7050800@redhat.com> <55F143C5.2070802@redhat.com> <55F28F8B.8080904@redhat.com> <55F97A47.3090400@redhat.com> Message-ID: <55F97BFD.7070908@redhat.com> On 09/16/2015 04:18 PM, Milan Kub?k wrote: > On 09/11/2015 10:23 AM, Martin Basti wrote: >> >> >> On 09/10/2015 10:48 AM, Martin Basti wrote: >>> Self NACK >>> >>> On 09/10/2015 10:21 AM, Martin Basti wrote: >>>> Patch attached. >>>> >>>> >>> >>> >>> >> Updated patch attached. > Looks good to me. The reinstall tests are failing. Is this known? > Apart from that, ACK for the code. > > Milan > > > > The tests are failing to add the second zone. E CalledProcessError: Command '['ipa', 'dnszone-add', 'example2.test.', '--dnssec', 'true']' returned non-zero exit status 1 Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Sep 16 14:40:58 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Sep 2015 16:40:58 +0200 Subject: [Freeipa-devel] [PATCH 492] config: allow user/host attributes with tagging options In-Reply-To: <55F96168.2010604@redhat.com> References: <55F92FE4.3070705@redhat.com> <55F96168.2010604@redhat.com> Message-ID: <55F97F7A.7060303@redhat.com> On 16.9.2015 14:32, David Kupka wrote: > On 16/09/15 11:01, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > Works for me, ACK. > Pushed to: master: 60dd90cf77097cd305f9cad4b03d28f2977dd38b ipa-4-2: bbcbbf3480fb30a7f963d6083a656cc19b8a7ed6 -- Jan Cholasta From mbasti at redhat.com Wed Sep 16 14:55:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 16:55:12 +0200 Subject: [Freeipa-devel] [PATCH 0312] CI: extend backup restore tests with DNS/DNSSEC In-Reply-To: <55F97BFD.7070908@redhat.com> References: <55F13DA4.7050800@redhat.com> <55F143C5.2070802@redhat.com> <55F28F8B.8080904@redhat.com> <55F97A47.3090400@redhat.com> <55F97BFD.7070908@redhat.com> Message-ID: <55F982D0.50508@redhat.com> On 09/16/2015 04:26 PM, Milan Kub?k wrote: > On 09/16/2015 04:18 PM, Milan Kub?k wrote: >> On 09/11/2015 10:23 AM, Martin Basti wrote: >>> >>> >>> On 09/10/2015 10:48 AM, Martin Basti wrote: >>>> Self NACK >>>> >>>> On 09/10/2015 10:21 AM, Martin Basti wrote: >>>>> Patch attached. >>>>> >>>>> >>>> >>>> >>>> >>> Updated patch attached. >> Looks good to me. The reinstall tests are failing. Is this known? >> Apart from that, ACK for the code. >> >> Milan >> >> >> >> > The tests are failing to add the second zone. > > E CalledProcessError: Command '['ipa', 'dnszone-add', > 'example2.test.', '--dnssec', 'true']' returned non-zero exit status 1 > > Milan We are aware of one test failing, Petr2 is debugging it. But it is not this case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Sep 16 15:15:50 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 16 Sep 2015 17:15:50 +0200 Subject: [Freeipa-devel] [PATCH 0367] winsync: Add inetUser objectclass to the passsync sysaccount In-Reply-To: <55F96CFF.5060407@redhat.com> References: <55F7E520.8020101@redhat.com> <55F7E6C1.6040903@redhat.com> <55F96BFC.6020702@redhat.com> <55F96CFF.5060407@redhat.com> Message-ID: <55F987A6.2050009@redhat.com> On 09/16/2015 03:22 PM, Tomas Babej wrote: > > > On 09/16/2015 03:17 PM, Petr Vobornik wrote: >> On 09/15/2015 11:37 AM, Tomas Babej wrote: >>> >>> >>> On 09/15/2015 11:30 AM, Tomas Babej wrote: >>>> Hi, >>>> >>>> attached patch fixes: >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1262315 >>>> >>>> Tomas >>>> >>>> >>>> >>> >>> The previous version is for ipa-4-2, attaching a patch for master as >>> well. >>> >>> Tomas >>> >> >> The update file should be added to makefile.am >> > > Right, fixed patches attached. > ACK Pushed to master: 73c82d00736ae032465b7e50a2ea51ad753c8093 Pushed to ipa-4-2: ffb676511054e72b05b25a8f339a15da5b40eb2f -- Petr Vobornik From mbasti at redhat.com Wed Sep 16 15:49:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 17:49:23 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests In-Reply-To: <55F90B9E.8000800@redhat.com> References: <55E86D57.1050006@redhat.com> <55E8819E.8020508@redhat.com> <55E95620.6060202@redhat.com> <55F90B9E.8000800@redhat.com> Message-ID: <55F98F83.9060702@redhat.com> On 09/16/2015 08:26 AM, Oleg Fayans wrote: > I ran the tests with these patches included in RHEL and they keep > failing at the same assertions as it was last time. Test stdout is > attached > > On 09/04/2015 10:28 AM, Martin Basti wrote: >> >> >> On 09/03/2015 07:21 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> The two functions >>> test_disable_reenable_signing_master and >>> test_disable_reenable_signing_replica >>> the error message for the laste assertion is different, although the >>> assertions are identical: >>> "RRSIG should be different" and "DNSKEY should be different". >>> Other than that, it's fine >>> >>> >>> On 09/03/2015 05:55 PM, Martin Basti wrote: >>>> Attached patches improve DNSSEC CI tests. >>>> >>>> >>> >> >> Thank you for review. >> >> Updated patches attached. > I was able to run and pass all tests on new machines, with latest master build. https://paste.fedoraproject.org/268040/41827314/ Even the one I expected to fail (corner case we are debugging) From mbasti at redhat.com Wed Sep 16 16:04:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 18:04:05 +0200 Subject: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests In-Reply-To: <55F931DA.2020108@redhat.com> References: <55E86D57.1050006@redhat.com> <55E8819E.8020508@redhat.com> <55E95620.6060202@redhat.com> <55F90B9E.8000800@redhat.com> <55F931DA.2020108@redhat.com> Message-ID: <55F992F5.3080305@redhat.com> On 09/16/2015 11:09 AM, Oleg Fayans wrote: > I guess the problem is caused by the old version of ipa-server, used > for testing (without DNSSec-related changes), not tests. The tests are > ok, ACK from me. > > On 09/16/2015 08:26 AM, Oleg Fayans wrote: >> I ran the tests with these patches included in RHEL and they keep >> failing at the same assertions as it was last time. Test stdout is >> attached >> >> On 09/04/2015 10:28 AM, Martin Basti wrote: >>> >>> >>> On 09/03/2015 07:21 PM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> The two functions >>>> test_disable_reenable_signing_master and >>>> test_disable_reenable_signing_replica >>>> the error message for the laste assertion is different, although the >>>> assertions are identical: >>>> "RRSIG should be different" and "DNSKEY should be different". >>>> Other than that, it's fine >>>> >>>> >>>> On 09/03/2015 05:55 PM, Martin Basti wrote: >>>>> Attached patches improve DNSSEC CI tests. >>>>> >>>>> >>>> >>> >>> Thank you for review. >>> >>> Updated patches attached. >> >> >> > Pushed to: master: 3c33b48655acabdd12de56e78cdfb2f7d17c414f ipa-4-2: 773c02e94df5e6aab714a9750f478be8cd0172af From mbasti at redhat.com Wed Sep 16 16:17:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 18:17:40 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 release notes draft In-Reply-To: <55F95106.1060808@redhat.com> References: <55F95106.1060808@redhat.com> Message-ID: <55F99624.4020909@redhat.com> On 09/16/2015 01:22 PM, Petr Vobornik wrote: > FreeIPA 4.2.1 was released last week but it was not fully announced yet. > > The release notes draft is prepared, updates welcome: > http://www.freeipa.org/page/Releases/4.2.1 Shall we add there note to create new backup files after upgrade (as this is good practice to do after every upgrade)? There were quite a lot backup&restore fixes. Martin^2 From mbasti at redhat.com Wed Sep 16 16:22:15 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 18:22:15 +0200 Subject: [Freeipa-devel] [PATCH 0312] CI: extend backup restore tests with DNS/DNSSEC In-Reply-To: <55F982D0.50508@redhat.com> References: <55F13DA4.7050800@redhat.com> <55F143C5.2070802@redhat.com> <55F28F8B.8080904@redhat.com> <55F97A47.3090400@redhat.com> <55F97BFD.7070908@redhat.com> <55F982D0.50508@redhat.com> Message-ID: <55F99737.5080805@redhat.com> On 09/16/2015 04:55 PM, Martin Basti wrote: > > > On 09/16/2015 04:26 PM, Milan Kub?k wrote: >> On 09/16/2015 04:18 PM, Milan Kub?k wrote: >>> On 09/11/2015 10:23 AM, Martin Basti wrote: >>>> >>>> >>>> On 09/10/2015 10:48 AM, Martin Basti wrote: >>>>> Self NACK >>>>> >>>>> On 09/10/2015 10:21 AM, Martin Basti wrote: >>>>>> Patch attached. >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> Updated patch attached. >>> Looks good to me. The reinstall tests are failing. Is this known? >>> Apart from that, ACK for the code. >>> >>> Milan >>> >>> >>> >>> >> The tests are failing to add the second zone. >> >> E CalledProcessError: Command '['ipa', 'dnszone-add', >> 'example2.test.', '--dnssec', 'true']' returned non-zero exit status 1 >> >> Milan > We are aware of one test failing, Petr2 is debugging it. But it is not > this case. > > > Ok It was mistake, this is different case,related ticket bellow. https://fedorahosted.org/freeipa/ticket/5296 Pushed to: master: 8772fb4c3dc9a5ba11cfc3bca5970eeaabea1d79 ipa-4-2: c469f818402b7b8e30914b3530163ac5c7383b04 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Sep 16 16:31:16 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 16 Sep 2015 18:31:16 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 release notes draft In-Reply-To: <55F99624.4020909@redhat.com> References: <55F95106.1060808@redhat.com> <55F99624.4020909@redhat.com> Message-ID: <55F99954.1040102@redhat.com> On 09/16/2015 06:17 PM, Martin Basti wrote: > > > On 09/16/2015 01:22 PM, Petr Vobornik wrote: >> FreeIPA 4.2.1 was released last week but it was not fully announced yet. >> >> The release notes draft is prepared, updates welcome: >> http://www.freeipa.org/page/Releases/4.2.1 > > Shall we add there note to create new backup files after upgrade (as > this is good practice to do after every upgrade)? > There were quite a lot backup&restore fixes. > > Martin^2 And also before upgrade. You mean to http://www.freeipa.org/page/Upgrade ? -- Petr Vobornik From mbasti at redhat.com Wed Sep 16 16:34:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 18:34:05 +0200 Subject: [Freeipa-devel] FreeIPA 4.2.1 release notes draft In-Reply-To: <55F99954.1040102@redhat.com> References: <55F95106.1060808@redhat.com> <55F99624.4020909@redhat.com> <55F99954.1040102@redhat.com> Message-ID: <55F999FD.8000709@redhat.com> On 09/16/2015 06:31 PM, Petr Vobornik wrote: > On 09/16/2015 06:17 PM, Martin Basti wrote: >> >> >> On 09/16/2015 01:22 PM, Petr Vobornik wrote: >>> FreeIPA 4.2.1 was released last week but it was not fully announced >>> yet. >>> >>> The release notes draft is prepared, updates welcome: >>> http://www.freeipa.org/page/Releases/4.2.1 >> >> Shall we add there note to create new backup files after upgrade (as >> this is good practice to do after every upgrade)? >> There were quite a lot backup&restore fixes. >> >> Martin^2 > > And also before upgrade. You mean to > http://www.freeipa.org/page/Upgrade ? Maybe in both, for this release, and we can add this note to Upgrade page to be there for all releases. From mbasti at redhat.com Wed Sep 16 16:40:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 18:40:29 +0200 Subject: [Freeipa-devel] [PATCH 0052] Add Chromium configuration note under Chrome section in ssbrowser In-Reply-To: References: Message-ID: <55F99B7D.3010706@redhat.com> On 09/03/2015 05:55 PM, Gabe Alford wrote: > Bump for review > > On Wed, Jul 29, 2015 at 7:49 AM, Gabe Alford > wrote: > > Hello, > > As Chromium and Chrome are configured similarly but are configured > in different /etc directories, this patch adds a note to the > Chrome section in ssbrowser.html stating that. > > Thanks, > > Gabe > > > > Thank you for patience. ACK Pushed to: master: 9bec46d01dfa572be6e2cbd04389cc09e4776bc5 ipa-4-2: 7d5bc9f5dedaf9b8064a0eb0f6457ae6615b2ceb -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Sep 16 16:52:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Sep 2015 18:52:29 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55F7E277.3070800@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> <55E831C7.1040202@redhat.com> <55E83E9B.8070901@redhat.com> <55E95F01.10809@redhat.com> <55E9A34E.3010808@redhat.com> <55F17358.4080601@redhat.com> <55F287FC.2030707@redhat.com> <55F29057.5050800@redhat.com> <55F2A2B4.7090705@redhat.com> <55F2B06C.2070801@redhat.com> <55F2BF43.4080903@redhat.com> <55F680F6.7040203@redhat.com> <55F69938.6000101@redhat.com> <55F6B45E.2020404@redhat.com> <55F6EC23.9090801@redhat.com> <55F7E277.3070800@redhat.com> Message-ID: <55F99E4D.3030008@redhat.com> On 09/15/2015 11:18 AM, Milan Kub?k wrote: > On 09/14/2015 05:47 PM, Martin Basti wrote: >> >> >> On 09/14/2015 01:49 PM, Lenka Doudova wrote: >>> All good, >>> ACK >>> >>> On 09/14/2015 11:54 AM, Milan Kub?k wrote: >>>> On 09/14/2015 10:10 AM, Lenka Doudova wrote: >>>>> NACK because: >>>>> >>>>> $ pep8 ipatests/test_xmlrpc/test_certprofile_plugin.py >>>>> ipatests/test_xmlrpc/test_certprofile_plugin.py:213:8: E121 >>>>> continuation line under-indented for hanging indent >>>>> >>>>> (just a missing space in the indent) >>>>> >>>>> Lenka >>>>> >>>>> On 09/11/2015 01:47 PM, Milan Kub?k wrote: >>>>>> On 09/11/2015 12:43 PM, Lenka Doudova wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 09/11/2015 11:45 AM, Milan Kub?k wrote: >>>>>>> >>>>>>>> On 09/11/2015 10:27 AM, Martin Basti wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/11/2015 09:51 AM, Lenka Doudova wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/10/2015 02:11 PM, Milan Kub?k wrote: >>>>>>>>>> >>>>>>>>>>> On 09/04/2015 03:57 PM, Martin Babinsky wrote: >>>>>>>>>>> >>>>>>>>>>>> On 09/04/2015 11:06 AM, Lenka Doudova wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> there's no traceback in the file you mentioned, but I'm >>>>>>>>>>>>> running it >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> through lite-server, so here's the traceback from there: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://pastebin.test.redhat.com/310598 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I can't really get to the problem. What I forgot to >>>>>>>>>>>>> mention in the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> previous email was that the tests fail when attempting to >>>>>>>>>>>>> add a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> certprofile, but if I try to do is manually using 'ipa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> certprofile-import' command with the exact same data as >>>>>>>>>>>>> used in the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> test, it works fine. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Lenka >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Do you get the traceback also when you run the tests using >>>>>>>>>>>> >>>>>>>>>>>> 'ipa-run-tests' with installed IPA master? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I don't think it is possible to run these tests against the >>>>>>>>>>> lite >>>>>>>>>>> server. Please do it on regular installation. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Anyway, sorry for the long delay. I send the updated patches. >>>>>>>>>>> >>>>>>>>>>> I updated them to reflect the fix for rename option and >>>>>>>>>>> extended >>>>>>>>>>> about test with importing a profile from XML file. The test >>>>>>>>>>> case >>>>>>>>>>> may need to be updated, based on the resolution of [1]. >>>>>>>>>>> >>>>>>>>>>> This at the moment raises remote retrieve error (400 from >>>>>>>>>>> dogtag), >>>>>>>>>>> I think there should be more clear message (detecting xml). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1]: https://fedorahosted.org/freeipa/ticket/5294 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Milan >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> can't build rpms after applying the patches (namely patch >>>>>>>>>> 0009.2): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Module ipatests.test_xmlrpc.utils >>>>>>>>>> >>>>>>>>>> ipatests/test_xmlrpc/utils.py:10: [E1101(no-member), >>>>>>>>>> prepare_config] >>>>>>>>>> Module 'py' has no 'path' member) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Lenka >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Do we need new util.py in test_xmlrpc? Why not just add it into >>>>>>>>> existing ipatests/util.py? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Updated patch attached. >>>>>>>> >>>>>>>> Changes: >>>>>>>> >>>>>>>> content of ipatests.test_xmlrpc.utils moved to ipatests.utils >>>>>>>> >>>>>>>> make-lint updated to ignore py.path submodule >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Again got an error: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Module ipatests.test_xmlrpc.test_certprofile_plugin >>>>>>> >>>>>>> >>>>>>> >>>>>>> ipatests/test_xmlrpc/test_certprofile_plugin.py:16: >>>>>>> [E0611(no-name-in-module), ] No name 'utils' in module 'ipatests') >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Probably just extra 's' in: >>>>>>> >>>>>>> >>>>>>> >>>>>>> from ipatests.utils import prepare_config >>>>>>> >>>>>>> >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> >>>>>>> >>>>>> Typo fixed. Removed the py module from the code after an offline >>>>>> discussion. >>>>>> Patch attached. >>>>>> >>>>>> Milan >>>>>> >>>>> >>>> Fixed. Patch attached. >>>> >>>> Milan >>> >> >> I cannot apply this patch on master branch even with 3-way merge, >> thus I cannot push this, please send rebased patch. > Hi, > > rebased patches attached. > > Milan Pushed to: ipa-4-2: 223dc3d8d99e773336c94a3d968521e5cea8e35d master: 1550b5ab50966387bac19f46b34a2107010d08d4 From jcholast at redhat.com Thu Sep 17 09:09:12 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Sep 2015 11:09:12 +0200 Subject: [Freeipa-devel] [PATCHES 481-486] Metaclass and str modernization In-Reply-To: <55F2D5F1.9090900@redhat.com> References: <55E5BA6C.2080502@redhat.com> <55E881FE.6010807@redhat.com> <55ED2864.1010404@redhat.com> <55F2D5F1.9090900@redhat.com> Message-ID: <55FA8338.9050802@redhat.com> On 11.9.2015 15:24, Petr Viktorin wrote: > On 09/07/2015 08:02 AM, Jan Cholasta wrote: >> On 3.9.2015 19:23, Petr Viktorin wrote: >>> On 09/01/2015 04:47 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches add some more modernization to our code. > [...] >>> 484: >>> To avoid merge conflicts later, perhaps it would be better to have >>> >>> if six.PY3: >>> unicode = str >>> >>> at the start of each affected file, instead of scattering changes in the >>> files? >>> (I can prepare the patch if you agree) >> >> (Be my guest) >> >>> >>> >>> 485: >>> six.binary_type is named "bytes" since Python 2.6. I think it would be >>> better to use that, to avoid another change when py2 is dropped. >>> (I can prepare the patch here, too) >> >> (OK) >> >>> >>> >>> 486: ACK > > Here are the two patches updated to use "unicode" and "bytes". Thanks, ACK. Pushed to master: 33aba6f35e43b5febf1751de4cef2863749f93e7 -- Jan Cholasta From jcholast at redhat.com Thu Sep 17 09:37:24 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Sep 2015 11:37:24 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55F67AC4.8080300@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> <55E68898.1000300@redhat.com> <55E8488E.5070308@redhat.com> <55EF4DD6.5010706@redhat.com> <55EFF35C.3050007@redhat.com> <55F060BE.6030403@redhat.com> <55F67AC4.8080300@redhat.com> Message-ID: <55FA89D4.2000609@redhat.com> On 14.9.2015 09:44, Jan Cholasta wrote: > On 9.9.2015 18:39, Petr Vobornik wrote: >> On 09/09/2015 10:52 AM, Jan Cholasta wrote: >>> On 8.9.2015 23:06, Petr Vobornik wrote: >>>> On 09/03/2015 03:18 PM, Jan Cholasta wrote: >>>>> On 2.9.2015 07:26, Endi Sukma Dewata wrote: >>>>>> On 9/1/2015 10:22 AM, Simo Sorce wrote: >>>>>>> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >>>>>>>> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>>>>>>>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>>>>>>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>>>>>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>>>>>>>> adds commands: >>>>>>>>>>>> * vaultcontainer-show [--service |--user ] >>>>>>>>>>>> * vaultcontainer-add-owner >>>>>>>>>>>> [--service |--user ] >>>>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>>>> ] >>>>>>>>>>>> * vaultcontainer-remove-owner >>>>>>>>>>>> [--service |--user ] >>>>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>>>> ] >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>>>>>>>> >>>>>>>>>>>> Use cases: >>>>>>>>>>>> 1. When user/service is deleted, associated vault container >>>>>>>>>>>> looses >>>>>>>>>>>> owner. There was no API command to set the owner. >>>>>>>>>>>> 2. Change owner of container by admin to manage access. >>>>>>>>>>>> >>>>>>>>>>>> Show command was added to show current owners. >>>>>>>>>>>> >>>>>>>>>>>> Find command was not added, should it be? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is also a design for vault container ownership handling >>>>>>>>>>> created by >>>>>>>>>>> Endi - it's for future Vault 2.0. >>>>>>>>>>> >>>>>>>>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This patch has a different API than the proposed - different >>>>>>>>>>> way of >>>>>>>>>>> specifying the container. The design page uses path e.g. >>>>>>>>>>> /users/foobar. >>>>>>>>>>> This patch uses the same way as vaults e.g. --user=foobar. This >>>>>>>>>>> means >>>>>>>>>>> that the implementation in this patch cannot manage ownership of >>>>>>>>>>> parent >>>>>>>>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>>>>>>>> >>>>>>>>>>> Do we want to go with this approach in 4.2? >>>>>>>>>>> >>>>>>>>>>> Attaching also new path which removes setting of owner which >>>>>>>>>>> doesn't >>>>>>>>>>> exist so that integrity is OK and that it is consistent with >>>>>>>>>>> removing of >>>>>>>>>>> user. >>>>>>>>>>> >>>>>>>>>>> Updated patch attached - output fix. >>>>>>>>>> >>>>>>>>>> We had a long discussion about this with Petr and we think the >>>>>>>>>> best >>>>>>>>>> approach is as follows: >>>>>>>>>> >>>>>>>>>> * Add new "Vault administrators" privilege. Vault >>>>>>>>>> administrators will >>>>>>>>>> have unrestricted access to vaults and vault containers, >>>>>>>>>> including >>>>>>>>>> the >>>>>>>>>> power to add/remove owners of vaults and vault containers. >>>>>>>>>> >>>>>>>>>> * Remove the ability of vault owners to add/remove other >>>>>>>>>> vault >>>>>>>>>> owners. If vault owner needs to be changed, vault administrator >>>>>>>>>> has to >>>>>>>>>> do it. Note that vault owners will still have the ability to >>>>>>>>>> add/remove >>>>>>>>>> vault members. >>>>>>>>>> >>>>>>>>>> * When adding new vault container, set owner to the current >>>>>>>>>> user. If >>>>>>>>>> vault container owner needs to be changed, vault administrator >>>>>>>>>> has >>>>>>>>>> to do >>>>>>>>>> it. >>>>>>>>>> >>>>>>>>>> * Allow adding vaults and vault containers only if the >>>>>>>>>> owner is >>>>>>>>>> set >>>>>>>>>> to the current user. >>>>>>>>>> >>>>>>>>>> * Introduce commands to modify vault container owner and to >>>>>>>>>> delete >>>>>>>>>> vault container, so the administrator has a choice between >>>>>>>>>> assigning >>>>>>>>>> ownership or deleting an unowned container. >>>>>>>>> >>>>>>>>> Also: >>>>>>>>> >>>>>>>>> * Control access to vault data using an ipaProtectedOperation >>>>>>>>> ACI. >>>>>>>>> Users which have read access to "ipaProtectedOperation;accessKRA" >>>>>>>>> on a >>>>>>>>> vault can retrieve data from the vault and users which have write >>>>>>>>> access >>>>>>>>> to "ipaProtectedOperation;accessKRA" on a vault can archive >>>>>>>>> data in >>>>>>>>> the >>>>>>>>> vault. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> CCing Simo and Endi to check the proposal. >>>>>>>> >>>>>>>> And Scott (related to #5216, #5215) >>>>>>> >>>>>>> Sounds reasonable to me. >>>>>>> I can see that allowing owners to hand over vaults w/o admin >>>>>>> intervention may have some appeal in some use cases, but I also >>>>>>> see it >>>>>>> can bring downsides with it, so all in all I think I agree with the >>>>>>> above points. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> Not a total objection, but if many people in unrelated groups are >>>>>> using >>>>>> vaults, and they are sharing the vaults only with members of each >>>>>> group, >>>>>> having to ask a Vault Administrator for each ownership change >>>>>> sounds a >>>>>> bit cumbersome. Since the Vault Adminstrator will have access to all >>>>>> vaults in all groups, only a small number of people can be trusted to >>>>>> hold that role. If there are many ownership changes the Vault >>>>>> Administrator will have to handle all those requests, and the vault >>>>>> users may have to wait until the change is completed. >>>>>> >>>>>> If owners are allowed to add others as owners, the vaults will be >>>>>> pretty >>>>>> much maintenance free to the admin. >>>>> >>>>> Owners can still manage members, which is IMO good enough for >>>>> sharing a >>>>> vault with other users. >>>>> >>>>>> >>>>>> Regardless, please update the wiki page to describe the new behavior >>>>>> when it's implemented: >>>>>> http://www.freeipa.org/page/V4/Password_Vault_1.1 >>>>> >>>>> Sure. >>>>> >>>>> I have updated and rebased Petr's patch 916. >>>>> >>>>> Patch 488 obsoletes Petr's patch 918. >>>>> >>>>> Patch for vault data access control is not included, because I was not >>>>> able to make GER work correctly with >>>>> "ipaProtectedOperation;accessKRA". >>>>> >>>> >>>> I found 1 major issue(#3), one easy fix(#2), optional(#1) and a >>>> question >>>> (#4). >>>> >>>> 1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a >>>> blocker. >>>> >>>> [pvoborni at vm-063 ~]$ ipa vaultcontainer-del --user=fbar >>>> -------------------------- >>>> Deleted vault container "" >>>> -------------------------- >>> >>> Fixed. >>> >>>> >>>> >>>> 2. Invalid description of vaultcontainer-show >>>> "Display information about a vault." >>> >>> Fixed >>> >>>> >>>> 3. Something which needs to be fixed: >>>> >>>> Setting password for first vault without a vault container fails(here >>>> run as vault admin but the same issue is present when it's run as the >>>> user). >>>> >>>> [pvoborni at vm-063 ~]$ ipa vault-add f1 --user=fbar >>>> New password: >>>> Verify password: >>>> ipa: ERROR: Invalid credentials >>>> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >>>> --------------- >>>> 1 vault matched >>>> --------------- >>>> Vault name: f1 >>>> Type: symmetric >>>> Vault user: fbar >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>> >>> Works for me. Are you testing on master or ipa-4-2? >> >> I might have not copied a required file during the testing. It works for >> me now as well. Petr investigated further and found out that this is caused by vaultcontainer-del, which deletes all its child vaults from LDAP, but not from KRA. Fixed by disabling subtree delete for vaultcontainer-del. >> >>> >>>> >>>> Second works: >>>> >>>> [pvoborni at vm-063 ~]$ ipa vault-add f2 --user=fbar >>>> New password: >>>> Verify password: >>>> ** Passwords do not match! ** >>>> New password: >>>> Verify password: >>>> ---------------- >>>> Added vault "f2" >>>> ---------------- >>>> Vault name: f2 >>>> Type: symmetric >>>> Salt: w4tnrjW/Ra2jGS8lI6Frfg== >>>> Owner users: va >>>> Vault user: fbar >>>> >>>> >>>> >>>> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >>>> ---------------- >>>> 2 vaults matched >>>> ---------------- >>>> Vault name: f1 >>>> Type: symmetric >>>> Vault user: fbar >>>> >>>> Vault name: f2 >>>> Type: symmetric >>>> Vault user: fbar >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> >>>> 4. Q: Should vault container owner delete all its vault? >>> >>> I don't know, should it? IMO it shouldn't, at least not by default. >>> >>>> >>>> As fbar when there is a vault without fbar as owner >>>> >>>> [root at vm-063 pvoborni]# ipa vaultcontainer-del >>>> ipa: ERROR: Not allowed on non-leaf entry >>>> >>>> when fbar is added as owner to all vaults >>>> >>>> [root at vm-063 pvoborni]# ipa vaultcontainer-del >>>> -------------------------- >>>> Deleted vault container "" >>>> -------------------------- >>>> [root at vm-063 pvoborni]# ipa vault-add f1 >>>> New password: >>>> Verify password: >>>> ipa: ERROR: Invalid credentials >>>> [root at vm-063 pvoborni]# ipa vault-del f1 >>>> ------------------ >>>> Deleted vault "f1" >>>> ------------------ >>>> [root at vm-063 pvoborni]# ipa vault-add f1 >>>> New password: >>>> Verify password: >>>> ---------------- >>>> Added vault "f1" >>>> ---------------- >>>> Vault name: f1 >>>> Type: symmetric >>>> Salt: bkHxRIipkaeX+H/fOnZdBw== >>>> Owner users: fbar >>>> Vault user: fbar >>>> >>> >>> >> >> > > Updated and rebased patches attached. > > Added new patch 491 to support KRA updates. Updated and rebased patches attached. Added new patch 493 which makes subtree deletion optional in LDAPDelete. Apply before the vault container commands patch. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-493-baseldap-make-subtree-deletion-optional-in-LDAPDelet.patch Type: text/x-patch Size: 1111 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0916-4-vault-add-vault-container-commands.patch Type: text/x-patch Size: 12818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-488.2-vault-set-owner-to-current-user-on-container-creatio.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-489.2-vault-update-access-control.patch Type: text/x-patch Size: 6173 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-490.2-vault-add-permissions-and-administrator-privilege.patch Type: text/x-patch Size: 11138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-491.1-install-support-KRA-update.patch Type: text/x-patch Size: 14508 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 17 11:47:29 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Sep 2015 13:47:29 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages Message-ID: <55FAA851.5030300@redhat.com> Hi fellow developers, more or less we tend to stick to the tradition of linking Trac tickets to the commit messages of the patches we send to the list. However, every now and then, a patch lands on the list, which is either linked to a BZ or does not contain any link at all. Admittedly, I am also guilty of this mishap. This poses certain problems, as we're trying to automate the bookkeeping and pushing-related processes with ipatool [1]. Nevertheless, this useful habit is not formally agreed upon by developers nor documented in our wiki [2]. I'd suggest we add it there, if we come to such consensus. This would mean: * Patches fixing an issue described only in BZ (rare issue) would need to create a Trac ticket referencing the BZ * Patches fixing an issue not tracked in Trac nor BZ would need to file a ticket in Trac and reference it Thoughts? [1] https://github.com/freeipa/freeipa-tools/blob/master/ipatool [2] http://www.freeipa.org/page/Contribute/Code From mkosek at redhat.com Thu Sep 17 11:53:32 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Sep 2015 13:53:32 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAA851.5030300@redhat.com> References: <55FAA851.5030300@redhat.com> Message-ID: <55FAA9BC.6050702@redhat.com> On 09/17/2015 01:47 PM, Tomas Babej wrote: > Hi fellow developers, > > more or less we tend to stick to the tradition of linking Trac tickets > to the commit messages of the patches we send to the list. > > However, every now and then, a patch lands on the list, which is either > linked to a BZ or does not contain any link at all. Admittedly, I am > also guilty of this mishap. This poses certain problems, as we're trying > to automate the bookkeeping and pushing-related processes with ipatool [1]. > > Nevertheless, this useful habit is not formally agreed upon by > developers nor documented in our wiki [2]. I'd suggest we add it there, > if we come to such consensus. > > This would mean: > * Patches fixing an issue described only in BZ (rare issue) would need > to create a Trac ticket referencing the BZ +1 > * Patches fixing an issue not tracked in Trac nor BZ would need to file > a ticket in Trac and reference it I am not sure we are there yet. For typos and small fixes, I do not think we need to create a hard requirement for a Trac ticket. But for patches that you want to be considered for say backports to downstream releases, it is better to have the ticket with the right metadata and collection of the right hashes that the downstream release can digest. > > Thoughts? > > [1] https://github.com/freeipa/freeipa-tools/blob/master/ipatool > [2] http://www.freeipa.org/page/Contribute/Code > From ldoudova at redhat.com Thu Sep 17 11:55:50 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 17 Sep 2015 13:55:50 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAA851.5030300@redhat.com> References: <55FAA851.5030300@redhat.com> Message-ID: <55FAAA46.5060302@redhat.com> Hi, though I'm not a fellow developer, I'd like to point out that the habit you mentioned (putting a link into commit message) is indeed documented on wiki [1]. It's just on a spot where it's not that much visible. Sorry if I misunderstood the point of your email. Lenka [1] http://www.freeipa.org/page/Contribute/Patch_Format On 09/17/2015 01:47 PM, Tomas Babej wrote: > Hi fellow developers, > > more or less we tend to stick to the tradition of linking Trac tickets > to the commit messages of the patches we send to the list. > > However, every now and then, a patch lands on the list, which is either > linked to a BZ or does not contain any link at all. Admittedly, I am > also guilty of this mishap. This poses certain problems, as we're trying > to automate the bookkeeping and pushing-related processes with ipatool [1]. > > Nevertheless, this useful habit is not formally agreed upon by > developers nor documented in our wiki [2]. I'd suggest we add it there, > if we come to such consensus. > > This would mean: > * Patches fixing an issue described only in BZ (rare issue) would need > to create a Trac ticket referencing the BZ > * Patches fixing an issue not tracked in Trac nor BZ would need to file > a ticket in Trac and reference it > > Thoughts? > > [1] https://github.com/freeipa/freeipa-tools/blob/master/ipatool > [2] http://www.freeipa.org/page/Contribute/Code > From abokovoy at redhat.com Thu Sep 17 12:00:01 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Sep 2015 15:00:01 +0300 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAA9BC.6050702@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> Message-ID: <20150917120001.GV6168@redhat.com> On Thu, 17 Sep 2015, Martin Kosek wrote: >On 09/17/2015 01:47 PM, Tomas Babej wrote: >> Hi fellow developers, >> >> more or less we tend to stick to the tradition of linking Trac tickets >> to the commit messages of the patches we send to the list. >> >> However, every now and then, a patch lands on the list, which is either >> linked to a BZ or does not contain any link at all. Admittedly, I am >> also guilty of this mishap. This poses certain problems, as we're trying >> to automate the bookkeeping and pushing-related processes with ipatool [1]. >> >> Nevertheless, this useful habit is not formally agreed upon by >> developers nor documented in our wiki [2]. I'd suggest we add it there, >> if we come to such consensus. >> >> This would mean: >> * Patches fixing an issue described only in BZ (rare issue) would need >> to create a Trac ticket referencing the BZ > >+1 > >> * Patches fixing an issue not tracked in Trac nor BZ would need to file >> a ticket in Trac and reference it > >I am not sure we are there yet. For typos and small fixes, I do not think we >need to create a hard requirement for a Trac ticket. But for patches that you >want to be considered for say backports to downstream releases, it is better to >have the ticket with the right metadata and collection of the right hashes that >the downstream release can digest. Yes, please do a ticket per a changeset. -- / Alexander Bokovoy From pvoborni at redhat.com Thu Sep 17 12:00:33 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 17 Sep 2015 14:00:33 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAA9BC.6050702@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> Message-ID: <55FAAB61.9040802@redhat.com> On 09/17/2015 01:53 PM, Martin Kosek wrote: > On 09/17/2015 01:47 PM, Tomas Babej wrote: >> Hi fellow developers, >> >> more or less we tend to stick to the tradition of linking Trac tickets >> to the commit messages of the patches we send to the list. >> >> However, every now and then, a patch lands on the list, which is either >> linked to a BZ or does not contain any link at all. Admittedly, I am >> also guilty of this mishap. This poses certain problems, as we're trying >> to automate the bookkeeping and pushing-related processes with ipatool [1]. >> >> Nevertheless, this useful habit is not formally agreed upon by >> developers nor documented in our wiki [2]. I'd suggest we add it there, >> if we come to such consensus. >> >> This would mean: >> * Patches fixing an issue described only in BZ (rare issue) would need >> to create a Trac ticket referencing the BZ > > +1 +1 > >> * Patches fixing an issue not tracked in Trac nor BZ would need to file >> a ticket in Trac and reference it > > I am not sure we are there yet. For typos and small fixes, I do not think we > need to create a hard requirement for a Trac ticket. But for patches that you > want to be considered for say backports to downstream releases, it is better to > have the ticket with the right metadata and collection of the right hashes that > the downstream release can digest. +1 > >> >> Thoughts? >> >> [1] https://github.com/freeipa/freeipa-tools/blob/master/ipatool >> [2] http://www.freeipa.org/page/Contribute/Code >> -- Petr Vobornik From mkosek at redhat.com Thu Sep 17 12:01:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Sep 2015 14:01:18 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <20150917120001.GV6168@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> Message-ID: <55FAAB8E.1030009@redhat.com> On 09/17/2015 02:00 PM, Alexander Bokovoy wrote: > On Thu, 17 Sep 2015, Martin Kosek wrote: >> On 09/17/2015 01:47 PM, Tomas Babej wrote: >>> Hi fellow developers, >>> >>> more or less we tend to stick to the tradition of linking Trac tickets >>> to the commit messages of the patches we send to the list. >>> >>> However, every now and then, a patch lands on the list, which is either >>> linked to a BZ or does not contain any link at all. Admittedly, I am >>> also guilty of this mishap. This poses certain problems, as we're trying >>> to automate the bookkeeping and pushing-related processes with ipatool [1]. >>> >>> Nevertheless, this useful habit is not formally agreed upon by >>> developers nor documented in our wiki [2]. I'd suggest we add it there, >>> if we come to such consensus. >>> >>> This would mean: >>> * Patches fixing an issue described only in BZ (rare issue) would need >>> to create a Trac ticket referencing the BZ >> >> +1 >> >>> * Patches fixing an issue not tracked in Trac nor BZ would need to file >>> a ticket in Trac and reference it >> >> I am not sure we are there yet. For typos and small fixes, I do not think we >> need to create a hard requirement for a Trac ticket. But for patches that you >> want to be considered for say backports to downstream releases, it is better to >> have the ticket with the right metadata and collection of the right hashes that >> the downstream release can digest. > Yes, please do a ticket per a changeset. Are you agreeing now to me, i.e. do not require tickets for trivial fixes or to Tomas' proposal - require ticket for *all* patches? From tbabej at redhat.com Thu Sep 17 12:07:44 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Sep 2015 14:07:44 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAA9BC.6050702@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> Message-ID: <55FAAD10.40104@redhat.com> On 09/17/2015 01:53 PM, Martin Kosek wrote: > On 09/17/2015 01:47 PM, Tomas Babej wrote: >> Hi fellow developers, >> >> more or less we tend to stick to the tradition of linking Trac tickets >> to the commit messages of the patches we send to the list. >> >> However, every now and then, a patch lands on the list, which is either >> linked to a BZ or does not contain any link at all. Admittedly, I am >> also guilty of this mishap. This poses certain problems, as we're trying >> to automate the bookkeeping and pushing-related processes with ipatool [1]. >> >> Nevertheless, this useful habit is not formally agreed upon by >> developers nor documented in our wiki [2]. I'd suggest we add it there, >> if we come to such consensus. >> >> This would mean: >> * Patches fixing an issue described only in BZ (rare issue) would need >> to create a Trac ticket referencing the BZ > > +1 > >> * Patches fixing an issue not tracked in Trac nor BZ would need to file >> a ticket in Trac and reference it > > I am not sure we are there yet. For typos and small fixes, I do not think we > need to create a hard requirement for a Trac ticket. But for patches that you > want to be considered for say backports to downstream releases, it is better to > have the ticket with the right metadata and collection of the right hashes that > the downstream release can digest. I agree it might be a good idea to be less harsh on the trivial patches, however, how do we draw the line? This puts the decision burden on the contributor who might not have the necessary insight and/or information. I'd suggest we go this route, I don't want to put more obstacles for new contributors and small patches. However, then the regular FreeIPA committers need to notify the new contributors if their patch crosses the triviality barrier and warrants a ticket :) From abokovoy at redhat.com Thu Sep 17 12:08:57 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Sep 2015 15:08:57 +0300 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAAB8E.1030009@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> Message-ID: <20150917120857.GW6168@redhat.com> On Thu, 17 Sep 2015, Martin Kosek wrote: >On 09/17/2015 02:00 PM, Alexander Bokovoy wrote: >> On Thu, 17 Sep 2015, Martin Kosek wrote: >>> On 09/17/2015 01:47 PM, Tomas Babej wrote: >>>> Hi fellow developers, >>>> >>>> more or less we tend to stick to the tradition of linking Trac tickets >>>> to the commit messages of the patches we send to the list. >>>> >>>> However, every now and then, a patch lands on the list, which is either >>>> linked to a BZ or does not contain any link at all. Admittedly, I am >>>> also guilty of this mishap. This poses certain problems, as we're trying >>>> to automate the bookkeeping and pushing-related processes with ipatool [1]. >>>> >>>> Nevertheless, this useful habit is not formally agreed upon by >>>> developers nor documented in our wiki [2]. I'd suggest we add it there, >>>> if we come to such consensus. >>>> >>>> This would mean: >>>> * Patches fixing an issue described only in BZ (rare issue) would need >>>> to create a Trac ticket referencing the BZ >>> >>> +1 >>> >>>> * Patches fixing an issue not tracked in Trac nor BZ would need to file >>>> a ticket in Trac and reference it >>> >>> I am not sure we are there yet. For typos and small fixes, I do not think we >>> need to create a hard requirement for a Trac ticket. But for patches that you >>> want to be considered for say backports to downstream releases, it is better to >>> have the ticket with the right metadata and collection of the right hashes that >>> the downstream release can digest. >> Yes, please do a ticket per a changeset. > >Are you agreeing now to me, i.e. do not require tickets for trivial fixes or to >Tomas' proposal - require ticket for *all* patches? I think we should have tickets for reasonable pieces of work. The problem is always in identifying what does 'reasonable' mean. A single-line fix may be an important CVE fix or a key to an important bugfix. Still, there should be a context to fit, thus a ticket. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Sep 17 12:12:01 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Sep 2015 15:12:01 +0300 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAAD10.40104@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <55FAAD10.40104@redhat.com> Message-ID: <20150917121201.GX6168@redhat.com> On Thu, 17 Sep 2015, Tomas Babej wrote: > > >On 09/17/2015 01:53 PM, Martin Kosek wrote: >> On 09/17/2015 01:47 PM, Tomas Babej wrote: >>> Hi fellow developers, >>> >>> more or less we tend to stick to the tradition of linking Trac tickets >>> to the commit messages of the patches we send to the list. >>> >>> However, every now and then, a patch lands on the list, which is either >>> linked to a BZ or does not contain any link at all. Admittedly, I am >>> also guilty of this mishap. This poses certain problems, as we're trying >>> to automate the bookkeeping and pushing-related processes with ipatool [1]. >>> >>> Nevertheless, this useful habit is not formally agreed upon by >>> developers nor documented in our wiki [2]. I'd suggest we add it there, >>> if we come to such consensus. >>> >>> This would mean: >>> * Patches fixing an issue described only in BZ (rare issue) would need >>> to create a Trac ticket referencing the BZ >> >> +1 >> >>> * Patches fixing an issue not tracked in Trac nor BZ would need to file >>> a ticket in Trac and reference it >> >> I am not sure we are there yet. For typos and small fixes, I do not think we >> need to create a hard requirement for a Trac ticket. But for patches that you >> want to be considered for say backports to downstream releases, it is better to >> have the ticket with the right metadata and collection of the right hashes that >> the downstream release can digest. > >I agree it might be a good idea to be less harsh on the trivial patches, >however, how do we draw the line? This puts the decision burden on the >contributor who might not have the necessary insight and/or information. > >I'd suggest we go this route, I don't want to put more obstacles for new >contributors and small patches. However, then the regular FreeIPA >committers need to notify the new contributors if their patch crosses >the triviality barrier and warrants a ticket :) Yes, a reviewer should be able to file a ticket. ;) -- / Alexander Bokovoy From tbabej at redhat.com Thu Sep 17 12:13:20 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Sep 2015 14:13:20 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAAA17.2090508@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAAA17.2090508@redhat.com> Message-ID: <55FAAE60.2000208@redhat.com> On 09/17/2015 01:55 PM, Lenka Doudova wrote: > Hi, > > though I'm not a fellow developer, I'd like to point out that the habit $ git shortlog | grep Lenka tells me otherwise. This thread is applicable to everybody contributing to the FreeIPA git repo, so maybe developer was a poor choice of wording. > you mentioned (putting a link into commit message) is indeed documented > on wiki [1]. Indeed, I missed that. However, the cited page only states: "If the patch adresses a ticket in Trac, the last line of the commit should be the URL to that ticket." which does not provide instructions in the case when the corresponding ticket does not exist. From jcholast at redhat.com Thu Sep 17 12:51:19 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Sep 2015 14:51:19 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <20150917120857.GW6168@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> Message-ID: <55FAB747.3010805@redhat.com> On 17.9.2015 14:08, Alexander Bokovoy wrote: > On Thu, 17 Sep 2015, Martin Kosek wrote: >> On 09/17/2015 02:00 PM, Alexander Bokovoy wrote: >>> On Thu, 17 Sep 2015, Martin Kosek wrote: >>>> On 09/17/2015 01:47 PM, Tomas Babej wrote: >>>>> Hi fellow developers, >>>>> >>>>> more or less we tend to stick to the tradition of linking Trac tickets >>>>> to the commit messages of the patches we send to the list. >>>>> >>>>> However, every now and then, a patch lands on the list, which is >>>>> either >>>>> linked to a BZ or does not contain any link at all. Admittedly, I am >>>>> also guilty of this mishap. This poses certain problems, as we're >>>>> trying >>>>> to automate the bookkeeping and pushing-related processes with >>>>> ipatool [1]. >>>>> >>>>> Nevertheless, this useful habit is not formally agreed upon by >>>>> developers nor documented in our wiki [2]. I'd suggest we add it >>>>> there, >>>>> if we come to such consensus. >>>>> >>>>> This would mean: >>>>> * Patches fixing an issue described only in BZ (rare issue) would need >>>>> to create a Trac ticket referencing the BZ >>>> >>>> +1 >>>> >>>>> * Patches fixing an issue not tracked in Trac nor BZ would need to >>>>> file >>>>> a ticket in Trac and reference it >>>> >>>> I am not sure we are there yet. For typos and small fixes, I do not >>>> think we >>>> need to create a hard requirement for a Trac ticket. But for patches >>>> that you >>>> want to be considered for say backports to downstream releases, it >>>> is better to >>>> have the ticket with the right metadata and collection of the right >>>> hashes that >>>> the downstream release can digest. >>> Yes, please do a ticket per a changeset. >> >> Are you agreeing now to me, i.e. do not require tickets for trivial >> fixes or to >> Tomas' proposal - require ticket for *all* patches? > I think we should have tickets for reasonable pieces of work. The > problem is always in identifying what does 'reasonable' mean. A > single-line fix may be an important CVE fix or a key to an important > bugfix. Still, there should be a context to fit, thus a ticket. Speaking as IPA package maitainer in RHEL, I would like to have ticket link in every commit in maintenance branches. If a commit goes to the master branch only, I'm OK with it not having a ticket link. So that's where I would draw the line - if a commit goes into a maintenance branch, it is a reasonable piece of work. -- Jan Cholasta From abokovoy at redhat.com Thu Sep 17 12:55:35 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Sep 2015 15:55:35 +0300 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAB747.3010805@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> Message-ID: <20150917125535.GY6168@redhat.com> On Thu, 17 Sep 2015, Jan Cholasta wrote: >On 17.9.2015 14:08, Alexander Bokovoy wrote: >>On Thu, 17 Sep 2015, Martin Kosek wrote: >>>On 09/17/2015 02:00 PM, Alexander Bokovoy wrote: >>>>On Thu, 17 Sep 2015, Martin Kosek wrote: >>>>>On 09/17/2015 01:47 PM, Tomas Babej wrote: >>>>>>Hi fellow developers, >>>>>> >>>>>>more or less we tend to stick to the tradition of linking Trac tickets >>>>>>to the commit messages of the patches we send to the list. >>>>>> >>>>>>However, every now and then, a patch lands on the list, which is >>>>>>either >>>>>>linked to a BZ or does not contain any link at all. Admittedly, I am >>>>>>also guilty of this mishap. This poses certain problems, as we're >>>>>>trying >>>>>>to automate the bookkeeping and pushing-related processes with >>>>>>ipatool [1]. >>>>>> >>>>>>Nevertheless, this useful habit is not formally agreed upon by >>>>>>developers nor documented in our wiki [2]. I'd suggest we add it >>>>>>there, >>>>>>if we come to such consensus. >>>>>> >>>>>>This would mean: >>>>>>* Patches fixing an issue described only in BZ (rare issue) would need >>>>>>to create a Trac ticket referencing the BZ >>>>> >>>>>+1 >>>>> >>>>>>* Patches fixing an issue not tracked in Trac nor BZ would need to >>>>>>file >>>>>>a ticket in Trac and reference it >>>>> >>>>>I am not sure we are there yet. For typos and small fixes, I do not >>>>>think we >>>>>need to create a hard requirement for a Trac ticket. But for patches >>>>>that you >>>>>want to be considered for say backports to downstream releases, it >>>>>is better to >>>>>have the ticket with the right metadata and collection of the right >>>>>hashes that >>>>>the downstream release can digest. >>>>Yes, please do a ticket per a changeset. >>> >>>Are you agreeing now to me, i.e. do not require tickets for trivial >>>fixes or to >>>Tomas' proposal - require ticket for *all* patches? >>I think we should have tickets for reasonable pieces of work. The >>problem is always in identifying what does 'reasonable' mean. A >>single-line fix may be an important CVE fix or a key to an important >>bugfix. Still, there should be a context to fit, thus a ticket. > >Speaking as IPA package maitainer in RHEL, I would like to have ticket >link in every commit in maintenance branches. If a commit goes to the >master branch only, I'm OK with it not having a ticket link. So that's >where I would draw the line - if a commit goes into a maintenance >branch, it is a reasonable piece of work. Good suggestion, thanks. We actually have the same with Samba -- *any* backport to released branches requires a new bug to be opened and mentioned in the commit message. -- / Alexander Bokovoy From pvoborni at redhat.com Thu Sep 17 13:01:47 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 17 Sep 2015 15:01:47 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55FA89D4.2000609@redhat.com> References: <55DCAE47.5080500@redhat.com> <55DDA17E.9050403@redhat.com> <55E5B57D.8030109@redhat.com> <55E5B8A7.9090700@redhat.com> <55E5C12D.1040007@redhat.com> <1441120972.28131.130.camel@willson.usersys.redhat.com> <55E68898.1000300@redhat.com> <55E8488E.5070308@redhat.com> <55EF4DD6.5010706@redhat.com> <55EFF35C.3050007@redhat.com> <55F060BE.6030403@redhat.com> <55F67AC4.8080300@redhat.com> <55FA89D4.2000609@redhat.com> Message-ID: <55FAB9BB.7050401@redhat.com> On 09/17/2015 11:37 AM, Jan Cholasta wrote: > On 14.9.2015 09:44, Jan Cholasta wrote: >> On 9.9.2015 18:39, Petr Vobornik wrote: >>> On 09/09/2015 10:52 AM, Jan Cholasta wrote: >>>> On 8.9.2015 23:06, Petr Vobornik wrote: >>>>> On 09/03/2015 03:18 PM, Jan Cholasta wrote: >>>>>> On 2.9.2015 07:26, Endi Sukma Dewata wrote: >>>>>>> On 9/1/2015 10:22 AM, Simo Sorce wrote: >>>>>>>> On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote: >>>>>>>>> On 09/01/2015 04:39 PM, Jan Cholasta wrote: >>>>>>>>>> On 1.9.2015 16:26, Jan Cholasta wrote: >>>>>>>>>>> On 26.8.2015 13:22, Petr Vobornik wrote: >>>>>>>>>>>> On 08/25/2015 08:04 PM, Petr Vobornik wrote: >>>>>>>>>>>>> adds commands: >>>>>>>>>>>>> * vaultcontainer-show [--service |--user ] >>>>>>>>>>>>> * vaultcontainer-add-owner >>>>>>>>>>>>> [--service |--user ] >>>>>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>>>>> ] >>>>>>>>>>>>> * vaultcontainer-remove-owner >>>>>>>>>>>>> [--service |--user ] >>>>>>>>>>>>> [--users ] [--groups ] [--services >>>>>>>>>>>>> ] >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5250 >>>>>>>>>>>>> >>>>>>>>>>>>> Use cases: >>>>>>>>>>>>> 1. When user/service is deleted, associated vault container >>>>>>>>>>>>> looses >>>>>>>>>>>>> owner. There was no API command to set the owner. >>>>>>>>>>>>> 2. Change owner of container by admin to manage access. >>>>>>>>>>>>> >>>>>>>>>>>>> Show command was added to show current owners. >>>>>>>>>>>>> >>>>>>>>>>>>> Find command was not added, should it be? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There is also a design for vault container ownership handling >>>>>>>>>>>> created by >>>>>>>>>>>> Endi - it's for future Vault 2.0. >>>>>>>>>>>> >>>>>>>>>>>> http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This patch has a different API than the proposed - different >>>>>>>>>>>> way of >>>>>>>>>>>> specifying the container. The design page uses path e.g. >>>>>>>>>>>> /users/foobar. >>>>>>>>>>>> This patch uses the same way as vaults e.g. --user=foobar. This >>>>>>>>>>>> means >>>>>>>>>>>> that the implementation in this patch cannot manage >>>>>>>>>>>> ownership of >>>>>>>>>>>> parent >>>>>>>>>>>> vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. >>>>>>>>>>>> >>>>>>>>>>>> Do we want to go with this approach in 4.2? >>>>>>>>>>>> >>>>>>>>>>>> Attaching also new path which removes setting of owner which >>>>>>>>>>>> doesn't >>>>>>>>>>>> exist so that integrity is OK and that it is consistent with >>>>>>>>>>>> removing of >>>>>>>>>>>> user. >>>>>>>>>>>> >>>>>>>>>>>> Updated patch attached - output fix. >>>>>>>>>>> >>>>>>>>>>> We had a long discussion about this with Petr and we think the >>>>>>>>>>> best >>>>>>>>>>> approach is as follows: >>>>>>>>>>> >>>>>>>>>>> * Add new "Vault administrators" privilege. Vault >>>>>>>>>>> administrators will >>>>>>>>>>> have unrestricted access to vaults and vault containers, >>>>>>>>>>> including >>>>>>>>>>> the >>>>>>>>>>> power to add/remove owners of vaults and vault containers. >>>>>>>>>>> >>>>>>>>>>> * Remove the ability of vault owners to add/remove other >>>>>>>>>>> vault >>>>>>>>>>> owners. If vault owner needs to be changed, vault administrator >>>>>>>>>>> has to >>>>>>>>>>> do it. Note that vault owners will still have the ability to >>>>>>>>>>> add/remove >>>>>>>>>>> vault members. >>>>>>>>>>> >>>>>>>>>>> * When adding new vault container, set owner to the current >>>>>>>>>>> user. If >>>>>>>>>>> vault container owner needs to be changed, vault administrator >>>>>>>>>>> has >>>>>>>>>>> to do >>>>>>>>>>> it. >>>>>>>>>>> >>>>>>>>>>> * Allow adding vaults and vault containers only if the >>>>>>>>>>> owner is >>>>>>>>>>> set >>>>>>>>>>> to the current user. >>>>>>>>>>> >>>>>>>>>>> * Introduce commands to modify vault container owner and to >>>>>>>>>>> delete >>>>>>>>>>> vault container, so the administrator has a choice between >>>>>>>>>>> assigning >>>>>>>>>>> ownership or deleting an unowned container. >>>>>>>>>> >>>>>>>>>> Also: >>>>>>>>>> >>>>>>>>>> * Control access to vault data using an ipaProtectedOperation >>>>>>>>>> ACI. >>>>>>>>>> Users which have read access to "ipaProtectedOperation;accessKRA" >>>>>>>>>> on a >>>>>>>>>> vault can retrieve data from the vault and users which have write >>>>>>>>>> access >>>>>>>>>> to "ipaProtectedOperation;accessKRA" on a vault can archive >>>>>>>>>> data in >>>>>>>>>> the >>>>>>>>>> vault. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> CCing Simo and Endi to check the proposal. >>>>>>>>> >>>>>>>>> And Scott (related to #5216, #5215) >>>>>>>> >>>>>>>> Sounds reasonable to me. >>>>>>>> I can see that allowing owners to hand over vaults w/o admin >>>>>>>> intervention may have some appeal in some use cases, but I also >>>>>>>> see it >>>>>>>> can bring downsides with it, so all in all I think I agree with the >>>>>>>> above points. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> Not a total objection, but if many people in unrelated groups are >>>>>>> using >>>>>>> vaults, and they are sharing the vaults only with members of each >>>>>>> group, >>>>>>> having to ask a Vault Administrator for each ownership change >>>>>>> sounds a >>>>>>> bit cumbersome. Since the Vault Adminstrator will have access to all >>>>>>> vaults in all groups, only a small number of people can be >>>>>>> trusted to >>>>>>> hold that role. If there are many ownership changes the Vault >>>>>>> Administrator will have to handle all those requests, and the vault >>>>>>> users may have to wait until the change is completed. >>>>>>> >>>>>>> If owners are allowed to add others as owners, the vaults will be >>>>>>> pretty >>>>>>> much maintenance free to the admin. >>>>>> >>>>>> Owners can still manage members, which is IMO good enough for >>>>>> sharing a >>>>>> vault with other users. >>>>>> >>>>>>> >>>>>>> Regardless, please update the wiki page to describe the new behavior >>>>>>> when it's implemented: >>>>>>> http://www.freeipa.org/page/V4/Password_Vault_1.1 >>>>>> >>>>>> Sure. >>>>>> >>>>>> I have updated and rebased Petr's patch 916. >>>>>> >>>>>> Patch 488 obsoletes Petr's patch 918. >>>>>> >>>>>> Patch for vault data access control is not included, because I was >>>>>> not >>>>>> able to make GER work correctly with >>>>>> "ipaProtectedOperation;accessKRA". >>>>>> >>>>> >>>>> I found 1 major issue(#3), one easy fix(#2), optional(#1) and a >>>>> question >>>>> (#4). >>>>> >>>>> 1. `ipa vaultcontainer-del` doesn't show user/service name. IMHO not a >>>>> blocker. >>>>> >>>>> [pvoborni at vm-063 ~]$ ipa vaultcontainer-del --user=fbar >>>>> -------------------------- >>>>> Deleted vault container "" >>>>> -------------------------- >>>> >>>> Fixed. >>>> >>>>> >>>>> >>>>> 2. Invalid description of vaultcontainer-show >>>>> "Display information about a vault." >>>> >>>> Fixed >>>> >>>>> >>>>> 3. Something which needs to be fixed: >>>>> >>>>> Setting password for first vault without a vault container fails(here >>>>> run as vault admin but the same issue is present when it's run as the >>>>> user). >>>>> >>>>> [pvoborni at vm-063 ~]$ ipa vault-add f1 --user=fbar >>>>> New password: >>>>> Verify password: >>>>> ipa: ERROR: Invalid credentials >>>>> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >>>>> --------------- >>>>> 1 vault matched >>>>> --------------- >>>>> Vault name: f1 >>>>> Type: symmetric >>>>> Vault user: fbar >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>> >>>> Works for me. Are you testing on master or ipa-4-2? >>> >>> I might have not copied a required file during the testing. It works for >>> me now as well. > > Petr investigated further and found out that this is caused by > vaultcontainer-del, which deletes all its child vaults from LDAP, but > not from KRA. Fixed by disabling subtree delete for vaultcontainer-del. > >>> >>>> >>>>> >>>>> Second works: >>>>> >>>>> [pvoborni at vm-063 ~]$ ipa vault-add f2 --user=fbar >>>>> New password: >>>>> Verify password: >>>>> ** Passwords do not match! ** >>>>> New password: >>>>> Verify password: >>>>> ---------------- >>>>> Added vault "f2" >>>>> ---------------- >>>>> Vault name: f2 >>>>> Type: symmetric >>>>> Salt: w4tnrjW/Ra2jGS8lI6Frfg== >>>>> Owner users: va >>>>> Vault user: fbar >>>>> >>>>> >>>>> >>>>> [pvoborni at vm-063 ~]$ ipa vault-find --user=fbar >>>>> ---------------- >>>>> 2 vaults matched >>>>> ---------------- >>>>> Vault name: f1 >>>>> Type: symmetric >>>>> Vault user: fbar >>>>> >>>>> Vault name: f2 >>>>> Type: symmetric >>>>> Vault user: fbar >>>>> ---------------------------- >>>>> Number of entries returned 2 >>>>> ---------------------------- >>>>> >>>>> >>>>> 4. Q: Should vault container owner delete all its vault? >>>> >>>> I don't know, should it? IMO it shouldn't, at least not by default. >>>> >>>>> >>>>> As fbar when there is a vault without fbar as owner >>>>> >>>>> [root at vm-063 pvoborni]# ipa vaultcontainer-del >>>>> ipa: ERROR: Not allowed on non-leaf entry >>>>> >>>>> when fbar is added as owner to all vaults >>>>> >>>>> [root at vm-063 pvoborni]# ipa vaultcontainer-del >>>>> -------------------------- >>>>> Deleted vault container "" >>>>> -------------------------- >>>>> [root at vm-063 pvoborni]# ipa vault-add f1 >>>>> New password: >>>>> Verify password: >>>>> ipa: ERROR: Invalid credentials >>>>> [root at vm-063 pvoborni]# ipa vault-del f1 >>>>> ------------------ >>>>> Deleted vault "f1" >>>>> ------------------ >>>>> [root at vm-063 pvoborni]# ipa vault-add f1 >>>>> New password: >>>>> Verify password: >>>>> ---------------- >>>>> Added vault "f1" >>>>> ---------------- >>>>> Vault name: f1 >>>>> Type: symmetric >>>>> Salt: bkHxRIipkaeX+H/fOnZdBw== >>>>> Owner users: fbar >>>>> Vault user: fbar >>>>> >>>> >>>> >>> >>> >> >> Updated and rebased patches attached. >> >> Added new patch 491 to support KRA updates. > > Updated and rebased patches attached. > > Added new patch 493 which makes subtree deletion optional in LDAPDelete. > Apply before the vault container commands patch. > ACK master: * 2964b019d93b33b9703e6e26c8ca6fc28509ba64 baseldap: make subtree deletion optional in LDAPDelete * d396913e9c0578fa68847b84e44a4f0dd916fbfd vault: add vault container commands * 5cf46b89364111b54172682283a6362bb82db9a6 vault: set owner to current user on container creation * d3503043c47a1adc139688776341dc86b7085448 vault: update access control * 0dfcf1d9db4b297791e3784588bf23cc0ac8d2ee vault: add permissions and administrator privilege * 5137478fb8bba16d9cbecba53983c893dc0884d5 install: support KRA update ipa-4-2: * b3932055c6ad0c4032790530c4776a5c7262cd8c baseldap: make subtree deletion optional in LDAPDelete * ad7325d08c432d77b048910d37be2bd8e13cb162 vault: add vault container commands * 78f890620b8cae286a03b26e28a0bee4ea49b8f1 vault: set owner to current user on container creation * b9615c89cd07a6bd2907686c03b2ea11e40c76bf vault: update access control * 500e0d152cf1611db47c775f3fbc5b72e1522da0 vault: add permissions and administrator privilege * b1587bf2d8072d76df52ea0c7480f146cbb8c933 install: support KRA update -- Petr Vobornik From mkubik at redhat.com Thu Sep 17 13:02:13 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 17 Sep 2015 15:02:13 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAB747.3010805@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> Message-ID: <55FAB9D5.9070408@redhat.com> On 09/17/2015 02:51 PM, Jan Cholasta wrote: > On 17.9.2015 14:08, Alexander Bokovoy wrote: >> On Thu, 17 Sep 2015, Martin Kosek wrote: >>> On 09/17/2015 02:00 PM, Alexander Bokovoy wrote: >>>> On Thu, 17 Sep 2015, Martin Kosek wrote: >>>>> On 09/17/2015 01:47 PM, Tomas Babej wrote: >>>>>> Hi fellow developers, >>>>>> >>>>>> more or less we tend to stick to the tradition of linking Trac >>>>>> tickets >>>>>> to the commit messages of the patches we send to the list. >>>>>> >>>>>> However, every now and then, a patch lands on the list, which is >>>>>> either >>>>>> linked to a BZ or does not contain any link at all. Admittedly, I am >>>>>> also guilty of this mishap. This poses certain problems, as we're >>>>>> trying >>>>>> to automate the bookkeeping and pushing-related processes with >>>>>> ipatool [1]. >>>>>> >>>>>> Nevertheless, this useful habit is not formally agreed upon by >>>>>> developers nor documented in our wiki [2]. I'd suggest we add it >>>>>> there, >>>>>> if we come to such consensus. >>>>>> >>>>>> This would mean: >>>>>> * Patches fixing an issue described only in BZ (rare issue) would >>>>>> need >>>>>> to create a Trac ticket referencing the BZ >>>>> >>>>> +1 >>>>> >>>>>> * Patches fixing an issue not tracked in Trac nor BZ would need to >>>>>> file >>>>>> a ticket in Trac and reference it >>>>> >>>>> I am not sure we are there yet. For typos and small fixes, I do not >>>>> think we >>>>> need to create a hard requirement for a Trac ticket. But for patches >>>>> that you >>>>> want to be considered for say backports to downstream releases, it >>>>> is better to >>>>> have the ticket with the right metadata and collection of the right >>>>> hashes that >>>>> the downstream release can digest. >>>> Yes, please do a ticket per a changeset. >>> >>> Are you agreeing now to me, i.e. do not require tickets for trivial >>> fixes or to >>> Tomas' proposal - require ticket for *all* patches? >> I think we should have tickets for reasonable pieces of work. The >> problem is always in identifying what does 'reasonable' mean. A >> single-line fix may be an important CVE fix or a key to an important >> bugfix. Still, there should be a context to fit, thus a ticket. > > Speaking as IPA package maitainer in RHEL, I would like to have ticket > link in every commit in maintenance branches. If a commit goes to the > master branch only, I'm OK with it not having a ticket link. So that's > where I would draw the line - if a commit goes into a maintenance > branch, it is a reasonable piece of work. > Hi, in general, which ticket should be referenced from a commit that implements tests? It can happen that the tests cover a set of tickets. What should we do then? Cheers, Milan From jcholast at redhat.com Thu Sep 17 13:06:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Sep 2015 15:06:10 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAB9D5.9070408@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> <55FAB9D5.9070408@redhat.com> Message-ID: <55FABAC2.9040900@redhat.com> On 17.9.2015 15:02, Milan Kub?k wrote: > On 09/17/2015 02:51 PM, Jan Cholasta wrote: >> On 17.9.2015 14:08, Alexander Bokovoy wrote: >>> On Thu, 17 Sep 2015, Martin Kosek wrote: >>>> On 09/17/2015 02:00 PM, Alexander Bokovoy wrote: >>>>> On Thu, 17 Sep 2015, Martin Kosek wrote: >>>>>> On 09/17/2015 01:47 PM, Tomas Babej wrote: >>>>>>> Hi fellow developers, >>>>>>> >>>>>>> more or less we tend to stick to the tradition of linking Trac >>>>>>> tickets >>>>>>> to the commit messages of the patches we send to the list. >>>>>>> >>>>>>> However, every now and then, a patch lands on the list, which is >>>>>>> either >>>>>>> linked to a BZ or does not contain any link at all. Admittedly, I am >>>>>>> also guilty of this mishap. This poses certain problems, as we're >>>>>>> trying >>>>>>> to automate the bookkeeping and pushing-related processes with >>>>>>> ipatool [1]. >>>>>>> >>>>>>> Nevertheless, this useful habit is not formally agreed upon by >>>>>>> developers nor documented in our wiki [2]. I'd suggest we add it >>>>>>> there, >>>>>>> if we come to such consensus. >>>>>>> >>>>>>> This would mean: >>>>>>> * Patches fixing an issue described only in BZ (rare issue) would >>>>>>> need >>>>>>> to create a Trac ticket referencing the BZ >>>>>> >>>>>> +1 >>>>>> >>>>>>> * Patches fixing an issue not tracked in Trac nor BZ would need to >>>>>>> file >>>>>>> a ticket in Trac and reference it >>>>>> >>>>>> I am not sure we are there yet. For typos and small fixes, I do not >>>>>> think we >>>>>> need to create a hard requirement for a Trac ticket. But for patches >>>>>> that you >>>>>> want to be considered for say backports to downstream releases, it >>>>>> is better to >>>>>> have the ticket with the right metadata and collection of the right >>>>>> hashes that >>>>>> the downstream release can digest. >>>>> Yes, please do a ticket per a changeset. >>>> >>>> Are you agreeing now to me, i.e. do not require tickets for trivial >>>> fixes or to >>>> Tomas' proposal - require ticket for *all* patches? >>> I think we should have tickets for reasonable pieces of work. The >>> problem is always in identifying what does 'reasonable' mean. A >>> single-line fix may be an important CVE fix or a key to an important >>> bugfix. Still, there should be a context to fit, thus a ticket. >> >> Speaking as IPA package maitainer in RHEL, I would like to have ticket >> link in every commit in maintenance branches. If a commit goes to the >> master branch only, I'm OK with it not having a ticket link. So that's >> where I would draw the line - if a commit goes into a maintenance >> branch, it is a reasonable piece of work. >> > Hi, > > in general, which ticket should be referenced from a commit that > implements tests? It can happen that the tests cover a set of tickets. > What should we do then? I would think file a new ticket with component set to "Tests" and reference it in the commit. > > Cheers, > Milan > -- Jan Cholasta From mkubik at redhat.com Thu Sep 17 13:30:45 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 17 Sep 2015 15:30:45 +0200 Subject: [Freeipa-devel] Early feedback on Tracker based tests Message-ID: <55FAC085.9080805@redhat.com> Hi list, I would like to ask you for any feedback you can provide me on $SUBJ. Currently the tests for host, certprofiles and stage user plugins are implemented with the use of the tracker that Petr Viktorin originally designed as a replacement for the declarative xmlrpc tests. With these tests already implemented, I'd like to know your feedback as for: * readability ot the tests * form of the Tracker class * the feedback on using the tracker instances via pytest's fixtures * anything else We in upstream qe are on the verge of rewriting the declarative tests into this form (en masse). Any feedback in the early stages of this process will help us deliver better tests. Cheers, Milan From mkubik at redhat.com Thu Sep 17 13:47:22 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 17 Sep 2015 15:47:22 +0200 Subject: [Freeipa-devel] Early feedback on Tracker based tests In-Reply-To: <55FAC085.9080805@redhat.com> References: <55FAC085.9080805@redhat.com> Message-ID: <55FAC46A.2060206@redhat.com> On 09/17/2015 03:30 PM, Milan Kub?k wrote: > Hi list, > > I would like to ask you for any feedback you can provide me on $SUBJ. > > Currently the tests for host, certprofiles and stage user plugins are > implemented > with the use of the tracker that Petr Viktorin originally designed as > a replacement > for the declarative xmlrpc tests. > > With these tests already implemented, I'd like to know your feedback > as for: > > * readability ot the tests > * form of the Tracker class > * the feedback on using the tracker instances via pytest's fixtures > * anything else > > We in upstream qe are on the verge of rewriting the declarative tests > into this form (en masse). > Any feedback in the early stages of this process will help us deliver > better tests. > > Cheers, > Milan > Some examples of the tests mentioned :) Host plugin test: https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_xmlrpc/test_host_plugin.py Stage user test: https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_xmlrpc/test_stageuser_plugin.py Declarative test: https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_xmlrpc/test_config_plugin.py Cheers, Milan From jhrozek at redhat.com Thu Sep 17 14:47:16 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 17 Sep 2015 16:47:16 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <20150917125535.GY6168@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> <20150917125535.GY6168@redhat.com> Message-ID: <20150917144716.GY14560@hendrix.arn.redhat.com> On Thu, Sep 17, 2015 at 03:55:35PM +0300, Alexander Bokovoy wrote: > >Speaking as IPA package maitainer in RHEL, I would like to have ticket > >link in every commit in maintenance branches. If a commit goes to the > >master branch only, I'm OK with it not having a ticket link. So that's > >where I would draw the line - if a commit goes into a maintenance branch, > >it is a reasonable piece of work. > Good suggestion, thanks. We actually have the same with Samba -- *any* > backport to released branches requires a new bug to be opened and > mentioned in the commit message. Seems reasonable for SSSD as well.. Two questions: 1) If you backport from a non-maintenance branch to a maintenance branch, do you also move the ticket? IOW, do you also expect the list of changes to be visible in track, or do you only care about 'auditing' of each commit? 2) If another commit (which can be totally unrelated in functionality, just touching the same area of code) needs to be applied before the one you backport, do you add the ticket URL to the prerequisite as well or create a new one? From pvoborni at redhat.com Thu Sep 17 14:53:10 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 17 Sep 2015 16:53:10 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.2.1 Message-ID: <55FAD3D6.7020509@redhat.com> The FreeIPA team would like to announce FreeIPA v4.2.1 bug fixing release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora 23 and rawhide. Builds for Fedora 22 are available in the official COPR repository . This announcement is also available at . == Highlights in 4.2.1 == === Enhancements === * Added support for multiple IP addresses during client installation === Bug fixes === * Various fixes for new Vault feature * Various fixes for new Certificates Profiles feature * Fixed ACI issue in search for hbac rules, sudo rules, users and other IPA objects by non-admin users * Backup and restore fixes, mostly related to DNSSEC * ipa-client-install is able to request a certificate in kickstart environment * Fixed server upgrade failure in "Enabling KDC proxy" step * Added option to establish bidirectional trust in Web UI == Upgrading == Upgrade instructions are available on Upgrade page . == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.2.0 == === Alexander Bokovoy (5) === * selinux: enable httpd_run_ipa to allow communicating with oddjobd services * oddjob: avoid chown keytab to sssd if sssd user does not exist * Fix selector of protocol for LSA RPC binding string * trusts: harden trust-fetch-domains oddjobd-based script * trusts: format Kerberos principal properly when fetching trust topology === Christian Heimes (10) === * Start dirsrv for kdcproxy upgrade * Fix selinux denial during kdcproxy user creation * certprofile-import: improve profile format documentation * otptoken: use ipapython.nsslib instead of Python's ssl module * Require Dogtag PKI >= 10.2.6 * Validate vault's file parameters * certprofile-import: do not require profileId in profile data * Asymmetric vault: validate public key in client * Add flag to list all service and user vaults * Change internal rsa_(public|private)_key variable names === David Kupka (9) === * migration: Use api.env variables. * cermonger: Use private unix socket when DBus SystemBus is not available. * ipa-client-install: Do not (re)start certmonger and DBus daemons. * user-undel: Fix error messages. * client: Add support for multiple IP addresses during installation. * client: Add description of --ip-address and --all-ip-addresses to man page * Backup/resore authentication control configuration * vault: Limit size of data stored in vault * ipactl: Do not start/stop/restart single service multiple times === Endi Sukma Dewata (6) === * Fixed missing KRA agent cert on replica. * Added CLI param and ACL for vault service operations. * Fixed vault container ownership. * Added support for changing vault encryption. * Removed clear text passwords from KRA install log. * Using LDAPI to setup CA and KRA agents. === Fraser Tweedale (14) === * user-show: add --out option to save certificates to file * Fix otptoken-remove-managedby command summary * Give more info on virtual command access denial * Allow SAN extension for cert-request self-service * Add profile for DNP3 / IEC 62351-8 certificates * Work around python-nss bug on unrecognised OIDs * Fix default CA ACL added during upgrade * Fix KRB5PrincipalName / UPN SAN comparison * certprofile: add profile format explanation * Add permission for bypassing CA ACL enforcement * Prohibit deletion of predefined profiles * cert-request: remove allowed extensions check * certprofile: prevent rename (modrdn) * certprofile: remove 'rename' option === Jan Cholasta (14) === * spec file: Move /etc/ipa/kdcproxy to the server subpackage * spec file: Update minimum required version of krb5 * install: Fix server and replica install options * ULC: Prevent preserved users from being assigned membership * spec file: Fix install with the server-dns subpackage * baseldap: Allow overriding member param label in LDAPModMember * vault: Fix param labels in output of vault owner commands * install: Fix replica install with custom certificates * vault: Fix vault-find with criteria * vault: Add container information to vault command results * spec file: Add Requires(post) on selinux-policy * cert renewal: Include KRA users in Dogtag LDAP update * cert renewal: Automatically update KRA agent PEM file * ldap: Make ldap2 connection management thread-safe again === Lenka Doudova (2) === * Automated test for stageuser plugin * Fix user tracker to reflect new user-del message === Martin Babinsky (12) === * ipa-ca-install: print more specific errors when CA is already installed * enable debugging of ntpd during client installation * fix broken search for users by their manager * ACI plugin: correctly parse bind rules enclosed in parentheses * test suite for user/host/service certificate management API commands * store certificates issued for user entries as userCertificate;binary * idranges: raise an error when local IPA ID range is being modified * fix typo in BasePathNamespace member pointing to ods exporter config * ipa-backup: archive DNSSEC zone file and kasp.db * ipa-restore: check whether DS is running before attempting connection * improve the handling of krb5-related errors in dnssec daemons * improve the usability of `ipa user-del --preserve` command === Martin Ba?ti (23) === * Prevent to rename certprofile profile id * Stageusedr-activate: show username instead of DN * copy-schema-to-ca: allow to overwrite schema files * fix selinuxusermap search for non-admin users * Validate adding privilege to a permission * sysrestore: copy files instead of moving them to avoind SELinux issues * Allow value 'no' for replica-certify-all attr in abort-clean-ruv subcommand * Py3: replace tab with space * DNS: Consolidate DNS RR types in API and schema * DNS: check if DNS package is installed * Remove ico files from Makefile * Use 'mv -Z' in specfile to restore SELinux context * ULC: Fix stageused-add --from-delete command * Fix upgrade of sidgen and extdom plugins * Add dependency to SSSD 1.13.1 * Server Upgrade: Start DS before CA is started. * Add user-stage command * DNSSEC: fix forward zone forwarders checks * DNSSEC: remove "DNSSEC is experimental" warnings * Backup: back up the hosts file * Installer: do not modify /etc/hosts before user agreement * DNSSEC: backup and restore opendnssec zone list file * DNSSEC: remove ccache and keytab of ipa-ods-exporter === Milan Kub?k (4) === * ipalib: pass api instance into textui in doctest snippets * spec file: update the python package names for libipa_hbac and libsss_nss_idmap * tests: Allow Tracker.dn be an instance of Fuzzy * ipatests: Take otptoken import test out of execution === Oleg Fayans (2) === * Added a user-friendly output to an import error * Temporary fix for ticket 5240 === Petr Voborn?k (17) === * Become IPA 4.2.0 * do not import memcache on client * webui: fix user reset password dialog * fix hbac rule search for non-admin users * webui: add Kerberos configuration instructions for Chrome * webui: fix regressions failed auth messages * webui: add LDAP vs Kerberos behavior description to user auth types * adjust search so that it works for non-admin users * validate mutually exclusive options in vault-add * add permission: System: Manage User Certificates * vault: normalize service principal in service vault operations * vault: validate vault type * vault: change default vault type to symmetric * fix missing information in object metadata * webui: add option to establish bidirectional trust * vault: fix vault tests after default type change * Become IPA 4.2.1 === Petr ?pa?ek (6) === * Create server-dns sub-package. * DNSSEC: prevent ipa-ods-exporter from looping after service auto-restart * DNSSEC: Fix deadlock in ipa-ods-exporter <-> ods-enforcerd interaction * DNSSEC: Fix HSM synchronization in ipa-dnskeysyncd when running on DNSSEC key master * DNSSEC: Fix key metadata export * DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5. === Rob Crittenden (1) === * Use %license instead of %doc for packaging the license === Simo Sorce (1) === * Fix DNS records installation for replicas === Stanislav Laznicka (1) === * ipa-client-install: warn when IP used in --server === Tom?? Babej (24) === * ipalib: Fix missing format for InvalidDomainLevelError * trusts: Check for AD root domain among our trusted domains * ipaplatform: Add constants submodule * tests: user_plugin: Add preserved flag when --all is used * dcerpc: Expand explanation for WERR_ACCESS_DENIED * idviews: Check for the Default Trust View only if applying the view * tests: service_plugin: Make sure the cert is decoded from base64 * tests: realmdomains_plugin: Add explanatory comment * tests: Version is currently generated during command call * tests: vault_plugin: Skip tests if KRA not available * tests: test_rpc: Create connection for the current thread * tests: test_cert: Services can have multiple certificates * dcerpc: Fix UnboundLocalError for ccache_name * dcerpc: Add get_trusted_domain_object_type method * idviews: Restrict anchor to name and name to anchor conversions * idviews: Enforce objectclass check in idoverride*-del * replication: Fix incorrect exception invocation * Fix incorrect type comparison in trust-fetch-domains * dcerpc: Simplify generation of LSA-RPC binding strings * adtrust-install: Correctly determine 4.2 FreeIPA servers * trusts: Detect domain clash with IPA domain when adding a AD trust * trusts: Detect missing Samba instance * winsync-migrate: Add warning about passsync * winsync-migrate: Expand the man page === Yuri Chornoivan (1) === * Fix minor typos -- Petr Vobornik From pvoborni at redhat.com Thu Sep 17 15:04:58 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 17 Sep 2015 17:04:58 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <20150917144716.GY14560@hendrix.arn.redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> <20150917125535.GY6168@redhat.com> <20150917144716.GY14560@hendrix.arn.redhat.com> Message-ID: <55FAD69A.4000104@redhat.com> On 09/17/2015 04:47 PM, Jakub Hrozek wrote: > On Thu, Sep 17, 2015 at 03:55:35PM +0300, Alexander Bokovoy wrote: >>> Speaking as IPA package maitainer in RHEL, I would like to have ticket >>> link in every commit in maintenance branches. If a commit goes to the >>> master branch only, I'm OK with it not having a ticket link. So that's >>> where I would draw the line - if a commit goes into a maintenance branch, >>> it is a reasonable piece of work. >> Good suggestion, thanks. We actually have the same with Samba -- *any* >> backport to released branches requires a new bug to be opened and >> mentioned in the commit message. > > Seems reasonable for SSSD as well.. > > Two questions: > 1) If you backport from a non-maintenance branch to a maintenance > branch, do you also move the ticket? IOW, do you also expect the > list of changes to be visible in track, or do you only care about > 'auditing' of each commit? > This cases happens rarely in FreeIPA upstream. Usually the patch is directly developed for a maintenance branch and all branches after that. E.g. a patch for 4.1.5 would go to ipa-4-1, ipa-4-2 and master branch. It would be in FreeIPA 4.1.5 milestone. Commits for each branch are recorded in the ticket. > 2) If another commit (which can be totally unrelated in > functionality, just touching the same area of code) needs to be > applied before the one you backport, do you add the ticket URL > to the prerequisite as well or create a new one? > If a backport happens much later, IMHO the proper way would be to create a separate ticket for the backport and reference the original ticket(s) and record all commits, even the prerequisites. -- Petr Vobornik From tbabej at redhat.com Thu Sep 17 15:13:06 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Sep 2015 17:13:06 +0200 Subject: [Freeipa-devel] [PATCH 0368] ipa-backup: Add mechanism to store empty directory structure Message-ID: <55FAD882.4070701@redhat.com> Hi, Certain subcomponents of IPA, such as Dogtag, cannot function if non-critical directories (such as log directories) have not been stored in the backup. This patch implements storage of selected empty directories, while preserving attributes and SELinux context. https://fedorahosted.org/freeipa/ticket/5297 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0368-ipa-backup-Add-mechanism-to-store-empty-directory-st.patch Type: text/x-patch Size: 4339 bytes Desc: not available URL: From abokovoy at redhat.com Thu Sep 17 15:17:07 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Sep 2015 18:17:07 +0300 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <20150917144716.GY14560@hendrix.arn.redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> <20150917125535.GY6168@redhat.com> <20150917144716.GY14560@hendrix.arn.redhat.com> Message-ID: <20150917151707.GZ6168@redhat.com> On Thu, 17 Sep 2015, Jakub Hrozek wrote: >On Thu, Sep 17, 2015 at 03:55:35PM +0300, Alexander Bokovoy wrote: >> >Speaking as IPA package maitainer in RHEL, I would like to have ticket >> >link in every commit in maintenance branches. If a commit goes to the >> >master branch only, I'm OK with it not having a ticket link. So that's >> >where I would draw the line - if a commit goes into a maintenance branch, >> >it is a reasonable piece of work. >> Good suggestion, thanks. We actually have the same with Samba -- *any* >> backport to released branches requires a new bug to be opened and >> mentioned in the commit message. > >Seems reasonable for SSSD as well.. > >Two questions: > 1) If you backport from a non-maintenance branch to a maintenance > branch, do you also move the ticket? IOW, do you also expect the > list of changes to be visible in track, or do you only care about > 'auditing' of each commit? Samba clones the bug. FreeIPA does add a comment with the hashes referencing the commits. > 2) If another commit (which can be totally unrelated in > functionality, just touching the same area of code) needs to be > applied before the one you backport, do you add the ticket URL > to the prerequisite as well or create a new one? If you have something else applying to a maintenance branch, just do a bug for it. If it is a patch for making the backport more manageable for applying, just have it part of the backport. -- / Alexander Bokovoy From rcritten at redhat.com Thu Sep 17 15:29:31 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Sep 2015 11:29:31 -0400 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <20150917151707.GZ6168@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> <20150917125535.GY6168@redhat.com> <20150917144716.GY14560@hendrix.arn.redhat.com> <20150917151707.GZ6168@redhat.com> Message-ID: <55FADC5B.9060803@redhat.com> Alexander Bokovoy wrote: > On Thu, 17 Sep 2015, Jakub Hrozek wrote: >> On Thu, Sep 17, 2015 at 03:55:35PM +0300, Alexander Bokovoy wrote: >>> >Speaking as IPA package maitainer in RHEL, I would like to have ticket >>> >link in every commit in maintenance branches. If a commit goes to the >>> >master branch only, I'm OK with it not having a ticket link. So that's >>> >where I would draw the line - if a commit goes into a maintenance >>> branch, >>> >it is a reasonable piece of work. >>> Good suggestion, thanks. We actually have the same with Samba -- *any* >>> backport to released branches requires a new bug to be opened and >>> mentioned in the commit message. >> >> Seems reasonable for SSSD as well.. >> >> Two questions: >> 1) If you backport from a non-maintenance branch to a maintenance >> branch, do you also move the ticket? IOW, do you also expect the >> list of changes to be visible in track, or do you only care about >> 'auditing' of each commit? > Samba clones the bug. FreeIPA does add a comment with the hashes > referencing the commits. > > >> 2) If another commit (which can be totally unrelated in >> functionality, just touching the same area of code) needs to be >> applied before the one you backport, do you add the ticket URL >> to the prerequisite as well or create a new one? > If you have something else applying to a maintenance branch, just do a > bug for it. If it is a patch for making the backport more manageable for > applying, just have it part of the backport. > I can't quite figure out what problem you're trying to solve here. Why not just reference the original ticket in the backported commit? What value, except perhaps in ticket reports, does this bring? rob From pviktori at redhat.com Thu Sep 17 15:35:57 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Sep 2015 17:35:57 +0200 Subject: [Freeipa-devel] [PATCH] Replace StandardError with Exception Message-ID: <55FADDDD.8020801@redhat.com> Hello, In Python 2, Exception has only two built-in subclasses: StandardError, and StopIteration. This makes StandardError pretty useless, and Python 3 removes it. This patch replaces StandardError with Exception. It has no effect on IPA code. However, it could theoretically affect external plugins (e.g. if they do "except StandardError"). -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0712-Replace-StandardError-with-Exception.patch Type: text/x-patch Size: 23080 bytes Desc: not available URL: From abokovoy at redhat.com Thu Sep 17 15:42:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Sep 2015 18:42:27 +0300 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FADC5B.9060803@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> <20150917125535.GY6168@redhat.com> <20150917144716.GY14560@hendrix.arn.redhat.com> <20150917151707.GZ6168@redhat.com> <55FADC5B.9060803@redhat.com> Message-ID: <20150917154227.GA6168@redhat.com> On Thu, 17 Sep 2015, Rob Crittenden wrote: >Alexander Bokovoy wrote: >> On Thu, 17 Sep 2015, Jakub Hrozek wrote: >>> On Thu, Sep 17, 2015 at 03:55:35PM +0300, Alexander Bokovoy wrote: >>>> >Speaking as IPA package maitainer in RHEL, I would like to have ticket >>>> >link in every commit in maintenance branches. If a commit goes to the >>>> >master branch only, I'm OK with it not having a ticket link. So that's >>>> >where I would draw the line - if a commit goes into a maintenance >>>> branch, >>>> >it is a reasonable piece of work. >>>> Good suggestion, thanks. We actually have the same with Samba -- *any* >>>> backport to released branches requires a new bug to be opened and >>>> mentioned in the commit message. >>> >>> Seems reasonable for SSSD as well.. >>> >>> Two questions: >>> 1) If you backport from a non-maintenance branch to a maintenance >>> branch, do you also move the ticket? IOW, do you also expect the >>> list of changes to be visible in track, or do you only care about >>> 'auditing' of each commit? >> Samba clones the bug. FreeIPA does add a comment with the hashes >> referencing the commits. >> >> >>> 2) If another commit (which can be totally unrelated in >>> functionality, just touching the same area of code) needs to be >>> applied before the one you backport, do you add the ticket URL >>> to the prerequisite as well or create a new one? >> If you have something else applying to a maintenance branch, just do a >> bug for it. If it is a patch for making the backport more manageable for >> applying, just have it part of the backport. >> > >I can't quite figure out what problem you're trying to solve here. Why >not just reference the original ticket in the backported commit? What >value, except perhaps in ticket reports, does this bring? It may, perhaps, be irrelevant to current FreeIPA state of integration with different distributions and products, but in Samba case a version often lives beyond what is supported by upstream, so a good trail of how backports landed in a released branch is often reused by various ISVs to track their own long term product branches. Samba code did undergo large changes in last ten years to the point that sometimes these backports are completely separate patchsets on their own, with own life and original bugs fixes/design decisions might not apply anymore exactly. Having a bug to record decisions made some time ago specifically to the branch helps in future when another person comes with a bug due to the backport -- not so rare, unfortunately, as sometimes an obscure side effect might change what others are caring about. I guess it also a sign of a Trac's and bugzilla's failure to allow attaching a single bug/ticket to multiple releases in a clear way so that people have to clone bugs to different streams to represent the same story in different contexts. -- / Alexander Bokovoy From simo at redhat.com Thu Sep 17 15:49:29 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 17 Sep 2015 11:49:29 -0400 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAAD10.40104@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <55FAAD10.40104@redhat.com> Message-ID: <1442504969.4697.89.camel@willson.usersys.redhat.com> On Thu, 2015-09-17 at 14:07 +0200, Tomas Babej wrote: > > On 09/17/2015 01:53 PM, Martin Kosek wrote: > > On 09/17/2015 01:47 PM, Tomas Babej wrote: > >> Hi fellow developers, > >> > >> more or less we tend to stick to the tradition of linking Trac tickets > >> to the commit messages of the patches we send to the list. > >> > >> However, every now and then, a patch lands on the list, which is either > >> linked to a BZ or does not contain any link at all. Admittedly, I am > >> also guilty of this mishap. This poses certain problems, as we're trying > >> to automate the bookkeeping and pushing-related processes with ipatool [1]. > >> > >> Nevertheless, this useful habit is not formally agreed upon by > >> developers nor documented in our wiki [2]. I'd suggest we add it there, > >> if we come to such consensus. > >> > >> This would mean: > >> * Patches fixing an issue described only in BZ (rare issue) would need > >> to create a Trac ticket referencing the BZ > > > > +1 > > > >> * Patches fixing an issue not tracked in Trac nor BZ would need to file > >> a ticket in Trac and reference it > > > > I am not sure we are there yet. For typos and small fixes, I do not think we > > need to create a hard requirement for a Trac ticket. But for patches that you > > want to be considered for say backports to downstream releases, it is better to > > have the ticket with the right metadata and collection of the right hashes that > > the downstream release can digest. > > I agree it might be a good idea to be less harsh on the trivial patches, > however, how do we draw the line? This puts the decision burden on the > contributor who might not have the necessary insight and/or information. > > I'd suggest we go this route, I don't want to put more obstacles for new > contributors and small patches. However, then the regular FreeIPA > committers need to notify the new contributors if their patch crosses > the triviality barrier and warrants a ticket :) Given you push through a tool, maybe you can teach the tool to open a new ticket if one is not referenced ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Sep 17 15:50:06 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 17 Sep 2015 17:50:06 +0200 Subject: [Freeipa-devel] [PATCH] 921 webui: use manual Firefox configuration for Firefox >= 40 Message-ID: <55FAE12E.8090302@redhat.com> The intended course of action is to show manual configuration in browserconfig.html instead of configuration with the extension for versions of Firefox >= 40. The reasoning is: * plan for enterprise environments was not published yet which forces as to use AMO (addons.mozilla.org) * with AMO the user experience is worse than a manual configuration steps for AMO: * go to AMO page * installed the extension * go back to IPA page * probably refresh * click configure * confirm manual config: * go to about:config * set network.negotiate-auth.trusted-uris with *domain.name https://fedorahosted.org/freeipa/ticket/4906 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0921-webui-use-manual-Firefox-configuration-for-Firefox-4.patch Type: text/x-patch Size: 5363 bytes Desc: not available URL: From pvoborni at redhat.com Thu Sep 17 16:00:25 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 17 Sep 2015 18:00:25 +0200 Subject: [Freeipa-devel] [PATCH] 920 webui: improve performance of search in association dialog In-Reply-To: <55E471B8.2020904@redhat.com> References: <55E471B8.2020904@redhat.com> Message-ID: <55FAE399.60506@redhat.com> On 08/31/2015 05:24 PM, Petr Vobornik wrote: > By adding no_members option to commands which supports it. > > It then skips memberof procession on the server side. > > https://fedorahosted.org/freeipa/ticket/5271 > > New version attached with change: - var options = { all: true }; + var options = {}; the 'all' option is not needed and actually negates the patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0920-1-webui-improve-performance-of-search-in-association-d.patch Type: text/x-patch Size: 2192 bytes Desc: not available URL: From jpazdziora at redhat.com Fri Sep 18 07:27:02 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 18 Sep 2015 09:27:02 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <55FAAE60.2000208@redhat.com> <55FAA851.5030300@redhat.com> Message-ID: <20150918072702.GA2227@redhat.com> On Thu, Sep 17, 2015 at 01:47:29PM +0200, Tomas Babej wrote: > also guilty of this mishap. This poses certain problems, as we're trying > to automate the bookkeeping and pushing-related processes with ipatool [1]. [...] > This would mean: > * Patches fixing an issue described only in BZ (rare issue) would need > to create a Trac ticket referencing the BZ > * Patches fixing an issue not tracked in Trac nor BZ would need to file > a ticket in Trac and reference it On Thu, Sep 17, 2015 at 02:13:20PM +0200, Tomas Babej wrote: > > which does not provide instructions in the case when the corresponding > ticket does not exist. If the fix is for issue not in trac, presumably some trivial change like a typo in some message, how does a commit without ticket link break ipatool? I understand that having reference to an issue in bugzilla in the commit is useful because it's then possible to find commits related to that issue, which is already tracked somewhere. Still, even for bugzilla, you could possibly just use the bugzilla URL. But if the issue is so small that noone really thought about filing it before, what's the purpose of creating one? We don't seem to suffer from the lack of tickets. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Fri Sep 18 07:34:06 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Sep 2015 09:34:06 +0200 Subject: [Freeipa-devel] Early feedback on Tracker based tests In-Reply-To: <55FAC085.9080805@redhat.com> References: <55FAC085.9080805@redhat.com> Message-ID: <55FBBE6E.3000906@redhat.com> On 09/17/2015 03:30 PM, Milan Kub?k wrote: > Hi list, > > I would like to ask you for any feedback you can provide me on $SUBJ. > > Currently the tests for host, certprofiles and stage user plugins are implemented > with the use of the tracker that Petr Viktorin originally designed as a > replacement > for the declarative xmlrpc tests. > > With these tests already implemented, I'd like to know your feedback as for: > > * readability ot the tests > * form of the Tracker class > * the feedback on using the tracker instances via pytest's fixtures > * anything else > > We in upstream qe are on the verge of rewriting the declarative tests into this > form (en masse). >From my POV, these tests looks better, should allow better granularity of running them and should be more independent. However, the conversion should be done continuously, as need as we have bigger fish to fry: - Existence of easy Acceptance Test for FreeIPA that other projects can run - Well-oiled CI automation on master and ipa-4-2 - FreeIPA 4.3 coverage and future-to-base base performance test for FreeIPA 4.4.+ > Any feedback in the early stages of this process will help us deliver better > tests. > > Cheers, > Milan > From pspacek at redhat.com Fri Sep 18 08:45:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 18 Sep 2015 10:45:59 +0200 Subject: [Freeipa-devel] Linking tickets in the commit messages In-Reply-To: <20150917154227.GA6168@redhat.com> References: <55FAA851.5030300@redhat.com> <55FAA9BC.6050702@redhat.com> <20150917120001.GV6168@redhat.com> <55FAAB8E.1030009@redhat.com> <20150917120857.GW6168@redhat.com> <55FAB747.3010805@redhat.com> <20150917125535.GY6168@redhat.com> <20150917144716.GY14560@hendrix.arn.redhat.com> <20150917151707.GZ6168@redhat.com> <55FADC5B.9060803@redhat.com> <20150917154227.GA6168@redhat.com> Message-ID: <55FBCF47.7090507@redhat.com> On 17.9.2015 17:42, Alexander Bokovoy wrote: > On Thu, 17 Sep 2015, Rob Crittenden wrote: >> Alexander Bokovoy wrote: >>> On Thu, 17 Sep 2015, Jakub Hrozek wrote: >>>> On Thu, Sep 17, 2015 at 03:55:35PM +0300, Alexander Bokovoy wrote: >>>>> >Speaking as IPA package maitainer in RHEL, I would like to have ticket >>>>> >link in every commit in maintenance branches. If a commit goes to the >>>>> >master branch only, I'm OK with it not having a ticket link. So that's >>>>> >where I would draw the line - if a commit goes into a maintenance >>>>> branch, >>>>> >it is a reasonable piece of work. >>>>> Good suggestion, thanks. We actually have the same with Samba -- *any* >>>>> backport to released branches requires a new bug to be opened and >>>>> mentioned in the commit message. >>>> >>>> Seems reasonable for SSSD as well.. >>>> >>>> Two questions: >>>> 1) If you backport from a non-maintenance branch to a maintenance >>>> branch, do you also move the ticket? IOW, do you also expect the >>>> list of changes to be visible in track, or do you only care about >>>> 'auditing' of each commit? >>> Samba clones the bug. FreeIPA does add a comment with the hashes >>> referencing the commits. >>> >>> >>>> 2) If another commit (which can be totally unrelated in >>>> functionality, just touching the same area of code) needs to be >>>> applied before the one you backport, do you add the ticket URL >>>> to the prerequisite as well or create a new one? >>> If you have something else applying to a maintenance branch, just do a >>> bug for it. If it is a patch for making the backport more manageable for >>> applying, just have it part of the backport. >>> >> >> I can't quite figure out what problem you're trying to solve here. Why >> not just reference the original ticket in the backported commit? What >> value, except perhaps in ticket reports, does this bring? > It may, perhaps, be irrelevant to current FreeIPA state of integration > with different distributions and products, but in Samba case a version > often lives beyond what is supported by upstream, so a good trail of how > backports landed in a released branch is often reused by various ISVs to > track their own long term product branches. Samba code did undergo large > changes in last ten years to the point that sometimes these backports > are completely separate patchsets on their own, with own life and > original bugs fixes/design decisions might not apply anymore exactly. > Having a bug to record decisions made some time ago specifically to the > branch helps in future when another person comes with a bug due to the > backport -- not so rare, unfortunately, as sometimes an obscure side > effect might change what others are caring about. > > I guess it also a sign of a Trac's and bugzilla's failure to allow > attaching a single bug/ticket to multiple releases in a clear way so > that people have to clone bugs to different streams to represent the > same story in different contexts. Well, I would say that it is our failure to use Trac :-) Nothing prevents us from using a separate field for tracking branches in which the patch landed, or something even more precise. E.g. bind-dyndb-ldap Trac has field 'fixedby' which contains hashes of commits fixing given ticket. Nothing prevents me from putting multiple hashes from multiple branches to that field, and I do that. Then, git describe --contains nicely shows which released version (tag) contains which commit etc. The main question is if it worth the effort because bookkeeping may easily consume more resources than the benefit, especially for small fixes. Should we create tickets for typo fix or other non-essential change just because it is applicable to all branches? I do not think so. I very much agree with Jan Pazdiora's note from other part of the thread: > But if the issue is so small that noone really thought about filing > it before, what's the purpose of creating one? We don't seem to > suffer from the lack of tickets. -- Petr^2 Spacek From pviktori at redhat.com Fri Sep 18 15:00:23 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Sep 2015 17:00:23 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting Message-ID: <55FC2707.5060709@redhat.com> Hello, Here are more patches that bring IPA closer to Python 3 compatibility. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0713-ipap11helper-Port-to-Python-3.patch Type: text/x-patch Size: 16522 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0714-rpc-Don-t-use-undocumented-urllib-functions.patch Type: text/x-patch Size: 1284 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0715-ipapython.dn-Use-rich-comparisons.patch Type: text/x-patch Size: 10236 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0716-test_dn-Split-bytes-and-unicode.patch Type: text/x-patch Size: 8225 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0717-Use-sys.maxsize-instead-of-sys.maxint.patch Type: text/x-patch Size: 3675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0718-Use-six.moves.urllib-instead-of-urllib-urllib2-urlpa.patch Type: text/x-patch Size: 25845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0719-Use-six.moves.xmlrpc.client-instead-of-xmlrpclib.patch Type: text/x-patch Size: 12771 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0720-Use-six.moves.configparser-instead-of-ConfigParser.patch Type: text/x-patch Size: 11450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0721-Use-six.moves.http_client-instead-of-httplib.patch Type: text/x-patch Size: 6531 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0722-Use-six.Stringio-instead-of-StringIO.StringIO.patch Type: text/x-patch Size: 3978 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0723-Remove-uses-of-the-types-module.patch Type: text/x-patch Size: 12482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0724-ipapython.ssh-Port-to-Python-3.patch Type: text/x-patch Size: 5547 bytes Desc: not available URL: From tbabej at redhat.com Mon Sep 21 07:47:55 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 21 Sep 2015 09:47:55 +0200 Subject: [Freeipa-devel] [PATCH 0368] ipa-backup: Add mechanism to store empty directory structure In-Reply-To: <55FAD882.4070701@redhat.com> References: <55FAD882.4070701@redhat.com> Message-ID: <55FFB62B.70000@redhat.com> On 09/17/2015 05:13 PM, Tomas Babej wrote: > Hi, > > Certain subcomponents of IPA, such as Dogtag, cannot function if > non-critical directories (such as log directories) have not been > stored in the backup. > > This patch implements storage of selected empty directories, > while preserving attributes and SELinux context. > > https://fedorahosted.org/freeipa/ticket/5297 > Attaching a patch for gzip requires. This is more a formal thing than anything else, gzip is required by systemd anyway. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0369-spec-Add-gzip-to-requires.patch Type: text/x-patch Size: 715 bytes Desc: not available URL: From mbasti at redhat.com Mon Sep 21 10:05:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 21 Sep 2015 12:05:11 +0200 Subject: [Freeipa-devel] [PATCH 0291, 0292] Limit max age of replication changelog In-Reply-To: <55F7D46E.7060003@redhat.com> References: <55AD0976.4070402@redhat.com> <55AD129D.8020608@redhat.com> <55AD1857.8090209@redhat.com> <55AD26EB.5030303@redhat.com> <55AD2A09.9070101@redhat.com> <55AFB0CE.3020508@redhat.com> <55F7D46E.7060003@redhat.com> Message-ID: <55FFD657.4050303@redhat.com> On 09/15/2015 10:18 AM, David Kupka wrote: > On 22/07/15 17:03, Martin Basti wrote: >> On 20/07/15 19:04, Mark Reynolds wrote: >>> >>> >>> On 07/20/2015 12:50 PM, Martin Basti wrote: >>>> On 20/07/15 17:48, Petr Vobornik wrote: >>>>> On 07/20/2015 05:24 PM, Rob Crittenden wrote: >>>>>> Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5086 >>>>>>> >>>>>>> Patch attached. >>>>>> >>>>>> Is this going to be a shock on upgrades for people who until now >>>>>> may be >>>>>> relying on the fact that there is no limit? >>>>> >>>>> Not making any point, but have to note: Ludwig raised a question on >>>>> users list but there was no feedback from users. >>>>> >>>>> https://www.redhat.com/archives/freeipa-users/2015-July/msg00022.html >>>>> >>>>>> >>>>>> Should there be a way for an admin to manage this, via the config >>>>>> module >>>>>> perhaps? >>>>>> >>>>>> IMHO this is a significant change and red flags need to be raised so >>>>>> users are aware of it. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> >>>> >>>> IIUC there is purge delay 7 days, so if changelog max age is 7 or >>>> more days, it will not break replication. >>>> The issue is if somebody uses changelog for different purpose, right? >>> Well the replication changelog can not be used for anything else but >>> the multimaster replication plugin. If a customer increased the >>> replication purge delay you could potentially run into issues, but >>> again this only comes into play when a replica is down for a very long >>> time. I'm not sure if IPA even provides the option to adjust the >>> replication purge delay, but that doesn't mean a customer can not >>> adjust these settings on their own. >>> >>> Mark >>> >> >> I'm attaching new patch, that modifies behavior of 'addifnew' keyword in >> update files. >> addifnew will no create new entry if doesn't exist. >> This is required for proper working of patch 292 >> >> Rob are you okay with these patches, as Mark wrote, changelog is used >> only for replication plugins, so it should not cause any issues to >> users. >> >> Martin^2 >> >> >> > Works as expected, ACK. > Pushed to: ipa-4-2: 96003cb12216a7062774ef5e1db41ce5b5ebbc44 master: e7713d45a4277901d8663c54893de48f8f6d5796 From jcholast at redhat.com Mon Sep 21 10:57:02 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 21 Sep 2015 12:57:02 +0200 Subject: [Freeipa-devel] [PATCH 0368] ipa-backup: Add mechanism to store empty directory structure In-Reply-To: <55FFB62B.70000@redhat.com> References: <55FAD882.4070701@redhat.com> <55FFB62B.70000@redhat.com> Message-ID: <55FFE27E.2070805@redhat.com> Hi, On 21.9.2015 09:47, Tomas Babej wrote: > > > On 09/17/2015 05:13 PM, Tomas Babej wrote: >> Hi, >> >> Certain subcomponents of IPA, such as Dogtag, cannot function if >> non-critical directories (such as log directories) have not been >> stored in the backup. >> >> This patch implements storage of selected empty directories, >> while preserving attributes and SELinux context. >> >> https://fedorahosted.org/freeipa/ticket/5297 >> > > Attaching a patch for gzip requires. This is more a formal thing than > anything else, gzip is required by systemd anyway. Please squash this change into the previous patch, there is no benefit in having it in a separate patch. Honza -- Jan Cholasta From mbasti at redhat.com Mon Sep 21 10:58:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 21 Sep 2015 12:58:47 +0200 Subject: [Freeipa-devel] [PATCH] 921 webui: use manual Firefox configuration for Firefox >= 40 In-Reply-To: <55FAE12E.8090302@redhat.com> References: <55FAE12E.8090302@redhat.com> Message-ID: <55FFE2E7.9000701@redhat.com> On 09/17/2015 05:50 PM, Petr Vobornik wrote: > The intended course of action is to show manual configuration in > browserconfig.html instead of configuration with the extension > for versions of Firefox >= 40. > > The reasoning is: > * plan for enterprise environments was not published yet which > forces as to use AMO (addons.mozilla.org) > * with AMO the user experience is worse than a manual configuration > > steps for AMO: > * go to AMO page > * installed the extension > * go back to IPA page > * probably refresh > * click configure > * confirm > > manual config: > * go to about:config > * set network.negotiate-auth.trusted-uris with *domain.name > > https://fedorahosted.org/freeipa/ticket/4906 > > ACK Pushed to: ipa-4-2: f1b2b0f5a1a73c2cffc19fe4fc8fb644bf1875be master: a94f3e5be88aec378e62f8696ca928635e0569a5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Mon Sep 21 13:25:12 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 21 Sep 2015 07:25:12 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: <55F90AD1.5000400@redhat.com> References: <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> <55F659BD.5040507@redhat.com> <55F67887.2000905@redhat.com> <55F7BEDA.4010908@redhat.com> <55F90AD1.5000400@redhat.com> Message-ID: Sorry. I had fixed another mistake and had not read your comment carefully. Updated patch attached. Gabe On Wed, Sep 16, 2015 at 12:23 AM, Jan Cholasta wrote: > On 15.9.2015 14:42, Gabe Alford wrote: > >> Yup. You are right. It was a mistake. Updated patch attached. >> >> On Tue, Sep 15, 2015 at 12:46 AM, Jan Cholasta > > wrote: >> >> On 14.9.2015 14:58, Gabe Alford wrote: >> >> Sounds good to me. Updated patch attached. >> >> On Mon, Sep 14, 2015 at 1:34 AM, Petr Spacek > >> >> wrote: >> >> On 14.9.2015 07:23, Jan Cholasta wrote: >> > IMO it does, because saying just "-1 is default" is not >> entirely correct and >> > "0 is default" would be confusing, as you pointed out. >> You might say "0 or -1 >> > is unlimited" if you think it's clearer. >> >> my +1 to "0 or -1 is unlimited" variant >> >> Petr^2 Spacek >> >> >> > On 10.9.2015 18:39, Gabe Alford wrote: >> >> Oops.. replied without the list. >> >> >> >> Reason I said -1 is because users might be confused if >> they >> enter `ipa >> >> config-mod --searchtimelimit=0`, and both `ipa >> user-show` and >> the webui >> >> show -1 instead of 0. I wonder if -1 makes more sense >> in that >> regard? >> >> Thoughts? Does "<= 0 is unlimited" make more sense? >> >> >> >> Thanks, >> >> >> >> Gabe >> >> >> The doc for ipasearchtimelimit and ipasearchrecordslimit says "-1 is >> unlimited", but both 0 and -1 is unlimited for them, and the doc for >> timelimit and sizelimit says "-1 or 0 is unlimited", but only 0 is >> unlimited for them. Looks like a mistake. >> >> -- >> Jan Cholasta >> >> >> > This hasn't changed since the previous patch and is still wrong, as -1 is > not supported here: > > Int('timelimit?', > label=_('Time Limit'), > - doc=_('Time limit of search in seconds'), > + doc=_('Time limit of search in seconds (-1 or 0 is > unlimited)'), > flags=['no_display'], > minvalue=0, > autofill=False, > ), > Int('sizelimit?', > label=_('Size Limit'), > - doc=_('Maximum number of entries returned'), > + doc=_('Maximum number of entries returned (-1 or 0 is > unlimited)'), > flags=['no_display'], > minvalue=0, > autofill=False, > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0053-9-Standardize-minvalue-for-ipasearchrecordlimit-and-ip.patch Type: text/x-patch Size: 8565 bytes Desc: not available URL: From tbabej at redhat.com Mon Sep 21 14:31:25 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 21 Sep 2015 16:31:25 +0200 Subject: [Freeipa-devel] [PATCH 0368] ipa-backup: Add mechanism to store empty directory structure In-Reply-To: <55FFE27E.2070805@redhat.com> References: <55FAD882.4070701@redhat.com> <55FFB62B.70000@redhat.com> <55FFE27E.2070805@redhat.com> Message-ID: <560014BD.8060204@redhat.com> On 09/21/2015 12:57 PM, Jan Cholasta wrote: > Hi, > > On 21.9.2015 09:47, Tomas Babej wrote: >> >> >> On 09/17/2015 05:13 PM, Tomas Babej wrote: >>> Hi, >>> >>> Certain subcomponents of IPA, such as Dogtag, cannot function if >>> non-critical directories (such as log directories) have not been >>> stored in the backup. >>> >>> This patch implements storage of selected empty directories, >>> while preserving attributes and SELinux context. >>> >>> https://fedorahosted.org/freeipa/ticket/5297 >>> >> >> Attaching a patch for gzip requires. This is more a formal thing than >> anything else, gzip is required by systemd anyway. > > Please squash this change into the previous patch, there is no benefit > in having it in a separate patch. > > Honza > Sure, this was more of an afterthought, attached. I also added some helpful comments that Martin^2 requested. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0368-2-ipa-backup-Add-mechanism-to-store-empty-directory-st.patch Type: text/x-patch Size: 5052 bytes Desc: not available URL: From redhatrises at gmail.com Mon Sep 21 15:37:12 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 21 Sep 2015 09:37:12 -0600 Subject: [Freeipa-devel] [PATCH 0054] Update FreeIPA package description Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5284 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0054-Update-FreeIPA-package-description.patch Type: text/x-patch Size: 5904 bytes Desc: not available URL: From redhatrises at gmail.com Mon Sep 21 15:37:13 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 21 Sep 2015 09:37:13 -0600 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5300 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0055-dnssec-options-missing-in-ipa-dns-install-man-page.patch Type: text/x-patch Size: 1364 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 22 06:00:36 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 22 Sep 2015 08:00:36 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> <55F1342D.90307@redhat.com> <55F19085.3010106@redhat.com> <55F659BD.5040507@redhat.com> <55F67887.2000905@redhat.com> <55F7BEDA.4010908@redhat.com> <55F90AD1.5000400@redhat.com> Message-ID: <5600EE84.6090301@redhat.com> On 21.9.2015 15:25, Gabe Alford wrote: > Sorry. I had fixed another mistake and had not read your comment > carefully. Updated patch attached. > > Gabe > > On Wed, Sep 16, 2015 at 12:23 AM, Jan Cholasta > wrote: > > On 15.9.2015 14:42, Gabe Alford wrote: > > Yup. You are right. It was a mistake. Updated patch attached. > > On Tue, Sep 15, 2015 at 12:46 AM, Jan Cholasta > > >> wrote: > > On 14.9.2015 14:58, Gabe Alford wrote: > > Sounds good to me. Updated patch attached. > > On Mon, Sep 14, 2015 at 1:34 AM, Petr Spacek > > > > > >>> wrote: > > On 14.9.2015 07:23, Jan Cholasta wrote: > > IMO it does, because saying just "-1 is default" > is not > entirely correct and > > "0 is default" would be confusing, as you > pointed out. > You might say "0 or -1 > > is unlimited" if you think it's clearer. > > my +1 to "0 or -1 is unlimited" variant > > Petr^2 Spacek > > > > On 10.9.2015 18:39, Gabe Alford wrote: > >> Oops.. replied without the list. > >> > >> Reason I said -1 is because users might be > confused if they > enter `ipa > >> config-mod --searchtimelimit=0`, and both `ipa > user-show` and > the webui > >> show -1 instead of 0. I wonder if -1 makes > more sense > in that > regard? > >> Thoughts? Does "<= 0 is unlimited" make more > sense? > >> > >> Thanks, > >> > >> Gabe > > > The doc for ipasearchtimelimit and ipasearchrecordslimit > says "-1 is > unlimited", but both 0 and -1 is unlimited for them, and > the doc for > timelimit and sizelimit says "-1 or 0 is unlimited", but > only 0 is > unlimited for them. Looks like a mistake. > > -- > Jan Cholasta > > > > This hasn't changed since the previous patch and is still wrong, as > -1 is not supported here: > > Int('timelimit?', > label=_('Time Limit'), > - doc=_('Time limit of search in seconds'), > + doc=_('Time limit of search in seconds (-1 or 0 is > unlimited)'), > flags=['no_display'], > minvalue=0, > autofill=False, > ), > Int('sizelimit?', > label=_('Size Limit'), > - doc=_('Maximum number of entries returned'), > + doc=_('Maximum number of entries returned (-1 or 0 is > unlimited)'), > flags=['no_display'], > minvalue=0, > autofill=False, > > -- > Jan Cholasta Thank you. ACK. Pushed to: master: 65e958fda4aee2e08cd1f7043369710b839476c3 ipa-4-2: 28d6ae0ac0e3d30f6672bd9a9a5f5827f2a768a3 -- Jan Cholasta From mbasti at redhat.com Tue Sep 22 07:17:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 22 Sep 2015 09:17:21 +0200 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page In-Reply-To: References: Message-ID: <56010081.4020205@redhat.com> On 09/21/2015 05:37 PM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5300 > > Thanks, > > Gabe > > Thank you! The option --no-dnssec-validation is used also in ipa-server-install and ipa-replica-install, so this option should be documented in multiple manpages. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Sep 22 08:29:04 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 22 Sep 2015 10:29:04 +0200 Subject: [Freeipa-devel] [PATCHES 466-468] install: Add common base class for server and replica install In-Reply-To: <55F92BF3.6010604@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> <55F7AB23.5040805@redhat.com> <55F907FA.40202@redhat.com> <55F92BF3.6010604@redhat.com> Message-ID: <56011150.6050106@redhat.com> On 09/16/2015 10:44 AM, Jan Cholasta wrote: > On 16.9.2015 08:11, Jan Cholasta wrote: >> On 15.9.2015 07:22, Jan Cholasta wrote: >>> On 10.8.2015 16:58, Martin Babinsky wrote: >>>> On 08/06/2015 08:22 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes part of >>>>> . >>>>> >>>>> See also Martin Babinsky's patch 51: >>>>> . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Honza >>>>> >>>> >>>> Sorry but NACK, see below: >>>> >>>> 1.) it seems that passing kwargs to Server components doesn't work as >>>> expected. See these logs (install on fresh F22 VM): >>>> >>>> http://fpaste.org/253416/21363814/ >>>> http://fpaste.org/253419/43921374/ >>> >>> Fixed. >>> >>>> >>>> 2.) the following code blows up in BaseServers' __init__: >>>> (http://fpaste.org/253400/21225314/) >>>> >>>> 392 if not self.dns.setup_dns: >>>> 393 if self.dns.forwarders: >>>> 394 raise RuntimeError( >>>> 395 "You cannot specify a --forwarder option >>>> without >>>> the " >>>> 396 "--setup-dns option") >>>> >>>> >>>> I think that the check should be: >>>> >>>> 392 if not self.setup_dns: >>>> 393 if self.dns.forwarders: >>> >>> Fixed. >>> >>>> >>>> IMHO BaseServerDNS class shouldn't have setup_dns knob, that should be >>>> set in the parent class (BaseServer) >>> >>> Fixed. >>> >>>> >>>> 3.) Is there any reason why BaseServer doesn't have 'master_password', >>>> 'idmax' and 'idstart' knobs? I know that these are then brought in by >>>> the derived Server class, but the check for them is in parent's >>>> __init__() method and it is IMHO a bit confusing >>> >>> The check should be in Server, fixed. >>> >>>> >>>> 4.) please add license header to the beginning of >>>> 'ipaserver/install/server/common.py' file >>> >>> Added. >>> >>> Updated patches attached. >> >> Self-NACK, I broke ipa-server-install --uninstall. > > Fixed. > ACK to all three patches. -- Martin^3 Babinsky From ofayans at redhat.com Tue Sep 22 08:42:18 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 22 Sep 2015 10:42:18 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 Message-ID: <5601146A.1000905@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0007-Added-a-proper-workaround-for-dnssec-test-failures.patch Type: text/x-patch Size: 2629 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 22 08:45:27 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 22 Sep 2015 10:45:27 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1441823142.3048.250.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> Message-ID: <56011527.40304@redhat.com> Hi, On 9.9.2015 20:25, Simo Sorce wrote: > On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: >> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >> and introduces a number of required changes and dependencies to achieve >> this goal. >> This work requires the custodia project to securely transfer keys >> between ipa servers. >> >> This work is not 100% complete, it still misses the ability to install >> kra instances and the ability to install a CA (via ipa-ca-install) with >> externally signed certs. >> >> However it is massive enough that warrants review and pushing, the resat >> of the changes can be applied later as this work should not disrupt the >> classic install methods. >> >> In order to build my previous patches (530-533) are needed as well as a >> number of updated components. >> >> I used the following coprs for testing: >> simo/jwcrypto >> simo/custodia >> abbra/sssd-kkdcproxy (for sssd 1.13.1) >> lkrispen/389-ds-current (for 389 > 1.3.4.4) >> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >> mkosek/freeipa-4.2-fedora-22 (misc) >> fedora/updates-testing (python-gssapi 1.1.2) >> >> Ludwig's copr is necessary to have a functional DNA plugin in replicas, >> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >> it will be released. >> >> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >> that may cause installation issues in some case (re-install of a >> replica). >> >> The domain must be raised to level 1 in order to use replica promotion. >> >> In order to promote a replica the server must be first joined as a >> regular client to the domain. >> >> This is the flow I usually use for testing: >> >> # ipa-client-install >> # kinit admin >> # ipa-replica-install --promote --setup-ca >> > etc...> >> >> These patches are also available in this git tree rebnase on current >> master: >> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > FYI: I rebased this branch on top of master and applied minor changes to > one of the DNS patches. I also added the missing support to install KRA. > > DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not > needed anymore. > > Dogtag's ticket is not fixed yet so running both --setup-ca and > --setup-kra at the same time will still yield an error and install will > fail. > > Please let me know if there are any major issues with this patchset, I'd > like to push it to master and attack the remaining issues as add ons > (install with external certs not supported yet for example) So far I have only read through the code without running it (mostly). "Remove unused arguments": ACK "Simplify the install_replica_ca function": ACK "IPA Custodia Daemon": 1) Instead of putting the code in "ipakeys" package, could you put it in "ipapython.keys"? This way it would be consistent with DNSSEC, which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/. 2) Is it safe to create cn=custodia in update file only? Updates are executed late in ipa-server-install. Is is guaranteed that nothing will try to access cn=custodia before the updates are run? (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) 3) Shouldn't cn=custodia be created only when domain level >= 1? 4) pylint fails with: daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), IPAKEMKeys.__init__] Use of super on an old style class) daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no 'config' member) daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) 5) There are some PEP8 transgressions: ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 > 79 characters) ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 > 79 characters) ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank lines, found 1 ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file "Add Custodia Client code": 1) Is there any significance in having this in a separate commit? I would think it can be safely squashed in the previous commit. 2) There is one PEP8 transgression: ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank lines (2) "Install ipa-custodia with the rest of ipa": 1) python-jwcrypto dependency is missing in the spec file. 2) I believe the daemons/ipa-custodia/* and install/share/bootstrap-template.ldif should be in the "IPA Custodia Daemon" commit. At the very least it would make reviews easier. 3) There is one PEP8 transgressions: ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank lines, found 1 "Require a DS version that has working DNA plugin": ACK "Implement replica promotion functionality": 1) I think a RuntimeError or sys.exit with an error message would be better than NotImplementedError for the unimplemented options. (Nevermind, these are removed in further commits.) 2) There is no domain level check when installing the replica from a replica file. 3) Instead of returning INSTALL_ERROR from promote_check() (which has no effect), raise an exception or call sys.exit(). 4) The --promote option is redundant. You can safely decide whether to promote or not based on whether replica file was provided or not and the domain level of the remote server. 5) There are some PEP8 transgressions: ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace after ',' ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace after ',' ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace after ',' ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 characters) ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 characters) ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank lines, found 1 ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > 79 characters) ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > 79 characters) ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > 79 characters) ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 blank lines, found 1 ./ipaserver/install/server/replicainstall.py:862:25: E128 continuation line under-indented for visual indent ./ipaserver/install/server/replicainstall.py:864:25: E128 continuation line under-indented for visual indent ./ipaserver/install/server/replicainstall.py:865:25: E128 continuation line under-indented for visual indent ./ipaserver/install/server/replicainstall.py:1014:13: E128 continuation line under-indented for visual indent ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing whitespace after ',' ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many blank lines (2) "Change DNS installer code to use passed in api": LGTM "Allow ipa-replica-conncheck to use default creds": LGTM "Add function to extract CA certs for install": LGTM "Allow to setup the CA when promoting a replica": 1) There are some PEP8 transgressions: ./ipaserver/install/ca.py:35:13: E125 continuation line with same indent as next logical line ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) ./ipaserver/install/replication.py:421:24: E231 missing whitespace after ',' ./ipaserver/install/replication.py:421:35: E231 missing whitespace after ',' ./ipaserver/install/replication.py:421:41: E231 missing whitespace after ',' ./ipaserver/install/replication.py:422:24: E231 missing whitespace after ',' ./ipaserver/install/replication.py:422:40: E231 missing whitespace after ',' ./ipaserver/install/replication.py:422:46: E231 missing whitespace after ',' ./ipaserver/install/replication.py:524:37: E128 continuation line under-indented for visual indent ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' ./ipaserver/install/replication.py:524:80: E501 line too long (187 > 79 characters) ./ipaserver/install/replication.py:526:80: E501 line too long (106 > 79 characters) ./ipaserver/install/replication.py:560:80: E501 line too long (86 > 79 characters) ./ipaserver/install/replication.py:847:80: E501 line too long (81 > 79 characters) ./ipaserver/install/replication.py:850:80: E501 line too long (89 > 79 characters) ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > 79 characters) ./ipaserver/install/replication.py:1766:17: E128 continuation line under-indented for visual indent ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > 79 characters) "Make checks for existing credentials reusable": 1) There are some PEP8 transgressions: ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank lines, found 1 ./ipaserver/install/installutils.py:1192:25: E128 continuation line under-indented for visual indent ./ipaserver/install/installutils.py:1194:25: E128 continuation line under-indented for visual indent ./ipaserver/install/installutils.py:1195:25: E128 continuation line under-indented for visual indent "Allow ipa-ca-install to use the new promotion code": 1) The --replica option is redundant. You can safely decide whether this is the first CA master or not based on information in cn=masters. 2) There are some PEP8 transgressions: ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace after ',' ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace after ',' "Remove unused kra option": ACK "Allow to install the KRA on a promoted server": 1) There are some PEP8 transgressions: ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line over-indented for visual indent ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, found 1 ./ipaserver/install/krainstance.py:382:13: E128 continuation line under-indented for visual indent ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing whitespace around operator ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many blank lines (2) ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, found 1 ./ipaserver/install/service.py:115:52: E203 whitespace before ',' Pushed first 2 commits to master: d8b1f42f171d666068583548315b4684e5f3c3a4 Honza -- Jan Cholasta From ofayans at redhat.com Tue Sep 22 09:21:33 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 22 Sep 2015 11:21:33 +0200 Subject: [Freeipa-devel] [PATCH] improved logging in dnssec tests Message-ID: <56011D9D.6010408@redhat.com> Hi all, I've noticed that in some tests some low-level functions can return False in a number of different conditions, which severely complicates test debugging. This patch implements the approach widely used in the Go language (and maybe, some other): The function returns not only a boolean, but a boolean plus any error message caught during the execution. This error message may be used by the higher level code for logging. For example, compare these outputs: 1. AssertionError: Zone example.test. is not signed (master): request timed out 2. AssertionError: Zone example.test. is not signed (master) What do you think? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0008-Added-error-propagation-for-imroved-debugging.patch Type: text/x-patch Size: 22087 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 22 10:10:33 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 22 Sep 2015 12:10:33 +0200 Subject: [Freeipa-devel] [PATCHES 466-468] install: Add common base class for server and replica install In-Reply-To: <56011150.6050106@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> <55F7AB23.5040805@redhat.com> <55F907FA.40202@redhat.com> <55F92BF3.6010604@redhat.com> <56011150.6050106@redhat.com> Message-ID: <56012919.4000007@redhat.com> On 22.9.2015 10:29, Martin Babinsky wrote: > On 09/16/2015 10:44 AM, Jan Cholasta wrote: >> On 16.9.2015 08:11, Jan Cholasta wrote: >>> On 15.9.2015 07:22, Jan Cholasta wrote: >>>> On 10.8.2015 16:58, Martin Babinsky wrote: >>>>> On 08/06/2015 08:22 AM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes part of >>>>>> . >>>>>> >>>>>> See also Martin Babinsky's patch 51: >>>>>> . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Sorry but NACK, see below: >>>>> >>>>> 1.) it seems that passing kwargs to Server components doesn't work as >>>>> expected. See these logs (install on fresh F22 VM): >>>>> >>>>> http://fpaste.org/253416/21363814/ >>>>> http://fpaste.org/253419/43921374/ >>>> >>>> Fixed. >>>> >>>>> >>>>> 2.) the following code blows up in BaseServers' __init__: >>>>> (http://fpaste.org/253400/21225314/) >>>>> >>>>> 392 if not self.dns.setup_dns: >>>>> 393 if self.dns.forwarders: >>>>> 394 raise RuntimeError( >>>>> 395 "You cannot specify a --forwarder option >>>>> without >>>>> the " >>>>> 396 "--setup-dns option") >>>>> >>>>> >>>>> I think that the check should be: >>>>> >>>>> 392 if not self.setup_dns: >>>>> 393 if self.dns.forwarders: >>>> >>>> Fixed. >>>> >>>>> >>>>> IMHO BaseServerDNS class shouldn't have setup_dns knob, that should be >>>>> set in the parent class (BaseServer) >>>> >>>> Fixed. >>>> >>>>> >>>>> 3.) Is there any reason why BaseServer doesn't have 'master_password', >>>>> 'idmax' and 'idstart' knobs? I know that these are then brought in by >>>>> the derived Server class, but the check for them is in parent's >>>>> __init__() method and it is IMHO a bit confusing >>>> >>>> The check should be in Server, fixed. >>>> >>>>> >>>>> 4.) please add license header to the beginning of >>>>> 'ipaserver/install/server/common.py' file >>>> >>>> Added. >>>> >>>> Updated patches attached. >>> >>> Self-NACK, I broke ipa-server-install --uninstall. >> >> Fixed. >> > > ACK to all three patches. > Thanks. Pushed to: master: 86edd6abeb9749e159a529b83cfce6443fff4ba5 ipa-4-2: 42d16b02cd153ac89ebd8ae07c98611dc3b6e471 -- Jan Cholasta From mbasti at redhat.com Tue Sep 22 11:19:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 22 Sep 2015 13:19:22 +0200 Subject: [Freeipa-devel] [PATCH 0368] ipa-backup: Add mechanism to store empty directory structure In-Reply-To: <560014BD.8060204@redhat.com> References: <55FAD882.4070701@redhat.com> <55FFB62B.70000@redhat.com> <55FFE27E.2070805@redhat.com> <560014BD.8060204@redhat.com> Message-ID: <5601393A.3000901@redhat.com> On 09/21/2015 04:31 PM, Tomas Babej wrote: > > On 09/21/2015 12:57 PM, Jan Cholasta wrote: >> Hi, >> >> On 21.9.2015 09:47, Tomas Babej wrote: >>> >>> On 09/17/2015 05:13 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Certain subcomponents of IPA, such as Dogtag, cannot function if >>>> non-critical directories (such as log directories) have not been >>>> stored in the backup. >>>> >>>> This patch implements storage of selected empty directories, >>>> while preserving attributes and SELinux context. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5297 >>>> >>> Attaching a patch for gzip requires. This is more a formal thing than >>> anything else, gzip is required by systemd anyway. >> Please squash this change into the previous patch, there is no benefit >> in having it in a separate patch. >> >> Honza >> > Sure, this was more of an afterthought, attached. > > I also added some helpful comments that Martin^2 requested. > > Tomas ACK Pushed to: ipa-4-2: 210a4254153fa96a61056a3d3d58b992191de880 master: cfeea91828ad47e1d321947d04f5f6de0e3d1c8c From dkupka at redhat.com Tue Sep 22 11:20:13 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 22 Sep 2015 13:20:13 +0200 Subject: [Freeipa-devel] [PATCH 0004] Rewrap errors in get_principal to CCacheError In-Reply-To: <55E9B3A0.7080803@redhat.com> References: <55E826E8.7080703@redhat.com> <55E83DF8.3040201@redhat.com> <55E9B3A0.7080803@redhat.com> Message-ID: <5601396D.5050404@redhat.com> On 04/09/15 17:07, Michael ?im??ek wrote: > On 2015-09-03 14:32, Tomas Babej wrote: >> >> >> On 09/03/2015 12:54 PM, Michael ?im??ek wrote: >>> After porting to gssapi, the ipa command prints ugly traceback when >>> kerberos credentials are not available. Rewrapping to CCacheError when >>> getting the principal name results in nicer error message. >>> >>> https://fedorahosted.org/freeipa/ticket/5272 >>> >>> >> >> This fixes the issue, however, I am getting a trailing forward slash in >> the error message: >> >> $ ipa user-find >> ipa: ERROR: Kerberos error: did not receive Kerberos credentials/ >> > > Attaching updated revision. I altered more places where kerberos errors > were used. > > Michael > > Thanks, patch works for me, ACK. -- David Kupka From jcholast at redhat.com Tue Sep 22 11:30:16 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 22 Sep 2015 13:30:16 +0200 Subject: [Freeipa-devel] [PATCH 0004] Rewrap errors in get_principal to CCacheError In-Reply-To: <5601396D.5050404@redhat.com> References: <55E826E8.7080703@redhat.com> <55E83DF8.3040201@redhat.com> <55E9B3A0.7080803@redhat.com> <5601396D.5050404@redhat.com> Message-ID: <56013BC8.6010203@redhat.com> On 22.9.2015 13:20, David Kupka wrote: > On 04/09/15 17:07, Michael ?im??ek wrote: >> On 2015-09-03 14:32, Tomas Babej wrote: >>> >>> >>> On 09/03/2015 12:54 PM, Michael ?im??ek wrote: >>>> After porting to gssapi, the ipa command prints ugly traceback when >>>> kerberos credentials are not available. Rewrapping to CCacheError when >>>> getting the principal name results in nicer error message. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5272 >>>> >>>> >>> >>> This fixes the issue, however, I am getting a trailing forward slash in >>> the error message: >>> >>> $ ipa user-find >>> ipa: ERROR: Kerberos error: did not receive Kerberos credentials/ >>> >> >> Attaching updated revision. I altered more places where kerberos errors >> were used. >> >> Michael >> >> > Thanks, patch works for me, ACK. > Pushed to master: bdccebbcdb9eb7da476762743121c1e73f95fa10 -- Jan Cholasta From jcholast at redhat.com Tue Sep 22 11:33:31 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 22 Sep 2015 13:33:31 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install Message-ID: <56013C8B.3070402@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-494-install-create-kdcproxy-user-during-server-install.patch Type: text/x-patch Size: 5066 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Sep 22 11:44:41 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 22 Sep 2015 13:44:41 +0200 Subject: [Freeipa-devel] [PATCH 0064] destroy httpd ccache after stopping the service Message-ID: <56013F29.5040303@redhat.com> This patch fixes https://fedorahosted.org/freeipa/ticket/5296 and generally makes cleaning up of httpd ccache more thorough. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0064-destroy-httpd-ccache-after-stopping-the-service.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: From tbabej at redhat.com Tue Sep 22 12:23:52 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Sep 2015 14:23:52 +0200 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <20150903143418.GN22106@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> Message-ID: <56014858.4020100@redhat.com> On 09/03/2015 04:34 PM, Alexander Bokovoy wrote: > On Thu, 03 Sep 2015, Tomas Babej wrote: >> Hi, >> >> this couple of patches fix https://fedorahosted.org/freeipa/ticket/5278 >> and improve our handling of realmdomains in general. > The code looks good to me. I haven't tested it yet, though. > Rebased on top of current master. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0362-2-util-Add-detect_dns_zone_realm_type-helper.patch Type: text/x-patch Size: 2637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0363-2-realmdomains-Minor-style-and-wording-improvements.patch Type: text/x-patch Size: 5717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0364-2-realmdomains-Add-validation-that-realmdomain-being-a.patch Type: text/x-patch Size: 5659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0365-2-realmdomains-Issue-a-warning-when-automated-manageme.patch Type: text/x-patch Size: 3909 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0366-2-realmdomains-Do-not-fail-due-the-ValidationError-whe.patch Type: text/x-patch Size: 1649 bytes Desc: not available URL: From dkupka at redhat.com Tue Sep 22 12:59:35 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 22 Sep 2015 14:59:35 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <55FC2707.5060709@redhat.com> References: <55FC2707.5060709@redhat.com> Message-ID: <560150B7.4060405@redhat.com> On 18/09/15 17:00, Petr Viktorin wrote: > Hello, > Here are more patches that bring IPA closer to Python 3 compatibility. > > > > Hi Petr, thanks for another batch of Python 3 compatibility patches. Unfortunately I hit a lot of pylint errors. Some of them are false positives for sure. Could you please look at them, mark the false positive with "pylint: disable=Exxxx" directive and fix the rest? http://fpaste.org/270090/92665414/ And one nitpick, I believe that the plus signs are not needed. > - self.arabic_hello_utf8 = '\xd9\x85\xd9\x83\xd9\x8a\xd9\x84' + \ > - '\xd8\xb9\x20\xd9\x85\xd8\xa7\xd9' + \ > - '\x84\xd9\x91\xd8\xb3\xd9\x84\xd8\xa7' > + self.arabic_hello_utf8 = (b'\xd9\x85\xd9\x83\xd9\x8a\xd9\x84' + > + b'\xd8\xb9\x20\xd9\x85\xd8\xa7\xd9' + > + b'\x84\xd9\x91\xd8\xb3\xd9\x84\xd8\xa7') -- David Kupka From mbabinsk at redhat.com Tue Sep 22 13:11:57 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 22 Sep 2015 15:11:57 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <56013C8B.3070402@redhat.com> References: <56013C8B.3070402@redhat.com> Message-ID: <5601539D.1000903@redhat.com> On 09/22/2015 01:33 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From redhatrises at gmail.com Tue Sep 22 13:32:02 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 22 Sep 2015 07:32:02 -0600 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page In-Reply-To: <56010081.4020205@redhat.com> References: <56010081.4020205@redhat.com> Message-ID: Thanks! Added and attached updated patch. Gabe On Tue, Sep 22, 2015 at 1:17 AM, Martin Basti wrote: > > > On 09/21/2015 05:37 PM, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5300 > > Thanks, > > Gabe > > > Thank you! > > The option --no-dnssec-validation is used also in ipa-server-install and > ipa-replica-install, so this option should be documented in multiple > manpages. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0055-2-dnssec-options-missing-in-man-pages.patch Type: text/x-patch Size: 4098 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 22 14:35:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 22 Sep 2015 16:35:35 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <5601539D.1000903@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> Message-ID: <56016737.7020901@redhat.com> On 22.9.2015 15:11, Martin Babinsky wrote: > On 09/22/2015 01:33 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK > Thanks. Pushed to: master: 0de860318332114ca739a8dd45902f7cc9a3c722 ipa-4-2: 4663625bbb3456db7f13578e6cac0c3e5fae2591 -- Jan Cholasta From simo at redhat.com Tue Sep 22 14:57:27 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Sep 2015 10:57:27 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56011527.40304@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> Message-ID: <1442933847.4697.147.camel@willson.usersys.redhat.com> On Tue, 2015-09-22 at 10:45 +0200, Jan Cholasta wrote: > Hi, > > On 9.9.2015 20:25, Simo Sorce wrote: > > On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: > >> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > >> and introduces a number of required changes and dependencies to achieve > >> this goal. > >> This work requires the custodia project to securely transfer keys > >> between ipa servers. > >> > >> This work is not 100% complete, it still misses the ability to install > >> kra instances and the ability to install a CA (via ipa-ca-install) with > >> externally signed certs. > >> > >> However it is massive enough that warrants review and pushing, the resat > >> of the changes can be applied later as this work should not disrupt the > >> classic install methods. > >> > >> In order to build my previous patches (530-533) are needed as well as a > >> number of updated components. > >> > >> I used the following coprs for testing: > >> simo/jwcrypto > >> simo/custodia > >> abbra/sssd-kkdcproxy (for sssd 1.13.1) > >> lkrispen/389-ds-current (for 389 > 1.3.4.4) > >> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > >> mkosek/freeipa-4.2-fedora-22 (misc) > >> fedora/updates-testing (python-gssapi 1.1.2) > >> > >> Ludwig's copr is necessary to have a functional DNA plugin in replicas, > >> eventually his patches should be committed in 389-ds-base 1.3.4.4 when > >> it will be released. > >> > >> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > >> that may cause installation issues in some case (re-install of a > >> replica). > >> > >> The domain must be raised to level 1 in order to use replica promotion. > >> > >> In order to promote a replica the server must be first joined as a > >> regular client to the domain. > >> > >> This is the flow I usually use for testing: > >> > >> # ipa-client-install > >> # kinit admin > >> # ipa-replica-install --promote --setup-ca > >> >> etc...> > >> > >> These patches are also available in this git tree rebnase on current > >> master: > >> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > > > FYI: I rebased this branch on top of master and applied minor changes to > > one of the DNS patches. I also added the missing support to install KRA. > > > > DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not > > needed anymore. > > > > Dogtag's ticket is not fixed yet so running both --setup-ca and > > --setup-kra at the same time will still yield an error and install will > > fail. > > > > Please let me know if there are any major issues with this patchset, I'd > > like to push it to master and attack the remaining issues as add ons > > (install with external certs not supported yet for example) > > So far I have only read through the code without running it (mostly). > > > "Remove unused arguments": ACK > > > "Simplify the install_replica_ca function": ACK Thanks for pushing these. > > "IPA Custodia Daemon": > > 1) Instead of putting the code in "ipakeys" package, could you put it in > "ipapython.keys"? This way it would be consistent with DNSSEC, which has > binaries in daemons/dnssec/ and modules in ipapython/dnssec/. I think I can do this, it was originally all in daemon becuse that's where I had the custodia submodules, but we do not carry a copy anymore. > 2) Is it safe to create cn=custodia in update file only? Updates are > executed late in ipa-server-install. Is is guaranteed that nothing will > try to access cn=custodia before the updates are run? > > (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) > > 3) Shouldn't cn=custodia be created only when domain level >= 1? It is used only at >= 1 level, but we have to create it when we update the code, otherwise you cannot switch to level 1. Switching a level ion LDAP cannot cause an update script to be run so you would have incomplete servers publicizing level 1 but not offering a critical service for level 1. > 4) pylint fails with: > > daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), > IPAKEMKeys.__init__] Use of super on an old style class) > daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), > IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no > 'config' member) > daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), > IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) On what pylint version ? I had to disable pylint for a while but it currently runs and doesn't complain to me ... > 5) There are some PEP8 transgressions: > > ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 > > 79 characters) > ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 > > 79 characters) > ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank > lines, found 1 > ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file I'll take care of these. > "Add Custodia Client code": > > 1) Is there any significance in having this in a separate commit? I > would think it can be safely squashed in the previous commit. Easier review (and rebasing), I want to keep chunks smaller. > 2) There is one PEP8 transgression: > > ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank lines (2) > > > "Install ipa-custodia with the rest of ipa": > > 1) python-jwcrypto dependency is missing in the spec file. It shouldn't be necessary as custodia already depends on it. > 2) I believe the daemons/ipa-custodia/* and > install/share/bootstrap-template.ldif should be in the "IPA Custodia > Daemon" commit. At the very least it would make reviews easier. ok > 3) There is one PEP8 transgressions: > > ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank > lines, found 1 > > > "Require a DS version that has working DNA plugin": ACK > > > "Implement replica promotion functionality": > > 1) I think a RuntimeError or sys.exit with an error message would be > better than NotImplementedError for the unimplemented options. > > (Nevermind, these are removed in further commits.) They were for my use indeed :) > 2) There is no domain level check when installing the replica from a > replica file. And why would we need it ? We discussed about preventing generation of a replica file at level 1, but that is not part of this patchset. > 3) Instead of returning INSTALL_ERROR from promote_check() (which has no > effect), raise an exception or call sys.exit(). ok > 4) The --promote option is redundant. You can safely decide whether to > promote or not based on whether replica file was provided or not and the > domain level of the remote server. Except there is a chick/egg issue in getting there, I am ok removing --promote in a followup patch, but not changing it in this patchset, it would require too much churn. > 5) There are some PEP8 transgressions: > > ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace after ',' > ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace after ',' > ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace after ',' > ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' > ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 > characters) > ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 > characters) > ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) > ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank lines, > found 1 > ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > 79 > characters) > ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > 79 > characters) > ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > 79 > characters) > ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 > blank lines, found 1 > ./ipaserver/install/server/replicainstall.py:862:25: E128 continuation > line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:864:25: E128 continuation > line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:865:25: E128 continuation > line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:1014:13: E128 continuation > line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing > whitespace after ',' > ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many blank > lines (2) > > > "Change DNS installer code to use passed in api": LGTM > > > "Allow ipa-replica-conncheck to use default creds": LGTM > > > "Add function to extract CA certs for install": LGTM > > > "Allow to setup the CA when promoting a replica": > > 1) There are some PEP8 transgressions: > > ./ipaserver/install/ca.py:35:13: E125 continuation line with same indent > as next logical line > ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) > ./ipaserver/install/replication.py:421:24: E231 missing whitespace after ',' > ./ipaserver/install/replication.py:421:35: E231 missing whitespace after ',' > ./ipaserver/install/replication.py:421:41: E231 missing whitespace after ',' > ./ipaserver/install/replication.py:422:24: E231 missing whitespace after ',' > ./ipaserver/install/replication.py:422:40: E231 missing whitespace after ',' > ./ipaserver/install/replication.py:422:46: E231 missing whitespace after ',' > ./ipaserver/install/replication.py:524:37: E128 continuation line > under-indented for visual indent > ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' > ./ipaserver/install/replication.py:524:80: E501 line too long (187 > 79 > characters) > ./ipaserver/install/replication.py:526:80: E501 line too long (106 > 79 > characters) > ./ipaserver/install/replication.py:560:80: E501 line too long (86 > 79 > characters) > ./ipaserver/install/replication.py:847:80: E501 line too long (81 > 79 > characters) > ./ipaserver/install/replication.py:850:80: E501 line too long (89 > 79 > characters) > ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > 79 > characters) > ./ipaserver/install/replication.py:1766:17: E128 continuation line > under-indented for visual indent > ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > 79 > characters) > > > "Make checks for existing credentials reusable": > > 1) There are some PEP8 transgressions: > > ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank lines, > found 1 > ./ipaserver/install/installutils.py:1192:25: E128 continuation line > under-indented for visual indent > ./ipaserver/install/installutils.py:1194:25: E128 continuation line > under-indented for visual indent > ./ipaserver/install/installutils.py:1195:25: E128 continuation line > under-indented for visual indent > > > "Allow ipa-ca-install to use the new promotion code": > > 1) The --replica option is redundant. You can safely decide whether this > is the first CA master or not based on information in cn=masters. > > 2) There are some PEP8 transgressions: > > ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace after ',' > ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace after ',' > > > "Remove unused kra option": ACK > > > "Allow to install the KRA on a promoted server": > > 1) There are some PEP8 transgressions: > > ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line > over-indented for visual indent > ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, > found 1 > ./ipaserver/install/krainstance.py:382:13: E128 continuation line > under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing > whitespace around operator > ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many blank > lines (2) > ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, found 1 > ./ipaserver/install/service.py:115:52: E203 whitespace before ',' > > > Pushed first 2 commits to master: d8b1f42f171d666068583548315b4684e5f3c3a4 Ok, I'll rework the patches as possible, do you want a new patchset sent to the list ? Or is it ok to rebnase the custodia-review branch in my freeipa.git tree ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Sep 22 15:23:35 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Sep 2015 11:23:35 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56011527.40304@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> Message-ID: <1442935415.4697.149.camel@willson.usersys.redhat.com> On Tue, 2015-09-22 at 10:45 +0200, Jan Cholasta wrote: > 4) pylint fails with: > > daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), > IPAKEMKeys.__init__] Use of super on an old style class) > daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), > IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no > 'config' member) > daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), > IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' > member) I do not know why pylint gives you these errors. The top level class for IPAKEMKeys is is ultimatile the custodia class called HTTPAuthorizer which is defined as a new-style class (derives from object), that class also unconditionally inits config. Maybe you ran pylint w/o custodia installed ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 23 00:09:25 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Sep 2015 20:09:25 -0400 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <56016737.7020901@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> Message-ID: <1442966965.4697.199.camel@willson.usersys.redhat.com> On Tue, 2015-09-22 at 16:35 +0200, Jan Cholasta wrote: > On 22.9.2015 15:11, Martin Babinsky wrote: > > On 09/22/2015 01:33 PM, Jan Cholasta wrote: > >> Hi, > >> > >> the attached patch fixes . > >> > >> Honza > >> > >> > >> > > ACK > > > > Thanks. > > Pushed to: > master: 0de860318332114ca739a8dd45902f7cc9a3c722 > ipa-4-2: 4663625bbb3456db7f13578e6cac0c3e5fae2591 This patch is somehow broken. I see that %{kdcproxy_home} has been removed from the spec file but not from everywhere, and it is simply undefined. On upgrade of my server I have no kdcproxy user and http fails to operate complaining that /var/lib/kdcproxy does not exist. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 23 00:22:47 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Sep 2015 20:22:47 -0400 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <1442966965.4697.199.camel@willson.usersys.redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> Message-ID: <1442967767.4697.201.camel@willson.usersys.redhat.com> On Tue, 2015-09-22 at 20:09 -0400, Simo Sorce wrote: > On Tue, 2015-09-22 at 16:35 +0200, Jan Cholasta wrote: > > On 22.9.2015 15:11, Martin Babinsky wrote: > > > On 09/22/2015 01:33 PM, Jan Cholasta wrote: > > >> Hi, > > >> > > >> the attached patch fixes . > > >> > > >> Honza > > >> > > >> > > >> > > > ACK > > > > > > > Thanks. > > > > Pushed to: > > master: 0de860318332114ca739a8dd45902f7cc9a3c722 > > ipa-4-2: 4663625bbb3456db7f13578e6cac0c3e5fae2591 > > This patch is somehow broken. > > I see that %{kdcproxy_home} has been removed from the spec file but not > from everywhere, and it is simply undefined. > > On upgrade of my server I have no kdcproxy user and http fails to > operate complaining that /var/lib/kdcproxy does not exist. Correction, the HTTP server works, but it spits lots of errors in error_log about /var/lib/kdcproxy not existing. Is the KDCProxy supposed to be installked/enabled on upgrade ? If not, why not ? Even if it is not enabled, shouldn't the user be created just in case ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 23 00:47:13 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Sep 2015 20:47:13 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1442933847.4697.147.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <1442933847.4697.147.camel@willson.usersys.redhat.com> Message-ID: <1442969233.4697.208.camel@willson.usersys.redhat.com> On Tue, 2015-09-22 at 10:57 -0400, Simo Sorce wrote: > On Tue, 2015-09-22 at 10:45 +0200, Jan Cholasta wrote: > > Hi, > > > > On 9.9.2015 20:25, Simo Sorce wrote: > > > On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: > > >> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > > >> and introduces a number of required changes and dependencies to achieve > > >> this goal. > > >> This work requires the custodia project to securely transfer keys > > >> between ipa servers. > > >> > > >> This work is not 100% complete, it still misses the ability to install > > >> kra instances and the ability to install a CA (via ipa-ca-install) with > > >> externally signed certs. > > >> > > >> However it is massive enough that warrants review and pushing, the resat > > >> of the changes can be applied later as this work should not disrupt the > > >> classic install methods. > > >> > > >> In order to build my previous patches (530-533) are needed as well as a > > >> number of updated components. > > >> > > >> I used the following coprs for testing: > > >> simo/jwcrypto > > >> simo/custodia > > >> abbra/sssd-kkdcproxy (for sssd 1.13.1) > > >> lkrispen/389-ds-current (for 389 > 1.3.4.4) > > >> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > > >> mkosek/freeipa-4.2-fedora-22 (misc) > > >> fedora/updates-testing (python-gssapi 1.1.2) > > >> > > >> Ludwig's copr is necessary to have a functional DNA plugin in replicas, > > >> eventually his patches should be committed in 389-ds-base 1.3.4.4 when > > >> it will be released. > > >> > > >> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > > >> that may cause installation issues in some case (re-install of a > > >> replica). > > >> > > >> The domain must be raised to level 1 in order to use replica promotion. > > >> > > >> In order to promote a replica the server must be first joined as a > > >> regular client to the domain. > > >> > > >> This is the flow I usually use for testing: > > >> > > >> # ipa-client-install > > >> # kinit admin > > >> # ipa-replica-install --promote --setup-ca > > >> > >> etc...> > > >> > > >> These patches are also available in this git tree rebnase on current > > >> master: > > >> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > > > > > FYI: I rebased this branch on top of master and applied minor changes to > > > one of the DNS patches. I also added the missing support to install KRA. > > > > > > DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not > > > needed anymore. > > > > > > Dogtag's ticket is not fixed yet so running both --setup-ca and > > > --setup-kra at the same time will still yield an error and install will > > > fail. > > > > > > Please let me know if there are any major issues with this patchset, I'd > > > like to push it to master and attack the remaining issues as add ons > > > (install with external certs not supported yet for example) > > > > So far I have only read through the code without running it (mostly). > > > > > > "Remove unused arguments": ACK > > > > > > "Simplify the install_replica_ca function": ACK > > Thanks for pushing these. > > > > > "IPA Custodia Daemon": > > > > 1) Instead of putting the code in "ipakeys" package, could you put it in > > "ipapython.keys"? This way it would be consistent with DNSSEC, which has > > binaries in daemons/dnssec/ and modules in ipapython/dnssec/. > > I think I can do this, it was originally all in daemon becuse that's > where I had the custodia submodules, but we do not carry a copy anymore. > > > 2) Is it safe to create cn=custodia in update file only? Updates are > > executed late in ipa-server-install. Is is guaranteed that nothing will > > try to access cn=custodia before the updates are run? > > > > (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) > > > > 3) Shouldn't cn=custodia be created only when domain level >= 1? > > It is used only at >= 1 level, but we have to create it when we update > the code, otherwise you cannot switch to level 1. > Switching a level ion LDAP cannot cause an update script to be run so > you would have incomplete servers publicizing level 1 but not offering a > critical service for level 1. > > > 4) pylint fails with: > > > > daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), > > IPAKEMKeys.__init__] Use of super on an old style class) > > daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), > > IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no > > 'config' member) > > daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), > > IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) > > On what pylint version ? > I had to disable pylint for a while but it currently runs and doesn't > complain to me ... pylint looks fine for everything I touched now. > > 5) There are some PEP8 transgressions: > > > > ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 > > > 79 characters) > > ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 > > > 79 characters) > > ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank > > lines, found 1 > > ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around > > keyword / parameter equals > > ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file > > I'll take care of these. > > "Add Custodia Client code": > > > > 1) Is there any significance in having this in a separate commit? I > > would think it can be safely squashed in the previous commit. > > Easier review (and rebasing), I want to keep chunks smaller. > > > 2) There is one PEP8 transgression: > > > > ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank lines (2) > > > > > > "Install ipa-custodia with the rest of ipa": > > > > 1) python-jwcrypto dependency is missing in the spec file. > > It shouldn't be necessary as custodia already depends on it. > > > 2) I believe the daemons/ipa-custodia/* and > > install/share/bootstrap-template.ldif should be in the "IPA Custodia > > Daemon" commit. At the very least it would make reviews easier. > > ok I ended up squashing together these first 3 commits, after looking more carefully into them they are less messy w/o submodules, and make sense to have all of them in a single unit. > > 3) There is one PEP8 transgressions: > > > > ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank > > lines, found 1 > > > > > > "Require a DS version that has working DNA plugin": ACK > > > > > > "Implement replica promotion functionality": > > > > 1) I think a RuntimeError or sys.exit with an error message would be > > better than NotImplementedError for the unimplemented options. > > > > (Nevermind, these are removed in further commits.) > > They were for my use indeed :) > > > 2) There is no domain level check when installing the replica from a > > replica file. > We discussed about preventing generation of a replica file at level 1, > but that is not part of this patchset. Will be added later. > > 3) Instead of returning INSTALL_ERROR from promote_check() (which has no > > effect), raise an exception or call sys.exit(). > > ok > > > 4) The --promote option is redundant. You can safely decide whether to > > promote or not based on whether replica file was provided or not and the > > domain level of the remote server. > > Except there is a chick/egg issue in getting there, I am ok removing > --promote in a followup patch, but not changing it in this patchset, it > would require too much churn. To be more precise we need to check that we are level 1 to be able to do promotion but we'll discover what level we are only after we can talk to the master. Should we assume level 1 if someone try to run ipa-replica-install on a client that is already joined ? I guess this can be done, and then we can fail later if it turns out the domain is not at level 1 just yet, what do you think ? Should I consider it enough that /et/cipa/defualt.conf is present to assume --promote ? > > 5) There are some PEP8 transgressions: > > > > ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace after ',' > > ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace after ',' > > ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace after ',' > > ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' > > ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 > > characters) > > ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 > > characters) > > ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) > > ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank lines, > > found 1 > > ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > 79 > > characters) > > ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > 79 > > characters) > > ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > 79 > > characters) > > ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 > > blank lines, found 1 > > ./ipaserver/install/server/replicainstall.py:862:25: E128 continuation > > line under-indented for visual indent > > ./ipaserver/install/server/replicainstall.py:864:25: E128 continuation > > line under-indented for visual indent > > ./ipaserver/install/server/replicainstall.py:865:25: E128 continuation > > line under-indented for visual indent > > ./ipaserver/install/server/replicainstall.py:1014:13: E128 continuation > > line under-indented for visual indent > > ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing > > whitespace after ',' > > ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many blank > > lines (2) > > > > > > "Change DNS installer code to use passed in api": LGTM > > > > > > "Allow ipa-replica-conncheck to use default creds": LGTM > > > > > > "Add function to extract CA certs for install": LGTM > > > > > > "Allow to setup the CA when promoting a replica": > > > > 1) There are some PEP8 transgressions: > > > > ./ipaserver/install/ca.py:35:13: E125 continuation line with same indent > > as next logical line > > ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) > > ./ipaserver/install/replication.py:421:24: E231 missing whitespace after ',' > > ./ipaserver/install/replication.py:421:35: E231 missing whitespace after ',' > > ./ipaserver/install/replication.py:421:41: E231 missing whitespace after ',' > > ./ipaserver/install/replication.py:422:24: E231 missing whitespace after ',' > > ./ipaserver/install/replication.py:422:40: E231 missing whitespace after ',' > > ./ipaserver/install/replication.py:422:46: E231 missing whitespace after ',' > > ./ipaserver/install/replication.py:524:37: E128 continuation line > > under-indented for visual indent > > ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' > > ./ipaserver/install/replication.py:524:80: E501 line too long (187 > 79 > > characters) > > ./ipaserver/install/replication.py:526:80: E501 line too long (106 > 79 > > characters) > > ./ipaserver/install/replication.py:560:80: E501 line too long (86 > 79 > > characters) > > ./ipaserver/install/replication.py:847:80: E501 line too long (81 > 79 > > characters) > > ./ipaserver/install/replication.py:850:80: E501 line too long (89 > 79 > > characters) > > ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > 79 > > characters) > > ./ipaserver/install/replication.py:1766:17: E128 continuation line > > under-indented for visual indent > > ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > 79 > > characters) > > > > > > "Make checks for existing credentials reusable": > > > > 1) There are some PEP8 transgressions: > > > > ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank lines, > > found 1 > > ./ipaserver/install/installutils.py:1192:25: E128 continuation line > > under-indented for visual indent > > ./ipaserver/install/installutils.py:1194:25: E128 continuation line > > under-indented for visual indent > > ./ipaserver/install/installutils.py:1195:25: E128 continuation line > > under-indented for visual indent > > > > > > "Allow ipa-ca-install to use the new promotion code": > > > > 1) The --replica option is redundant. You can safely decide whether this > > is the first CA master or not based on information in cn=masters. > > > > 2) There are some PEP8 transgressions: > > > > ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace after ',' > > ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace after ',' > > > > > > "Remove unused kra option": ACK > > > > > > "Allow to install the KRA on a promoted server": > > > > 1) There are some PEP8 transgressions: > > > > ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line > > over-indented for visual indent > > ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, > > found 1 > > ./ipaserver/install/krainstance.py:382:13: E128 continuation line > > under-indented for visual indent > > ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing > > whitespace around operator > > ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many blank > > lines (2) > > ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, found 1 > > ./ipaserver/install/service.py:115:52: E203 whitespace before ',' > > I also pep8ed every single patch. "git show -U0 | pep8 --diff" is awesome :) > > > > Pushed first 2 commits to master: d8b1f42f171d666068583548315b4684e5f3c3a4 > > Ok, I'll rework the patches as possible, do you want a new patchset sent > to the list ? Or is it ok to rebnase the custodia-review branch in my > freeipa.git tree ? For now I simply updated my custodia-review branch, let me know if you want a patch-bomb to the list too. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed Sep 23 05:21:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 07:21:37 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1442935415.4697.149.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <1442935415.4697.149.camel@willson.usersys.redhat.com> Message-ID: <560236E1.8090405@redhat.com> On 22.9.2015 17:23, Simo Sorce wrote: > On Tue, 2015-09-22 at 10:45 +0200, Jan Cholasta wrote: >> 4) pylint fails with: >> >> daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), >> IPAKEMKeys.__init__] Use of super on an old style class) >> daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), >> IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no >> 'config' member) >> daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), >> IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' >> member) > > I do not know why pylint gives you these errors. > The top level class for IPAKEMKeys is is ultimatile the custodia class > called HTTPAuthorizer which is defined as a new-style class (derives > from object), that class also unconditionally inits config. > Maybe you ran pylint w/o custodia installed ? Yes, that was it. Sorry. -- Jan Cholasta From jcholast at redhat.com Wed Sep 23 06:35:52 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 08:35:52 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1442969233.4697.208.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <1442933847.4697.147.camel@willson.usersys.redhat.com> <1442969233.4697.208.camel@willson.usersys.redhat.com> Message-ID: <56024848.3030005@redhat.com> On 23.9.2015 02:47, Simo Sorce wrote: > On Tue, 2015-09-22 at 10:57 -0400, Simo Sorce wrote: >> On Tue, 2015-09-22 at 10:45 +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 9.9.2015 20:25, Simo Sorce wrote: >>>> On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: >>>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>>>> and introduces a number of required changes and dependencies to achieve >>>>> this goal. >>>>> This work requires the custodia project to securely transfer keys >>>>> between ipa servers. >>>>> >>>>> This work is not 100% complete, it still misses the ability to install >>>>> kra instances and the ability to install a CA (via ipa-ca-install) with >>>>> externally signed certs. >>>>> >>>>> However it is massive enough that warrants review and pushing, the resat >>>>> of the changes can be applied later as this work should not disrupt the >>>>> classic install methods. >>>>> >>>>> In order to build my previous patches (530-533) are needed as well as a >>>>> number of updated components. >>>>> >>>>> I used the following coprs for testing: >>>>> simo/jwcrypto >>>>> simo/custodia >>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>>> fedora/updates-testing (python-gssapi 1.1.2) >>>>> >>>>> Ludwig's copr is necessary to have a functional DNA plugin in replicas, >>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>>>> it will be released. >>>>> >>>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>>>> that may cause installation issues in some case (re-install of a >>>>> replica). >>>>> >>>>> The domain must be raised to level 1 in order to use replica promotion. >>>>> >>>>> In order to promote a replica the server must be first joined as a >>>>> regular client to the domain. >>>>> >>>>> This is the flow I usually use for testing: >>>>> >>>>> # ipa-client-install >>>>> # kinit admin >>>>> # ipa-replica-install --promote --setup-ca >>>>> >>>> etc...> >>>>> >>>>> These patches are also available in this git tree rebnase on current >>>>> master: >>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>> >>>> FYI: I rebased this branch on top of master and applied minor changes to >>>> one of the DNS patches. I also added the missing support to install KRA. >>>> >>>> DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not >>>> needed anymore. >>>> >>>> Dogtag's ticket is not fixed yet so running both --setup-ca and >>>> --setup-kra at the same time will still yield an error and install will >>>> fail. >>>> >>>> Please let me know if there are any major issues with this patchset, I'd >>>> like to push it to master and attack the remaining issues as add ons >>>> (install with external certs not supported yet for example) >>> >>> So far I have only read through the code without running it (mostly). >>> >>> >>> "Remove unused arguments": ACK >>> >>> >>> "Simplify the install_replica_ca function": ACK >> >> Thanks for pushing these. >> >>> >>> "IPA Custodia Daemon": >>> >>> 1) Instead of putting the code in "ipakeys" package, could you put it in >>> "ipapython.keys"? This way it would be consistent with DNSSEC, which has >>> binaries in daemons/dnssec/ and modules in ipapython/dnssec/. >> >> I think I can do this, it was originally all in daemon becuse that's >> where I had the custodia submodules, but we do not carry a copy anymore. >> >>> 2) Is it safe to create cn=custodia in update file only? Updates are >>> executed late in ipa-server-install. Is is guaranteed that nothing will >>> try to access cn=custodia before the updates are run? >>> >>> (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) >>> >>> 3) Shouldn't cn=custodia be created only when domain level >= 1? >> >> It is used only at >= 1 level, but we have to create it when we update >> the code, otherwise you cannot switch to level 1. >> Switching a level ion LDAP cannot cause an update script to be run so >> you would have incomplete servers publicizing level 1 but not offering a >> critical service for level 1. Makes sense, thanks. >> >>> 4) pylint fails with: >>> >>> daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), >>> IPAKEMKeys.__init__] Use of super on an old style class) >>> daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), >>> IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no >>> 'config' member) >>> daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), >>> IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) >> >> On what pylint version ? >> I had to disable pylint for a while but it currently runs and doesn't >> complain to me ... > > pylint looks fine for everything I touched now. As I said in the other thread, this is without custodia installed, so just ignore it. > >>> 5) There are some PEP8 transgressions: >>> >>> ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 > >>> 79 characters) >>> ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 > >>> 79 characters) >>> ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank >>> lines, found 1 >>> ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file >> >> I'll take care of these. > >>> "Add Custodia Client code": >>> >>> 1) Is there any significance in having this in a separate commit? I >>> would think it can be safely squashed in the previous commit. >> >> Easier review (and rebasing), I want to keep chunks smaller. >> >>> 2) There is one PEP8 transgression: >>> >>> ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank lines (2) >>> >>> >>> "Install ipa-custodia with the rest of ipa": >>> >>> 1) python-jwcrypto dependency is missing in the spec file. >> >> It shouldn't be necessary as custodia already depends on it. IMO it is a good practice to require all direct dependencies, because you can't control indirect dependencies. For example, if one day custodia switched from jwcrypto to something different, ipa would lose the jwcrypto dependency without us knowing. >> >>> 2) I believe the daemons/ipa-custodia/* and >>> install/share/bootstrap-template.ldif should be in the "IPA Custodia >>> Daemon" commit. At the very least it would make reviews easier. >> >> ok > > I ended up squashing together these first 3 commits, after looking more > carefully into them they are less messy w/o submodules, and make sense > to have all of them in a single unit. OK. > >>> 3) There is one PEP8 transgressions: >>> >>> ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank >>> lines, found 1 >>> >>> >>> "Require a DS version that has working DNA plugin": ACK >>> >>> >>> "Implement replica promotion functionality": >>> >>> 1) I think a RuntimeError or sys.exit with an error message would be >>> better than NotImplementedError for the unimplemented options. >>> >>> (Nevermind, these are removed in further commits.) >> >> They were for my use indeed :) >> >>> 2) There is no domain level check when installing the replica from a >>> replica file. > >> We discussed about preventing generation of a replica file at level 1, >> but that is not part of this patchset. > > Will be added later. What I mean is that installing a replica using an already existing replica file should be prevented at level 1 as well: root at ipa1# ipa-server-install --domain-level=0 root at ipa1# ipa-replica-prepare ipa2.example.com root at ipa1# ipa domainlevel-set 1 root at ipa2# ipa-replica-install replica-info-ipa2.example.com.gpg ERROR: Can't install replica from a replica file at domain level > 0 > > >>> 3) Instead of returning INSTALL_ERROR from promote_check() (which has no >>> effect), raise an exception or call sys.exit(). >> >> ok >> >>> 4) The --promote option is redundant. You can safely decide whether to >>> promote or not based on whether replica file was provided or not and the >>> domain level of the remote server. >> >> Except there is a chick/egg issue in getting there, I am ok removing >> --promote in a followup patch, but not changing it in this patchset, it >> would require too much churn. OK, no problem. > > To be more precise we need to check that we are level 1 to be able to do > promotion but we'll discover what level we are only after we can talk to > the master. > > Should we assume level 1 if someone try to run ipa-replica-install on a > client that is already joined ? > I guess this can be done, and then we can fail later if it turns out the > domain is not at level 1 just yet, what do you think ? > Should I consider it enough that /et/cipa/defualt.conf is present to > assume --promote ? I think it should be good enough to assume promotion if replica file is not provided, and check domain level later when we can connect to the remote server: if replica file provided: # assume domain level == 0 # we can connect to the remote server using info from the replica file connect to the remote server if domain level != 0: fail install replica using the replica file else: # assume domain level > 0 if client not installed: install client # we can connect to the remote server when client is installed connect to remote server if domain level == 0: if client installed by us: uninstall client fail install replica using promotion > >>> 5) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace after ',' >>> ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace after ',' >>> ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace after ',' >>> ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' >>> ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 >>> characters) >>> ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 >>> characters) >>> ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) >>> ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank lines, >>> found 1 >>> ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > 79 >>> characters) >>> ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > 79 >>> characters) >>> ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > 79 >>> characters) >>> ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 >>> blank lines, found 1 >>> ./ipaserver/install/server/replicainstall.py:862:25: E128 continuation >>> line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:864:25: E128 continuation >>> line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:865:25: E128 continuation >>> line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:1014:13: E128 continuation >>> line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing >>> whitespace after ',' >>> ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many blank >>> lines (2) >>> >>> >>> "Change DNS installer code to use passed in api": LGTM >>> >>> >>> "Allow ipa-replica-conncheck to use default creds": LGTM >>> >>> >>> "Add function to extract CA certs for install": LGTM >>> >>> >>> "Allow to setup the CA when promoting a replica": >>> >>> 1) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/ca.py:35:13: E125 continuation line with same indent >>> as next logical line >>> ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) >>> ./ipaserver/install/replication.py:421:24: E231 missing whitespace after ',' >>> ./ipaserver/install/replication.py:421:35: E231 missing whitespace after ',' >>> ./ipaserver/install/replication.py:421:41: E231 missing whitespace after ',' >>> ./ipaserver/install/replication.py:422:24: E231 missing whitespace after ',' >>> ./ipaserver/install/replication.py:422:40: E231 missing whitespace after ',' >>> ./ipaserver/install/replication.py:422:46: E231 missing whitespace after ',' >>> ./ipaserver/install/replication.py:524:37: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' >>> ./ipaserver/install/replication.py:524:80: E501 line too long (187 > 79 >>> characters) >>> ./ipaserver/install/replication.py:526:80: E501 line too long (106 > 79 >>> characters) >>> ./ipaserver/install/replication.py:560:80: E501 line too long (86 > 79 >>> characters) >>> ./ipaserver/install/replication.py:847:80: E501 line too long (81 > 79 >>> characters) >>> ./ipaserver/install/replication.py:850:80: E501 line too long (89 > 79 >>> characters) >>> ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > 79 >>> characters) >>> ./ipaserver/install/replication.py:1766:17: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > 79 >>> characters) >>> >>> >>> "Make checks for existing credentials reusable": >>> >>> 1) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank lines, >>> found 1 >>> ./ipaserver/install/installutils.py:1192:25: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/installutils.py:1194:25: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/installutils.py:1195:25: E128 continuation line >>> under-indented for visual indent >>> >>> >>> "Allow ipa-ca-install to use the new promotion code": >>> >>> 1) The --replica option is redundant. You can safely decide whether this >>> is the first CA master or not based on information in cn=masters. >>> >>> 2) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace after ',' >>> ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace after ',' >>> >>> >>> "Remove unused kra option": ACK >>> >>> >>> "Allow to install the KRA on a promoted server": >>> >>> 1) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line >>> over-indented for visual indent >>> ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, >>> found 1 >>> ./ipaserver/install/krainstance.py:382:13: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing >>> whitespace around operator >>> ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many blank >>> lines (2) >>> ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, found 1 >>> ./ipaserver/install/service.py:115:52: E203 whitespace before ',' >>> > > I also pep8ed every single patch. > "git show -U0 | pep8 --diff" is awesome :) Thanks. That's exactly what I used :-) > >>> >>> Pushed first 2 commits to master: d8b1f42f171d666068583548315b4684e5f3c3a4 >> >> Ok, I'll rework the patches as possible, do you want a new patchset sent >> to the list ? Or is it ok to rebnase the custodia-review branch in my >> freeipa.git tree ? > > For now I simply updated my custodia-review branch, let me know if you > want a patch-bomb to the list too. Git is fine. > > Simo. > -- Jan Cholasta From pspacek at redhat.com Wed Sep 23 07:13:38 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Sep 2015 09:13:38 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <5601146A.1000905@redhat.com> References: <5601146A.1000905@redhat.com> Message-ID: <56025122.8090203@redhat.com> On 22.9.2015 10:42, Oleg Fayans wrote: > +++ b/ipatests/test_integration/tasks.py > @@ -58,6 +58,14 @@ def check_arguments_are(slice, instanceof): > return wrapped > return wrapper > > +def prepare_reverse_zone(host, ip): > + nums = ip.split('.')[:-1] > + zone = ".".join(reversed(nums)) + ".in-addr.arpa." > + host.run_command(["ipa", > + "dnszone-add", > + zone, > + "--name-from-ip=%s" % ip], raiseonerr=False) > + NACK: - this will break IPv6-only hosts - you should use DNSName class or other functions from python-dns for DNS name manipulation I hope this helps. -- Petr^2 Spacek From pspacek at redhat.com Wed Sep 23 07:18:23 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Sep 2015 09:18:23 +0200 Subject: [Freeipa-devel] [PATCH] improved logging in dnssec tests In-Reply-To: <56011D9D.6010408@redhat.com> References: <56011D9D.6010408@redhat.com> Message-ID: <5602523F.5050607@redhat.com> On 22.9.2015 11:21, Oleg Fayans wrote: > Hi all, > > I've noticed that in some tests some low-level functions can return False in a > number of different conditions, which severely complicates test debugging. > This patch implements the approach widely used in the Go language (and maybe, > some other): The function returns not only a boolean, but a boolean plus any > error message caught during the execution. This error message may be used by > the higher level code for logging. For example, compare these outputs: > 1. AssertionError: Zone example.test. is not signed (master): request timed out > 2. AssertionError: Zone example.test. is not signed (master) > > What do you think? I'm not against this patch in principle but honestly, it seems as waste of time to me. E.g. a timeout can be caused by several different problems (LDAP down, KDC down, named down, firewall ...), the fact that the zone is not signed can be caused by different problems (time skew between replica and master, one of dnssec helpers does not work, LDAP replication is broken ...), and the error you are going to display can be very misleading. In all cases you have to try it using dig or drill and read logs to see what happened and why. (I did not test the patch because it would take too much time I do not have now.) -- Petr^2 Spacek From jcholast at redhat.com Wed Sep 23 08:54:15 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 10:54:15 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <1442967767.4697.201.camel@willson.usersys.redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> Message-ID: <560268B7.9070603@redhat.com> On 23.9.2015 02:22, Simo Sorce wrote: > On Tue, 2015-09-22 at 20:09 -0400, Simo Sorce wrote: >> On Tue, 2015-09-22 at 16:35 +0200, Jan Cholasta wrote: >>> On 22.9.2015 15:11, Martin Babinsky wrote: >>>> On 09/22/2015 01:33 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes . >>>>> >>>>> Honza >>>>> >>>>> >>>>> >>>> ACK >>>> >>> >>> Thanks. >>> >>> Pushed to: >>> master: 0de860318332114ca739a8dd45902f7cc9a3c722 >>> ipa-4-2: 4663625bbb3456db7f13578e6cac0c3e5fae2591 >> >> This patch is somehow broken. >> >> I see that %{kdcproxy_home} has been removed from the spec file but not >> from everywhere, and it is simply undefined. >> >> On upgrade of my server I have no kdcproxy user and http fails to >> operate complaining that /var/lib/kdcproxy does not exist. > > Correction, the HTTP server works, but it spits lots of errors in > error_log about /var/lib/kdcproxy not existing. > > Is the KDCProxy supposed to be installked/enabled on upgrade ? > If not, why not ? > Even if it is not enabled, shouldn't the user be created just in case ? Fixed, patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-495-install-fix-kdcproxy-user-home-directory.patch Type: text/x-patch Size: 2429 bytes Desc: not available URL: From cheimes at redhat.com Wed Sep 23 09:44:10 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 23 Sep 2015 11:44:10 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <560268B7.9070603@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> <560268B7.9070603@redhat.com> Message-ID: <5602746A.60806@redhat.com> On 2015-09-23 10:54, Jan Cholasta wrote: >> Correction, the HTTP server works, but it spits lots of errors in >> error_log about /var/lib/kdcproxy not existing. >> >> Is the KDCProxy supposed to be installked/enabled on upgrade ? >> If not, why not ? >> Even if it is not enabled, shouldn't the user be created just in case ? > > Fixed, patch attached. I haven't tested the patch yet. It looks like the kdcproxy user doesn't own its home directory. Please chown /var/lib/kdcproxy. 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 jcholast at redhat.com Wed Sep 23 10:40:44 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 12:40:44 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <5602746A.60806@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> <560268B7.9070603@redhat.com> <5602746A.60806@redhat.com> Message-ID: <560281AC.2040104@redhat.com> On 23.9.2015 11:44, Christian Heimes wrote: > On 2015-09-23 10:54, Jan Cholasta wrote: >>> Correction, the HTTP server works, but it spits lots of errors in >>> error_log about /var/lib/kdcproxy not existing. >>> >>> Is the KDCProxy supposed to be installked/enabled on upgrade ? >>> If not, why not ? >>> Even if it is not enabled, shouldn't the user be created just in case ? >> >> Fixed, patch attached. > > I haven't tested the patch yet. It looks like the kdcproxy user doesn't > own its home directory. Please chown /var/lib/kdcproxy. I can't chown it because the user may not exist at RPM install time. It doesn't matter anyway, since nothing is ever stored in the directory and KDC proxy works just fine. The same thing is done for the DS user and nobody complained so far, so I assumed it should be OK for KDC proxy as well. -- Jan Cholasta From cheimes at redhat.com Wed Sep 23 10:49:06 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 23 Sep 2015 12:49:06 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <560281AC.2040104@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> <560268B7.9070603@redhat.com> <5602746A.60806@redhat.com> <560281AC.2040104@redhat.com> Message-ID: <560283A2.3000707@redhat.com> On 2015-09-23 12:40, Jan Cholasta wrote: > On 23.9.2015 11:44, Christian Heimes wrote: >> On 2015-09-23 10:54, Jan Cholasta wrote: >>>> Correction, the HTTP server works, but it spits lots of errors in >>>> error_log about /var/lib/kdcproxy not existing. >>>> >>>> Is the KDCProxy supposed to be installked/enabled on upgrade ? >>>> If not, why not ? >>>> Even if it is not enabled, shouldn't the user be created just in case ? >>> >>> Fixed, patch attached. >> >> I haven't tested the patch yet. It looks like the kdcproxy user doesn't >> own its home directory. Please chown /var/lib/kdcproxy. > > I can't chown it because the user may not exist at RPM install time. It > doesn't matter anyway, since nothing is ever stored in the directory and > KDC proxy works just fine. The same thing is done for the DS user and > nobody complained so far, so I assumed it should be OK for KDC proxy as > well. I think we have a slight misunderstanding here. :) Of course you can't set the owner at RPM install time. I wasn't talking about chown-ing the directory in RPM, but chown-ing the directory after or inside the tasks.create_system_user() call. Sorry for the confusion! AFAIK neither mod_wsgi nor python-kdcproxy need a writeable home directory. It's not guaranteed for eternity, though. 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 mbabinsk at redhat.com Wed Sep 23 10:53:48 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 23 Sep 2015 12:53:48 +0200 Subject: [Freeipa-devel] [PATCH 0065] CI test for IPA install/backup/uninstall/install/restore scenario Message-ID: <560284BC.7050300@redhat.com> Should help to catch bugs like https://fedorahosted.org/freeipa/ticket/5296 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0065-CI-test-for-full-IPA-restore-into-a-running-IPA-serv.patch Type: text/x-patch Size: 2147 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Sep 23 11:01:19 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 23 Sep 2015 13:01:19 +0200 Subject: [Freeipa-devel] [PATCH 0065] CI test for IPA install/backup/uninstall/install/restore scenario In-Reply-To: <560284BC.7050300@redhat.com> References: <560284BC.7050300@redhat.com> Message-ID: <5602867F.50904@redhat.com> On 09/23/2015 12:53 PM, Martin Babinsky wrote: > CI test for full IPA restore into a running IPA server self-NACK -- Martin^3 Babinsky From mbasti at redhat.com Wed Sep 23 11:04:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Sep 2015 13:04:56 +0200 Subject: [Freeipa-devel] [PATCH 0064] destroy httpd ccache after stopping the service In-Reply-To: <56013F29.5040303@redhat.com> References: <56013F29.5040303@redhat.com> Message-ID: <56028758.60503@redhat.com> On 09/22/2015 01:44 PM, Martin Babinsky wrote: > This patch fixes https://fedorahosted.org/freeipa/ticket/5296 and > generally makes cleaning up of httpd ccache more thorough. > > > ACK Pushed to: master: 93d080d726359db16749104c8bc20d14a5455dc0 ipa-4-2: 23f1d4ed605f9f4b22d6ad93c4110fff7358682c -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Sep 23 11:20:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Sep 2015 13:20:19 +0200 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page In-Reply-To: References: <56010081.4020205@redhat.com> Message-ID: <56028AF3.709@redhat.com> On 09/22/2015 03:32 PM, Gabe Alford wrote: > create mode 100644 install/tools/man/freeipa-rga-0055-dnssec-options-missing-in-ipa-dns-install-man-page.patch Hello, your patch created new patch :-) Also there were 3 white space errors, please remove them. Martin From jcholast at redhat.com Wed Sep 23 11:37:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 13:37:17 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <560283A2.3000707@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> <560268B7.9070603@redhat.com> <5602746A.60806@redhat.com> <560281AC.2040104@redhat.com> <560283A2.3000707@redhat.com> Message-ID: <56028EED.2040101@redhat.com> On 23.9.2015 12:49, Christian Heimes wrote: > On 2015-09-23 12:40, Jan Cholasta wrote: >> On 23.9.2015 11:44, Christian Heimes wrote: >>> On 2015-09-23 10:54, Jan Cholasta wrote: >>>>> Correction, the HTTP server works, but it spits lots of errors in >>>>> error_log about /var/lib/kdcproxy not existing. >>>>> >>>>> Is the KDCProxy supposed to be installked/enabled on upgrade ? >>>>> If not, why not ? >>>>> Even if it is not enabled, shouldn't the user be created just in case ? >>>> >>>> Fixed, patch attached. >>> >>> I haven't tested the patch yet. It looks like the kdcproxy user doesn't >>> own its home directory. Please chown /var/lib/kdcproxy. >> >> I can't chown it because the user may not exist at RPM install time. It >> doesn't matter anyway, since nothing is ever stored in the directory and >> KDC proxy works just fine. The same thing is done for the DS user and >> nobody complained so far, so I assumed it should be OK for KDC proxy as >> well. > > I think we have a slight misunderstanding here. :) Of course you can't > set the owner at RPM install time. I wasn't talking about chown-ing the > directory in RPM, but chown-ing the directory after or inside the > tasks.create_system_user() call. Sorry for the confusion! > > AFAIK neither mod_wsgi nor python-kdcproxy need a writeable home > directory. It's not guaranteed for eternity, though. OK. Updated patch attached. Added patch 496, please apply before 495. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-496-platform-add-option-to-create-home-directory-when-ad.patch Type: text/x-patch Size: 2454 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-495.1-install-fix-kdcproxy-user-home-directory.patch Type: text/x-patch Size: 2446 bytes Desc: not available URL: From tbabej at redhat.com Wed Sep 23 11:39:28 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 23 Sep 2015 13:39:28 +0200 Subject: [Freeipa-devel] [PATCHES 0370-0371] winsync-migrate: Handle invalid characters in the names of IPA entities Message-ID: <56028F70.6060008@redhat.com> Hi, this fixes https://fedorahosted.org/freeipa/ticket/5319. Details in the commit messages. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0370-winsync-migrate-Convert-entity-names-to-posix-friend.patch Type: text/x-patch Size: 3973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0371-winsync-migrate-Properly-handle-collisions-in-the-na.patch Type: text/x-patch Size: 2334 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 23 12:40:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Sep 2015 14:40:29 +0200 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <56014858.4020100@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> <56014858.4020100@redhat.com> Message-ID: <56029DBD.9040403@redhat.com> On 09/22/2015 02:23 PM, Tomas Babej wrote: > On 09/03/2015 04:34 PM, Alexander Bokovoy wrote: >> On Thu, 03 Sep 2015, Tomas Babej wrote: >>> Hi, >>> >>> this couple of patches fix https://fedorahosted.org/freeipa/ticket/5278 >>> and improve our handling of realmdomains in general. >> The code looks good to me. I haven't tested it yet, though. >> > Rebased on top of current master. Please fix tests too. [root at vm-065 ~]# ipa-run-tests test_xmlrpc/test_realmdomains_plugin.py --verbose =============================================================================================== test session starts =============================================================================================== platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 -- /usr/bin/python plugins: multihost, sourceorder collected 13 items test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0000: realmdomains_show: Retrieve realm domains] PASSED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0001: realmdomains_show: Retrieve realm domains - print all attributes] PASSED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0002: realmdomains_mod: Replace list of realm domains with "[u'abc.idm.lab.eng.brq.redhat.com', u'example1.com']"] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0003: realmdomains_mod: Add domain "example2.com" to list] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0004: realmdomains_mod: Delete domain "example2.com" from list] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0005: realmdomains_mod: Add domain "example2.com" and delete domain "example1.com"] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0006: realmdomains_mod: Try to specify --domain and --add-domain options together] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0007: realmdomains_mod: Try to replace list of realm domains with a list without our domain] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0008: realmdomains_mod: Try to replace list of realm domains with a list with an invalid domain "doesnotexist.test"] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0009: realmdomains_mod: Try to add an invalid domain "doesnotexist.test"] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0010: realmdomains_mod: Try to delete our domain] FAILED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0011: realmdomains_mod: Try to delete domain which is not in list] PASSED test_xmlrpc/test_realmdomains_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_realmdomains::test_command[0012: realmdomains_mod: Add an invalid domain "doesnotexist.test" with --force option] FAILED From redhatrises at gmail.com Wed Sep 23 13:12:31 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 23 Sep 2015 07:12:31 -0600 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page In-Reply-To: <56028AF3.709@redhat.com> References: <56010081.4020205@redhat.com> <56028AF3.709@redhat.com> Message-ID: Odd and done. Updated patch attached. Gabe On Wed, Sep 23, 2015 at 5:20 AM, Martin Basti wrote: > > > On 09/22/2015 03:32 PM, Gabe Alford wrote: > >> create mode 100644 >> install/tools/man/freeipa-rga-0055-dnssec-options-missing-in-ipa-dns-install-man-page.patch >> > Hello, > > your patch created new patch :-) > > Also there were 3 white space errors, please remove them. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0055-3-dnssec-option-missing-in-ipa-dns-install-man-page.patch Type: text/x-patch Size: 2048 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 23 13:14:52 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Sep 2015 15:14:52 +0200 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page In-Reply-To: References: <56010081.4020205@redhat.com> <56028AF3.709@redhat.com> Message-ID: <5602A5CC.2040403@redhat.com> On 09/23/2015 03:12 PM, Gabe Alford wrote: > Odd and done. Updated patch attached. > > Gabe > > On Wed, Sep 23, 2015 at 5:20 AM, Martin Basti > wrote: > > > > On 09/22/2015 03:32 PM, Gabe Alford wrote: > > create mode 100644 > install/tools/man/freeipa-rga-0055-dnssec-options-missing-in-ipa-dns-install-man-page.patch > > Hello, > > your patch created new patch :-) > > Also there were 3 white space errors, please remove them. > > Martin > > Thank you, but there is still missing update in ipa-server-install manpage Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed Sep 23 13:36:48 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 23 Sep 2015 07:36:48 -0600 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page In-Reply-To: <5602A5CC.2040403@redhat.com> References: <56010081.4020205@redhat.com> <56028AF3.709@redhat.com> <5602A5CC.2040403@redhat.com> Message-ID: Thanks. Updated patch attached. On Wed, Sep 23, 2015 at 7:14 AM, Martin Basti wrote: > > > On 09/23/2015 03:12 PM, Gabe Alford wrote: > > Odd and done. Updated patch attached. > > Gabe > > On Wed, Sep 23, 2015 at 5:20 AM, Martin Basti wrote: > >> >> >> On 09/22/2015 03:32 PM, Gabe Alford wrote: >> >>> create mode 100644 >>> install/tools/man/freeipa-rga-0055-dnssec-options-missing-in-ipa-dns-install-man-page.patch >>> >> Hello, >> >> your patch created new patch :-) >> >> Also there were 3 white space errors, please remove them. >> >> Martin >> > > Thank you, but there is still missing update in ipa-server-install manpage > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0055-4-dnssec-option-missing-in-ipa-dns-install-man-page.patch Type: text/x-patch Size: 2668 bytes Desc: not available URL: From simo at redhat.com Wed Sep 23 13:37:04 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Sep 2015 09:37:04 -0400 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <56028EED.2040101@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> <560268B7.9070603@redhat.com> <5602746A.60806@redhat.com> <560281AC.2040104@redhat.com> <560283A2.3000707@redhat.com> <56028EED.2040101@redhat.com> Message-ID: <1443015424.3593.13.camel@willson.usersys.redhat.com> On Wed, 2015-09-23 at 13:37 +0200, Jan Cholasta wrote: > On 23.9.2015 12:49, Christian Heimes wrote: > > On 2015-09-23 12:40, Jan Cholasta wrote: > >> On 23.9.2015 11:44, Christian Heimes wrote: > >>> On 2015-09-23 10:54, Jan Cholasta wrote: > >>>>> Correction, the HTTP server works, but it spits lots of errors in > >>>>> error_log about /var/lib/kdcproxy not existing. > >>>>> > >>>>> Is the KDCProxy supposed to be installked/enabled on upgrade ? > >>>>> If not, why not ? > >>>>> Even if it is not enabled, shouldn't the user be created just in case ? > >>>> > >>>> Fixed, patch attached. > >>> > >>> I haven't tested the patch yet. It looks like the kdcproxy user doesn't > >>> own its home directory. Please chown /var/lib/kdcproxy. > >> > >> I can't chown it because the user may not exist at RPM install time. It > >> doesn't matter anyway, since nothing is ever stored in the directory and > >> KDC proxy works just fine. The same thing is done for the DS user and > >> nobody complained so far, so I assumed it should be OK for KDC proxy as > >> well. > > > > I think we have a slight misunderstanding here. :) Of course you can't > > set the owner at RPM install time. I wasn't talking about chown-ing the > > directory in RPM, but chown-ing the directory after or inside the > > tasks.create_system_user() call. Sorry for the confusion! > > > > AFAIK neither mod_wsgi nor python-kdcproxy need a writeable home > > directory. It's not guaranteed for eternity, though. > > OK. Updated patch attached. Added patch 496, please apply before 495. We have 2 options: 1. Home is created and chowned at user creation time 2. Home is owned by RPM packages. The option we do *not* have is to have RPM own the directory and then chown it later. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Wed Sep 23 14:25:32 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 23 Sep 2015 16:25:32 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <56028EED.2040101@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> <560268B7.9070603@redhat.com> <5602746A.60806@redhat.com> <560281AC.2040104@redhat.com> <560283A2.3000707@redhat.com> <56028EED.2040101@redhat.com> Message-ID: <5602B65C.1050603@redhat.com> On 09/23/2015 01:37 PM, Jan Cholasta wrote: > On 23.9.2015 12:49, Christian Heimes wrote: >> On 2015-09-23 12:40, Jan Cholasta wrote: >>> On 23.9.2015 11:44, Christian Heimes wrote: >>>> On 2015-09-23 10:54, Jan Cholasta wrote: >>>>>> Correction, the HTTP server works, but it spits lots of errors in >>>>>> error_log about /var/lib/kdcproxy not existing. >>>>>> >>>>>> Is the KDCProxy supposed to be installked/enabled on upgrade ? >>>>>> If not, why not ? >>>>>> Even if it is not enabled, shouldn't the user be created just in >>>>>> case ? >>>>> >>>>> Fixed, patch attached. >>>> >>>> I haven't tested the patch yet. It looks like the kdcproxy user doesn't >>>> own its home directory. Please chown /var/lib/kdcproxy. >>> >>> I can't chown it because the user may not exist at RPM install time. It >>> doesn't matter anyway, since nothing is ever stored in the directory and >>> KDC proxy works just fine. The same thing is done for the DS user and >>> nobody complained so far, so I assumed it should be OK for KDC proxy as >>> well. >> >> I think we have a slight misunderstanding here. :) Of course you can't >> set the owner at RPM install time. I wasn't talking about chown-ing the >> directory in RPM, but chown-ing the directory after or inside the >> tasks.create_system_user() call. Sorry for the confusion! >> >> AFAIK neither mod_wsgi nor python-kdcproxy need a writeable home >> directory. It's not guaranteed for eternity, though. > > OK. Updated patch attached. Added patch 496, please apply before 495. > > > ACK to both patches. -- Martin^3 Babinsky From jcholast at redhat.com Wed Sep 23 14:30:21 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 16:30:21 +0200 Subject: [Freeipa-devel] [PATCH 494] install: create kdcproxy user during server install In-Reply-To: <5602B65C.1050603@redhat.com> References: <56013C8B.3070402@redhat.com> <5601539D.1000903@redhat.com> <56016737.7020901@redhat.com> <1442966965.4697.199.camel@willson.usersys.redhat.com> <1442967767.4697.201.camel@willson.usersys.redhat.com> <560268B7.9070603@redhat.com> <5602746A.60806@redhat.com> <560281AC.2040104@redhat.com> <560283A2.3000707@redhat.com> <56028EED.2040101@redhat.com> <5602B65C.1050603@redhat.com> Message-ID: <5602B77D.3080105@redhat.com> On 23.9.2015 16:25, Martin Babinsky wrote: > On 09/23/2015 01:37 PM, Jan Cholasta wrote: >> On 23.9.2015 12:49, Christian Heimes wrote: >>> On 2015-09-23 12:40, Jan Cholasta wrote: >>>> On 23.9.2015 11:44, Christian Heimes wrote: >>>>> On 2015-09-23 10:54, Jan Cholasta wrote: >>>>>>> Correction, the HTTP server works, but it spits lots of errors in >>>>>>> error_log about /var/lib/kdcproxy not existing. >>>>>>> >>>>>>> Is the KDCProxy supposed to be installked/enabled on upgrade ? >>>>>>> If not, why not ? >>>>>>> Even if it is not enabled, shouldn't the user be created just in >>>>>>> case ? >>>>>> >>>>>> Fixed, patch attached. >>>>> >>>>> I haven't tested the patch yet. It looks like the kdcproxy user >>>>> doesn't >>>>> own its home directory. Please chown /var/lib/kdcproxy. >>>> >>>> I can't chown it because the user may not exist at RPM install time. It >>>> doesn't matter anyway, since nothing is ever stored in the directory >>>> and >>>> KDC proxy works just fine. The same thing is done for the DS user and >>>> nobody complained so far, so I assumed it should be OK for KDC proxy as >>>> well. >>> >>> I think we have a slight misunderstanding here. :) Of course you can't >>> set the owner at RPM install time. I wasn't talking about chown-ing the >>> directory in RPM, but chown-ing the directory after or inside the >>> tasks.create_system_user() call. Sorry for the confusion! >>> >>> AFAIK neither mod_wsgi nor python-kdcproxy need a writeable home >>> directory. It's not guaranteed for eternity, though. >> >> OK. Updated patch attached. Added patch 496, please apply before 495. >> >> >> > ACK to both patches. > Thanks. Pushed to: master: 4c39561261e79fe1cfdef916eafbcb9c204e77e8 ipa-4-2: 091b119580f7bbd534e7643e09fd33a85d8c010b -- Jan Cholasta From pviktori at redhat.com Wed Sep 23 14:46:35 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Sep 2015 16:46:35 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <560150B7.4060405@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> Message-ID: <5602BB4B.4060206@redhat.com> On 09/22/2015 02:59 PM, David Kupka wrote: > On 18/09/15 17:00, Petr Viktorin wrote: >> Hello, >> Here are more patches that bring IPA closer to Python 3 compatibility. >> >> >> >> > > Hi Petr, > thanks for another batch of Python 3 compatibility patches. > Unfortunately I hit a lot of pylint errors. Some of them are false > positives for sure. Could you please look at them, mark the false > positive with "pylint: disable=Exxxx" directive and fix the rest? > > http://fpaste.org/270090/92665414/ > Thanks. I'm actually having some trouble running pylint on an f23 machine; have you seen this error before? $ ./make-lint Traceback (most recent call last): File "./make-lint", line 280, in sys.exit(main()) File "./make-lint", line 251, in main linter.check(files) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 747, in check self._do_check(files_or_modules) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 869, in _do_check self.check_astroid_module(ast_node, walker, rawcheckers, tokencheckers) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 924, in check_astroid_module tokens = utils.tokenize_module(ast_node) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 137, in tokenize_module with module.stream() as stream: AttributeError: 'Module' object has no attribute 'stream' Anyway, I've ran pylint on f21. Updated patches attached. > And one nitpick, I believe that the plus signs are not needed. > >> - self.arabic_hello_utf8 = '\xd9\x85\xd9\x83\xd9\x8a\xd9\x84' + \ >> - '\xd8\xb9\x20\xd9\x85\xd8\xa7\xd9' + \ >> - '\x84\xd9\x91\xd8\xb3\xd9\x84\xd8\xa7' >> + self.arabic_hello_utf8 = (b'\xd9\x85\xd9\x83\xd9\x8a\xd9\x84' + >> + b'\xd8\xb9\x20\xd9\x85\xd8\xa7\xd9' + >> + >> b'\x84\xd9\x91\xd8\xb3\xd9\x84\xd8\xa7') No, but I don't think they hurt. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0713.2-ipap11helper-Port-to-Python-3.patch Type: text/x-patch Size: 16522 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0714.2-rpc-Don-t-use-undocumented-urllib-functions.patch Type: text/x-patch Size: 1284 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0715.2-ipapython.dn-Use-rich-comparisons.patch Type: text/x-patch Size: 10236 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0716.2-test_dn-Split-bytes-and-unicode.patch Type: text/x-patch Size: 8225 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0717.2-Use-sys.maxsize-instead-of-sys.maxint.patch Type: text/x-patch Size: 3675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0718.2-Use-six.moves.urllib-instead-of-urllib-urllib2-urlpa.patch Type: text/x-patch Size: 26145 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0719.2-Use-six.moves.xmlrpc.client-instead-of-xmlrpclib.patch Type: text/x-patch Size: 13249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0720.2-Use-six.moves.configparser-instead-of-ConfigParser.patch Type: text/x-patch Size: 11450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0721.2-Use-six.moves.http_client-instead-of-httplib.patch Type: text/x-patch Size: 3748 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0722.2-Use-six.Stringio-instead-of-StringIO.StringIO.patch Type: text/x-patch Size: 3978 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0723.2-Remove-uses-of-the-types-module.patch Type: text/x-patch Size: 12482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0724.2-ipapython.ssh-Port-to-Python-3.patch Type: text/x-patch Size: 5547 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0725.2-Appease-pylint.patch Type: text/x-patch Size: 1277 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Sep 23 14:52:22 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 23 Sep 2015 16:52:22 +0200 Subject: [Freeipa-devel] [PATCHES 0370-0371] winsync-migrate: Handle invalid characters in the names of IPA entities In-Reply-To: <56028F70.6060008@redhat.com> References: <56028F70.6060008@redhat.com> Message-ID: <5602BCA6.4000903@redhat.com> On 09/23/2015 01:39 PM, Tomas Babej wrote: > Hi, > > this fixes https://fedorahosted.org/freeipa/ticket/5319. > > Details in the commit messages. > > Tomas > > ACK -- Martin^3 Babinsky From jcholast at redhat.com Wed Sep 23 14:56:31 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 16:56:31 +0200 Subject: [Freeipa-devel] [PATCHES 0370-0371] winsync-migrate: Handle invalid characters in the names of IPA entities In-Reply-To: <5602BCA6.4000903@redhat.com> References: <56028F70.6060008@redhat.com> <5602BCA6.4000903@redhat.com> Message-ID: <5602BD9F.4060000@redhat.com> On 23.9.2015 16:52, Martin Babinsky wrote: > On 09/23/2015 01:39 PM, Tomas Babej wrote: >> Hi, >> >> this fixes https://fedorahosted.org/freeipa/ticket/5319. >> >> Details in the commit messages. >> >> Tomas >> >> > > ACK > The patches need to be rebased on top of ipa-4-2. -- Jan Cholasta From mbasti at redhat.com Wed Sep 23 15:01:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Sep 2015 17:01:33 +0200 Subject: [Freeipa-devel] [PATCHES 466-468, 0316] install: Add common base class for server and replica install In-Reply-To: <56012919.4000007@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> <55F7AB23.5040805@redhat.com> <55F907FA.40202@redhat.com> <55F92BF3.6010604@redhat.com> <56011150.6050106@redhat.com> <56012919.4000007@redhat.com> Message-ID: <5602BECD.8070705@redhat.com> On 09/22/2015 12:10 PM, Jan Cholasta wrote: > On 22.9.2015 10:29, Martin Babinsky wrote: >> On 09/16/2015 10:44 AM, Jan Cholasta wrote: >>> On 16.9.2015 08:11, Jan Cholasta wrote: >>>> On 15.9.2015 07:22, Jan Cholasta wrote: >>>>> On 10.8.2015 16:58, Martin Babinsky wrote: >>>>>> On 08/06/2015 08:22 AM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch fixes part of >>>>>>> . >>>>>>> >>>>>>> See also Martin Babinsky's patch 51: >>>>>>> . >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> Sorry but NACK, see below: >>>>>> >>>>>> 1.) it seems that passing kwargs to Server components doesn't >>>>>> work as >>>>>> expected. See these logs (install on fresh F22 VM): >>>>>> >>>>>> http://fpaste.org/253416/21363814/ >>>>>> http://fpaste.org/253419/43921374/ >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 2.) the following code blows up in BaseServers' __init__: >>>>>> (http://fpaste.org/253400/21225314/) >>>>>> >>>>>> 392 if not self.dns.setup_dns: >>>>>> 393 if self.dns.forwarders: >>>>>> 394 raise RuntimeError( >>>>>> 395 "You cannot specify a --forwarder option >>>>>> without >>>>>> the " >>>>>> 396 "--setup-dns option") >>>>>> >>>>>> >>>>>> I think that the check should be: >>>>>> >>>>>> 392 if not self.setup_dns: >>>>>> 393 if self.dns.forwarders: >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> IMHO BaseServerDNS class shouldn't have setup_dns knob, that >>>>>> should be >>>>>> set in the parent class (BaseServer) >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 3.) Is there any reason why BaseServer doesn't have >>>>>> 'master_password', >>>>>> 'idmax' and 'idstart' knobs? I know that these are then brought >>>>>> in by >>>>>> the derived Server class, but the check for them is in parent's >>>>>> __init__() method and it is IMHO a bit confusing >>>>> >>>>> The check should be in Server, fixed. >>>>> >>>>>> >>>>>> 4.) please add license header to the beginning of >>>>>> 'ipaserver/install/server/common.py' file >>>>> >>>>> Added. >>>>> >>>>> Updated patches attached. >>>> >>>> Self-NACK, I broke ipa-server-install --uninstall. >>> >>> Fixed. >>> >> >> ACK to all three patches. >> > > Thanks. > > Pushed to: > master: 86edd6abeb9749e159a529b83cfce6443fff4ba5 > ipa-4-2: 42d16b02cd153ac89ebd8ae07c98611dc3b6e471 > These patches introduced regression. ipa-replica-install in unattended mode requires to specify -a, -p and -r options. Attached patch fixes it. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0316-Replica-inst.-fix-do-not-require-r-a-p-options-in-un.patch Type: text/x-patch Size: 2412 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Sep 23 15:03:49 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 23 Sep 2015 17:03:49 +0200 Subject: [Freeipa-devel] [PATCHES 0370-0371] winsync-migrate: Handle invalid characters in the names of IPA entities In-Reply-To: <5602BD9F.4060000@redhat.com> References: <56028F70.6060008@redhat.com> <5602BCA6.4000903@redhat.com> <5602BD9F.4060000@redhat.com> Message-ID: <5602BF55.1050805@redhat.com> On 09/23/2015 04:56 PM, Jan Cholasta wrote: > On 23.9.2015 16:52, Martin Babinsky wrote: >> On 09/23/2015 01:39 PM, Tomas Babej wrote: >>> Hi, >>> >>> this fixes https://fedorahosted.org/freeipa/ticket/5319. >>> >>> Details in the commit messages. >>> >>> Tomas >>> >>> >> >> ACK >> > > The patches need to be rebased on top of ipa-4-2. > Attaching rebased patches on Tomas's behalf. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-tbabej-0371-winsync-migrate-Properly-handle-collisions-in-the-na.patch Type: text/x-patch Size: 2338 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-tbabej-0370-winsync-migrate-Convert-entity-names-to-posix-friend.patch Type: text/x-patch Size: 3971 bytes Desc: not available URL: From jcholast at redhat.com Wed Sep 23 15:06:36 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Sep 2015 17:06:36 +0200 Subject: [Freeipa-devel] [PATCHES 0370-0371] winsync-migrate: Handle invalid characters in the names of IPA entities In-Reply-To: <5602BF55.1050805@redhat.com> References: <56028F70.6060008@redhat.com> <5602BCA6.4000903@redhat.com> <5602BD9F.4060000@redhat.com> <5602BF55.1050805@redhat.com> Message-ID: <5602BFFC.3040301@redhat.com> On 23.9.2015 17:03, Martin Babinsky wrote: > On 09/23/2015 04:56 PM, Jan Cholasta wrote: >> On 23.9.2015 16:52, Martin Babinsky wrote: >>> On 09/23/2015 01:39 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this fixes https://fedorahosted.org/freeipa/ticket/5319. >>>> >>>> Details in the commit messages. >>>> >>>> Tomas >>>> >>>> >>> >>> ACK >>> >> >> The patches need to be rebased on top of ipa-4-2. >> > > Attaching rebased patches on Tomas's behalf. > Thanks. Pushed to: master: 75cba4e8bfe0479078ba112d99628ed517e010a2 ipa-4-2: d639e932e248866e7a5993f899f025778860bc95 -- Jan Cholasta From tbabej at redhat.com Wed Sep 23 15:06:58 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 23 Sep 2015 17:06:58 +0200 Subject: [Freeipa-devel] [PATCHES 0370-0371] winsync-migrate: Handle invalid characters in the names of IPA entities In-Reply-To: <5602BD9F.4060000@redhat.com> References: <56028F70.6060008@redhat.com> <5602BCA6.4000903@redhat.com> <5602BD9F.4060000@redhat.com> Message-ID: <5602C012.9020101@redhat.com> On 09/23/2015 04:56 PM, Jan Cholasta wrote: > On 23.9.2015 16:52, Martin Babinsky wrote: >> On 09/23/2015 01:39 PM, Tomas Babej wrote: >>> Hi, >>> >>> this fixes https://fedorahosted.org/freeipa/ticket/5319. >>> >>> Details in the commit messages. >>> >>> Tomas >>> >>> >> >> ACK >> > > The patches need to be rebased on top of ipa-4-2. > Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-4.2-0370-winsync-migrate-Convert-entity-names-to-posix-friend.patch Type: text/x-patch Size: 3967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-4.2-0371-winsync-migrate-Properly-handle-collisions-in-the-na.patch Type: text/x-patch Size: 2334 bytes Desc: not available URL: From tbabej at redhat.com Wed Sep 23 15:07:27 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 23 Sep 2015 17:07:27 +0200 Subject: [Freeipa-devel] [PATCHES 0370-0371] winsync-migrate: Handle invalid characters in the names of IPA entities In-Reply-To: <5602C012.9020101@redhat.com> References: <56028F70.6060008@redhat.com> <5602BCA6.4000903@redhat.com> <5602BD9F.4060000@redhat.com> <5602C012.9020101@redhat.com> Message-ID: <5602C02F.4000505@redhat.com> On 09/23/2015 05:06 PM, Tomas Babej wrote: > > > On 09/23/2015 04:56 PM, Jan Cholasta wrote: >> On 23.9.2015 16:52, Martin Babinsky wrote: >>> On 09/23/2015 01:39 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this fixes https://fedorahosted.org/freeipa/ticket/5319. >>>> >>>> Details in the commit messages. >>>> >>>> Tomas >>>> >>>> >>> >>> ACK >>> >> >> The patches need to be rebased on top of ipa-4-2. >> > > Attached. > Ah, I was race conditioned! From simo at redhat.com Wed Sep 23 17:47:46 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Sep 2015 13:47:46 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56024848.3030005@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <1442933847.4697.147.camel@willson.usersys.redhat.com> <1442969233.4697.208.camel@willson.usersys.redhat.com> <56024848.3030005@redhat.com> Message-ID: <1443030466.6835.4.camel@willson.usersys.redhat.com> On Wed, 2015-09-23 at 08:35 +0200, Jan Cholasta wrote: > What I mean is that installing a replica using an already existing > replica file should be prevented at level 1 as well: > > root at ipa1# ipa-server-install --domain-level=0 > root at ipa1# ipa-replica-prepare ipa2.example.com > root at ipa1# ipa domainlevel-set 1 > > root at ipa2# ipa-replica-install replica-info-ipa2.example.com.gpg > ERROR: Can't install replica from a replica file at domain level > 0 Ok I rebased the patchset with a modification to assume promotion if no file was provided, and then raise appropriate RuntimeErrors if conditions about the domain level are not met. This change also prevents installing with a replica file if domain level is currently at 1. They are in the usual custodia-review branch. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Sep 24 00:25:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 24 Sep 2015 02:25:05 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56011527.40304@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> Message-ID: <560342E1.8070709@redhat.com> On 09/22/2015 10:45 AM, Jan Cholasta wrote: > Hi, > > On 9.9.2015 20:25, Simo Sorce wrote: >> On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: >>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>> and introduces a number of required changes and dependencies to >>> achieve >>> this goal. >>> This work requires the custodia project to securely transfer keys >>> between ipa servers. >>> >>> This work is not 100% complete, it still misses the ability to install >>> kra instances and the ability to install a CA (via ipa-ca-install) with >>> externally signed certs. >>> >>> However it is massive enough that warrants review and pushing, the >>> resat >>> of the changes can be applied later as this work should not disrupt the >>> classic install methods. >>> >>> In order to build my previous patches (530-533) are needed as well as a >>> number of updated components. >>> >>> I used the following coprs for testing: >>> simo/jwcrypto >>> simo/custodia >>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>> mkosek/freeipa-4.2-fedora-22 (misc) >>> fedora/updates-testing (python-gssapi 1.1.2) >>> >>> Ludwig's copr is necessary to have a functional DNA plugin in replicas, >>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>> it will be released. >>> >>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>> that may cause installation issues in some case (re-install of a >>> replica). >>> >>> The domain must be raised to level 1 in order to use replica promotion. >>> >>> In order to promote a replica the server must be first joined as a >>> regular client to the domain. >>> >>> This is the flow I usually use for testing: >>> >>> # ipa-client-install >>> # kinit admin >>> # ipa-replica-install --promote --setup-ca >>> >> etc...> >>> >>> These patches are also available in this git tree rebnase on current >>> master: >>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>> >> >> FYI: I rebased this branch on top of master and applied minor changes to >> one of the DNS patches. I also added the missing support to install KRA. >> >> DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not >> needed anymore. >> >> Dogtag's ticket is not fixed yet so running both --setup-ca and >> --setup-kra at the same time will still yield an error and install will >> fail. >> >> Please let me know if there are any major issues with this patchset, I'd >> like to push it to master and attack the remaining issues as add ons >> (install with external certs not supported yet for example) > > So far I have only read through the code without running it (mostly). > > > "Remove unused arguments": ACK > > > "Simplify the install_replica_ca function": ACK > > > "IPA Custodia Daemon": > > 1) Instead of putting the code in "ipakeys" package, could you put it > in "ipapython.keys"? This way it would be consistent with DNSSEC, > which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/. > > 2) Is it safe to create cn=custodia in update file only? Updates are > executed late in ipa-server-install. Is is guaranteed that nothing > will try to access cn=custodia before the updates are run? > > (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) > > 3) Shouldn't cn=custodia be created only when domain level >= 1? > > 4) pylint fails with: > > daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), > IPAKEMKeys.__init__] Use of super on an old style class) > daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), > IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no > 'config' member) > daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), > IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) > > 5) There are some PEP8 transgressions: > > ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 > > 79 characters) > ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 > > 79 characters) > ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank > lines, found 1 > ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around > keyword / parameter equals > ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file > > > "Add Custodia Client code": > > 1) Is there any significance in having this in a separate commit? I > would think it can be safely squashed in the previous commit. > > > 2) There is one PEP8 transgression: > > ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank > lines (2) > > > "Install ipa-custodia with the rest of ipa": > > 1) python-jwcrypto dependency is missing in the spec file. > > 2) I believe the daemons/ipa-custodia/* and > install/share/bootstrap-template.ldif should be in the "IPA Custodia > Daemon" commit. At the very least it would make reviews easier. > > 3) There is one PEP8 transgressions: > > ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank > lines, found 1 > > > "Require a DS version that has working DNA plugin": ACK > > > "Implement replica promotion functionality": > > 1) I think a RuntimeError or sys.exit with an error message would be > better than NotImplementedError for the unimplemented options. > > (Nevermind, these are removed in further commits.) > > 2) There is no domain level check when installing the replica from a > replica file. > > 3) Instead of returning INSTALL_ERROR from promote_check() (which has > no effect), raise an exception or call sys.exit(). > > 4) The --promote option is redundant. You can safely decide whether to > promote or not based on whether replica file was provided or not and > the domain level of the remote server. > > 5) There are some PEP8 transgressions: > > ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace > after ',' > ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace > after ',' > ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace > after ',' > ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' > ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 > characters) > ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 > characters) > ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) > ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank > lines, found 1 > ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > 79 > characters) > ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > 79 > characters) > ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > 79 > characters) > ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 > blank lines, found 1 > ./ipaserver/install/server/replicainstall.py:862:25: E128 continuation > line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:864:25: E128 continuation > line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:865:25: E128 continuation > line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:1014:13: E128 > continuation line under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing > whitespace after ',' > ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many > blank lines (2) > > > "Change DNS installer code to use passed in api": LGTM > > > "Allow ipa-replica-conncheck to use default creds": LGTM > > > "Add function to extract CA certs for install": LGTM > > > "Allow to setup the CA when promoting a replica": > > 1) There are some PEP8 transgressions: > > ./ipaserver/install/ca.py:35:13: E125 continuation line with same > indent as next logical line > ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) > ./ipaserver/install/replication.py:421:24: E231 missing whitespace > after ',' > ./ipaserver/install/replication.py:421:35: E231 missing whitespace > after ',' > ./ipaserver/install/replication.py:421:41: E231 missing whitespace > after ',' > ./ipaserver/install/replication.py:422:24: E231 missing whitespace > after ',' > ./ipaserver/install/replication.py:422:40: E231 missing whitespace > after ',' > ./ipaserver/install/replication.py:422:46: E231 missing whitespace > after ',' > ./ipaserver/install/replication.py:524:37: E128 continuation line > under-indented for visual indent > ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' > ./ipaserver/install/replication.py:524:80: E501 line too long (187 > > 79 characters) > ./ipaserver/install/replication.py:526:80: E501 line too long (106 > > 79 characters) > ./ipaserver/install/replication.py:560:80: E501 line too long (86 > 79 > characters) > ./ipaserver/install/replication.py:847:80: E501 line too long (81 > 79 > characters) > ./ipaserver/install/replication.py:850:80: E501 line too long (89 > 79 > characters) > ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > > 79 characters) > ./ipaserver/install/replication.py:1766:17: E128 continuation line > under-indented for visual indent > ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > > 79 characters) > > > "Make checks for existing credentials reusable": > > 1) There are some PEP8 transgressions: > > ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank > lines, found 1 > ./ipaserver/install/installutils.py:1192:25: E128 continuation line > under-indented for visual indent > ./ipaserver/install/installutils.py:1194:25: E128 continuation line > under-indented for visual indent > ./ipaserver/install/installutils.py:1195:25: E128 continuation line > under-indented for visual indent > > > "Allow ipa-ca-install to use the new promotion code": > > 1) The --replica option is redundant. You can safely decide whether > this is the first CA master or not based on information in cn=masters. > > 2) There are some PEP8 transgressions: > > ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace > after ',' > ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace > after ',' > > > "Remove unused kra option": ACK > > > "Allow to install the KRA on a promoted server": > > 1) There are some PEP8 transgressions: > > ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line > over-indented for visual indent > ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, > found 1 > ./ipaserver/install/krainstance.py:382:13: E128 continuation line > under-indented for visual indent > ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing > whitespace around operator > ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many > blank lines (2) > ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, > found 1 > ./ipaserver/install/service.py:115:52: E203 whitespace before ',' > > > Pushed first 2 commits to master: > d8b1f42f171d666068583548315b4684e5f3c3a4 > > > Honza > Hello, we have broken ipa-kra-install in master. https://fedorahosted.org/freeipa/ticket/5321 I did git bisect and it found: 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 is the first bad commit commit 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 Author: Simo Sorce Date: Tue Aug 25 13:38:05 2015 -0400 Remove unused arguments In the dogtag/ca/kra instances self.domain is never used. Remove it. Signed-off-by: Simo Sorce Reviewed-By: Jan Cholasta :040000 040000 d4ad87647b181b182a3a56bdac6c95c008ec2623 8728f38996eeaa387617880c29fdd8b4c1f21ad4 M ipaserver I do not see anything bad in the commit, so I maybe I did bisect wrong, I will investigate later. But it is caused by a recent change, because it worked from master branch on moday. Martin^2 From mbasti at redhat.com Thu Sep 24 08:43:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 24 Sep 2015 10:43:00 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560342E1.8070709@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> Message-ID: <5603B794.4090806@redhat.com> On 09/24/2015 02:25 AM, Martin Basti wrote: > > > On 09/22/2015 10:45 AM, Jan Cholasta wrote: >> Hi, >> >> On 9.9.2015 20:25, Simo Sorce wrote: >>> On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: >>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>>> and introduces a number of required changes and dependencies to >>>> achieve >>>> this goal. >>>> This work requires the custodia project to securely transfer keys >>>> between ipa servers. >>>> >>>> This work is not 100% complete, it still misses the ability to install >>>> kra instances and the ability to install a CA (via ipa-ca-install) >>>> with >>>> externally signed certs. >>>> >>>> However it is massive enough that warrants review and pushing, the >>>> resat >>>> of the changes can be applied later as this work should not disrupt >>>> the >>>> classic install methods. >>>> >>>> In order to build my previous patches (530-533) are needed as well >>>> as a >>>> number of updated components. >>>> >>>> I used the following coprs for testing: >>>> simo/jwcrypto >>>> simo/custodia >>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>> fedora/updates-testing (python-gssapi 1.1.2) >>>> >>>> Ludwig's copr is necessary to have a functional DNA plugin in >>>> replicas, >>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>>> it will be released. >>>> >>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>>> that may cause installation issues in some case (re-install of a >>>> replica). >>>> >>>> The domain must be raised to level 1 in order to use replica >>>> promotion. >>>> >>>> In order to promote a replica the server must be first joined as a >>>> regular client to the domain. >>>> >>>> This is the flow I usually use for testing: >>>> >>>> # ipa-client-install >>>> # kinit admin >>>> # ipa-replica-install --promote --setup-ca >>>> >>> etc...> >>>> >>>> These patches are also available in this git tree rebnase on current >>>> master: >>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>> >>> >>> FYI: I rebased this branch on top of master and applied minor >>> changes to >>> one of the DNS patches. I also added the missing support to install >>> KRA. >>> >>> DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not >>> needed anymore. >>> >>> Dogtag's ticket is not fixed yet so running both --setup-ca and >>> --setup-kra at the same time will still yield an error and install will >>> fail. >>> >>> Please let me know if there are any major issues with this patchset, >>> I'd >>> like to push it to master and attack the remaining issues as add ons >>> (install with external certs not supported yet for example) >> >> So far I have only read through the code without running it (mostly). >> >> >> "Remove unused arguments": ACK >> >> >> "Simplify the install_replica_ca function": ACK >> >> >> "IPA Custodia Daemon": >> >> 1) Instead of putting the code in "ipakeys" package, could you put it >> in "ipapython.keys"? This way it would be consistent with DNSSEC, >> which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/. >> >> 2) Is it safe to create cn=custodia in update file only? Updates are >> executed late in ipa-server-install. Is is guaranteed that nothing >> will try to access cn=custodia before the updates are run? >> >> (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) >> >> 3) Shouldn't cn=custodia be created only when domain level >= 1? >> >> 4) pylint fails with: >> >> daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), >> IPAKEMKeys.__init__] Use of super on an old style class) >> daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), >> IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no >> 'config' member) >> daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), >> IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) >> >> 5) There are some PEP8 transgressions: >> >> ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 >> > 79 characters) >> ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 >> > 79 characters) >> ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank >> lines, found 1 >> ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around >> keyword / parameter equals >> ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file >> >> >> "Add Custodia Client code": >> >> 1) Is there any significance in having this in a separate commit? I >> would think it can be safely squashed in the previous commit. >> >> >> 2) There is one PEP8 transgression: >> >> ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank >> lines (2) >> >> >> "Install ipa-custodia with the rest of ipa": >> >> 1) python-jwcrypto dependency is missing in the spec file. >> >> 2) I believe the daemons/ipa-custodia/* and >> install/share/bootstrap-template.ldif should be in the "IPA Custodia >> Daemon" commit. At the very least it would make reviews easier. >> >> 3) There is one PEP8 transgressions: >> >> ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank >> lines, found 1 >> >> >> "Require a DS version that has working DNA plugin": ACK >> >> >> "Implement replica promotion functionality": >> >> 1) I think a RuntimeError or sys.exit with an error message would be >> better than NotImplementedError for the unimplemented options. >> >> (Nevermind, these are removed in further commits.) >> >> 2) There is no domain level check when installing the replica from a >> replica file. >> >> 3) Instead of returning INSTALL_ERROR from promote_check() (which has >> no effect), raise an exception or call sys.exit(). >> >> 4) The --promote option is redundant. You can safely decide whether >> to promote or not based on whether replica file was provided or not >> and the domain level of the remote server. >> >> 5) There are some PEP8 transgressions: >> >> ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace >> after ',' >> ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace >> after ',' >> ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace >> after ',' >> ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' >> ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 >> characters) >> ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 >> characters) >> ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) >> ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank >> lines, found 1 >> ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > >> 79 characters) >> ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > >> 79 characters) >> ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > >> 79 characters) >> ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 >> blank lines, found 1 >> ./ipaserver/install/server/replicainstall.py:862:25: E128 >> continuation line under-indented for visual indent >> ./ipaserver/install/server/replicainstall.py:864:25: E128 >> continuation line under-indented for visual indent >> ./ipaserver/install/server/replicainstall.py:865:25: E128 >> continuation line under-indented for visual indent >> ./ipaserver/install/server/replicainstall.py:1014:13: E128 >> continuation line under-indented for visual indent >> ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing >> whitespace after ',' >> ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many >> blank lines (2) >> >> >> "Change DNS installer code to use passed in api": LGTM >> >> >> "Allow ipa-replica-conncheck to use default creds": LGTM >> >> >> "Add function to extract CA certs for install": LGTM >> >> >> "Allow to setup the CA when promoting a replica": >> >> 1) There are some PEP8 transgressions: >> >> ./ipaserver/install/ca.py:35:13: E125 continuation line with same >> indent as next logical line >> ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) >> ./ipaserver/install/replication.py:421:24: E231 missing whitespace >> after ',' >> ./ipaserver/install/replication.py:421:35: E231 missing whitespace >> after ',' >> ./ipaserver/install/replication.py:421:41: E231 missing whitespace >> after ',' >> ./ipaserver/install/replication.py:422:24: E231 missing whitespace >> after ',' >> ./ipaserver/install/replication.py:422:40: E231 missing whitespace >> after ',' >> ./ipaserver/install/replication.py:422:46: E231 missing whitespace >> after ',' >> ./ipaserver/install/replication.py:524:37: E128 continuation line >> under-indented for visual indent >> ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' >> ./ipaserver/install/replication.py:524:80: E501 line too long (187 > >> 79 characters) >> ./ipaserver/install/replication.py:526:80: E501 line too long (106 > >> 79 characters) >> ./ipaserver/install/replication.py:560:80: E501 line too long (86 > >> 79 characters) >> ./ipaserver/install/replication.py:847:80: E501 line too long (81 > >> 79 characters) >> ./ipaserver/install/replication.py:850:80: E501 line too long (89 > >> 79 characters) >> ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > >> 79 characters) >> ./ipaserver/install/replication.py:1766:17: E128 continuation line >> under-indented for visual indent >> ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > >> 79 characters) >> >> >> "Make checks for existing credentials reusable": >> >> 1) There are some PEP8 transgressions: >> >> ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank >> lines, found 1 >> ./ipaserver/install/installutils.py:1192:25: E128 continuation line >> under-indented for visual indent >> ./ipaserver/install/installutils.py:1194:25: E128 continuation line >> under-indented for visual indent >> ./ipaserver/install/installutils.py:1195:25: E128 continuation line >> under-indented for visual indent >> >> >> "Allow ipa-ca-install to use the new promotion code": >> >> 1) The --replica option is redundant. You can safely decide whether >> this is the first CA master or not based on information in cn=masters. >> >> 2) There are some PEP8 transgressions: >> >> ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace >> after ',' >> ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace >> after ',' >> >> >> "Remove unused kra option": ACK >> >> >> "Allow to install the KRA on a promoted server": >> >> 1) There are some PEP8 transgressions: >> >> ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line >> over-indented for visual indent >> ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, >> found 1 >> ./ipaserver/install/krainstance.py:382:13: E128 continuation line >> under-indented for visual indent >> ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing >> whitespace around operator >> ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many >> blank lines (2) >> ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, >> found 1 >> ./ipaserver/install/service.py:115:52: E203 whitespace before ',' >> >> >> Pushed first 2 commits to master: >> d8b1f42f171d666068583548315b4684e5f3c3a4 >> >> >> Honza >> > > Hello, > > we have broken ipa-kra-install in master. > https://fedorahosted.org/freeipa/ticket/5321 > > I did git bisect and it found: > > 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 is the first bad commit > commit 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 > Author: Simo Sorce > Date: Tue Aug 25 13:38:05 2015 -0400 > > Remove unused arguments > > In the dogtag/ca/kra instances self.domain is never used. > Remove it. > > Signed-off-by: Simo Sorce > Reviewed-By: Jan Cholasta > > :040000 040000 d4ad87647b181b182a3a56bdac6c95c008ec2623 > 8728f38996eeaa387617880c29fdd8b4c1f21ad4 M ipaserver > > > I do not see anything bad in the commit, so I maybe I did bisect > wrong, I will investigate later. But it is caused by a recent change, > because it worked from master branch on moday. > > Martin^2 > I confirm. I reverted this commit in my branch, and ipa-kra-install works again. So unused variable is really used somewhere, but I cannot find where. Martin^2 From pviktori at redhat.com Thu Sep 24 09:02:22 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 24 Sep 2015 11:02:22 +0200 Subject: [Freeipa-devel] [PATCH] Replace StandardError with Exception In-Reply-To: <55FADDDD.8020801@redhat.com> References: <55FADDDD.8020801@redhat.com> Message-ID: <5603BC1E.4020209@redhat.com> On 09/17/2015 05:35 PM, Petr Viktorin wrote: > Hello, > In Python 2, Exception has only two built-in subclasses: StandardError, > and StopIteration. > This makes StandardError pretty useless, and Python 3 removes it. > > This patch replaces StandardError with Exception. It has no effect on > IPA code. However, it could theoretically affect external plugins (e.g. > if they do "except StandardError"). ping, anybody for review of this patch? -- Petr Viktorin From mkosek at redhat.com Thu Sep 24 11:19:51 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Sep 2015 13:19:51 +0200 Subject: [Freeipa-devel] Scope of ECC support in FreeIPA/Dogtag In-Reply-To: <20150915132655.GJ16937@dhcp-40-8.bne.redhat.com> References: <55F80AD1.9060005@redhat.com> <20150915132655.GJ16937@dhcp-40-8.bne.redhat.com> Message-ID: <5603DC57.4010400@redhat.com> On 09/15/2015 03:26 PM, Fraser Tweedale wrote: > On Tue, Sep 15, 2015 at 02:10:57PM +0200, Martin Kosek wrote: >> Hi Nathan and others, >> >> I am now going through FreeIPA 4.4 items and I am thinking about ECC support in >> FreeIPA: >> >> https://fedorahosted.org/freeipa/ticket/3951 >> >> AFAIK, ECC should be already supported in Dogtag. Could you please advise what >> is the scope of expected changes in FreeIPA? >> >> My understanding is that following parts are required: >> 1) Generating ECC signing certificate for FreeIPA CA. This is not clear to me >> though, if this task can be easily done during upgrade. >> > Lightweight (sub)CAs should allow it easily - once they support > specifying the key type and size/curve (currently subCAs are > hardcoded to rsa2048 but the subCAs are still a WIP; there is a > separate ticket[1] to track it). > > There will also be a small amount of work on the IPA side - and > maybe some on Dogtag side - to allow new installation to use ECC > root. > > [1] https://fedorahosted.org/pki/ticket/1589 > >> 2) Updating FreeIPA Certificate Profiles (which should be now in LDAP) and >> adding respective EC algorithms support to "signingAlgsAllowed", as noted in >> https://fedorahosted.org/freeipa/ticket/3951#comment:1. >> > Yes, we will need to update the included profiles. I have been > thinking about how to get more flexibility for profile updates; I > think versioning profiles is desirable but that will be a separate > design proposal. > > Anyhow, I am happy to own these efforts. Ok, thanks you for all the information - please do :-) > > Cheers, > Fraser > >> Is that correct or more is needed to make that working and supported in FreeIPA? >> >> -- >> Martin Kosek >> Supervisor, Software Engineering - Identity Management Team >> Red Hat Inc. From mkubik at redhat.com Thu Sep 24 12:49:02 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 24 Sep 2015 14:49:02 +0200 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test Message-ID: <5603F13E.4060805@redhat.com> Hi all, an update for CA ACL tests! I, with help from M. Babinsky, managed to find a way how to change the identity during acceptance cest run, which allows to test CA ACLs (and perhaps other areas with some form of access controll). This allowed me to write a test for CA ACLs and certificate profiles that checks if the ACL/profile is being used and enforced. The first several tests are based on Fraser's blogpost using SMIME profile [1]. The master and ipa-4-2 branches diverged a bit, so I had to change two commits when rebasing to ipa-4-2 branch. Commits should be applied in the order (including rebased patches I sent in an earlier email): master: * 12 - 17 ipa-4-2: * 18, 13 - 15, 19, 17 For convenience: patches on top of master: https://github.com/apophys/freeipa/tree/acl-profile-functional patches on top of ipa-4-2: https://github.com/apophys/freeipa/tree/acl-42 [1]: https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ Cheers, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0012.3-ipatests-add-fuzzy-instances-for-CA-ACL-DN-and-RDN.patch Type: text/x-patch Size: 1139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0013.3-ipatests-Add-initial-CAACLTracker-implementation.patch Type: text/x-patch Size: 12295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0014.3-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 1332 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0015-ipatests-CA-ACL-added-config-templates.patch Type: text/x-patch Size: 10439 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0016-ipatests-added-unlock_principal_password-and-change_.patch Type: text/x-patch Size: 2484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0017-ipatests-CA-ACL-and-cert-profile-functional-test.patch Type: text/x-patch Size: 7657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0018-ipatests-add-fuzzy-instances-for-CA-ACL-DN-and-RDN.patch Type: text/x-patch Size: 1133 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0019-ipatests-added-unlock_principal_password-and-change_.patch Type: text/x-patch Size: 2394 bytes Desc: not available URL: From simo at redhat.com Thu Sep 24 13:10:30 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 24 Sep 2015 09:10:30 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5603B794.4090806@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> Message-ID: <5603F646.5090004@redhat.com> On 24/09/15 04:43, Martin Basti wrote: > > > On 09/24/2015 02:25 AM, Martin Basti wrote: >> >> >> On 09/22/2015 10:45 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 9.9.2015 20:25, Simo Sorce wrote: >>>> On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: >>>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>>>> and introduces a number of required changes and dependencies to >>>>> achieve >>>>> this goal. >>>>> This work requires the custodia project to securely transfer keys >>>>> between ipa servers. >>>>> >>>>> This work is not 100% complete, it still misses the ability to install >>>>> kra instances and the ability to install a CA (via ipa-ca-install) >>>>> with >>>>> externally signed certs. >>>>> >>>>> However it is massive enough that warrants review and pushing, the >>>>> resat >>>>> of the changes can be applied later as this work should not disrupt >>>>> the >>>>> classic install methods. >>>>> >>>>> In order to build my previous patches (530-533) are needed as well >>>>> as a >>>>> number of updated components. >>>>> >>>>> I used the following coprs for testing: >>>>> simo/jwcrypto >>>>> simo/custodia >>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>>> fedora/updates-testing (python-gssapi 1.1.2) >>>>> >>>>> Ludwig's copr is necessary to have a functional DNA plugin in >>>>> replicas, >>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>>>> it will be released. >>>>> >>>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>>>> that may cause installation issues in some case (re-install of a >>>>> replica). >>>>> >>>>> The domain must be raised to level 1 in order to use replica >>>>> promotion. >>>>> >>>>> In order to promote a replica the server must be first joined as a >>>>> regular client to the domain. >>>>> >>>>> This is the flow I usually use for testing: >>>>> >>>>> # ipa-client-install >>>>> # kinit admin >>>>> # ipa-replica-install --promote --setup-ca >>>>> >>>> etc...> >>>>> >>>>> These patches are also available in this git tree rebnase on current >>>>> master: >>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>>> >>>> >>>> FYI: I rebased this branch on top of master and applied minor >>>> changes to >>>> one of the DNS patches. I also added the missing support to install >>>> KRA. >>>> >>>> DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not >>>> needed anymore. >>>> >>>> Dogtag's ticket is not fixed yet so running both --setup-ca and >>>> --setup-kra at the same time will still yield an error and install will >>>> fail. >>>> >>>> Please let me know if there are any major issues with this patchset, >>>> I'd >>>> like to push it to master and attack the remaining issues as add ons >>>> (install with external certs not supported yet for example) >>> >>> So far I have only read through the code without running it (mostly). >>> >>> >>> "Remove unused arguments": ACK >>> >>> >>> "Simplify the install_replica_ca function": ACK >>> >>> >>> "IPA Custodia Daemon": >>> >>> 1) Instead of putting the code in "ipakeys" package, could you put it >>> in "ipapython.keys"? This way it would be consistent with DNSSEC, >>> which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/. >>> >>> 2) Is it safe to create cn=custodia in update file only? Updates are >>> executed late in ipa-server-install. Is is guaranteed that nothing >>> will try to access cn=custodia before the updates are run? >>> >>> (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) >>> >>> 3) Shouldn't cn=custodia be created only when domain level >= 1? >>> >>> 4) pylint fails with: >>> >>> daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), >>> IPAKEMKeys.__init__] Use of super on an old style class) >>> daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), >>> IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no >>> 'config' member) >>> daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), >>> IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) >>> >>> 5) There are some PEP8 transgressions: >>> >>> ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 >>> > 79 characters) >>> ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 >>> > 79 characters) >>> ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank >>> lines, found 1 >>> ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around >>> keyword / parameter equals >>> ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file >>> >>> >>> "Add Custodia Client code": >>> >>> 1) Is there any significance in having this in a separate commit? I >>> would think it can be safely squashed in the previous commit. >>> >>> >>> 2) There is one PEP8 transgression: >>> >>> ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank >>> lines (2) >>> >>> >>> "Install ipa-custodia with the rest of ipa": >>> >>> 1) python-jwcrypto dependency is missing in the spec file. >>> >>> 2) I believe the daemons/ipa-custodia/* and >>> install/share/bootstrap-template.ldif should be in the "IPA Custodia >>> Daemon" commit. At the very least it would make reviews easier. >>> >>> 3) There is one PEP8 transgressions: >>> >>> ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank >>> lines, found 1 >>> >>> >>> "Require a DS version that has working DNA plugin": ACK >>> >>> >>> "Implement replica promotion functionality": >>> >>> 1) I think a RuntimeError or sys.exit with an error message would be >>> better than NotImplementedError for the unimplemented options. >>> >>> (Nevermind, these are removed in further commits.) >>> >>> 2) There is no domain level check when installing the replica from a >>> replica file. >>> >>> 3) Instead of returning INSTALL_ERROR from promote_check() (which has >>> no effect), raise an exception or call sys.exit(). >>> >>> 4) The --promote option is redundant. You can safely decide whether >>> to promote or not based on whether replica file was provided or not >>> and the domain level of the remote server. >>> >>> 5) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' >>> ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 >>> characters) >>> ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 >>> characters) >>> ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) >>> ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank >>> lines, found 1 >>> ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > >>> 79 characters) >>> ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > >>> 79 characters) >>> ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > >>> 79 characters) >>> ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 >>> blank lines, found 1 >>> ./ipaserver/install/server/replicainstall.py:862:25: E128 >>> continuation line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:864:25: E128 >>> continuation line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:865:25: E128 >>> continuation line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:1014:13: E128 >>> continuation line under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing >>> whitespace after ',' >>> ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many >>> blank lines (2) >>> >>> >>> "Change DNS installer code to use passed in api": LGTM >>> >>> >>> "Allow ipa-replica-conncheck to use default creds": LGTM >>> >>> >>> "Add function to extract CA certs for install": LGTM >>> >>> >>> "Allow to setup the CA when promoting a replica": >>> >>> 1) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/ca.py:35:13: E125 continuation line with same >>> indent as next logical line >>> ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) >>> ./ipaserver/install/replication.py:421:24: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/replication.py:421:35: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/replication.py:421:41: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/replication.py:422:24: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/replication.py:422:40: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/replication.py:422:46: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/replication.py:524:37: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' >>> ./ipaserver/install/replication.py:524:80: E501 line too long (187 > >>> 79 characters) >>> ./ipaserver/install/replication.py:526:80: E501 line too long (106 > >>> 79 characters) >>> ./ipaserver/install/replication.py:560:80: E501 line too long (86 > >>> 79 characters) >>> ./ipaserver/install/replication.py:847:80: E501 line too long (81 > >>> 79 characters) >>> ./ipaserver/install/replication.py:850:80: E501 line too long (89 > >>> 79 characters) >>> ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > >>> 79 characters) >>> ./ipaserver/install/replication.py:1766:17: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > >>> 79 characters) >>> >>> >>> "Make checks for existing credentials reusable": >>> >>> 1) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank >>> lines, found 1 >>> ./ipaserver/install/installutils.py:1192:25: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/installutils.py:1194:25: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/installutils.py:1195:25: E128 continuation line >>> under-indented for visual indent >>> >>> >>> "Allow ipa-ca-install to use the new promotion code": >>> >>> 1) The --replica option is redundant. You can safely decide whether >>> this is the first CA master or not based on information in cn=masters. >>> >>> 2) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace >>> after ',' >>> ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace >>> after ',' >>> >>> >>> "Remove unused kra option": ACK >>> >>> >>> "Allow to install the KRA on a promoted server": >>> >>> 1) There are some PEP8 transgressions: >>> >>> ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line >>> over-indented for visual indent >>> ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, >>> found 1 >>> ./ipaserver/install/krainstance.py:382:13: E128 continuation line >>> under-indented for visual indent >>> ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing >>> whitespace around operator >>> ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many >>> blank lines (2) >>> ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, >>> found 1 >>> ./ipaserver/install/service.py:115:52: E203 whitespace before ',' >>> >>> >>> Pushed first 2 commits to master: >>> d8b1f42f171d666068583548315b4684e5f3c3a4 >>> >>> >>> Honza >>> >> >> Hello, >> >> we have broken ipa-kra-install in master. >> https://fedorahosted.org/freeipa/ticket/5321 >> >> I did git bisect and it found: >> >> 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 is the first bad commit >> commit 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 >> Author: Simo Sorce >> Date: Tue Aug 25 13:38:05 2015 -0400 >> >> Remove unused arguments >> >> In the dogtag/ca/kra instances self.domain is never used. >> Remove it. >> >> Signed-off-by: Simo Sorce >> Reviewed-By: Jan Cholasta >> >> :040000 040000 d4ad87647b181b182a3a56bdac6c95c008ec2623 >> 8728f38996eeaa387617880c29fdd8b4c1f21ad4 M ipaserver >> >> >> I do not see anything bad in the commit, so I maybe I did bisect >> wrong, I will investigate later. But it is caused by a recent change, >> because it worked from master branch on moday. >> >> Martin^2 >> > I confirm. I reverted this commit in my branch, and ipa-kra-install > works again. So unused variable is really used somewhere, but I cannot > find where. I think the problem is that the patch was pushed prematurely. The option should become unused once the other patches in this patchset are applied, that is why that patch was not on top of the list but rather down close to the bottom. Simo. -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Thu Sep 24 13:12:11 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 24 Sep 2015 23:12:11 +1000 Subject: [Freeipa-devel] Scope of ECC support in FreeIPA/Dogtag In-Reply-To: <5603DC57.4010400@redhat.com> References: <55F80AD1.9060005@redhat.com> <20150915132655.GJ16937@dhcp-40-8.bne.redhat.com> <5603DC57.4010400@redhat.com> Message-ID: <20150924131211.GI16937@dhcp-40-8.bne.redhat.com> On Thu, Sep 24, 2015 at 01:19:51PM +0200, Martin Kosek wrote: > On 09/15/2015 03:26 PM, Fraser Tweedale wrote: > > On Tue, Sep 15, 2015 at 02:10:57PM +0200, Martin Kosek wrote: > >> Hi Nathan and others, > >> > >> I am now going through FreeIPA 4.4 items and I am thinking about ECC support in > >> FreeIPA: > >> > >> https://fedorahosted.org/freeipa/ticket/3951 > >> > >> AFAIK, ECC should be already supported in Dogtag. Could you please advise what > >> is the scope of expected changes in FreeIPA? > >> > >> My understanding is that following parts are required: > >> 1) Generating ECC signing certificate for FreeIPA CA. This is not clear to me > >> though, if this task can be easily done during upgrade. > >> > > Lightweight (sub)CAs should allow it easily - once they support > > specifying the key type and size/curve (currently subCAs are > > hardcoded to rsa2048 but the subCAs are still a WIP; there is a > > separate ticket[1] to track it). > > > > There will also be a small amount of work on the IPA side - and > > maybe some on Dogtag side - to allow new installation to use ECC > > root. > > > > [1] https://fedorahosted.org/pki/ticket/1589 > > > >> 2) Updating FreeIPA Certificate Profiles (which should be now in LDAP) and > >> adding respective EC algorithms support to "signingAlgsAllowed", as noted in > >> https://fedorahosted.org/freeipa/ticket/3951#comment:1. > >> > > Yes, we will need to update the included profiles. I have been > > thinking about how to get more flexibility for profile updates; I > > think versioning profiles is desirable but that will be a separate > > design proposal. > > > > Anyhow, I am happy to own these efforts. > > Ok, thanks you for all the information - please do :-) > I became owner of #3951 and also filed #5323 "Mechanism to update included certprofiles". Thanks, Fraser > > > > Cheers, > > Fraser > > > >> Is that correct or more is needed to make that working and supported in FreeIPA? > >> > >> -- > >> Martin Kosek > >> Supervisor, Software Engineering - Identity Management Team > >> Red Hat Inc. From mkubik at redhat.com Thu Sep 24 15:08:52 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 24 Sep 2015 17:08:52 +0200 Subject: [Freeipa-devel] [PATCH 0315] CI: backup&restore with KRA installed In-Reply-To: <55F2E86B.7040904@redhat.com> References: <55F2E86B.7040904@redhat.com> Message-ID: <56041204.8070706@redhat.com> On 09/11/2015 04:42 PM, Martin Basti wrote: > Patch mbasti-0312-2 > > Patch attached. > > LGTM, ack Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Sep 25 11:26:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 25 Sep 2015 13:26:35 +0200 Subject: [Freeipa-devel] [PATCH 0315] CI: backup&restore with KRA installed In-Reply-To: <56041204.8070706@redhat.com> References: <55F2E86B.7040904@redhat.com> <56041204.8070706@redhat.com> Message-ID: <56052F6B.2030608@redhat.com> On 09/24/2015 05:08 PM, Milan Kub?k wrote: > On 09/11/2015 04:42 PM, Martin Basti wrote: >> Patch mbasti-0312-2 >> >> Patch attached. >> >> > LGTM, ack > > Milan > > Pushed to: master: 28c25241fe7e1d8ff44a97daca44910b6ed57193 ipa-4-2: e87ae21da8e771662a7a931afe26967ff05145a2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Sep 25 11:48:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 25 Sep 2015 13:48:10 +0200 Subject: [Freeipa-devel] [PATCH 0055] dnssec options missing in ipa-dns-install man page In-Reply-To: References: <56010081.4020205@redhat.com> <56028AF3.709@redhat.com> <5602A5CC.2040403@redhat.com> Message-ID: <5605347A.3000705@redhat.com> On 09/23/2015 03:36 PM, Gabe Alford wrote: > Thanks. Updated patch attached. > > On Wed, Sep 23, 2015 at 7:14 AM, Martin Basti > wrote: > > > > On 09/23/2015 03:12 PM, Gabe Alford wrote: >> Odd and done. Updated patch attached. >> >> Gabe >> >> On Wed, Sep 23, 2015 at 5:20 AM, Martin Basti > > wrote: >> >> >> >> On 09/22/2015 03:32 PM, Gabe Alford wrote: >> >> create mode 100644 >> install/tools/man/freeipa-rga-0055-dnssec-options-missing-in-ipa-dns-install-man-page.patch >> >> Hello, >> >> your patch created new patch :-) >> >> Also there were 3 white space errors, please remove them. >> >> Martin >> >> > Thank you, but there is still missing update in ipa-server-install > manpage > > Martin > > Thank you. ACK Pushed to: master: e2b77f6283743cd339a47f002d9fe673bcfb70e3 ipa-4-2: a5b1cb24a0ae7145e0315bd0ef9205b648b19578 -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Fri Sep 25 14:53:05 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 25 Sep 2015 10:53:05 -0400 Subject: [Freeipa-devel] [PATCH 0086] Migrate OTP import script to python-cryptography In-Reply-To: <1441033728.7711.15.camel@redhat.com> References: <1441033728.7711.15.camel@redhat.com> Message-ID: <1443192785.10697.135.camel@redhat.com> On Mon, 2015-08-31 at 11:08 -0400, Nathaniel McCallum wrote: > https://fedorahosted.org/freeipa/ticket/5192 > -- > 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 Attached patch rebases the previous patch for master. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0086.1-Migrate-OTP-import-script-to-python-cryptography.patch Type: text/x-patch Size: 14257 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Sep 25 16:13:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 25 Sep 2015 18:13:39 +0200 Subject: [Freeipa-devel] [PATCH 0066] fix for regression in ipa-restore Message-ID: <560572B3.9010801@redhat.com> fixes https://fedorahosted.org/freeipa/ticket/5328 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0066-do-not-overwrite-files-with-local-users-groups-when-.patch Type: text/x-patch Size: 1778 bytes Desc: not available URL: From npmccallum at redhat.com Fri Sep 25 16:18:00 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 25 Sep 2015 12:18:00 -0400 Subject: [Freeipa-devel] [PATCH] 0087 Fix an integer underflow bug in libotp Message-ID: <1443197880.10697.140.camel@redhat.com> Temporarily storing the offset time in an unsigned integer causes the value of the offset to underflow when a (valid) negative offset value is generated. Using a signed variable avoids this problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0087-Fix-an-integer-underflow-bug-in-libotp.patch Type: text/x-patch Size: 2242 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Sep 25 16:29:51 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 25 Sep 2015 18:29:51 +0200 Subject: [Freeipa-devel] [PATCH 0086] Migrate OTP import script to python-cryptography In-Reply-To: <1443192785.10697.135.camel@redhat.com> References: <1441033728.7711.15.camel@redhat.com> <1443192785.10697.135.camel@redhat.com> Message-ID: <5605767F.3080906@redhat.com> On 09/25/2015 04:53 PM, Nathaniel McCallum wrote: > On Mon, 2015-08-31 at 11:08 -0400, Nathaniel McCallum wrote: >> https://fedorahosted.org/freeipa/ticket/5192 >> -- >> 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 > > Attached patch rebases the previous patch for master. > > Nathaniel > > > Hi Nathaniel, pylint is not happy with your patches: """ ************* Module ipaserver.install.ipa_otptoken_import ipaserver/install/ipa_otptoken_import.py:189: [E1120(no-value-for-parameter), PBKDF2KeyDerivation.__init__] No value for argument 'backend' in constructor call) ipaserver/install/ipa_otptoken_import.py:235: [E1120(no-value-for-parameter), XMLDecryptor.__call__] No value for argument 'backend' in constructor call) """ This is probably the reason for 2 of the otptoken_import tests to fail with TypeError, see http://fpaste.org/271526/31985721/ -- Martin^3 Babinsky From npmccallum at redhat.com Fri Sep 25 16:38:41 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 25 Sep 2015 12:38:41 -0400 Subject: [Freeipa-devel] [PATCH] 0087 Fix an integer underflow bug in libotp In-Reply-To: <1443197880.10697.140.camel@redhat.com> References: <1443197880.10697.140.camel@redhat.com> Message-ID: <1443199121.10697.141.camel@redhat.com> On Fri, 2015-09-25 at 12:18 -0400, Nathaniel McCallum wrote: > Temporarily storing the offset time in an unsigned integer causes the > value of the offset to underflow when a (valid) negative offset value > is generated. Using a signed variable avoids this problem. This new version makes the patch smaller. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0087.1-Fix-an-integer-underflow-bug-in-libotp.patch Type: text/x-patch Size: 1485 bytes Desc: not available URL: From npmccallum at redhat.com Fri Sep 25 17:05:11 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 25 Sep 2015 13:05:11 -0400 Subject: [Freeipa-devel] [PATCH 0086] Migrate OTP import script to python-cryptography In-Reply-To: <5605767F.3080906@redhat.com> References: <1441033728.7711.15.camel@redhat.com> <1443192785.10697.135.camel@redhat.com> <5605767F.3080906@redhat.com> Message-ID: <1443200711.10697.142.camel@redhat.com> On Fri, 2015-09-25 at 18:29 +0200, Martin Babinsky wrote: > On 09/25/2015 04:53 PM, Nathaniel McCallum wrote: > > On Mon, 2015-08-31 at 11:08 -0400, Nathaniel McCallum wrote: > > > https://fedorahosted.org/freeipa/ticket/5192 > > > -- > > > 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/Cod > > > e > > > > Attached patch rebases the previous patch for master. > > > > Nathaniel > > > > > > > Hi Nathaniel, > > pylint is not happy with your patches: > > """ > ************* Module ipaserver.install.ipa_otptoken_import > ipaserver/install/ipa_otptoken_import.py:189: > [E1120(no-value-for-parameter), PBKDF2KeyDerivation.__init__] No > value > for argument 'backend' in constructor call) > ipaserver/install/ipa_otptoken_import.py:235: > [E1120(no-value-for-parameter), XMLDecryptor.__call__] No value for > argument 'backend' in constructor call) > """ > > This is probably the reason for 2 of the otptoken_import tests to > fail > with TypeError, see http://fpaste.org/271526/31985721/ Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0086.2-Migrate-OTP-import-script-to-python-cryptography.patch Type: text/x-patch Size: 14201 bytes Desc: not available URL: From pspacek at redhat.com Tue Sep 29 06:51:47 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 29 Sep 2015 08:51:47 +0200 Subject: [Freeipa-devel] [rfc-dist] RFC 7642 on System for Cross-domain Identity Management (SCIM) In-Reply-To: <20150925233454.9ADDF18380A@rfc-editor.org> References: <20150925233454.9ADDF18380A@rfc-editor.org> Message-ID: <560A3503.2030305@redhat.com> Hello, I did not read any of the RFCs referenced below, but it sounds relevant to us: 1. Introduction [...] Unlike the practice of some protocols like Application Bridging for Federated Access Beyond web (ABFAB) and SAML2 WebSSO, SCIM provides provisioning and de-provisioning of resources in a separate context from authentication (aka just-in-time provisioning). [...] 2. SCIM User Scenarios 2.1. Background and Context The System for Cross-domain Identity Management (SCIM) specification is designed to manage user identity in cloud-based applications and services in a standardized way to enable interoperability, security, and scalability. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. The intent of the SCIM specification is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. Links: * http://tools.ietf.org/html/rfc7642 * http://tools.ietf.org/html/rfc7643 * http://tools.ietf.org/html/rfc7644 I hope this is not just noise. Petr^2 Spacek -------- Forwarded Message -------- Subject: [rfc-dist] RFC 7642 on System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements Date: Fri, 25 Sep 2015 16:34:54 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: drafts-update-ref at iana.org, scim at ietf.org, rfc-editor at rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7642 Title: System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements Author: K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan Status: Informational Stream: IETF Date: September 2015 Mailbox: kepeng.lkp at alibaba-inc.com, phil.hunt at oracle.com, vumip1 at gmail.com, tonynad at microsoft.com, zachary.zeltsan at gmail.com Pages: 19 Characters: 38759 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-scim-use-cases-08.txt URL: https://www.rfc-editor.org/info/rfc7642 DOI: http://dx.doi.org/10.17487/RFC7642 This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements. This document is a product of the System for Cross-domain Identity Management Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ rfc-dist mailing list rfc-dist at rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-dist http://www.rfc-editor.org -- Petr^2 Spacek From ofayans at redhat.com Tue Sep 29 07:12:32 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 29 Sep 2015 09:12:32 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <56025122.8090203@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> Message-ID: <560A39E0.2090507@redhat.com> Hi all, On 09/23/2015 09:13 AM, Petr Spacek wrote: > On 22.9.2015 10:42, Oleg Fayans wrote: >> +++ b/ipatests/test_integration/tasks.py >> @@ -58,6 +58,14 @@ def check_arguments_are(slice, instanceof): >> return wrapped >> return wrapper >> >> +def prepare_reverse_zone(host, ip): >> + nums = ip.split('.')[:-1] >> + zone = ".".join(reversed(nums)) + ".in-addr.arpa." >> + host.run_command(["ipa", >> + "dnszone-add", >> + zone, >> + "--name-from-ip=%s" % ip], raiseonerr=False) >> + > > NACK: > - this will break IPv6-only hosts > - you should use DNSName class or other functions from python-dns for DNS name > manipulation > > I hope this helps. Thanks, it did :) Used a ipalib.util get_reverse_zone_default function that does just that: creates a reverse zone name. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0007.1-Added-a-proper-workaround-for-dnssec-test-failures.patch Type: text/x-patch Size: 2894 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Sep 29 10:00:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 29 Sep 2015 12:00:05 +0200 Subject: [Freeipa-devel] [PATCH 0086] Migrate OTP import script to python-cryptography In-Reply-To: <1443200711.10697.142.camel@redhat.com> References: <1441033728.7711.15.camel@redhat.com> <1443192785.10697.135.camel@redhat.com> <5605767F.3080906@redhat.com> <1443200711.10697.142.camel@redhat.com> Message-ID: <560A6125.9090506@redhat.com> On 09/25/2015 07:05 PM, Nathaniel McCallum wrote: > On Fri, 2015-09-25 at 18:29 +0200, Martin Babinsky wrote: >> On 09/25/2015 04:53 PM, Nathaniel McCallum wrote: >>> On Mon, 2015-08-31 at 11:08 -0400, Nathaniel McCallum wrote: >>>> https://fedorahosted.org/freeipa/ticket/5192 >>>> -- >>>> 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/Cod >>>> e >>> >>> Attached patch rebases the previous patch for master. >>> >>> Nathaniel >>> >>> >>> >> Hi Nathaniel, >> >> pylint is not happy with your patches: >> >> """ >> ************* Module ipaserver.install.ipa_otptoken_import >> ipaserver/install/ipa_otptoken_import.py:189: >> [E1120(no-value-for-parameter), PBKDF2KeyDerivation.__init__] No >> value >> for argument 'backend' in constructor call) >> ipaserver/install/ipa_otptoken_import.py:235: >> [E1120(no-value-for-parameter), XMLDecryptor.__call__] No value for >> argument 'backend' in constructor call) >> """ >> >> This is probably the reason for 2 of the otptoken_import tests to >> fail >> with TypeError, see http://fpaste.org/271526/31985721/ > > Fixed. > Nathaniel, I still get two failing tests (see http://fpaste.org/272526/14435143/). I also noticed some other issues with OTP importing code, but those are probably beyond the scope of your patch: ipa-otptoken-import prints the following error when attempting to add token to IPA: Error adding token: no context.ldap2_140453224789456 in thread 'MainThread' This is caused by incorrect creation of ldap2 connection in the 'run()' method of 'ipa_otptoken_import.py'. I think we should connect to LDAP directly using api.Backend.ldap2: @@ -510,9 +510,8 @@ class OTPTokenImport(admintool.AdminTool): api.bootstrap(in_server=True) api.finalize() - conn = ldap2(api) try: - conn.connect() + api.Backend.ldap2.connect() except (gssapi.exceptions.GSSError, errors.ACIError): raise admintool.ScriptError("Unable to connect to LDAP! Did you kinit?") @@ -527,7 +526,7 @@ class OTPTokenImport(admintool.AdminTool): self.log.info("Added token: %s", keypkg.id) keypkg.remove() finally: - conn.disconnect() + api.Backend.ldap2.disconnect() # Write out the XML file without the tokens that succeeded. self.doc.save(self.output) However, this approach doesn't work when 'ipa-otptoken-import' is run as root on IPA master: in this case ldap2 connects using autobind and does not set principal in the context. This causes the logic which guesses the token owner in 'otptoken_add' to explode violently (http://fpaste.org/272543/35164611/). Should I file a separate ticket for this issue? -- Martin^3 Babinsky From tbabej at redhat.com Tue Sep 29 11:57:07 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 29 Sep 2015 13:57:07 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Fix an integer underflow bug in libotp In-Reply-To: <1443199121.10697.141.camel@redhat.com> References: <1443197880.10697.140.camel@redhat.com> <1443199121.10697.141.camel@redhat.com> Message-ID: <560A7C93.7070407@redhat.com> On 09/25/2015 06:38 PM, Nathaniel McCallum wrote: > On Fri, 2015-09-25 at 12:18 -0400, Nathaniel McCallum wrote: >> Temporarily storing the offset time in an unsigned integer causes the >> value of the offset to underflow when a (valid) negative offset value >> is generated. Using a signed variable avoids this problem. > > This new version makes the patch smaller. > > > ACK, this fixes the issue, I was able to synchronize with negative offset after applying the patch. ipa otptoken-find --all ------------------- 1 OTP token matched ------------------- dn: ipatokenuniqueid=1e7a8029-8872-46f5-8254-9d03a62d2417,cn=otp,dc=ipa,dc=test Unique ID: 1e7a8029-8872-46f5-8254-9d03a62d2417 Type: TOTP Owner: test Key: eu/S8oUunB188tRc5HE8CkxMmyI= Algorithm: sha1 Digits: 6 Clock offset: 4294963816 Clock interval: 30 ipatokentotpwatermark: 48117551 objectclass: top, ipatokentotp, ipatoken ---------------------------- Number of entries returned 1 ---------------------------- [master]$ ipa otptoken-sync User ID: test Password: First Code: Second Code: Token synchronized. [master]$ ipa otptoken-find --all ------------------- 1 OTP token matched ------------------- dn: ipatokenuniqueid=1e7a8029-8872-46f5-8254-9d03a62d2417,cn=otp,dc=ipa,dc=test Unique ID: 1e7a8029-8872-46f5-8254-9d03a62d2417 Type: TOTP Owner: test Key: eu/S8oUunB188tRc5HE8CkxMmyI= Algorithm: sha1 Digits: 6 Clock offset: -3450 Clock interval: 30 ipatokentotpwatermark: 48117590 objectclass: top, ipatokentotp, ipatoken ---------------------------- Number of entries returned 1 ---------------------------- From tbabej at redhat.com Tue Sep 29 13:10:41 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 29 Sep 2015 15:10:41 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Fix an integer underflow bug in libotp In-Reply-To: <560A7C93.7070407@redhat.com> References: <1443197880.10697.140.camel@redhat.com> <1443199121.10697.141.camel@redhat.com> <560A7C93.7070407@redhat.com> Message-ID: <560A8DD1.6070104@redhat.com> On 09/29/2015 01:57 PM, Tomas Babej wrote: > > On 09/25/2015 06:38 PM, Nathaniel McCallum wrote: >> On Fri, 2015-09-25 at 12:18 -0400, Nathaniel McCallum wrote: >>> Temporarily storing the offset time in an unsigned integer causes the >>> value of the offset to underflow when a (valid) negative offset value >>> is generated. Using a signed variable avoids this problem. >> >> This new version makes the patch smaller. >> >> >> > > ACK, this fixes the issue, I was able to synchronize with negative > offset after applying the patch. Pushed to: master: d3cca6db57fb26aea1d45bc522336dddc6256825 ipa-4-2: 3c52f62e6c4e07b107780d95a6a4ff79d89c75b9 Issue filed under: https://fedorahosted.org/freeipa/ticket/5333 From mkubik at redhat.com Tue Sep 29 13:11:31 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 29 Sep 2015 15:11:31 +0200 Subject: [Freeipa-devel] [PATCHES 466-468, 0316] install: Add common base class for server and replica install In-Reply-To: <5602BECD.8070705@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> <55F7AB23.5040805@redhat.com> <55F907FA.40202@redhat.com> <55F92BF3.6010604@redhat.com> <56011150.6050106@redhat.com> <56012919.4000007@redhat.com> <5602BECD.8070705@redhat.com> Message-ID: <560A8E03.70002@redhat.com> On 09/23/2015 05:01 PM, Martin Basti wrote: > > > On 09/22/2015 12:10 PM, Jan Cholasta wrote: >> On 22.9.2015 10:29, Martin Babinsky wrote: >>> On 09/16/2015 10:44 AM, Jan Cholasta wrote: >>>> On 16.9.2015 08:11, Jan Cholasta wrote: >>>>> On 15.9.2015 07:22, Jan Cholasta wrote: >>>>>> On 10.8.2015 16:58, Martin Babinsky wrote: >>>>>>> On 08/06/2015 08:22 AM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patch fixes part of >>>>>>>> . >>>>>>>> >>>>>>>> See also Martin Babinsky's patch 51: >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> Sorry but NACK, see below: >>>>>>> >>>>>>> 1.) it seems that passing kwargs to Server components doesn't >>>>>>> work as >>>>>>> expected. See these logs (install on fresh F22 VM): >>>>>>> >>>>>>> http://fpaste.org/253416/21363814/ >>>>>>> http://fpaste.org/253419/43921374/ >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> 2.) the following code blows up in BaseServers' __init__: >>>>>>> (http://fpaste.org/253400/21225314/) >>>>>>> >>>>>>> 392 if not self.dns.setup_dns: >>>>>>> 393 if self.dns.forwarders: >>>>>>> 394 raise RuntimeError( >>>>>>> 395 "You cannot specify a --forwarder option >>>>>>> without >>>>>>> the " >>>>>>> 396 "--setup-dns option") >>>>>>> >>>>>>> >>>>>>> I think that the check should be: >>>>>>> >>>>>>> 392 if not self.setup_dns: >>>>>>> 393 if self.dns.forwarders: >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> IMHO BaseServerDNS class shouldn't have setup_dns knob, that >>>>>>> should be >>>>>>> set in the parent class (BaseServer) >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> >>>>>>> 3.) Is there any reason why BaseServer doesn't have >>>>>>> 'master_password', >>>>>>> 'idmax' and 'idstart' knobs? I know that these are then brought >>>>>>> in by >>>>>>> the derived Server class, but the check for them is in parent's >>>>>>> __init__() method and it is IMHO a bit confusing >>>>>> >>>>>> The check should be in Server, fixed. >>>>>> >>>>>>> >>>>>>> 4.) please add license header to the beginning of >>>>>>> 'ipaserver/install/server/common.py' file >>>>>> >>>>>> Added. >>>>>> >>>>>> Updated patches attached. >>>>> >>>>> Self-NACK, I broke ipa-server-install --uninstall. >>>> >>>> Fixed. >>>> >>> >>> ACK to all three patches. >>> >> >> Thanks. >> >> Pushed to: >> master: 86edd6abeb9749e159a529b83cfce6443fff4ba5 >> ipa-4-2: 42d16b02cd153ac89ebd8ae07c98611dc3b6e471 >> > These patches introduced regression. > ipa-replica-install in unattended mode requires to specify -a, -p and > -r options. > > Attached patch fixes it. > > > Works for me, ACK. Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Sep 29 13:15:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 29 Sep 2015 15:15:41 +0200 Subject: [Freeipa-devel] [PATCHES 466-468, 0316] install: Add common base class for server and replica install In-Reply-To: <560A8E03.70002@redhat.com> References: <55C2FD30.4030303@redhat.com> <55C8BBFF.7090907@redhat.com> <55F7AB23.5040805@redhat.com> <55F907FA.40202@redhat.com> <55F92BF3.6010604@redhat.com> <56011150.6050106@redhat.com> <56012919.4000007@redhat.com> <5602BECD.8070705@redhat.com> <560A8E03.70002@redhat.com> Message-ID: <560A8EFD.8070006@redhat.com> On 09/29/2015 03:11 PM, Milan Kub?k wrote: > On 09/23/2015 05:01 PM, Martin Basti wrote: >> >> >> On 09/22/2015 12:10 PM, Jan Cholasta wrote: >>> On 22.9.2015 10:29, Martin Babinsky wrote: >>>> On 09/16/2015 10:44 AM, Jan Cholasta wrote: >>>>> On 16.9.2015 08:11, Jan Cholasta wrote: >>>>>> On 15.9.2015 07:22, Jan Cholasta wrote: >>>>>>> On 10.8.2015 16:58, Martin Babinsky wrote: >>>>>>>> On 08/06/2015 08:22 AM, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the attached patch fixes part of >>>>>>>>> . >>>>>>>>> >>>>>>>>> See also Martin Babinsky's patch 51: >>>>>>>>> . >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> Sorry but NACK, see below: >>>>>>>> >>>>>>>> 1.) it seems that passing kwargs to Server components doesn't >>>>>>>> work as >>>>>>>> expected. See these logs (install on fresh F22 VM): >>>>>>>> >>>>>>>> http://fpaste.org/253416/21363814/ >>>>>>>> http://fpaste.org/253419/43921374/ >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> >>>>>>>> 2.) the following code blows up in BaseServers' __init__: >>>>>>>> (http://fpaste.org/253400/21225314/) >>>>>>>> >>>>>>>> 392 if not self.dns.setup_dns: >>>>>>>> 393 if self.dns.forwarders: >>>>>>>> 394 raise RuntimeError( >>>>>>>> 395 "You cannot specify a --forwarder option >>>>>>>> without >>>>>>>> the " >>>>>>>> 396 "--setup-dns option") >>>>>>>> >>>>>>>> >>>>>>>> I think that the check should be: >>>>>>>> >>>>>>>> 392 if not self.setup_dns: >>>>>>>> 393 if self.dns.forwarders: >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> >>>>>>>> IMHO BaseServerDNS class shouldn't have setup_dns knob, that >>>>>>>> should be >>>>>>>> set in the parent class (BaseServer) >>>>>>> >>>>>>> Fixed. >>>>>>> >>>>>>>> >>>>>>>> 3.) Is there any reason why BaseServer doesn't have >>>>>>>> 'master_password', >>>>>>>> 'idmax' and 'idstart' knobs? I know that these are then brought >>>>>>>> in by >>>>>>>> the derived Server class, but the check for them is in parent's >>>>>>>> __init__() method and it is IMHO a bit confusing >>>>>>> >>>>>>> The check should be in Server, fixed. >>>>>>> >>>>>>>> >>>>>>>> 4.) please add license header to the beginning of >>>>>>>> 'ipaserver/install/server/common.py' file >>>>>>> >>>>>>> Added. >>>>>>> >>>>>>> Updated patches attached. >>>>>> >>>>>> Self-NACK, I broke ipa-server-install --uninstall. >>>>> >>>>> Fixed. >>>>> >>>> >>>> ACK to all three patches. >>>> >>> >>> Thanks. >>> >>> Pushed to: >>> master: 86edd6abeb9749e159a529b83cfce6443fff4ba5 >>> ipa-4-2: 42d16b02cd153ac89ebd8ae07c98611dc3b6e471 >>> >> These patches introduced regression. >> ipa-replica-install in unattended mode requires to specify -a, -p and >> -r options. >> >> Attached patch fixes it. >> >> >> > Works for me, ACK. > > Milan Pushed to ipa-4-2: ad285897f54190fd0113209f32fce7f37fb0ce77 Pushed to master: 74da4f5870edda85039b3bba52fb0a578676fb44 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Sep 29 13:19:59 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 29 Sep 2015 15:19:59 +0200 Subject: [Freeipa-devel] [PATCH] 0087 Fix an integer underflow bug in libotp In-Reply-To: <560A8DD1.6070104@redhat.com> References: <1443197880.10697.140.camel@redhat.com> <1443199121.10697.141.camel@redhat.com> <560A7C93.7070407@redhat.com> <560A8DD1.6070104@redhat.com> Message-ID: <560A8FFF.6060405@redhat.com> On 09/29/2015 03:10 PM, Tomas Babej wrote: > > > On 09/29/2015 01:57 PM, Tomas Babej wrote: >> >> On 09/25/2015 06:38 PM, Nathaniel McCallum wrote: >>> On Fri, 2015-09-25 at 12:18 -0400, Nathaniel McCallum wrote: >>>> Temporarily storing the offset time in an unsigned integer causes the >>>> value of the offset to underflow when a (valid) negative offset value >>>> is generated. Using a signed variable avoids this problem. >>> >>> This new version makes the patch smaller. >>> >>> >>> >> >> ACK, this fixes the issue, I was able to synchronize with negative >> offset after applying the patch. > > Pushed to: > master: d3cca6db57fb26aea1d45bc522336dddc6256825 > ipa-4-2: 3c52f62e6c4e07b107780d95a6a4ff79d89c75b9 > > Issue filed under: https://fedorahosted.org/freeipa/ticket/5333 > Well, actually, correct hashes are: Pushed to: master: 9e3eeadeb3120f3577e00ab9cb410eccf8d71de0 ipa-4-2: 7db0a8e8512733ff91462b9b3b20c21ad6ec4212 From dkupka at redhat.com Tue Sep 29 13:27:41 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 29 Sep 2015 15:27:41 +0200 Subject: [Freeipa-devel] [PATCH 0066] fix for regression in ipa-restore In-Reply-To: <560572B3.9010801@redhat.com> References: <560572B3.9010801@redhat.com> Message-ID: <560A91CD.4020101@redhat.com> On 25/09/15 18:13, Martin Babinsky wrote: > fixes https://fedorahosted.org/freeipa/ticket/5328 > > > Fixes the issue for me, ACK. -- David Kupka From jpazdziora at redhat.com Tue Sep 29 13:28:26 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 29 Sep 2015 15:28:26 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5603F646.5090004@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> Message-ID: <20150929132826.GA1529@redhat.com> On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: > > I think the problem is that the patch was pushed prematurely. > The option should become unused once the other patches in this patchset are > applied, that is why that patch was not on top of the list but rather down > close to the bottom. Simo, could you please add the How To Test steps to http://www.freeipa.org/page/V4/Replica_Promotion? It would make the functional check of this patchset easier, spelling out how the workflow is supposed to work. Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From simo at redhat.com Tue Sep 29 13:55:15 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Sep 2015 09:55:15 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <20150929132826.GA1529@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> Message-ID: <560A9843.6000407@redhat.com> On 29/09/15 09:28, Jan Pazdziora wrote: > On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: >> >> I think the problem is that the patch was pushed prematurely. >> The option should become unused once the other patches in this patchset are >> applied, that is why that patch was not on top of the list but rather down >> close to the bottom. > > Simo, > > could you please add the > > How To Test > > steps to http://www.freeipa.org/page/V4/Replica_Promotion? > > It would make the functional check of this patchset easier, spelling > out how the workflow is supposed to work. Done. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From ofayans at redhat.com Tue Sep 29 14:39:49 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 29 Sep 2015 16:39:49 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560A9843.6000407@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> <560A9843.6000407@redhat.com> Message-ID: <560AA2B5.2040303@redhat.com> Hi Simo, Is this [1] the correct link to the repo containing all latest replica-promotion patches? I tried to build the packages from this code and the build failed due to libpdb not having make_pdb_method [2] I was able to successfully build from the clean upstream tree on the same machine. [1] https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review [2] https://paste.fedoraproject.org/272672/53685114/ On 09/29/2015 03:55 PM, Simo Sorce wrote: > On 29/09/15 09:28, Jan Pazdziora wrote: >> On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: >>> >>> I think the problem is that the patch was pushed prematurely. >>> The option should become unused once the other patches in this >>> patchset are >>> applied, that is why that patch was not on top of the list but rather >>> down >>> close to the bottom. >> >> Simo, >> >> could you please add the >> >> How To Test >> >> steps to http://www.freeipa.org/page/V4/Replica_Promotion? >> >> It would make the functional check of this patchset easier, spelling >> out how the workflow is supposed to work. > > Done. > > HTH, > Simo. > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From simo at redhat.com Tue Sep 29 14:54:05 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Sep 2015 10:54:05 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560AA2B5.2040303@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> <560A9843.6000407@redhat.com> <560AA2B5.2040303@redhat.com> Message-ID: <560AA60D.6060703@redhat.com> On 29/09/15 10:39, Oleg Fayans wrote: > Hi Simo, > > Is this [1] the correct link to the repo containing all latest > replica-promotion patches? I tried to build the packages from this code > and the build failed due to libpdb not having make_pdb_method [2] > I was able to successfully build from the clean upstream tree on the > same machine. I rebased it on top of current master, let me know if this helps. Simo. > > [1] > https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > [2] https://paste.fedoraproject.org/272672/53685114/ > > On 09/29/2015 03:55 PM, Simo Sorce wrote: >> On 29/09/15 09:28, Jan Pazdziora wrote: >>> On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: >>>> >>>> I think the problem is that the patch was pushed prematurely. >>>> The option should become unused once the other patches in this >>>> patchset are >>>> applied, that is why that patch was not on top of the list but rather >>>> down >>>> close to the bottom. >>> >>> Simo, >>> >>> could you please add the >>> >>> How To Test >>> >>> steps to http://www.freeipa.org/page/V4/Replica_Promotion? >>> >>> It would make the functional check of this patchset easier, spelling >>> out how the workflow is supposed to work. >> >> Done. >> >> HTH, >> Simo. >> >> > -- Simo Sorce * Red Hat, Inc * New York From ofayans at redhat.com Tue Sep 29 15:50:45 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 29 Sep 2015 17:50:45 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560AA60D.6060703@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> <560A9843.6000407@redhat.com> <560AA2B5.2040303@redhat.com> <560AA60D.6060703@redhat.com> Message-ID: <560AB355.9070503@redhat.com> Hi Simo, It seems to have resolved the initial issue, but now the build fails due to lint complaints: https://paste.fedoraproject.org/272714/54174014/ On 09/29/2015 04:54 PM, Simo Sorce wrote: > On 29/09/15 10:39, Oleg Fayans wrote: >> Hi Simo, >> >> Is this [1] the correct link to the repo containing all latest >> replica-promotion patches? I tried to build the packages from this code >> and the build failed due to libpdb not having make_pdb_method [2] >> I was able to successfully build from the clean upstream tree on the >> same machine. > > > I rebased it on top of current master, let me know if this helps. > > Simo. > >> >> [1] >> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >> >> >> [2] https://paste.fedoraproject.org/272672/53685114/ >> >> On 09/29/2015 03:55 PM, Simo Sorce wrote: >>> On 29/09/15 09:28, Jan Pazdziora wrote: >>>> On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: >>>>> >>>>> I think the problem is that the patch was pushed prematurely. >>>>> The option should become unused once the other patches in this >>>>> patchset are >>>>> applied, that is why that patch was not on top of the list but rather >>>>> down >>>>> close to the bottom. >>>> >>>> Simo, >>>> >>>> could you please add the >>>> >>>> How To Test >>>> >>>> steps to http://www.freeipa.org/page/V4/Replica_Promotion? >>>> >>>> It would make the functional check of this patchset easier, spelling >>>> out how the workflow is supposed to work. >>> >>> Done. >>> >>> HTH, >>> Simo. >>> >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From simo at redhat.com Tue Sep 29 16:47:30 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Sep 2015 12:47:30 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560AB355.9070503@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> <560A9843.6000407@redhat.com> <560AA2B5.2040303@redhat.com> <560AA60D.6060703@redhat.com> <560AB355.9070503@redhat.com> Message-ID: <560AC0A2.8020300@redhat.com> On 29/09/15 11:50, Oleg Fayans wrote: > Hi Simo, > > It seems to have resolved the initial issue, but now the build fails due > to lint complaints: https://paste.fedoraproject.org/272714/54174014/ These happens if you do not have custodia installed. I guess I should make it also a BuildRequires ? Simo. > On 09/29/2015 04:54 PM, Simo Sorce wrote: >> On 29/09/15 10:39, Oleg Fayans wrote: >>> Hi Simo, >>> >>> Is this [1] the correct link to the repo containing all latest >>> replica-promotion patches? I tried to build the packages from this code >>> and the build failed due to libpdb not having make_pdb_method [2] >>> I was able to successfully build from the clean upstream tree on the >>> same machine. >> >> >> I rebased it on top of current master, let me know if this helps. >> >> Simo. >> >>> >>> [1] >>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>> >>> >>> >>> [2] https://paste.fedoraproject.org/272672/53685114/ >>> >>> On 09/29/2015 03:55 PM, Simo Sorce wrote: >>>> On 29/09/15 09:28, Jan Pazdziora wrote: >>>>> On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: >>>>>> >>>>>> I think the problem is that the patch was pushed prematurely. >>>>>> The option should become unused once the other patches in this >>>>>> patchset are >>>>>> applied, that is why that patch was not on top of the list but rather >>>>>> down >>>>>> close to the bottom. >>>>> >>>>> Simo, >>>>> >>>>> could you please add the >>>>> >>>>> How To Test >>>>> >>>>> steps to http://www.freeipa.org/page/V4/Replica_Promotion? >>>>> >>>>> It would make the functional check of this patchset easier, spelling >>>>> out how the workflow is supposed to work. >>>> >>>> Done. >>>> >>>> HTH, >>>> Simo. >>>> >>>> >>> >> >> > -- Simo Sorce * Red Hat, Inc * New York From ofayans at redhat.com Tue Sep 29 18:56:16 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 29 Sep 2015 20:56:16 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560AC0A2.8020300@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> <560A9843.6000407@redhat.com> <560AA2B5.2040303@redhat.com> <560AA60D.6060703@redhat.com> <560AB355.9070503@redhat.com> <560AC0A2.8020300@redhat.com> Message-ID: <560ADED0.9020006@redhat.com> On 09/29/2015 06:47 PM, Simo Sorce wrote: > On 29/09/15 11:50, Oleg Fayans wrote: >> Hi Simo, >> >> It seems to have resolved the initial issue, but now the build fails due >> to lint complaints: https://paste.fedoraproject.org/272714/54174014/ > > These happens if you do not have custodia installed. > I guess I should make it also a BuildRequires ? I think so, yes. > > Simo. > >> On 09/29/2015 04:54 PM, Simo Sorce wrote: >>> On 29/09/15 10:39, Oleg Fayans wrote: >>>> Hi Simo, >>>> >>>> Is this [1] the correct link to the repo containing all latest >>>> replica-promotion patches? I tried to build the packages from this code >>>> and the build failed due to libpdb not having make_pdb_method [2] >>>> I was able to successfully build from the clean upstream tree on the >>>> same machine. >>> >>> >>> I rebased it on top of current master, let me know if this helps. >>> >>> Simo. >>> >>>> >>>> [1] >>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>> >>>> >>>> >>>> >>>> [2] https://paste.fedoraproject.org/272672/53685114/ >>>> >>>> On 09/29/2015 03:55 PM, Simo Sorce wrote: >>>>> On 29/09/15 09:28, Jan Pazdziora wrote: >>>>>> On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: >>>>>>> >>>>>>> I think the problem is that the patch was pushed prematurely. >>>>>>> The option should become unused once the other patches in this >>>>>>> patchset are >>>>>>> applied, that is why that patch was not on top of the list but >>>>>>> rather >>>>>>> down >>>>>>> close to the bottom. >>>>>> >>>>>> Simo, >>>>>> >>>>>> could you please add the >>>>>> >>>>>> How To Test >>>>>> >>>>>> steps to http://www.freeipa.org/page/V4/Replica_Promotion? >>>>>> >>>>>> It would make the functional check of this patchset easier, spelling >>>>>> out how the workflow is supposed to work. >>>>> >>>>> Done. >>>>> >>>>> HTH, >>>>> Simo. >>>>> >>>>> >>>> >>> >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From simo at redhat.com Tue Sep 29 19:31:23 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Sep 2015 15:31:23 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560ADED0.9020006@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> <560A9843.6000407@redhat.com> <560AA2B5.2040303@redhat.com> <560AA60D.6060703@redhat.com> <560AB355.9070503@redhat.com> <560AC0A2.8020300@redhat.com> <560ADED0.9020006@redhat.com> Message-ID: <560AE70B.5020700@redhat.com> On 29/09/15 14:56, Oleg Fayans wrote: > > > On 09/29/2015 06:47 PM, Simo Sorce wrote: >> On 29/09/15 11:50, Oleg Fayans wrote: >>> Hi Simo, >>> >>> It seems to have resolved the initial issue, but now the build fails due >>> to lint complaints: https://paste.fedoraproject.org/272714/54174014/ >> >> These happens if you do not have custodia installed. >> I guess I should make it also a BuildRequires ? > > I think so, yes. Turns out it is already there. Simo. >> Simo. >> >>> On 09/29/2015 04:54 PM, Simo Sorce wrote: >>>> On 29/09/15 10:39, Oleg Fayans wrote: >>>>> Hi Simo, >>>>> >>>>> Is this [1] the correct link to the repo containing all latest >>>>> replica-promotion patches? I tried to build the packages from this >>>>> code >>>>> and the build failed due to libpdb not having make_pdb_method [2] >>>>> I was able to successfully build from the clean upstream tree on the >>>>> same machine. >>>> >>>> >>>> I rebased it on top of current master, let me know if this helps. >>>> >>>> Simo. >>>> >>>>> >>>>> [1] >>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [2] https://paste.fedoraproject.org/272672/53685114/ >>>>> >>>>> On 09/29/2015 03:55 PM, Simo Sorce wrote: >>>>>> On 29/09/15 09:28, Jan Pazdziora wrote: >>>>>>> On Thu, Sep 24, 2015 at 09:10:30AM -0400, Simo Sorce wrote: >>>>>>>> >>>>>>>> I think the problem is that the patch was pushed prematurely. >>>>>>>> The option should become unused once the other patches in this >>>>>>>> patchset are >>>>>>>> applied, that is why that patch was not on top of the list but >>>>>>>> rather >>>>>>>> down >>>>>>>> close to the bottom. >>>>>>> >>>>>>> Simo, >>>>>>> >>>>>>> could you please add the >>>>>>> >>>>>>> How To Test >>>>>>> >>>>>>> steps to http://www.freeipa.org/page/V4/Replica_Promotion? >>>>>>> >>>>>>> It would make the functional check of this patchset easier, spelling >>>>>>> out how the workflow is supposed to work. >>>>>> >>>>>> Done. >>>>>> >>>>>> HTH, >>>>>> Simo. >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Simo Sorce * Red Hat, Inc * New York From brian at bstinson.com Wed Sep 30 02:32:02 2015 From: brian at bstinson.com (Brian Stinson) Date: Tue, 29 Sep 2015 21:32:02 -0500 Subject: [Freeipa-devel] The Community Auth.NEXT Working Group Inagural Meeting Message-ID: <20150930023202.GB12870@ender.bstinson.lan> Hi FreeIPA! We are starting a working group of member projects looking to solve problems related to Community Authentication. The FreeIPA Community Portal feature added this summer is one of the important bits we are evaluating. We are hoping to collaborate on centos-devel at centos.org, and have IRC meetings in #centos-devel on Freenode every now and then to check in. We currently have interest from CentOS, Fedora, and a few other projects, and would love to invite anyone interested to participate. Patrick Uiterwijk will be starting a thread soon scheduling our next IRC meeting in 2 weeks time. Here are the minutes from our first meeting: ========================================================================= #centos-devel: Community Authentication Working Group Meeting 29-Sep-2015 ========================================================================= Meeting started by puiterwijk at 13:00:07 UTC. The full logs are available at https://www.centos.org/minutes/2015/september/centos-devel.2015-09-29-13.00.html Meeting summary --------------- * Working Group Intro (puiterwijk, 13:00:27) * LINK: https://lists.centos.org/pipermail/centos-devel/2015-September/013854.html (puiterwijk, 13:03:22) * AGREED: mailing list for discussions: centos-devel, notifications cross-posted to community-auth-next-wg list at fedorahosted (puiterwijk, 13:17:59) * ACTION: bstinson to distribute minutes to the IPA team, and do a call for a WG representative (bstinson, 13:25:41) * Goals (puiterwijk, 13:28:13) * LINK: https://lists.fedorahosted.org/pipermail/community-auth-next-wg/2015-September/000000.html (puiterwijk, 13:28:43) * AGREED: adopt puiterwijk's two goals from the community-auth-next-wg mailing list, and add in a technical goal of collaborating on a FAS -> IPA migration (puiterwijk, 13:42:02) * Agreed: adopt puiterwijk's two goals from the community-auth-next-wg mailing list, and add in a technical goal of collaborating on a FAS -> IPA migration (puiterwijk, 13:42:38) * GOAL: determine what features FreeIPA with the community portal lacks to replace FAS for community projects (bstinson, 13:42:44) * GOAL: coordinate their development if the FreeIPA community is willing to add them to make FreeIPA a valid replacement for FAS (bstinson, 13:43:05) * GOAL: ensuring that there is a migration path from FAS => IPA (bstinson, 13:43:20) * Neither Fedora Infra nor CentOS will commit to moving to IPA as part of this working group at this point (puiterwijk, 13:44:46) * ACTION: puiterwijk to start a requirements gathering thread (bstinson, 13:50:13) * ACTION: puiterwijk to start a "scheduling" thread for the next syncup meeting (~2 weeks) (bstinson, 13:55:46) * ACTION: bstinson to cross-post the first meeting's minutes to centos-devel, community-auth-next-wg, and freeipa-devel(with an introduction) (bstinson, 13:56:13) * Open floor (puiterwijk, 13:57:02) Meeting ended at 13:58:01 UTC. Action Items ------------ * bstinson to distribute minutes to the IPA team, and do a call for a WG representative * puiterwijk to start a requirements gathering thread * puiterwijk to start a "scheduling" thread for the next syncup meeting (~2 weeks) * bstinson to cross-post the first meeting's minutes to centos-devel, community-auth-next-wg, and freeipa-devel(with an introduction) Action Items, by person ----------------------- * bstinson * bstinson to distribute minutes to the IPA team, and do a call for a WG representative * bstinson to cross-post the first meeting's minutes to centos-devel, community-auth-next-wg, and freeipa-devel(with an introduction) * puiterwijk * puiterwijk to start a requirements gathering thread * puiterwijk to start a "scheduling" thread for the next syncup meeting (~2 weeks) * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * puiterwijk (84) * bstinson (46) * Arrfab (16) * csim (15) * gwd (3) * centbot (3) * kbsingh (2) * billings (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot Cheers! -- Brian Stinson CentOS Infrastructure Team From abokovoy at redhat.com Wed Sep 30 06:05:07 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 30 Sep 2015 09:05:07 +0300 Subject: [Freeipa-devel] The Community Auth.NEXT Working Group Inagural Meeting In-Reply-To: <20150930023202.GB12870@ender.bstinson.lan> References: <20150930023202.GB12870@ender.bstinson.lan> Message-ID: <20150930060507.GH4539@redhat.com> On Tue, 29 Sep 2015, Brian Stinson wrote: >Hi FreeIPA! > >We are starting a working group of member projects looking to solve problems >related to Community Authentication. The FreeIPA Community Portal feature added >this summer is one of the important bits we are evaluating. > >We are hoping to collaborate on centos-devel at centos.org, and have IRC meetings >in #centos-devel on Freenode every now and then to check in. We currently have >interest from CentOS, Fedora, and a few other projects, and would love to >invite anyone interested to participate. > >Patrick Uiterwijk will be starting a thread soon scheduling our next IRC >meeting in 2 weeks time. Thanks, Brian. There is also community-auth-next-wg at lists.fedoraproject.org for the same purpose around Fedora Project needs. Reading your first meeting notes, it is unclear why we couldn't use this list and would instead need to subscribe to centos-devel@ (which I assume has more than this topic to discuss). > >Here are the minutes from our first meeting: > >========================================================================= >#centos-devel: Community Authentication Working Group Meeting 29-Sep-2015 >========================================================================= > > >Meeting started by puiterwijk at 13:00:07 UTC. The full logs are >available at https://www.centos.org/minutes/2015/september/centos-devel.2015-09-29-13.00.html > > > >Meeting summary >--------------- >* Working Group Intro (puiterwijk, 13:00:27) > * LINK: > https://lists.centos.org/pipermail/centos-devel/2015-September/013854.html > (puiterwijk, 13:03:22) > * AGREED: mailing list for discussions: centos-devel, notifications > cross-posted to community-auth-next-wg list at fedorahosted > (puiterwijk, 13:17:59) > * ACTION: bstinson to distribute minutes to the IPA team, and do a > call for a WG representative (bstinson, 13:25:41) > >* Goals (puiterwijk, 13:28:13) > * LINK: > https://lists.fedorahosted.org/pipermail/community-auth-next-wg/2015-September/000000.html > (puiterwijk, 13:28:43) > * AGREED: adopt puiterwijk's two goals from the community-auth-next-wg > mailing list, and add in a technical goal of collaborating on a FAS > -> IPA migration (puiterwijk, 13:42:02) > * Agreed: adopt puiterwijk's two goals from the community-auth-next-wg > mailing list, and add in a technical goal of collaborating on a FAS > -> IPA migration (puiterwijk, 13:42:38) > * GOAL: determine what features FreeIPA with the community portal > lacks to replace FAS for community projects (bstinson, 13:42:44) > * GOAL: coordinate their development if the FreeIPA community is > willing to add them to make FreeIPA a valid replacement for FAS > (bstinson, 13:43:05) > * GOAL: ensuring that there is a migration path from FAS => IPA > (bstinson, 13:43:20) > * Neither Fedora Infra nor CentOS will commit to moving to IPA as part > of this working group at this point (puiterwijk, 13:44:46) > * ACTION: puiterwijk to start a requirements gathering thread > (bstinson, 13:50:13) > * ACTION: puiterwijk to start a "scheduling" thread for the next > syncup meeting (~2 weeks) (bstinson, 13:55:46) > * ACTION: bstinson to cross-post the first meeting's minutes to > centos-devel, community-auth-next-wg, and freeipa-devel(with an > introduction) (bstinson, 13:56:13) > >* Open floor (puiterwijk, 13:57:02) > >Meeting ended at 13:58:01 UTC. > > > > >Action Items >------------ >* bstinson to distribute minutes to the IPA team, and do a call for a WG > representative >* puiterwijk to start a requirements gathering thread >* puiterwijk to start a "scheduling" thread for the next syncup meeting > (~2 weeks) >* bstinson to cross-post the first meeting's minutes to centos-devel, > community-auth-next-wg, and freeipa-devel(with an introduction) > > > > >Action Items, by person >----------------------- >* bstinson > * bstinson to distribute minutes to the IPA team, and do a call for a > WG representative > * bstinson to cross-post the first meeting's minutes to centos-devel, > community-auth-next-wg, and freeipa-devel(with an introduction) >* puiterwijk > * puiterwijk to start a requirements gathering thread > * puiterwijk to start a "scheduling" thread for the next syncup > meeting (~2 weeks) >* **UNASSIGNED** > * (none) > > > > >People Present (lines said) >--------------------------- >* puiterwijk (84) >* bstinson (46) >* Arrfab (16) >* csim (15) >* gwd (3) >* centbot (3) >* kbsingh (2) >* billings (2) > > > > >Generated by `MeetBot`_ 0.1.4 > >.. _`MeetBot`: http://wiki.debian.org/MeetBot > > >Cheers! > >-- >Brian Stinson >CentOS Infrastructure Team > >-- >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 pviktori at redhat.com Wed Sep 30 08:25:16 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Sep 2015 10:25:16 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <5602BB4B.4060206@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> Message-ID: <560B9C6C.2040600@redhat.com> On 09/23/2015 04:46 PM, Petr Viktorin wrote: > On 09/22/2015 02:59 PM, David Kupka wrote: >> On 18/09/15 17:00, Petr Viktorin wrote: >>> Hello, >>> Here are more patches that bring IPA closer to Python 3 compatibility. >>> >>> >>> >>> >> >> Hi Petr, >> thanks for another batch of Python 3 compatibility patches. >> Unfortunately I hit a lot of pylint errors. Some of them are false >> positives for sure. Could you please look at them, mark the false >> positive with "pylint: disable=Exxxx" directive and fix the rest? >> >> http://fpaste.org/270090/92665414/ >> > > Thanks. > I'm actually having some trouble running pylint on an f23 machine; have > you seen this error before? > > $ ./make-lint > Traceback (most recent call last): > File "./make-lint", line 280, in > sys.exit(main()) > File "./make-lint", line 251, in main > linter.check(files) > File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 747, in check > self._do_check(files_or_modules) > File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 869, in > _do_check > self.check_astroid_module(ast_node, walker, rawcheckers, tokencheckers) > File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 924, in > check_astroid_module > tokens = utils.tokenize_module(ast_node) > File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 137, in > tokenize_module > with module.stream() as stream: > AttributeError: 'Module' object has no attribute 'stream' > > > Anyway, I've ran pylint on f21. Updated patches attached. ping, could someone take a look at the patches? -- Petr Viktorin From mbasti at redhat.com Wed Sep 30 08:44:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 30 Sep 2015 10:44:42 +0200 Subject: [Freeipa-devel] [PATCH] 920 webui: improve performance of search in association dialog In-Reply-To: <55FAE399.60506@redhat.com> References: <55E471B8.2020904@redhat.com> <55FAE399.60506@redhat.com> Message-ID: <560BA0FA.1050206@redhat.com> On 09/17/2015 06:00 PM, Petr Vobornik wrote: > On 08/31/2015 05:24 PM, Petr Vobornik wrote: >> By adding no_members option to commands which supports it. >> >> It then skips memberof procession on the server side. >> >> https://fedorahosted.org/freeipa/ticket/5271 >> >> > New version attached with change: > > - var options = { all: true }; > + var options = {}; > > the 'all' option is not needed and actually negates the patch. > > ACK Pushed to: ipa-4-2: bf3121df0d086bcaf2b95903775fefbcafdd18c3 master: 34e6c3ea05b23f4a5fe6fb6aaadd394967f31340 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Sep 30 08:51:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 30 Sep 2015 10:51:55 +0200 Subject: [Freeipa-devel] [PATCH] Replace StandardError with Exception In-Reply-To: <5603BC1E.4020209@redhat.com> References: <55FADDDD.8020801@redhat.com> <5603BC1E.4020209@redhat.com> Message-ID: <560BA2AB.7080404@redhat.com> On 24.9.2015 11:02, Petr Viktorin wrote: > On 09/17/2015 05:35 PM, Petr Viktorin wrote: >> Hello, >> In Python 2, Exception has only two built-in subclasses: StandardError, >> and StopIteration. >> This makes StandardError pretty useless, and Python 3 removes it. >> >> This patch replaces StandardError with Exception. It has no effect on >> IPA code. However, it could theoretically affect external plugins (e.g. >> if they do "except StandardError"). > > ping, anybody for review of this patch? Works for me, ACK. Pushed to master: 01da4a8de3ed8651cc95df6125751e1603dbd14e -- Jan Cholasta From ofayans at redhat.com Wed Sep 30 09:12:04 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 30 Sep 2015 11:12:04 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560A39E0.2090507@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> Message-ID: <560BA764.6030301@redhat.com> Guys, could you please review this patch again? I'd like to have this fix in the new ipa-tests package for downstream team On 09/29/2015 09:12 AM, Oleg Fayans wrote: > Hi all, > > On 09/23/2015 09:13 AM, Petr Spacek wrote: >> On 22.9.2015 10:42, Oleg Fayans wrote: >>> +++ b/ipatests/test_integration/tasks.py >>> @@ -58,6 +58,14 @@ def check_arguments_are(slice, instanceof): >>> return wrapped >>> return wrapper >>> >>> +def prepare_reverse_zone(host, ip): >>> + nums = ip.split('.')[:-1] >>> + zone = ".".join(reversed(nums)) + ".in-addr.arpa." >>> + host.run_command(["ipa", >>> + "dnszone-add", >>> + zone, >>> + "--name-from-ip=%s" % ip], raiseonerr=False) >>> + >> >> NACK: >> - this will break IPv6-only hosts >> - you should use DNSName class or other functions from python-dns for >> DNS name >> manipulation >> >> I hope this helps. > > Thanks, it did :) > Used a ipalib.util get_reverse_zone_default function that does just > that: creates a reverse zone name. > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pspacek at redhat.com Wed Sep 30 09:46:27 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 30 Sep 2015 11:46:27 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560A39E0.2090507@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> Message-ID: <560BAF73.20805@redhat.com> On 29.9.2015 09:12, Oleg Fayans wrote: > +def prepare_reverse_zone(host, ip): > + zone = get_reverse_zone_default(ip) > + host.run_command(["ipa", > + "dnszone-add", > + zone, > + "--name-from-ip=%s" % ip], raiseonerr=False) There is probably no point in specifying --name-from-ip because you did that already by calling get_reverse_zone_default(ip). Anyway, I'm not sure that this > + prepare_reverse_zone(master, replica.ip) will not break if the reverse zone already exists (think about case where two or more replicas are in the same subnet). I did not test the code, I simply do not have time for it right now. -- Petr^2 Spacek From ofayans at redhat.com Wed Sep 30 10:19:35 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 30 Sep 2015 12:19:35 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560BAF73.20805@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> Message-ID: <560BB737.2040609@redhat.com> On 09/30/2015 11:46 AM, Petr Spacek wrote: > On 29.9.2015 09:12, Oleg Fayans wrote: >> +def prepare_reverse_zone(host, ip): >> + zone = get_reverse_zone_default(ip) >> + host.run_command(["ipa", >> + "dnszone-add", >> + zone, >> + "--name-from-ip=%s" % ip], raiseonerr=False) > > There is probably no point in specifying --name-from-ip because you did that > already by calling get_reverse_zone_default(ip). Agree. Fixed > > Anyway, I'm not sure that this >> + prepare_reverse_zone(master, replica.ip) > will not break if the reverse zone already exists (think about case where two > or more replicas are in the same subnet). That's why I am using the raiseonerr=False here. > > I did not test the code, I simply do not have time for it right now. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0007.2-Added-a-proper-workaround-for-dnssec-test-failures.patch Type: text/x-patch Size: 2840 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 30 11:24:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 30 Sep 2015 13:24:35 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560BB737.2040609@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> <560BB737.2040609@redhat.com> Message-ID: <560BC673.5070203@redhat.com> On 09/30/2015 12:19 PM, Oleg Fayans wrote: > > > On 09/30/2015 11:46 AM, Petr Spacek wrote: >> On 29.9.2015 09:12, Oleg Fayans wrote: >>> +def prepare_reverse_zone(host, ip): >>> + zone = get_reverse_zone_default(ip) >>> + host.run_command(["ipa", >>> + "dnszone-add", >>> + zone, >>> + "--name-from-ip=%s" % ip], raiseonerr=False) >> >> There is probably no point in specifying --name-from-ip because you >> did that >> already by calling get_reverse_zone_default(ip). > > Agree. Fixed > >> >> Anyway, I'm not sure that this >>> + prepare_reverse_zone(master, replica.ip) >> will not break if the reverse zone already exists (think about case >> where two >> or more replicas are in the same subnet). > > That's why I am using the raiseonerr=False here. > >> >> I did not test the code, I simply do not have time for it right now. >> > > > LGTM, I will test it soon, but it needs rebase for ipa-4-2 branch -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Sep 30 11:41:12 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Sep 2015 13:41:12 +0200 Subject: [Freeipa-devel] [rfc-dist] RFC 7642 on System for Cross-domain Identity Management (SCIM) In-Reply-To: <560A3503.2030305@redhat.com> References: <20150925233454.9ADDF18380A@rfc-editor.org> <560A3503.2030305@redhat.com> Message-ID: <560BCA58.6070405@redhat.com> Thanks for sharing. Just for the record, there was a lot of SCIM related presentations at the latest LDAPCon where FreeIPA was present as well: http://lanyrd.com/2013/ldapcon/ I would like to know if there is actually any FreeIPA user interested in this type of interface, worth asking on freeipa-users? On 09/29/2015 08:51 AM, Petr Spacek wrote: > Hello, > > I did not read any of the RFCs referenced below, but it sounds relevant to us: > > 1. Introduction > > [...] > > Unlike the practice of some protocols like Application Bridging for > Federated Access Beyond web (ABFAB) and SAML2 WebSSO, SCIM provides > provisioning and de-provisioning of resources in a separate context > from authentication (aka just-in-time provisioning). > > [...] > > 2. SCIM User Scenarios > > 2.1. Background and Context > > The System for Cross-domain Identity Management (SCIM) specification > is designed to manage user identity in cloud-based applications and > services in a standardized way to enable interoperability, security, > and scalability. The specification suite seeks to build upon > experience with existing schemas and deployments, placing specific > emphasis on simplicity of development and integration, while applying > existing authentication, authorization, and privacy models. The > intent of the SCIM specification is to reduce the cost and complexity > of user management operations by providing a common user schema and > extension model, as well as binding documents to provide patterns for > exchanging this schema using standard protocols. In essence, make it > fast, cheap, and easy to move users in to, out of, and around the > cloud. > > Links: > * http://tools.ietf.org/html/rfc7642 > * http://tools.ietf.org/html/rfc7643 > * http://tools.ietf.org/html/rfc7644 > > > I hope this is not just noise. > > Petr^2 Spacek > > > > -------- Forwarded Message -------- > Subject: [rfc-dist] RFC 7642 on System for Cross-domain Identity Management: > Definitions, Overview, Concepts, and Requirements > Date: Fri, 25 Sep 2015 16:34:54 -0700 (PDT) > From: rfc-editor at rfc-editor.org > To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org > CC: drafts-update-ref at iana.org, scim at ietf.org, rfc-editor at rfc-editor.org > > A new Request for Comments is now available in online RFC libraries. > > > RFC 7642 > > Title: System for Cross-domain Identity Management: > Definitions, Overview, Concepts, and Requirements > Author: K. LI, Ed., P. Hunt, B. Khasnabish, > A. Nadalin, Z. Zeltsan > Status: Informational > Stream: IETF > Date: September 2015 > Mailbox: kepeng.lkp at alibaba-inc.com, > phil.hunt at oracle.com, > vumip1 at gmail.com, tonynad at microsoft.com, > zachary.zeltsan at gmail.com > Pages: 19 > Characters: 38759 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-scim-use-cases-08.txt > > URL: https://www.rfc-editor.org/info/rfc7642 > > DOI: http://dx.doi.org/10.17487/RFC7642 > > This document provides definitions and an overview of the System for > Cross-domain Identity Management (SCIM). It lays out the system's > concepts, models, and flows, and it includes user scenarios, use > cases, and requirements. > > This document is a product of the System for Cross-domain Identity Management > Working Group of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > rfc-dist mailing list > rfc-dist at rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-dist > http://www.rfc-editor.org > > > From jcholast at redhat.com Wed Sep 30 12:32:33 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 30 Sep 2015 14:32:33 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5603F646.5090004@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> Message-ID: <560BD661.50107@redhat.com> On 24.9.2015 15:10, Simo Sorce wrote: > On 24/09/15 04:43, Martin Basti wrote: >> >> >> On 09/24/2015 02:25 AM, Martin Basti wrote: >>> >>> >>> On 09/22/2015 10:45 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 9.9.2015 20:25, Simo Sorce wrote: >>>>> On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: >>>>>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>>>>> and introduces a number of required changes and dependencies to >>>>>> achieve >>>>>> this goal. >>>>>> This work requires the custodia project to securely transfer keys >>>>>> between ipa servers. >>>>>> >>>>>> This work is not 100% complete, it still misses the ability to >>>>>> install >>>>>> kra instances and the ability to install a CA (via ipa-ca-install) >>>>>> with >>>>>> externally signed certs. >>>>>> >>>>>> However it is massive enough that warrants review and pushing, the >>>>>> resat >>>>>> of the changes can be applied later as this work should not disrupt >>>>>> the >>>>>> classic install methods. >>>>>> >>>>>> In order to build my previous patches (530-533) are needed as well >>>>>> as a >>>>>> number of updated components. >>>>>> >>>>>> I used the following coprs for testing: >>>>>> simo/jwcrypto >>>>>> simo/custodia >>>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>>>> fedora/updates-testing (python-gssapi 1.1.2) >>>>>> >>>>>> Ludwig's copr is necessary to have a functional DNA plugin in >>>>>> replicas, >>>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 >>>>>> when >>>>>> it will be released. >>>>>> >>>>>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>>>>> that may cause installation issues in some case (re-install of a >>>>>> replica). >>>>>> >>>>>> The domain must be raised to level 1 in order to use replica >>>>>> promotion. >>>>>> >>>>>> In order to promote a replica the server must be first joined as a >>>>>> regular client to the domain. >>>>>> >>>>>> This is the flow I usually use for testing: >>>>>> >>>>>> # ipa-client-install >>>>>> # kinit admin >>>>>> # ipa-replica-install --promote --setup-ca >>>>>> >>>>> etc...> >>>>>> >>>>>> These patches are also available in this git tree rebnase on current >>>>>> master: >>>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>>>> >>>>>> >>>>> >>>>> FYI: I rebased this branch on top of master and applied minor >>>>> changes to >>>>> one of the DNS patches. I also added the missing support to install >>>>> KRA. >>>>> >>>>> DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not >>>>> needed anymore. >>>>> >>>>> Dogtag's ticket is not fixed yet so running both --setup-ca and >>>>> --setup-kra at the same time will still yield an error and install >>>>> will >>>>> fail. >>>>> >>>>> Please let me know if there are any major issues with this patchset, >>>>> I'd >>>>> like to push it to master and attack the remaining issues as add ons >>>>> (install with external certs not supported yet for example) >>>> >>>> So far I have only read through the code without running it (mostly). >>>> >>>> >>>> "Remove unused arguments": ACK >>>> >>>> >>>> "Simplify the install_replica_ca function": ACK >>>> >>>> >>>> "IPA Custodia Daemon": >>>> >>>> 1) Instead of putting the code in "ipakeys" package, could you put it >>>> in "ipapython.keys"? This way it would be consistent with DNSSEC, >>>> which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/. >>>> >>>> 2) Is it safe to create cn=custodia in update file only? Updates are >>>> executed late in ipa-server-install. Is is guaranteed that nothing >>>> will try to access cn=custodia before the updates are run? >>>> >>>> (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) >>>> >>>> 3) Shouldn't cn=custodia be created only when domain level >= 1? >>>> >>>> 4) pylint fails with: >>>> >>>> daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), >>>> IPAKEMKeys.__init__] Use of super on an old style class) >>>> daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), >>>> IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no >>>> 'config' member) >>>> daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), >>>> IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' >>>> member) >>>> >>>> 5) There are some PEP8 transgressions: >>>> >>>> ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 >>>> > 79 characters) >>>> ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 >>>> > 79 characters) >>>> ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank >>>> lines, found 1 >>>> ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around >>>> keyword / parameter equals >>>> ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file >>>> >>>> >>>> "Add Custodia Client code": >>>> >>>> 1) Is there any significance in having this in a separate commit? I >>>> would think it can be safely squashed in the previous commit. >>>> >>>> >>>> 2) There is one PEP8 transgression: >>>> >>>> ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank >>>> lines (2) >>>> >>>> >>>> "Install ipa-custodia with the rest of ipa": >>>> >>>> 1) python-jwcrypto dependency is missing in the spec file. >>>> >>>> 2) I believe the daemons/ipa-custodia/* and >>>> install/share/bootstrap-template.ldif should be in the "IPA Custodia >>>> Daemon" commit. At the very least it would make reviews easier. >>>> >>>> 3) There is one PEP8 transgressions: >>>> >>>> ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank >>>> lines, found 1 >>>> >>>> >>>> "Require a DS version that has working DNA plugin": ACK >>>> >>>> >>>> "Implement replica promotion functionality": >>>> >>>> 1) I think a RuntimeError or sys.exit with an error message would be >>>> better than NotImplementedError for the unimplemented options. >>>> >>>> (Nevermind, these are removed in further commits.) >>>> >>>> 2) There is no domain level check when installing the replica from a >>>> replica file. >>>> >>>> 3) Instead of returning INSTALL_ERROR from promote_check() (which has >>>> no effect), raise an exception or call sys.exit(). >>>> >>>> 4) The --promote option is redundant. You can safely decide whether >>>> to promote or not based on whether replica file was provided or not >>>> and the domain level of the remote server. >>>> >>>> 5) There are some PEP8 transgressions: >>>> >>>> ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' >>>> ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 >>>> characters) >>>> ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 >>>> characters) >>>> ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) >>>> ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank >>>> lines, found 1 >>>> ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > >>>> 79 characters) >>>> ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > >>>> 79 characters) >>>> ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > >>>> 79 characters) >>>> ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 >>>> blank lines, found 1 >>>> ./ipaserver/install/server/replicainstall.py:862:25: E128 >>>> continuation line under-indented for visual indent >>>> ./ipaserver/install/server/replicainstall.py:864:25: E128 >>>> continuation line under-indented for visual indent >>>> ./ipaserver/install/server/replicainstall.py:865:25: E128 >>>> continuation line under-indented for visual indent >>>> ./ipaserver/install/server/replicainstall.py:1014:13: E128 >>>> continuation line under-indented for visual indent >>>> ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing >>>> whitespace after ',' >>>> ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many >>>> blank lines (2) >>>> >>>> >>>> "Change DNS installer code to use passed in api": LGTM >>>> >>>> >>>> "Allow ipa-replica-conncheck to use default creds": LGTM >>>> >>>> >>>> "Add function to extract CA certs for install": LGTM >>>> >>>> >>>> "Allow to setup the CA when promoting a replica": >>>> >>>> 1) There are some PEP8 transgressions: >>>> >>>> ./ipaserver/install/ca.py:35:13: E125 continuation line with same >>>> indent as next logical line >>>> ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines (2) >>>> ./ipaserver/install/replication.py:421:24: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/replication.py:421:35: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/replication.py:421:41: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/replication.py:422:24: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/replication.py:422:40: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/replication.py:422:46: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/replication.py:524:37: E128 continuation line >>>> under-indented for visual indent >>>> ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' >>>> ./ipaserver/install/replication.py:524:80: E501 line too long (187 > >>>> 79 characters) >>>> ./ipaserver/install/replication.py:526:80: E501 line too long (106 > >>>> 79 characters) >>>> ./ipaserver/install/replication.py:560:80: E501 line too long (86 > >>>> 79 characters) >>>> ./ipaserver/install/replication.py:847:80: E501 line too long (81 > >>>> 79 characters) >>>> ./ipaserver/install/replication.py:850:80: E501 line too long (89 > >>>> 79 characters) >>>> ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > >>>> 79 characters) >>>> ./ipaserver/install/replication.py:1766:17: E128 continuation line >>>> under-indented for visual indent >>>> ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > >>>> 79 characters) >>>> >>>> >>>> "Make checks for existing credentials reusable": >>>> >>>> 1) There are some PEP8 transgressions: >>>> >>>> ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank >>>> lines, found 1 >>>> ./ipaserver/install/installutils.py:1192:25: E128 continuation line >>>> under-indented for visual indent >>>> ./ipaserver/install/installutils.py:1194:25: E128 continuation line >>>> under-indented for visual indent >>>> ./ipaserver/install/installutils.py:1195:25: E128 continuation line >>>> under-indented for visual indent >>>> >>>> >>>> "Allow ipa-ca-install to use the new promotion code": >>>> >>>> 1) The --replica option is redundant. You can safely decide whether >>>> this is the first CA master or not based on information in cn=masters. >>>> >>>> 2) There are some PEP8 transgressions: >>>> >>>> ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace >>>> after ',' >>>> ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace >>>> after ',' >>>> >>>> >>>> "Remove unused kra option": ACK >>>> >>>> >>>> "Allow to install the KRA on a promoted server": >>>> >>>> 1) There are some PEP8 transgressions: >>>> >>>> ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line >>>> over-indented for visual indent >>>> ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, >>>> found 1 >>>> ./ipaserver/install/krainstance.py:382:13: E128 continuation line >>>> under-indented for visual indent >>>> ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing >>>> whitespace around operator >>>> ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many >>>> blank lines (2) >>>> ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, >>>> found 1 >>>> ./ipaserver/install/service.py:115:52: E203 whitespace before ',' >>>> >>>> >>>> Pushed first 2 commits to master: >>>> d8b1f42f171d666068583548315b4684e5f3c3a4 >>>> >>>> >>>> Honza >>>> >>> >>> Hello, >>> >>> we have broken ipa-kra-install in master. >>> https://fedorahosted.org/freeipa/ticket/5321 >>> >>> I did git bisect and it found: >>> >>> 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 is the first bad commit >>> commit 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 >>> Author: Simo Sorce >>> Date: Tue Aug 25 13:38:05 2015 -0400 >>> >>> Remove unused arguments >>> >>> In the dogtag/ca/kra instances self.domain is never used. >>> Remove it. >>> >>> Signed-off-by: Simo Sorce >>> Reviewed-By: Jan Cholasta >>> >>> :040000 040000 d4ad87647b181b182a3a56bdac6c95c008ec2623 >>> 8728f38996eeaa387617880c29fdd8b4c1f21ad4 M ipaserver >>> >>> >>> I do not see anything bad in the commit, so I maybe I did bisect >>> wrong, I will investigate later. But it is caused by a recent change, >>> because it worked from master branch on moday. >>> >>> Martin^2 >>> >> I confirm. I reverted this commit in my branch, and ipa-kra-install >> works again. So unused variable is really used somewhere, but I cannot >> find where. > > I think the problem is that the patch was pushed prematurely. > The option should become unused once the other patches in this patchset > are applied, that is why that patch was not on top of the list but > rather down close to the bottom. The patch *was* on the top of the list, it was literally the first patch in the patchset. Anyway, found the cause, see the attached patch for a fix. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-497-install-fix-invocation-of-KRAInstance.create_instanc.patch Type: text/x-patch Size: 902 bytes Desc: not available URL: From cheimes at redhat.com Wed Sep 30 12:44:44 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 30 Sep 2015 14:44:44 +0200 Subject: [Freeipa-devel] The Community Auth.NEXT Working Group Inagural Meeting In-Reply-To: <20150930060507.GH4539@redhat.com> References: <20150930023202.GB12870@ender.bstinson.lan> <20150930060507.GH4539@redhat.com> Message-ID: <560BD93C.8060407@redhat.com> On 2015-09-30 08:05, Alexander Bokovoy wrote: > On Tue, 29 Sep 2015, Brian Stinson wrote: >> Hi FreeIPA! >> >> We are starting a working group of member projects looking to solve >> problems >> related to Community Authentication. The FreeIPA Community Portal >> feature added >> this summer is one of the important bits we are evaluating. >> >> We are hoping to collaborate on centos-devel at centos.org, and have IRC >> meetings >> in #centos-devel on Freenode every now and then to check in. We >> currently have >> interest from CentOS, Fedora, and a few other projects, and would love to >> invite anyone interested to participate. >> >> Patrick Uiterwijk will be starting a thread soon scheduling our next IRC >> meeting in 2 weeks time. > Thanks, Brian. > > There is also community-auth-next-wg at lists.fedoraproject.org for the same > purpose around Fedora Project needs. Reading your first meeting notes, > it is unclear why we couldn't use this list and would instead need to > subscribe to centos-devel@ (which I assume has more than this topic to > discuss). Hi Brian, thanks for your mail and for keeping us in the loop. I agree with Alexander's suggestion to use Patrick's new mailing list community-auth-next-wg. The centos-devel mailing list and #centos-devel channel are too busy to follow. For me and the other FreeIPA devs a dedicated mailing list has a better signal to noise ratio. I'm already subscribed to more mailing lists than I'm able to read on a daily bases... About the working-group representative for FreeIPA, I'm probably the best candidate. I'm familiar with the community portal. For the next months I'm busy with another project, but I can spare one to two hours a week to give feedback. I also like to get started on the design process early. Some neessary features and changes belong in the FreeIPA core, e.g. password change or unique email addresses. I like to addresss the modifications in FreeIPA 4.4. 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 mbasti at redhat.com Wed Sep 30 12:47:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 30 Sep 2015 14:47:04 +0200 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test In-Reply-To: <5603F13E.4060805@redhat.com> References: <5603F13E.4060805@redhat.com> Message-ID: <560BD9C8.2070205@redhat.com> On 09/24/2015 02:49 PM, Milan Kub?k wrote: > Hi all, > > an update for CA ACL tests! > > I, with help from M. Babinsky, managed to find a way how to change the > identity during acceptance cest run, which allows > to test CA ACLs (and perhaps other areas with some form of access > controll). > > This allowed me to write a test for CA ACLs and certificate profiles > that checks if the ACL/profile is being used and enforced. > The first several tests are based on Fraser's blogpost using SMIME > profile [1]. > > The master and ipa-4-2 branches diverged a bit, so I had to change two > commits when rebasing to ipa-4-2 branch. > > Commits should be applied in the order (including rebased patches I > sent in an earlier email): > > master: > * 12 - 17 > > ipa-4-2: > * 18, 13 - 15, 19, 17 > > For convenience: > patches on top of master: > https://github.com/apophys/freeipa/tree/acl-profile-functional > patches on top of ipa-4-2: https://github.com/apophys/freeipa/tree/acl-42 > > > [1]: > https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ > > Cheers, > Milan > > NACK 0) rpm file does not contain test_xmlrpc/data directory, please modify setup.py.in. 1) Code contains to much todo for my taste. 2) Please do not use filter function, use dict comprehension. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Sep 30 13:15:15 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 30 Sep 2015 09:15:15 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560BD661.50107@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <1441823142.3048.250.camel@willson.usersys.redhat.com> <56011527.40304@redhat.com> <560342E1.8070709@redhat.com> <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <560BD661.50107@redhat.com> Message-ID: <560BE063.7030006@redhat.com> On 30/09/15 08:32, Jan Cholasta wrote: > On 24.9.2015 15:10, Simo Sorce wrote: >> On 24/09/15 04:43, Martin Basti wrote: >>> >>> >>> On 09/24/2015 02:25 AM, Martin Basti wrote: >>>> >>>> >>>> On 09/22/2015 10:45 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 9.9.2015 20:25, Simo Sorce wrote: >>>>>> On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: >>>>>>> This patchset implements >>>>>>> https://fedorahosted.org/freeipa/ticket/2888 >>>>>>> and introduces a number of required changes and dependencies to >>>>>>> achieve >>>>>>> this goal. >>>>>>> This work requires the custodia project to securely transfer keys >>>>>>> between ipa servers. >>>>>>> >>>>>>> This work is not 100% complete, it still misses the ability to >>>>>>> install >>>>>>> kra instances and the ability to install a CA (via ipa-ca-install) >>>>>>> with >>>>>>> externally signed certs. >>>>>>> >>>>>>> However it is massive enough that warrants review and pushing, the >>>>>>> resat >>>>>>> of the changes can be applied later as this work should not disrupt >>>>>>> the >>>>>>> classic install methods. >>>>>>> >>>>>>> In order to build my previous patches (530-533) are needed as well >>>>>>> as a >>>>>>> number of updated components. >>>>>>> >>>>>>> I used the following coprs for testing: >>>>>>> simo/jwcrypto >>>>>>> simo/custodia >>>>>>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>>>>>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>>>>>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>>>>>> mkosek/freeipa-4.2-fedora-22 (misc) >>>>>>> fedora/updates-testing (python-gssapi 1.1.2) >>>>>>> >>>>>>> Ludwig's copr is necessary to have a functional DNA plugin in >>>>>>> replicas, >>>>>>> eventually his patches should be committed in 389-ds-base 1.3.4.4 >>>>>>> when >>>>>>> it will be released. >>>>>>> >>>>>>> We are aware of a dogtag bug >>>>>>> https://fedorahosted.org/pki/ticket/1580 >>>>>>> that may cause installation issues in some case (re-install of a >>>>>>> replica). >>>>>>> >>>>>>> The domain must be raised to level 1 in order to use replica >>>>>>> promotion. >>>>>>> >>>>>>> In order to promote a replica the server must be first joined as a >>>>>>> regular client to the domain. >>>>>>> >>>>>>> This is the flow I usually use for testing: >>>>>>> >>>>>>> # ipa-client-install >>>>>>> # kinit admin >>>>>>> # ipa-replica-install --promote --setup-ca >>>>>>> >>>>>> etc...> >>>>>>> >>>>>>> These patches are also available in this git tree rebnase on current >>>>>>> master: >>>>>>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> FYI: I rebased this branch on top of master and applied minor >>>>>> changes to >>>>>> one of the DNS patches. I also added the missing support to install >>>>>> KRA. >>>>>> >>>>>> DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not >>>>>> needed anymore. >>>>>> >>>>>> Dogtag's ticket is not fixed yet so running both --setup-ca and >>>>>> --setup-kra at the same time will still yield an error and install >>>>>> will >>>>>> fail. >>>>>> >>>>>> Please let me know if there are any major issues with this patchset, >>>>>> I'd >>>>>> like to push it to master and attack the remaining issues as add ons >>>>>> (install with external certs not supported yet for example) >>>>> >>>>> So far I have only read through the code without running it (mostly). >>>>> >>>>> >>>>> "Remove unused arguments": ACK >>>>> >>>>> >>>>> "Simplify the install_replica_ca function": ACK >>>>> >>>>> >>>>> "IPA Custodia Daemon": >>>>> >>>>> 1) Instead of putting the code in "ipakeys" package, could you put it >>>>> in "ipapython.keys"? This way it would be consistent with DNSSEC, >>>>> which has binaries in daemons/dnssec/ and modules in >>>>> ipapython/dnssec/. >>>>> >>>>> 2) Is it safe to create cn=custodia in update file only? Updates are >>>>> executed late in ipa-server-install. Is is guaranteed that nothing >>>>> will try to access cn=custodia before the updates are run? >>>>> >>>>> (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) >>>>> >>>>> 3) Shouldn't cn=custodia be created only when domain level >= 1? >>>>> >>>>> 4) pylint fails with: >>>>> >>>>> daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), >>>>> IPAKEMKeys.__init__] Use of super on an old style class) >>>>> daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), >>>>> IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no >>>>> 'config' member) >>>>> daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), >>>>> IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' >>>>> member) >>>>> >>>>> 5) There are some PEP8 transgressions: >>>>> >>>>> ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 >>>>> > 79 characters) >>>>> ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 >>>>> > 79 characters) >>>>> ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank >>>>> lines, found 1 >>>>> ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:14:13: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:14:15: E251 unexpected spaces around >>>>> keyword / parameter equals >>>>> ./daemons/ipa-custodia/setup.py:16:1: W391 blank line at end of file >>>>> >>>>> >>>>> "Add Custodia Client code": >>>>> >>>>> 1) Is there any significance in having this in a separate commit? I >>>>> would think it can be safely squashed in the previous commit. >>>>> >>>>> >>>>> 2) There is one PEP8 transgression: >>>>> >>>>> ./daemons/ipa-custodia/ipakeys/client.py:45:5: E303 too many blank >>>>> lines (2) >>>>> >>>>> >>>>> "Install ipa-custodia with the rest of ipa": >>>>> >>>>> 1) python-jwcrypto dependency is missing in the spec file. >>>>> >>>>> 2) I believe the daemons/ipa-custodia/* and >>>>> install/share/bootstrap-template.ldif should be in the "IPA Custodia >>>>> Daemon" commit. At the very least it would make reviews easier. >>>>> >>>>> 3) There is one PEP8 transgressions: >>>>> >>>>> ./ipaserver/install/custodiainstance.py:10:1: E302 expected 2 blank >>>>> lines, found 1 >>>>> >>>>> >>>>> "Require a DS version that has working DNA plugin": ACK >>>>> >>>>> >>>>> "Implement replica promotion functionality": >>>>> >>>>> 1) I think a RuntimeError or sys.exit with an error message would be >>>>> better than NotImplementedError for the unimplemented options. >>>>> >>>>> (Nevermind, these are removed in further commits.) >>>>> >>>>> 2) There is no domain level check when installing the replica from a >>>>> replica file. >>>>> >>>>> 3) Instead of returning INSTALL_ERROR from promote_check() (which has >>>>> no effect), raise an exception or call sys.exit(). >>>>> >>>>> 4) The --promote option is redundant. You can safely decide whether >>>>> to promote or not based on whether replica file was provided or not >>>>> and the domain level of the remote server. >>>>> >>>>> 5) There are some PEP8 transgressions: >>>>> >>>>> ./ipaserver/install/cainstance.py:264:35: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/cainstance.py:264:49: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/cainstance.py:264:63: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/cainstance.py:267:49: E203 whitespace before ',' >>>>> ./ipaserver/install/dsinstance.py:258:80: E501 line too long (88 > 79 >>>>> characters) >>>>> ./ipaserver/install/dsinstance.py:317:80: E501 line too long (90 > 79 >>>>> characters) >>>>> ./ipaserver/install/dsinstance.py:457:5: E303 too many blank lines (2) >>>>> ./ipaserver/install/installutils.py:1115:1: E302 expected 2 blank >>>>> lines, found 1 >>>>> ./ipaserver/install/krbinstance.py:185:80: E501 line too long (85 > >>>>> 79 characters) >>>>> ./ipaserver/install/krbinstance.py:186:80: E501 line too long (85 > >>>>> 79 characters) >>>>> ./ipaserver/install/krbinstance.py:191:80: E501 line too long (92 > >>>>> 79 characters) >>>>> ./ipaserver/install/server/replicainstall.py:412:1: E302 expected 2 >>>>> blank lines, found 1 >>>>> ./ipaserver/install/server/replicainstall.py:862:25: E128 >>>>> continuation line under-indented for visual indent >>>>> ./ipaserver/install/server/replicainstall.py:864:25: E128 >>>>> continuation line under-indented for visual indent >>>>> ./ipaserver/install/server/replicainstall.py:865:25: E128 >>>>> continuation line under-indented for visual indent >>>>> ./ipaserver/install/server/replicainstall.py:1014:13: E128 >>>>> continuation line under-indented for visual indent >>>>> ./ipaserver/install/server/replicainstall.py:1044:42: E231 missing >>>>> whitespace after ',' >>>>> ./ipaserver/install/server/replicainstall.py:1125:5: E303 too many >>>>> blank lines (2) >>>>> >>>>> >>>>> "Change DNS installer code to use passed in api": LGTM >>>>> >>>>> >>>>> "Allow ipa-replica-conncheck to use default creds": LGTM >>>>> >>>>> >>>>> "Add function to extract CA certs for install": LGTM >>>>> >>>>> >>>>> "Allow to setup the CA when promoting a replica": >>>>> >>>>> 1) There are some PEP8 transgressions: >>>>> >>>>> ./ipaserver/install/ca.py:35:13: E125 continuation line with same >>>>> indent as next logical line >>>>> ./ipaserver/install/cainstance.py:1488:5: E303 too many blank lines >>>>> (2) >>>>> ./ipaserver/install/replication.py:421:24: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/replication.py:421:35: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/replication.py:421:41: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/replication.py:422:24: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/replication.py:422:40: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/replication.py:422:46: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/replication.py:524:37: E128 continuation line >>>>> under-indented for visual indent >>>>> ./ipaserver/install/replication.py:524:38: E201 whitespace after '[' >>>>> ./ipaserver/install/replication.py:524:80: E501 line too long (187 > >>>>> 79 characters) >>>>> ./ipaserver/install/replication.py:526:80: E501 line too long (106 > >>>>> 79 characters) >>>>> ./ipaserver/install/replication.py:560:80: E501 line too long (86 > >>>>> 79 characters) >>>>> ./ipaserver/install/replication.py:847:80: E501 line too long (81 > >>>>> 79 characters) >>>>> ./ipaserver/install/replication.py:850:80: E501 line too long (89 > >>>>> 79 characters) >>>>> ./ipaserver/install/replication.py:1761:80: E501 line too long (81 > >>>>> 79 characters) >>>>> ./ipaserver/install/replication.py:1766:17: E128 continuation line >>>>> under-indented for visual indent >>>>> ./ipaserver/install/replication.py:1807:80: E501 line too long (89 > >>>>> 79 characters) >>>>> >>>>> >>>>> "Make checks for existing credentials reusable": >>>>> >>>>> 1) There are some PEP8 transgressions: >>>>> >>>>> ./ipaserver/install/installutils.py:1140:1: E302 expected 2 blank >>>>> lines, found 1 >>>>> ./ipaserver/install/installutils.py:1192:25: E128 continuation line >>>>> under-indented for visual indent >>>>> ./ipaserver/install/installutils.py:1194:25: E128 continuation line >>>>> under-indented for visual indent >>>>> ./ipaserver/install/installutils.py:1195:25: E128 continuation line >>>>> under-indented for visual indent >>>>> >>>>> >>>>> "Allow ipa-ca-install to use the new promotion code": >>>>> >>>>> 1) The --replica option is redundant. You can safely decide whether >>>>> this is the first CA master or not based on information in cn=masters. >>>>> >>>>> 2) There are some PEP8 transgressions: >>>>> >>>>> ./ipaserver/install/dsinstance.py:173:26: E231 missing whitespace >>>>> after ',' >>>>> ./ipaserver/install/dsinstance.py:173:40: E231 missing whitespace >>>>> after ',' >>>>> >>>>> >>>>> "Remove unused kra option": ACK >>>>> >>>>> >>>>> "Allow to install the KRA on a promoted server": >>>>> >>>>> 1) There are some PEP8 transgressions: >>>>> >>>>> ./ipaserver/install/ipa_kra_install.py:198:33: E127 continuation line >>>>> over-indented for visual indent >>>>> ./ipaserver/install/krainstance.py:55:1: E302 expected 2 blank lines, >>>>> found 1 >>>>> ./ipaserver/install/krainstance.py:382:13: E128 continuation line >>>>> under-indented for visual indent >>>>> ./ipaserver/install/server/replicainstall.py:1073:18: E225 missing >>>>> whitespace around operator >>>>> ./ipaserver/install/server/replicainstall.py:1081:5: E303 too many >>>>> blank lines (2) >>>>> ./ipaserver/install/service.py:103:1: E302 expected 2 blank lines, >>>>> found 1 >>>>> ./ipaserver/install/service.py:115:52: E203 whitespace before ',' >>>>> >>>>> >>>>> Pushed first 2 commits to master: >>>>> d8b1f42f171d666068583548315b4684e5f3c3a4 >>>>> >>>>> >>>>> Honza >>>>> >>>> >>>> Hello, >>>> >>>> we have broken ipa-kra-install in master. >>>> https://fedorahosted.org/freeipa/ticket/5321 >>>> >>>> I did git bisect and it found: >>>> >>>> 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 is the first bad commit >>>> commit 953b1079cfc8d2da486ebb65b9cfd4d85f680c67 >>>> Author: Simo Sorce >>>> Date: Tue Aug 25 13:38:05 2015 -0400 >>>> >>>> Remove unused arguments >>>> >>>> In the dogtag/ca/kra instances self.domain is never used. >>>> Remove it. >>>> >>>> Signed-off-by: Simo Sorce >>>> Reviewed-By: Jan Cholasta >>>> >>>> :040000 040000 d4ad87647b181b182a3a56bdac6c95c008ec2623 >>>> 8728f38996eeaa387617880c29fdd8b4c1f21ad4 M ipaserver >>>> >>>> >>>> I do not see anything bad in the commit, so I maybe I did bisect >>>> wrong, I will investigate later. But it is caused by a recent change, >>>> because it worked from master branch on moday. >>>> >>>> Martin^2 >>>> >>> I confirm. I reverted this commit in my branch, and ipa-kra-install >>> works again. So unused variable is really used somewhere, but I cannot >>> find where. >> >> I think the problem is that the patch was pushed prematurely. >> The option should become unused once the other patches in this patchset >> are applied, that is why that patch was not on top of the list but >> rather down close to the bottom. > > The patch *was* on the top of the list, it was literally the first patch > in the patchset. > > Anyway, found the cause, see the attached patch for a fix. ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From jpazdziora at redhat.com Wed Sep 30 14:24:37 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 30 Sep 2015 16:24:37 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560AE70B.5020700@redhat.com> References: <5603B794.4090806@redhat.com> <5603F646.5090004@redhat.com> <20150929132826.GA1529@redhat.com> <560A9843.6000407@redhat.com> <560AA2B5.2040303@redhat.com> <560AA60D.6060703@redhat.com> <560AB355.9070503@redhat.com> <560AC0A2.8020300@redhat.com> <560ADED0.9020006@redhat.com> <560AE70B.5020700@redhat.com> Message-ID: <20150930142437.GA16170@redhat.com> On Tue, Sep 29, 2015 at 03:31:23PM -0400, Simo Sorce wrote: > On 29/09/15 14:56, Oleg Fayans wrote: > > > > > >On 09/29/2015 06:47 PM, Simo Sorce wrote: > >>On 29/09/15 11:50, Oleg Fayans wrote: > >>>Hi Simo, > >>> > >>>It seems to have resolved the initial issue, but now the build fails due > >>>to lint complaints: https://paste.fedoraproject.org/272714/54174014/ > >> > >>These happens if you do not have custodia installed. > >>I guess I should make it also a BuildRequires ? > > > >I think so, yes. > > Turns out it is already there. Oleg, were you able to build from the branch now? Simo, could you maybe make a copr repo from your branch? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat