From brian at bstinson.com Thu Oct 1 02:33:26 2015 From: brian at bstinson.com (Brian Stinson) Date: Wed, 30 Sep 2015 21:33:26 -0500 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: <20151001023326.GI12870@ender.bstinson.lan> On Sep 30 09: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). > > > > >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 The idea behind using centos-devel is to get a little more visibility in the beginning, and if we get too 'noisy' we can move to another list later on. We have members of other upstream projects already subscribed to this list who are currently involved with the CBS, CI, and other projects, so it would be good to get their eyes on this in case they'd like to participate. There has also been talk of an authentication Special Interest Group (working on building/packaging/testing projects in this space) and it's likely the discussions on centos-devel would overlap some. Our plan for the working group is: Discussions => centos-devel at centos.org Meeting Minutes and Summaries (for archive purposes) => community-auth-next-wg at lists.fedorahosted.org IRC meetings => #centos-devel Cheers! Brian From jcholast at redhat.com Thu Oct 1 05:43:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 1 Oct 2015 07:43:05 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560BE063.7030006@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> <560BE063.7030006@redhat.com> Message-ID: <560CC7E9.7050009@redhat.com> On 30.9.2015 15:15, Simo Sorce wrote: > 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 Pushed to master: c388dbd4de36442773079a2c6e52547b4b60b993 -- Jan Cholasta From mkubik at redhat.com Thu Oct 1 08:06:06 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 1 Oct 2015 10:06:06 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf Message-ID: <560CE96E.1000200@redhat.com> Fixes https://fedorahosted.org/freeipa/ticket/5331 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0020-ipatests-configure-Network-Manager-not-to-manage-res.patch Type: text/x-patch Size: 2796 bytes Desc: not available URL: From mkubik at redhat.com Thu Oct 1 08:18:24 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 1 Oct 2015 10:18:24 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560CE96E.1000200@redhat.com> References: <560CE96E.1000200@redhat.com> Message-ID: <560CEC50.6080707@redhat.com> On 10/01/2015 10:06 AM, Milan Kub?k wrote: > Fixes https://fedorahosted.org/freeipa/ticket/5331 > > Patch attached. > > Patch for ipa-4-2 branch. Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ipa42-mkubik-0020-ipatests-configure-Network-Manager-not-to-manage-res.patch Type: text/x-patch Size: 2799 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 1 09:18:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 11:18:54 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560BC673.5070203@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> <560BB737.2040609@redhat.com> <560BC673.5070203@redhat.com> Message-ID: <560CFA7E.8090107@redhat.com> On 09/30/2015 01:24 PM, Martin Basti wrote: > > > 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 > > ACK, please send rebased version for ipa-4-2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 1 09:23:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 11:23:41 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560CEC50.6080707@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> Message-ID: <560CFB9D.4070503@redhat.com> On 10/01/2015 10:18 AM, Milan Kub?k wrote: > On 10/01/2015 10:06 AM, Milan Kub?k wrote: >> Fixes https://fedorahosted.org/freeipa/ticket/5331 >> >> Patch attached. >> >> > Patch for ipa-4-2 branch. > > Milan > > NACK http://fpaste.org/273499/43691381/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu Oct 1 10:06:59 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 1 Oct 2015 12:06:59 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560AE70B.5020700@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> <560AE70B.5020700@redhat.com> Message-ID: <560D05C3.5020005@redhat.com> Hi Simo, I was able to build the packages based on your git repo. However, my attempt to install the resulting bits failed due to lack of dependencies: pki-ca >= 10.2.7 is needed by freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 pki-kra >= 10.2.7 is needed by freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 My system has version 10.2.6 of above packages provided by mkosek/freeipa-master copr repo. What is the correct repo to get 10.2.7 from? On 09/29/2015 09:31 PM 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. > > 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. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From lkrispen at redhat.com Thu Oct 1 10:29:18 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 01 Oct 2015 12:29:18 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560D05C3.5020005@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> <560AE70B.5020700@redhat.com> <560D05C3.5020005@redhat.com> Message-ID: <560D0AFE.6020204@redhat.com> On 10/01/2015 12:06 PM, Oleg Fayans wrote: > Hi Simo, > > I was able to build the packages based on your git repo. However, my > attempt to install the resulting bits failed due to lack of dependencies: > > pki-ca >= 10.2.7 is needed by > freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 > pki-kra >= 10.2.7 is needed by > freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 > > My system has version 10.2.6 of above packages provided by > mkosek/freeipa-master copr repo. > > What is the correct repo to get 10.2.7 from? when Simo first submitted the patches for review he also listed the repos used: 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) I'm not sure if all of them are still needed, eg for 389-ds the private repo is no longer neede, but you can use this for missing rpms > > On 09/29/2015 09:31 PM 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. >> >> 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. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From mbasti at redhat.com Thu Oct 1 10:26:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 12:26:44 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560CFB9D.4070503@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> <560CFB9D.4070503@redhat.com> Message-ID: <560D0A64.4050503@redhat.com> On 10/01/2015 11:23 AM, Martin Basti wrote: > > > On 10/01/2015 10:18 AM, Milan Kub?k wrote: >> On 10/01/2015 10:06 AM, Milan Kub?k wrote: >>> Fixes https://fedorahosted.org/freeipa/ticket/5331 >>> >>> Patch attached. >>> >>> >> Patch for ipa-4-2 branch. >> >> Milan >> >> > NACK > > http://fpaste.org/273499/43691381/ > > I did investigation, this happened because my VM did not have NetworkManager installed (fedora 22 cloud) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Thu Oct 1 10:27:08 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 1 Oct 2015 12:27:08 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560CFB9D.4070503@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> <560CFB9D.4070503@redhat.com> Message-ID: <560D0A7C.5080803@redhat.com> On 10/01/2015 11:23 AM, Martin Basti wrote: > > > On 10/01/2015 10:18 AM, Milan Kub?k wrote: >> On 10/01/2015 10:06 AM, Milan Kub?k wrote: >>> Fixes https://fedorahosted.org/freeipa/ticket/5331 >>> >>> Patch attached. >>> >>> >> Patch for ipa-4-2 branch. >> >> Milan >> >> > NACK > > http://fpaste.org/273499/43691381/ I disagree. From [1]: Fedora now by default relies on NetworkManager for network configuration. This is the case also for minimal installations and server installations. The cloud image, which you are probably using does not have NetworkManager installed. I think we can rely on the default here and assume NetworkManager is present. If you and the list disagree, I will make the fix depend on NetworkManager's presence. Nitpick: there can be other services that manage (and rewrite) resolv.conf. [1]: https://fedoraproject.org/wiki/Tools/NetworkManager -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu Oct 1 10:39:26 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 1 Oct 2015 12:39:26 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560D0AFE.6020204@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> <560AE70B.5020700@redhat.com> <560D05C3.5020005@redhat.com> <560D0AFE.6020204@redhat.com> Message-ID: <560D0D5E.5090604@redhat.com> Hi Ludwig, Thank you! vakwetu/dogtag_10.2.7_test_builds was the bit that was missing On 10/01/2015 12:29 PM, Ludwig Krispenz wrote: > > On 10/01/2015 12:06 PM, Oleg Fayans wrote: >> Hi Simo, >> >> I was able to build the packages based on your git repo. However, my >> attempt to install the resulting bits failed due to lack of dependencies: >> >> pki-ca >= 10.2.7 is needed by >> freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 >> pki-kra >= 10.2.7 is needed by >> freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 >> >> My system has version 10.2.6 of above packages provided by >> mkosek/freeipa-master copr repo. >> >> What is the correct repo to get 10.2.7 from? > when Simo first submitted the patches for review he also listed the > repos used: > > 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) > > I'm not sure if all of them are still needed, eg for 389-ds the private > repo is no longer neede, but you can use this for missing rpms > > >> >> On 09/29/2015 09:31 PM 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. >>> >>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From abokovoy at redhat.com Thu Oct 1 10:39:47 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Oct 2015 13:39:47 +0300 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560D0A7C.5080803@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> <560CFB9D.4070503@redhat.com> <560D0A7C.5080803@redhat.com> Message-ID: <20151001103947.GB4971@redhat.com> On Thu, 01 Oct 2015, Milan Kub?k wrote: >On 10/01/2015 11:23 AM, Martin Basti wrote: >> >> >>On 10/01/2015 10:18 AM, Milan Kub?k wrote: >>>On 10/01/2015 10:06 AM, Milan Kub?k wrote: >>>>Fixes https://fedorahosted.org/freeipa/ticket/5331 >>>> >>>>Patch attached. >>>> >>>> >>>Patch for ipa-4-2 branch. >>> >>>Milan >>> >>> >>NACK >> >>http://fpaste.org/273499/43691381/ >I disagree. From [1]: > > Fedora now by default relies on NetworkManager for network >configuration. This is the case also for minimal installations and >server installations. > >The cloud image, which you are probably using does not have >NetworkManager installed. I think we can rely on the default here and >assume >NetworkManager is present. > >If you and the list disagree, I will make the fix depend on >NetworkManager's presence. >Nitpick: there can be other services that manage (and rewrite) resolv.conf. While other tools may do it, please make it so that your fix only activated if NetworkManager is active. We'll get to other services once we'll encounter them. -- / Alexander Bokovoy From jcholast at redhat.com Thu Oct 1 10:55:09 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 1 Oct 2015 12:55:09 +0200 Subject: [Freeipa-devel] [PATCHES 466-468, 0316] install: Add common base class for server and replica install In-Reply-To: <560A8EFD.8070006@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> <560A8EFD.8070006@redhat.com> Message-ID: <560D110D.80208@redhat.com> On 29.9.2015 15:15, Martin Basti wrote: > > > 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 Martin found an additional issued, see the attached patch for a fix. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-498-install-fix-ipa-server-install-fail-on-missing-forwa.patch Type: text/x-patch Size: 2873 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 1 11:01:32 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 13:01:32 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <560B9C6C.2040600@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> Message-ID: <560D128C.9000105@redhat.com> On 09/30/2015 10:25 AM, Petr Viktorin wrote: > 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? > > LGTM I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and everything works From jcholast at redhat.com Thu Oct 1 11:42:39 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 1 Oct 2015 13:42:39 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560D0D5E.5090604@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> <560AE70B.5020700@redhat.com> <560D05C3.5020005@redhat.com> <560D0AFE.6020204@redhat.com> <560D0D5E.5090604@redhat.com> Message-ID: <560D1C2F.5080606@redhat.com> Hi, I have just imported python-jwcrypto, custodia and pki-core-10.2.7 into mkosek/freeipa-master as well, to (hopefully) make things easier. Simo, custodia failed to build F22, any idea why? See . On 1.10.2015 12:39, Oleg Fayans wrote: > Hi Ludwig, > > Thank you! vakwetu/dogtag_10.2.7_test_builds was the bit that was missing > > On 10/01/2015 12:29 PM, Ludwig Krispenz wrote: >> >> On 10/01/2015 12:06 PM, Oleg Fayans wrote: >>> Hi Simo, >>> >>> I was able to build the packages based on your git repo. However, my >>> attempt to install the resulting bits failed due to lack of >>> dependencies: >>> >>> pki-ca >= 10.2.7 is needed by >>> freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 >>> pki-kra >= 10.2.7 is needed by >>> freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 >>> >>> My system has version 10.2.6 of above packages provided by >>> mkosek/freeipa-master copr repo. >>> >>> What is the correct repo to get 10.2.7 from? >> when Simo first submitted the patches for review he also listed the >> repos used: >> >> 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) >> >> I'm not sure if all of them are still needed, eg for 389-ds the private >> repo is no longer neede, but you can use this for missing rpms >> >> >>> >>> On 09/29/2015 09:31 PM 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. >>>> >>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > -- Jan Cholasta From mkubik at redhat.com Thu Oct 1 11:58:55 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 1 Oct 2015 13:58:55 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <20151001103947.GB4971@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> <560CFB9D.4070503@redhat.com> <560D0A7C.5080803@redhat.com> <20151001103947.GB4971@redhat.com> Message-ID: <560D1FFF.4060402@redhat.com> On 10/01/2015 12:39 PM, Alexander Bokovoy wrote: > On Thu, 01 Oct 2015, Milan Kub?k wrote: >> On 10/01/2015 11:23 AM, Martin Basti wrote: >>> >>> >>> On 10/01/2015 10:18 AM, Milan Kub?k wrote: >>>> On 10/01/2015 10:06 AM, Milan Kub?k wrote: >>>>> Fixes https://fedorahosted.org/freeipa/ticket/5331 >>>>> >>>>> Patch attached. >>>>> >>>>> >>>> Patch for ipa-4-2 branch. >>>> >>>> Milan >>>> >>>> >>> NACK >>> >>> http://fpaste.org/273499/43691381/ >> I disagree. From [1]: >> >> Fedora now by default relies on NetworkManager for network >> configuration. This is the case also for minimal installations and >> server installations. >> >> The cloud image, which you are probably using does not have >> NetworkManager installed. I think we can rely on the default here and >> assume >> NetworkManager is present. >> >> If you and the list disagree, I will make the fix depend on >> NetworkManager's presence. >> Nitpick: there can be other services that manage (and rewrite) >> resolv.conf. > While other tools may do it, please make it so that your fix only > activated if NetworkManager is active. > > We'll get to other services once we'll encounter them. > Ok. Now I only apply the config and restart NetworkManager when it is already running. I don't check if the service is enabled. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ipa42-mkubik-0020-1-ipatests-configure-Network-Manager-not-to-manage-res.patch Type: text/x-patch Size: 3320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0020-1-ipatests-configure-Network-Manager-not-to-manage-res.patch Type: text/x-patch Size: 3317 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 1 12:18:24 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 1 Oct 2015 14:18:24 +0200 Subject: [Freeipa-devel] [PATCH 0066] fix for regression in ipa-restore In-Reply-To: <560A91CD.4020101@redhat.com> References: <560572B3.9010801@redhat.com> <560A91CD.4020101@redhat.com> Message-ID: <560D2490.1050901@redhat.com> On 09/29/2015 03:27 PM, David Kupka wrote: > On 25/09/15 18:13, Martin Babinsky wrote: >> fixes https://fedorahosted.org/freeipa/ticket/5328 >> >> >> > Fixes the issue for me, ACK. > Just checking - what is the impact here, will ipa-restore still work on a clean machine without FreeIPA installed, i.e. without dirsrv being in /etc/passwd? From dkupka at redhat.com Thu Oct 1 12:23:24 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 1 Oct 2015 14:23:24 +0200 Subject: [Freeipa-devel] [PATCH 0066] fix for regression in ipa-restore In-Reply-To: <560D2490.1050901@redhat.com> References: <560572B3.9010801@redhat.com> <560A91CD.4020101@redhat.com> <560D2490.1050901@redhat.com> Message-ID: <560D25BC.5030301@redhat.com> On 01/10/15 14:18, Martin Kosek wrote: > On 09/29/2015 03:27 PM, David Kupka wrote: >> On 25/09/15 18:13, Martin Babinsky wrote: >>> fixes https://fedorahosted.org/freeipa/ticket/5328 >>> >>> >>> >> Fixes the issue for me, ACK. >> > > Just checking - what is the impact here, will ipa-restore still work on a clean > machine without FreeIPA installed, i.e. without dirsrv being in /etc/passwd? > Yes, restore on clean machine should not be affected. The problem is in scenario such as: 1. install freeipa packages 2. install freeipa-server 3. run ipa-backup 4. *add some system user* 5. run ipa-restore After restore the newly added system user is gone. -- David Kupka From mbabinsk at redhat.com Thu Oct 1 12:24:23 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 1 Oct 2015 14:24:23 +0200 Subject: [Freeipa-devel] [PATCH 0066] fix for regression in ipa-restore In-Reply-To: <560D2490.1050901@redhat.com> References: <560572B3.9010801@redhat.com> <560A91CD.4020101@redhat.com> <560D2490.1050901@redhat.com> Message-ID: <560D25F7.1060506@redhat.com> On 10/01/2015 02:18 PM, Martin Kosek wrote: > On 09/29/2015 03:27 PM, David Kupka wrote: >> On 25/09/15 18:13, Martin Babinsky wrote: >>> fixes https://fedorahosted.org/freeipa/ticket/5328 >>> >>> >>> >> Fixes the issue for me, ACK. >> > > Just checking - what is the impact here, will ipa-restore still work on a clean > machine without FreeIPA installed, i.e. without dirsrv being in /etc/passwd? > Yes it will since dirsrv/ca users are (re)created during full restore anyway. -- Martin^3 Babinsky From ofayans at redhat.com Thu Oct 1 12:43:48 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 1 Oct 2015 14:43:48 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560CFA7E.8090107@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> <560BB737.2040609@redhat.com> <560BC673.5070203@redhat.com> <560CFA7E.8090107@redhat.com> Message-ID: <560D2A84.10202@redhat.com> Hi Martin, On 10/01/2015 11:18 AM, Martin Basti wrote: > > > On 09/30/2015 01:24 PM, Martin Basti wrote: >> >> >> 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 >> >> > ACK, please send rebased version for ipa-4-2 Here it is -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0007.3-Added-a-proper-workaround-for-dnssec-test-failures_4-2.patch Type: text/x-patch Size: 2592 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 1 12:48:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 14:48:55 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560D2A84.10202@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> <560BB737.2040609@redhat.com> <560BC673.5070203@redhat.com> <560CFA7E.8090107@redhat.com> <560D2A84.10202@redhat.com> Message-ID: <560D2BB7.8070805@redhat.com> On 10/01/2015 02:43 PM, Oleg Fayans wrote: > Hi Martin, > > On 10/01/2015 11:18 AM, Martin Basti wrote: >> >> >> On 09/30/2015 01:24 PM, Martin Basti wrote: >>> >>> >>> 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 >>> >>> >> ACK, please send rebased version for ipa-4-2 > > Here it is > Pushed to ipa-4-2: c898c968d3979a0d8c2fe0db8e125dfc2268eba0 Pushed to master: 03d696f224642c1c4c4f1a434fecefd1c6270e37 From mbabinsk at redhat.com Thu Oct 1 12:49:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 1 Oct 2015 14:49:34 +0200 Subject: [Freeipa-devel] [PATCH 0067] ipa-server-install: mark master_password Knob as deprecated Message-ID: <560D2BDE.3090101@redhat.com> Pave Picka found out that the fix for https://fedorahosted.org/freeipa/ticket/4516 was partially undone during 4.2 installer rectofaring efforts. This one-liner should fix it for good (or at least until we move the code around again). -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0067-ipa-server-install-mark-master_password-Knob-as-depr.patch Type: text/x-patch Size: 953 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 1 13:00:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 15:00:03 +0200 Subject: [Freeipa-devel] [PATCHES 466-468, 0316] install: Add common base class for server and replica install In-Reply-To: <560D110D.80208@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> <560A8EFD.8070006@redhat.com> <560D110D.80208@redhat.com> Message-ID: <560D2E53.70005@redhat.com> On 10/01/2015 12:55 PM, Jan Cholasta wrote: > On 29.9.2015 15:15, Martin Basti wrote: >> >> >> 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 > > Martin found an additional issued, see the attached patch for a fix. > ACK Pushed to: ipa-4-2: 75a8454caeeaf293c0b6be48f2b8476e7707447f master: 6067824be494745926204a7ba3709c3c0f054326 From jcholast at redhat.com Thu Oct 1 13:15:20 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 1 Oct 2015 15:15:20 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <560D128C.9000105@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> Message-ID: <560D31E8.6000707@redhat.com> Hi, On 1.10.2015 13:01, Martin Basti wrote: > > > On 09/30/2015 10:25 AM, Petr Viktorin wrote: >> 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? >> >> > LGTM > > I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and > everything works Patches 713-719: ACK Patch 720: You missed: ipa-client/ipa-install/ipa-client-install:32: from ConfigParser import RawConfigParser Patches 721-722: ACK Patch 723: Why the "NoneType = type(None)" in parameters.py? It is used only at: ipalib/parameters.py:388: type = NoneType # Ouch, this wont be very useful in the real world! Patch 724: The SSHPublicKey class was written with the assumption that "str" means binary data, so unless I'm missing something, you only need to replace "str" with "bytes". Patch 725: ACK Honza -- Jan Cholasta From simo at redhat.com Thu Oct 1 13:22:09 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 1 Oct 2015 09:22:09 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560D1C2F.5080606@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> <560AE70B.5020700@redhat.com> <560D05C3.5020005@redhat.com> <560D0AFE.6020204@redhat.com> <560D0D5E.5090604@redhat.com> <560D1C2F.5080606@redhat.com> Message-ID: <560D3381.1090108@redhat.com> On 01/10/15 07:42, Jan Cholasta wrote: > Hi, > > I have just imported python-jwcrypto, custodia and pki-core-10.2.7 into > mkosek/freeipa-master as well, to (hopefully) make things easier. > > Simo, custodia failed to build F22, any idea why? See > . On the surface it looks like a missing dependency on cffi, though I am not sure why we'd need it, maybe the tests are downloading cryptography to build it for non-system python versions ? Simo. > > On 1.10.2015 12:39, Oleg Fayans wrote: >> Hi Ludwig, >> >> Thank you! vakwetu/dogtag_10.2.7_test_builds was the bit that was missing >> >> On 10/01/2015 12:29 PM, Ludwig Krispenz wrote: >>> >>> On 10/01/2015 12:06 PM, Oleg Fayans wrote: >>>> Hi Simo, >>>> >>>> I was able to build the packages based on your git repo. However, my >>>> attempt to install the resulting bits failed due to lack of >>>> dependencies: >>>> >>>> pki-ca >= 10.2.7 is needed by >>>> freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 >>>> pki-kra >= 10.2.7 is needed by >>>> freeipa-server-4.2.90.201510010815GITb726fa9-0.fc22.x86_64 >>>> >>>> My system has version 10.2.6 of above packages provided by >>>> mkosek/freeipa-master copr repo. >>>> >>>> What is the correct repo to get 10.2.7 from? >>> when Simo first submitted the patches for review he also listed the >>> repos used: >>> >>> 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) >>> >>> I'm not sure if all of them are still needed, eg for 389-ds the private >>> repo is no longer neede, but you can use this for missing rpms >>> >>> >>>> >>>> On 09/29/2015 09:31 PM 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. >>>>> >>>>> 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 mbabinsk at redhat.com Thu Oct 1 13:43:26 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 1 Oct 2015 15:43:26 +0200 Subject: [Freeipa-devel] [PATCH 0067] ipa-server-install: mark master_password Knob as deprecated In-Reply-To: <560D2BDE.3090101@redhat.com> References: <560D2BDE.3090101@redhat.com> Message-ID: <560D387E.6080505@redhat.com> On 10/01/2015 02:49 PM, Martin Babinsky wrote: > Pave Picka found out that the fix for > https://fedorahosted.org/freeipa/ticket/4516 > was partially undone during 4.2 installer rectofaring efforts. > > This one-liner should fix it for good (or at least until we move the > code around again). > > > created anew ticket for this regression (https://fedorahosted.org/freeipa/ticket/5335) and closed the original one again. Sorry for confusion and thanks to Honza for correcting me. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0067.1-ipa-server-install-mark-master_password-Knob-as-depr.patch Type: text/x-patch Size: 981 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 1 14:09:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 1 Oct 2015 16:09:29 +0200 Subject: [Freeipa-devel] [PATCH 0067] ipa-server-install: mark master_password Knob as deprecated In-Reply-To: <560D387E.6080505@redhat.com> References: <560D2BDE.3090101@redhat.com> <560D387E.6080505@redhat.com> Message-ID: <560D3E99.2000202@redhat.com> On 1.10.2015 15:43, Martin Babinsky wrote: > On 10/01/2015 02:49 PM, Martin Babinsky wrote: >> Pave Picka found out that the fix for >> https://fedorahosted.org/freeipa/ticket/4516 >> was partially undone during 4.2 installer rectofaring efforts. >> >> This one-liner should fix it for good (or at least until we move the >> code around again). >> >> >> > > created anew ticket for this regression > (https://fedorahosted.org/freeipa/ticket/5335) and closed the original > one again. > > Sorry for confusion and thanks to Honza for correcting me. Works for me, ACK. Pushed to: master: e3cb6305cc39caf8323ed0d1b729369910c97505 ipa-4-2: 63c888406b2a59e0640ceba57f6db551177a804f -- Jan Cholasta From ofayans at redhat.com Thu Oct 1 14:33:28 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 1 Oct 2015 16:33:28 +0200 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: <560D4438.40401@redhat.com> First glance on the packages built from today's tree reveal the following problems: 1. Having PTR sync enabled in global DNS configuration and installing client with --enable-dns-updates option, ipa master still does not create a PTR record for the client machine. As a result, ipa-repolica-install throws the following error: ipa : ERROR Reverse DNS resolution of address 192.168.122.171 (f22replica1.pesen.net) failed. Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.) 2. When corresponding PTR record is created manually, ipa-replica-install still fails: Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR no matching entry found The same error was catched by Jan Pazdziora (current discussion in #ipa channel) 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. > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Thu Oct 1 15:20:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 1 Oct 2015 17:20:33 +0200 Subject: [Freeipa-devel] [PATCH 0068] backup/restore CI TESTS: re-kinit after ipa-restore in some tests Message-ID: <560D4F41.7010303@redhat.com> This patch fixes failing DNS/DSSEC/KRA tests for backup and restore into already installed IPA master. It may require my PATCH 0065 to apply cleanly. Additionally, applying my PATCH 0066 (acked but not pushed as of writing this) should result in all backup/restore tests passing. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0068-re-kinit-after-ipa-restore-in-backup-restore-CI-test.patch Type: text/x-patch Size: 2019 bytes Desc: not available URL: From simo at redhat.com Thu Oct 1 22:16:41 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 1 Oct 2015 18:16:41 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560D4438.40401@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> Message-ID: <560DB0C9.4030207@redhat.com> On 01/10/15 10:33, Oleg Fayans wrote: > First glance on the packages built from today's tree reveal the > following problems: > > 1. > Having PTR sync enabled in global DNS configuration and installing > client with --enable-dns-updates option, ipa master still does not > create a PTR record for the client machine. As a result, > ipa-repolica-install throws the following error: > > ipa : ERROR Reverse DNS resolution of address 192.168.122.171 > (f22replica1.pesen.net) failed. Clients may not function properly. > Please check your DNS setup. (Note that this check queries IPA DNS > directly and ignores /etc/hosts.) I work around this by passing in --no-host-dns for now > 2. > When corresponding PTR record is created manually, ipa-replica-install > still fails: > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROR no matching > entry found > > The same error was catched by Jan Pazdziora (current discussion in #ipa > channel) I pushed a rebase patchset on top of current master that includes a small patch that should deal with the kra detection bug properly. HTH, Simo. > > > 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. >> >> >> > -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Oct 2 10:44:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 12:44:11 +0200 Subject: [Freeipa-devel] [PATCH 0068] backup/restore CI TESTS: re-kinit after ipa-restore in some tests In-Reply-To: <560D4F41.7010303@redhat.com> References: <560D4F41.7010303@redhat.com> Message-ID: <560E5FFB.4080809@redhat.com> On 10/01/2015 05:20 PM, Martin Babinsky wrote: > This patch fixes failing DNS/DSSEC/KRA tests for backup and restore > into already installed IPA master. > > It may require my PATCH 0065 to apply cleanly. > > Additionally, applying my PATCH 0066 (acked but not pushed as of > writing this) should result in all backup/restore tests passing. > > > ACK I just added ticket to patch before push Pushed to: master: 7ab52384be3109a572564797b3d186234144414b ipa-4-2: a5f6887db2cef69ca15238c5df04cdf3f4412b26 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 2 10:46:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 12:46:08 +0200 Subject: [Freeipa-devel] [PATCH 0066] fix for regression in ipa-restore In-Reply-To: <560A91CD.4020101@redhat.com> References: <560572B3.9010801@redhat.com> <560A91CD.4020101@redhat.com> Message-ID: <560E6070.7060107@redhat.com> On 09/29/2015 03:27 PM, David Kupka wrote: > On 25/09/15 18:13, Martin Babinsky wrote: >> fixes https://fedorahosted.org/freeipa/ticket/5328 >> >> >> > Fixes the issue for me, ACK. > Pushed to: master: 14977b5d84796c02a2c2a41f78919810cce83732 ipa-4-2: d333a96bce6ee0073152d94cdd8bf58d3e9d6f09 From pviktori at redhat.com Fri Oct 2 11:09:14 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 2 Oct 2015 13:09:14 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <560D31E8.6000707@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> <560D31E8.6000707@redhat.com> Message-ID: <560E65DA.6030204@redhat.com> On 10/01/2015 03:15 PM, Jan Cholasta wrote: > Hi, > > On 1.10.2015 13:01, Martin Basti wrote: >> >> >> On 09/30/2015 10:25 AM, Petr Viktorin wrote: >>> 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. [...] >>> >> LGTM >> >> I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and >> everything works > > Patches 713-719: ACK > > > Patch 720: > > You missed: > > ipa-client/ipa-install/ipa-client-install:32: from ConfigParser > import RawConfigParser Thanks, fixed. > Patches 721-722: ACK > > > Patch 723: > > Why the "NoneType = type(None)" in parameters.py? It is used only at: > > ipalib/parameters.py:388: type = NoneType # Ouch, this wont be very > useful in the real world! I believe this is less confusing than `type = type(None)`, but I can change that if needed. > Patch 724: > > The SSHPublicKey class was written with the assumption that "str" means > binary data, so unless I'm missing something, you only need to replace > "str" with "bytes". It specifically did take non-binary data as str: - if isinstance(key, str) and key[:3] != '\0\0\0': - key = key.decode(encoding) I've removed this for Python 3, where text data shouldn't be in bytes. Since this means the '\0\0\0' check is skipped in __init__ under Python 3, I've added it also to _parse_raw. It's not necessary to dispatch to "_parse_raw" or "_parse_base64 or _parse_openssh" based on type, but I believe this makes the control flow clearer to follow. > Patch 725: ACK -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0713.3-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.3-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.3-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.3-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.3-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.3-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.3-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.3-Use-six.moves.configparser-instead-of-ConfigParser.patch Type: text/x-patch Size: 12096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0721.3-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.3-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.3-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.3-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.3-Appease-pylint.patch Type: text/x-patch Size: 1277 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 2 12:05:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 14:05:58 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560D1FFF.4060402@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> <560CFB9D.4070503@redhat.com> <560D0A7C.5080803@redhat.com> <20151001103947.GB4971@redhat.com> <560D1FFF.4060402@redhat.com> Message-ID: <560E7326.30400@redhat.com> On 10/01/2015 01:58 PM, Milan Kub?k wrote: > On 10/01/2015 12:39 PM, Alexander Bokovoy wrote: >> On Thu, 01 Oct 2015, Milan Kub?k wrote: >>> On 10/01/2015 11:23 AM, Martin Basti wrote: >>>> >>>> >>>> On 10/01/2015 10:18 AM, Milan Kub?k wrote: >>>>> On 10/01/2015 10:06 AM, Milan Kub?k wrote: >>>>>> Fixes https://fedorahosted.org/freeipa/ticket/5331 >>>>>> >>>>>> Patch attached. >>>>>> >>>>>> >>>>> Patch for ipa-4-2 branch. >>>>> >>>>> Milan >>>>> >>>>> >>>> NACK >>>> >>>> http://fpaste.org/273499/43691381/ >>> I disagree. From [1]: >>> >>> Fedora now by default relies on NetworkManager for network >>> configuration. This is the case also for minimal installations and >>> server installations. >>> >>> The cloud image, which you are probably using does not have >>> NetworkManager installed. I think we can rely on the default here >>> and assume >>> NetworkManager is present. >>> >>> If you and the list disagree, I will make the fix depend on >>> NetworkManager's presence. >>> Nitpick: there can be other services that manage (and rewrite) >>> resolv.conf. >> While other tools may do it, please make it so that your fix only >> activated if NetworkManager is active. >> >> We'll get to other services once we'll encounter them. >> > Ok. Now I only apply the config and resta > rt NetworkManager when it is already running. I don't check if the > service is enabled. > ACK Pushed to master: c22c60b87c101178e5e653cada53dfdb861d1ad0 I cannot apply patch for ipa42 please send rebased version From mkubik at redhat.com Fri Oct 2 12:11:41 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 2 Oct 2015 14:11:41 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560E7326.30400@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> <560CFB9D.4070503@redhat.com> <560D0A7C.5080803@redhat.com> <20151001103947.GB4971@redhat.com> <560D1FFF.4060402@redhat.com> <560E7326.30400@redhat.com> Message-ID: <560E747D.30606@redhat.com> On 10/02/2015 02:05 PM, Martin Basti wrote: > > > On 10/01/2015 01:58 PM, Milan Kub?k wrote: >> On 10/01/2015 12:39 PM, Alexander Bokovoy wrote: >>> On Thu, 01 Oct 2015, Milan Kub?k wrote: >>>> On 10/01/2015 11:23 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 10/01/2015 10:18 AM, Milan Kub?k wrote: >>>>>> On 10/01/2015 10:06 AM, Milan Kub?k wrote: >>>>>>> Fixes https://fedorahosted.org/freeipa/ticket/5331 >>>>>>> >>>>>>> Patch attached. >>>>>>> >>>>>>> >>>>>> Patch for ipa-4-2 branch. >>>>>> >>>>>> Milan >>>>>> >>>>>> >>>>> NACK >>>>> >>>>> http://fpaste.org/273499/43691381/ >>>> I disagree. From [1]: >>>> >>>> Fedora now by default relies on NetworkManager for network >>>> configuration. This is the case also for minimal installations and >>>> server installations. >>>> >>>> The cloud image, which you are probably using does not have >>>> NetworkManager installed. I think we can rely on the default here >>>> and assume >>>> NetworkManager is present. >>>> >>>> If you and the list disagree, I will make the fix depend on >>>> NetworkManager's presence. >>>> Nitpick: there can be other services that manage (and rewrite) >>>> resolv.conf. >>> While other tools may do it, please make it so that your fix only >>> activated if NetworkManager is active. >>> >>> We'll get to other services once we'll encounter them. >>> >> Ok. Now I only apply the config and resta > >> rt NetworkManager when it is already running. I don't check if the >> service is enabled. >> > ACK > > Pushed to master: c22c60b87c101178e5e653cada53dfdb861d1ad0 > > I cannot apply patch for ipa42 please send rebased version There you go. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ipa42-mkubik-0020-2-ipatests-configure-Network-Manager-not-to-manage-res.patch Type: text/x-patch Size: 3341 bytes Desc: not available URL: From dkupka at redhat.com Fri Oct 2 12:14:58 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 2 Oct 2015 14:14:58 +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: <560E7542.6060301@redhat.com> On 23/09/15 16:46, 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? No, I've not seen any tracebacks with packaged pylint on F23. I hit a traceback when I was playing with latest pylint and astroid code. But I'm almost certain that the cause was that make-lint uses pylint's internals and it changed slightly again. > > $ ./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. > > -- David Kupka From mbasti at redhat.com Fri Oct 2 12:15:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 14:15:09 +0200 Subject: [Freeipa-devel] [patch 0020] ipatests: configure Network Manager not to manage resolv.conf In-Reply-To: <560E747D.30606@redhat.com> References: <560CE96E.1000200@redhat.com> <560CEC50.6080707@redhat.com> <560CFB9D.4070503@redhat.com> <560D0A7C.5080803@redhat.com> <20151001103947.GB4971@redhat.com> <560D1FFF.4060402@redhat.com> <560E7326.30400@redhat.com> <560E747D.30606@redhat.com> Message-ID: <560E754D.5030809@redhat.com> On 10/02/2015 02:11 PM, Milan Kub?k wrote: > On 10/02/2015 02:05 PM, Martin Basti wrote: >> >> >> On 10/01/2015 01:58 PM, Milan Kub?k wrote: >>> On 10/01/2015 12:39 PM, Alexander Bokovoy wrote: >>>> On Thu, 01 Oct 2015, Milan Kub?k wrote: >>>>> On 10/01/2015 11:23 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 10/01/2015 10:18 AM, Milan Kub?k wrote: >>>>>>> On 10/01/2015 10:06 AM, Milan Kub?k wrote: >>>>>>>> Fixes https://fedorahosted.org/freeipa/ticket/5331 >>>>>>>> >>>>>>>> Patch attached. >>>>>>>> >>>>>>>> >>>>>>> Patch for ipa-4-2 branch. >>>>>>> >>>>>>> Milan >>>>>>> >>>>>>> >>>>>> NACK >>>>>> >>>>>> http://fpaste.org/273499/43691381/ >>>>> I disagree. From [1]: >>>>> >>>>> Fedora now by default relies on NetworkManager for network >>>>> configuration. This is the case also for minimal installations and >>>>> server installations. >>>>> >>>>> The cloud image, which you are probably using does not have >>>>> NetworkManager installed. I think we can rely on the default here >>>>> and assume >>>>> NetworkManager is present. >>>>> >>>>> If you and the list disagree, I will make the fix depend on >>>>> NetworkManager's presence. >>>>> Nitpick: there can be other services that manage (and rewrite) >>>>> resolv.conf. >>>> While other tools may do it, please make it so that your fix only >>>> activated if NetworkManager is active. >>>> >>>> We'll get to other services once we'll encounter them. >>>> >>> Ok. Now I only apply the config and resta >> >>> rt NetworkManager when it is already running. I don't check if the >>> service is enabled. >>> >> ACK >> >> Pushed to master: c22c60b87c101178e5e653cada53dfdb861d1ad0 >> >> I cannot apply patch for ipa42 please send rebased version > There you go. > Pushed to ipa-4-2: 7a90bafd3012ba6ace31683bfc59f7f0c3cf6e9a From redhatrises at gmail.com Fri Oct 2 12:32:26 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 2 Oct 2015 06:32:26 -0600 Subject: [Freeipa-devel] [PATCH 0054] Update FreeIPA package description In-Reply-To: References: Message-ID: Bump for review. On Mon, Sep 21, 2015 at 9:37 AM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5284 > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 2 13:23:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 15:23:37 +0200 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <55DE502E.3030200@redhat.com> References: <55D0AC54.6040401@redhat.com> <55D44A4E.7080805@redhat.com> <55D57CDF.6070709@redhat.com> <55DE502E.3030200@redhat.com> Message-ID: <560E8559.2060107@redhat.com> On 08/27/2015 01:47 AM, Endi Sukma Dewata wrote: > On 8/20/2015 2:08 AM, Endi Sukma Dewata wrote: >> On 8/19/2015 4:20 AM, Martin Basti wrote: >>> On 08/16/2015 05:29 PM, Endi Sukma Dewata wrote: >>>> The vault-add and vault-archive commands have been modified to >>>> optionally retrieve a secret from a source vault, then re-archive >>>> the secret into the new/existing target vault. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5223 >>>> >>>> >>>> >>> I cannot apply this patch. >> >> Rebased. It depends on patch #371-2. > > Rebased due to other changes in vault. > Code works for me, but wouldn't be better to create a new command, something like vault-copy, instead of adding new options to existing command? Martin^2 From mbasti at redhat.com Fri Oct 2 14:11:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 16:11:54 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560D2BB7.8070805@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> <560BB737.2040609@redhat.com> <560BC673.5070203@redhat.com> <560CFA7E.8090107@redhat.com> <560D2A84.10202@redhat.com> <560D2BB7.8070805@redhat.com> Message-ID: <560E90AA.3080108@redhat.com> On 10/01/2015 02:48 PM, Martin Basti wrote: > > > On 10/01/2015 02:43 PM, Oleg Fayans wrote: >> Hi Martin, >> >> On 10/01/2015 11:18 AM, Martin Basti wrote: >>> >>> >>> On 09/30/2015 01:24 PM, Martin Basti wrote: >>>> >>>> >>>> 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 >>>> >>>> >>> ACK, please send rebased version for ipa-4-2 >> >> Here it is >> > Pushed to ipa-4-2: c898c968d3979a0d8c2fe0db8e125dfc2268eba0 > Pushed to master: 03d696f224642c1c4c4f1a434fecefd1c6270e37 > In rebased patch for ipa-4-2 you removed import for function and I didn't noticed that. This breaks builds of ipa-4-2. Patch that fix this attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0317-Fix-import-get_reverse_zone_default-in-tasks.patch Type: text/x-patch Size: 919 bytes Desc: not available URL: From mkubik at redhat.com Fri Oct 2 14:14:18 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 2 Oct 2015 16:14:18 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560E90AA.3080108@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> <560BB737.2040609@redhat.com> <560BC673.5070203@redhat.com> <560CFA7E.8090107@redhat.com> <560D2A84.10202@redhat.com> <560D2BB7.8070805@redhat.com> <560E90AA.3080108@redhat.com> Message-ID: <560E913A.7030009@redhat.com> On 10/02/2015 04:11 PM, Martin Basti wrote: > > > On 10/01/2015 02:48 PM, Martin Basti wrote: >> >> >> On 10/01/2015 02:43 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> On 10/01/2015 11:18 AM, Martin Basti wrote: >>>> >>>> >>>> On 09/30/2015 01:24 PM, Martin Basti wrote: >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>> ACK, please send rebased version for ipa-4-2 >>> >>> Here it is >>> >> Pushed to ipa-4-2: c898c968d3979a0d8c2fe0db8e125dfc2268eba0 >> Pushed to master: 03d696f224642c1c4c4f1a434fecefd1c6270e37 >> > > In rebased patch for ipa-4-2 you removed import for function and I > didn't noticed that. > This breaks builds of ipa-4-2. > > Patch that fix this attached. > > > ACK -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 2 14:15:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 16:15:42 +0200 Subject: [Freeipa-devel] [PATCH] Proper fix for ticket 5306 In-Reply-To: <560E913A.7030009@redhat.com> References: <5601146A.1000905@redhat.com> <56025122.8090203@redhat.com> <560A39E0.2090507@redhat.com> <560BAF73.20805@redhat.com> <560BB737.2040609@redhat.com> <560BC673.5070203@redhat.com> <560CFA7E.8090107@redhat.com> <560D2A84.10202@redhat.com> <560D2BB7.8070805@redhat.com> <560E90AA.3080108@redhat.com> <560E913A.7030009@redhat.com> Message-ID: <560E918E.1030603@redhat.com> On 10/02/2015 04:14 PM, Milan Kub?k wrote: > On 10/02/2015 04:11 PM, Martin Basti wrote: >> >> >> On 10/01/2015 02:48 PM, Martin Basti wrote: >>> >>> >>> On 10/01/2015 02:43 PM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> On 10/01/2015 11:18 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 09/30/2015 01:24 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> ACK, please send rebased version for ipa-4-2 >>>> >>>> Here it is >>>> >>> Pushed to ipa-4-2: c898c968d3979a0d8c2fe0db8e125dfc2268eba0 >>> Pushed to master: 03d696f224642c1c4c4f1a434fecefd1c6270e37 >>> >> >> In rebased patch for ipa-4-2 you removed import for function and I >> didn't noticed that. >> This breaks builds of ipa-4-2. >> >> Patch that fix this attached. >> >> >> > ACK > > -- > Milan Kubik Pushed to ipa-4-2: e7a33b71256dbda37308c4fd0ac5394472c753f7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Oct 5 05:56:41 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 5 Oct 2015 07:56:41 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <560E65DA.6030204@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> <560D31E8.6000707@redhat.com> <560E65DA.6030204@redhat.com> Message-ID: <56121119.10906@redhat.com> On 2.10.2015 13:09, Petr Viktorin wrote: > On 10/01/2015 03:15 PM, Jan Cholasta wrote: >> Hi, >> >> On 1.10.2015 13:01, Martin Basti wrote: >>> >>> >>> On 09/30/2015 10:25 AM, Petr Viktorin wrote: >>>> 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. > [...] >>>> >>> LGTM >>> >>> I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and >>> everything works >> >> Patches 713-719: ACK >> >> >> Patch 720: >> >> You missed: >> >> ipa-client/ipa-install/ipa-client-install:32: from ConfigParser >> import RawConfigParser > > > Thanks, fixed. > >> Patches 721-722: ACK >> >> >> Patch 723: >> >> Why the "NoneType = type(None)" in parameters.py? It is used only at: >> >> ipalib/parameters.py:388: type = NoneType # Ouch, this wont be very >> useful in the real world! > > I believe this is less confusing than `type = type(None)`, but I can > change that if needed. I don't care which one is used TBH, just that it is done consistently accross the whole patch, and this seemed like the simpler thing to do. > >> Patch 724: >> >> The SSHPublicKey class was written with the assumption that "str" means >> binary data, so unless I'm missing something, you only need to replace >> "str" with "bytes". > > It specifically did take non-binary data as str: > > - if isinstance(key, str) and key[:3] != '\0\0\0': > - key = key.decode(encoding) I don't follow, this is quite obviously binary data. It reads: "If key is binary and does not start with 3 null bytes, decode it to text using the specified encoding." > > I've removed this for Python 3, where text data shouldn't be in bytes. > > Since this means the '\0\0\0' check is skipped in __init__ under Python > 3, I've added it also to _parse_raw. When the SSH integration feature was first introduced, SSH public keys were stored in the raw binary form in LDAP, i.e. not text data. We still need to support that, so support for binary data and the 3 null check must remain in SSHPublicKey. > > It's not necessary to dispatch to "_parse_raw" or "_parse_base64 or > _parse_openssh" based on type, but I believe this makes the control flow > clearer to follow. > >> Patch 725: ACK > > -- Jan Cholasta From jcholast at redhat.com Mon Oct 5 07:21:58 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 5 Oct 2015 09:21:58 +0200 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <560E8559.2060107@redhat.com> References: <55D0AC54.6040401@redhat.com> <55D44A4E.7080805@redhat.com> <55D57CDF.6070709@redhat.com> <55DE502E.3030200@redhat.com> <560E8559.2060107@redhat.com> Message-ID: <56122516.3090402@redhat.com> On 2.10.2015 15:23, Martin Basti wrote: > > > On 08/27/2015 01:47 AM, Endi Sukma Dewata wrote: >> On 8/20/2015 2:08 AM, Endi Sukma Dewata wrote: >>> On 8/19/2015 4:20 AM, Martin Basti wrote: >>>> On 08/16/2015 05:29 PM, Endi Sukma Dewata wrote: >>>>> The vault-add and vault-archive commands have been modified to >>>>> optionally retrieve a secret from a source vault, then re-archive >>>>> the secret into the new/existing target vault. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5223 >>>>> >>>>> >>>>> >>>> I cannot apply this patch. >>> >>> Rebased. It depends on patch #371-2. >> >> Rebased due to other changes in vault. >> > > Code works for me, but wouldn't be better to create a new command, > something like vault-copy, instead of adding new options to existing > command? +1 -- Jan Cholasta From pspacek at redhat.com Mon Oct 5 07:55:19 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 5 Oct 2015 09:55:19 +0200 Subject: [Freeipa-devel] [PATCH 0054] Update FreeIPA package description In-Reply-To: References: Message-ID: <56122CE7.5060200@redhat.com> On 2.10.2015 14:32, Gabe Alford wrote: > Bump for review. Sorry for delay. I like the new text, ACK. Petr^2 Spacek > On Mon, Sep 21, 2015 at 9:37 AM, Gabe Alford wrote: > >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5284 >> >> Thanks, >> >> Gabe From mbasti at redhat.com Mon Oct 5 10:28:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 5 Oct 2015 12:28:17 +0200 Subject: [Freeipa-devel] FreeIPA CI tests in Vagrant Message-ID: <561250C1.7060205@redhat.com> Hello, I would like to share my script that allows to create topology for FreeIPA CI tests in Vagrant. It is very first "stupid" version, works only with F22 box. It is useful for development. Script creates Vagrant configuration and CI configuration for YAML. Machines created by vagrant are named: controller (created by default) master (created by default) replica1 (--replicas option) . . replicaN client1 (--client option) . . clientM The script is available here https://github.com/bastiak/ipa-devel-tools Required packages: vagrant vagrant-libvirt PyYAML Usage: $python3 ipa-vagrant-ci-topology-create.py ci-test --replicas 1 --clients 1 $python3 ipa-vagrant-ci-topology-create.py -h Use --help for more options It creates directory structure in current location . ??? ci-test ? ??? controller_rsa # generated private key for controller ? ??? controller_rsa.pub # generated public key for controller (needed by CI tests) ? ??? ipa-test-config.yaml # generated configuration for CI tests ? ??? provisioning # currently empty dir, but I have big plans with it :) ? ??? rpms # custom RPMs that will be installed on all machines ? ??? Vagrantfile # generated configration file for Vagrant $ cd ci-test $ vagrant up $ vagrant ssh [controller|master|replica1|...] (by default it open connection to controller machine) $IPATEST_YAML_CONFIG=/vagrant/ipa-test-config.yaml ipa-run-tests test_integration/test_simple_replication.py # configuration file is located in /vagrant directory $ logout $ vagrant destroy Martin From mkubik at redhat.com Mon Oct 5 11:45:25 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 5 Oct 2015 13:45:25 +0200 Subject: [Freeipa-devel] [patch 0021] Include ipatests/test_xmlrpc/data directory into distribution Message-ID: <561262D5.2030406@redhat.com> Adds ipatests/test_xmlrpc/data directory and its content into package. The files are needed for certprofile (and CA ACL) tests. Patch attached. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0021-Include-ipatests-test_xmlrpc-data-directory-into-dis.patch Type: text/x-patch Size: 835 bytes Desc: not available URL: From jpazdziora at redhat.com Mon Oct 5 12:15:41 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 5 Oct 2015 14:15:41 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560D4438.40401@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> Message-ID: <20151005121541.GA10207@redhat.com> On Thu, Oct 01, 2015 at 04:33:28PM +0200, Oleg Fayans wrote: > > 1. > Having PTR sync enabled in global DNS configuration and installing client > with --enable-dns-updates option, ipa master still does not create a PTR > record for the client machine. As a result, ipa-repolica-install throws the > following error: > > ipa : ERROR Reverse DNS resolution of address 192.168.122.171 > (f22replica1.pesen.net) failed. Clients may not function properly. Please > check your DNS setup. (Note that this check queries IPA DNS directly and > ignores /etc/hosts.) I believe you also need to have the PTR sync enabled in the forward zone (pesen.net). -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbabinsk at redhat.com Mon Oct 5 13:00:10 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 5 Oct 2015 15:00:10 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization Message-ID: <5612745A.2090805@redhat.com> These patches implement the plumbing required to properly support canonicalization of Kerberos principals ( https://fedorahosted.org/freeipa/ticket/3864). Setting multiple principal aliases on hosts/services is beyond the scope of this patchset and should be done after these patches are pushed. I will try to send some tests for the patches later this week. Please review the hell out of them. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0077-account-for-added-krbcanonicalname-attribute-during-.patch Type: text/x-patch Size: 7146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0076-set-krbcanonicalname-on-host-entry-during-krbinstanc.patch Type: text/x-patch Size: 1098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0075-IPA-API-set-krbcanonicalname-instead-of-ipakrbprinci.patch Type: text/x-patch Size: 6419 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0074-ipa-enrollment-set-krbCanonicalName-attribute-on-enr.patch Type: text/x-patch Size: 1961 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0073-ipa-kdb-set-krbCanonicalName-when-creating-new-princ.patch Type: text/x-patch Size: 1503 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0072-add-krbCanonicalName-to-attributes-watched-by-MODRDN.patch Type: text/x-patch Size: 1189 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0071-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: freeipa-mbabinsk-0070-mark-ipaKrbPrincipalAlias-attribute-as-deprecated-in.patch Type: text/x-patch Size: 1389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0069-perform-case-insensitive-principal-search-when-canon.patch Type: text/x-patch Size: 2329 bytes Desc: not available URL: From tjaalton at ubuntu.com Mon Oct 5 13:08:32 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 5 Oct 2015 16:08:32 +0300 Subject: [Freeipa-devel] [PATCHES] from Debian Message-ID: <56127650.9010600@ubuntu.com> Hi Here are a few prep patches to get off the list before getting to discuss how to add Debian platform support.. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0001-Add-GENERATE_RNDC_KEY.patch Type: text/x-patch Size: 1801 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0002-Fix-hyphen-used-as-minus-sign-warning.patch Type: text/x-patch Size: 6185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0003-Fix-manpage-has-errors-from-man-warning.patch Type: text/x-patch Size: 2881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0004-default.conf.5-Fix-a-typo.patch Type: text/x-patch Size: 1109 bytes Desc: not available URL: From simo at redhat.com Mon Oct 5 13:31:02 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 5 Oct 2015 09:31:02 -0400 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56127650.9010600@ubuntu.com> References: <56127650.9010600@ubuntu.com> Message-ID: <56127B96.30000@redhat.com> On 05/10/15 09:08, Timo Aaltonen wrote: > > Hi > > Here are a few prep patches to get off the list before getting to > discuss how to add Debian platform support.. > LGTM. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Oct 5 13:37:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 5 Oct 2015 15:37:08 +0200 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56127B96.30000@redhat.com> References: <56127650.9010600@ubuntu.com> <56127B96.30000@redhat.com> Message-ID: <56127D04.4080005@redhat.com> On 10/05/2015 03:31 PM, Simo Sorce wrote: > On 05/10/15 09:08, Timo Aaltonen wrote: >> >> Hi >> >> Here are a few prep patches to get off the list before getting to >> discuss how to add Debian platform support.. >> > > LGTM. > > Simo. > > IMO this should be written in this way (I didn't test) ipautil.run([paths.GENERATE_RNDC_KEY]) Martin From tjaalton at ubuntu.com Mon Oct 5 13:41:22 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 5 Oct 2015 16:41:22 +0300 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56127D04.4080005@redhat.com> References: <56127650.9010600@ubuntu.com> <56127B96.30000@redhat.com> <56127D04.4080005@redhat.com> Message-ID: <56127E02.2090907@ubuntu.com> On 05.10.2015 16:37, Martin Basti wrote: > > > On 10/05/2015 03:31 PM, Simo Sorce wrote: >> On 05/10/15 09:08, Timo Aaltonen wrote: >>> >>> Hi >>> >>> Here are a few prep patches to get off the list before getting to >>> discuss how to add Debian platform support.. >>> >> >> LGTM. >> >> Simo. >> >> > > IMO this should be written in this way (I didn't test) > > ipautil.run([paths.GENERATE_RNDC_KEY]) Yes you're right, here's an updated version. -- t -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0001-2-Add-GENERATE_RNDC_KEY.patch Type: text/x-patch Size: 1803 bytes Desc: not available URL: From ofayans at redhat.com Mon Oct 5 13:42:26 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 5 Oct 2015 15:42:26 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <20151005121541.GA10207@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> <20151005121541.GA10207@redhat.com> Message-ID: <56127E42.4090306@redhat.com> Hi Jan, Simo On 10/05/2015 02:15 PM, Jan Pazdziora wrote: > On Thu, Oct 01, 2015 at 04:33:28PM +0200, Oleg Fayans wrote: >> >> 1. >> Having PTR sync enabled in global DNS configuration and installing client >> with --enable-dns-updates option, ipa master still does not create a PTR >> record for the client machine. As a result, ipa-repolica-install throws the >> following error: >> >> ipa : ERROR Reverse DNS resolution of address 192.168.122.171 >> (f22replica1.pesen.net) failed. Clients may not function properly. Please >> check your DNS setup. (Note that this check queries IPA DNS directly and >> ignores /etc/hosts.) > > I believe you also need to have the PTR sync enabled in the forward zone >(pesen.net). > Today I was unable to reproduce this issue with just PTR sync enabled in global dns configuration. I wonder, what might have caused it. Anyway, today I hit a number of other issues with replica promotion. 1. At one point ipa-replica-install on a configured client has thrown the following error: Configuring ipa-custodia [1/5]: Generating ipa-custodia config file [2/5]: Generating ipa-custodia keys [3/5]: Importing RA Key [error] HTTPError: 502 Server Error: Proxy Error Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR 502 Server Error: Proxy Error (corresponding part of the error log of dirsrv attached) 2. The second attempt after re-enrolling client resulted in the error of CA installation: Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [4/24]: creating installation admin user [5/24]: setting up certificate server ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpHAJVFG'' returned non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation logs and the following files/directories for more information: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki-ca-install.log ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration failed. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR CA configuration failed. Weird thing is that mentioned log files were missing in the system. 3. This is probably not related to replica promotions, but anyway: when I do `ipa host-del --updatedns %client_hostname%` on master, it does delete the host, but *preserves* dns records (in both zones). Is --updatedns option not aimed at automatic deletion of dns records? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target ou=sudoers,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=users,cn=compat,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:45 -0400] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pesen,dc=net does not exist [05/Oct/2015:04:08:46 -0400] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [05/Oct/2015:04:08:46 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pesen,dc=net--no CoS Templates found, which should be added before the CoS Definition. [05/Oct/2015:04:08:46 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [05/Oct/2015:04:08:46 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=pesen,dc=net. Check if DB RUV needs to be updated [05/Oct/2015:04:08:46 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/f22master.pesen.net at PESEN.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [05/Oct/2015:04:08:46 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/f22master.pesen.net at PESEN.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [05/Oct/2015:04:08:47 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [05/Oct/2015:04:08:47 -0400] - Listening on All Interfaces port 636 for LDAPS requests [05/Oct/2015:04:08:47 -0400] - Listening on /var/run/slapd-PESEN-NET.socket for LDAPI requests [05/Oct/2015:04:08:49 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:08:49 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:08:50 -0400] NSMMReplicationPlugin - agmt="cn=caTof22replica2.pesen.net" (f22replica2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [05/Oct/2015:04:08:50 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:08:50 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:08:50 -0400] NSMMReplicationPlugin - agmt="cn=meTof22replica2.pesen.net" (f22replica2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [05/Oct/2015:04:08:56 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:08:56 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:08:56 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:08:56 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:08:59 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:08:59 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:09:00 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:09:00 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:09:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:09:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:09:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:09:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:09:25 -0400] - Operation error fetching Null DN (4d117b18-6b3811e5-98bf90b1-17e491b1), error -30993. [05/Oct/2015:04:09:38 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:09:38 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:09:38 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:09:39 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:10:26 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:10:26 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:10:26 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:10:26 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:12:02 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:12:02 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:12:02 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:12:02 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:15:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:15:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:15:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:15:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:20:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:20:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:20:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:20:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:25:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:25:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:25:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:25:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:30:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:30:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:30:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:30:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:35:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:35:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:35:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:35:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:40:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:40:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:40:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:40:15 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:45:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:45:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:45:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:45:15 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:50:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:50:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:50:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:50:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:55:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:55:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:04:55:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:04:55:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:00:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:00:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:00:15 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:00:15 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:00:20 -0400] NSMMReplicationPlugin - agmt="cn=meTof22replica1.pesen.net" (f22replica1:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [05/Oct/2015:05:00:22 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meTof22replica1.pesen.net" (f22replica1:389)". [05/Oct/2015:05:00:26 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=meTof22replica1.pesen.net" (f22replica1:389)". Sent 452 entries. [05/Oct/2015:05:00:29 -0400] NSMMReplicationPlugin - agmt="cn=meTof22replica1.pesen.net" (f22replica1:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. [05/Oct/2015:05:00:32 -0400] NSMMReplicationPlugin - agmt="cn=meTof22replica1.pesen.net" (f22replica1:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [05/Oct/2015:05:00:38 -0400] NSMMReplicationPlugin - agmt="cn=meTof22replica1.pesen.net" (f22replica1:389): Replication bind with GSSAPI auth resumed [05/Oct/2015:05:05:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:05:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:05:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:05:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:10:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:10:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:10:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:10:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:15:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:15:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:15:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:15:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:20:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:20:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:20:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:20:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:25:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:25:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:25:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:25:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:30:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:30:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:30:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:30:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:35:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:35:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:35:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:35:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:40:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:40:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:40:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:40:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:45:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:45:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:45:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:45:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:50:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:50:15 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:50:15 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:50:15 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:55:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:55:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:05:55:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:05:55:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:06:00:14 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:06:00:14 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [05/Oct/2015:06:00:15 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [05/Oct/2015:06:00:15 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) From simo at redhat.com Mon Oct 5 13:47:14 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 5 Oct 2015 09:47:14 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56127E42.4090306@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> <20151005121541.GA10207@redhat.com> <56127E42.4090306@redhat.com> Message-ID: <56127F62.8090705@redhat.com> On 05/10/15 09:42, Oleg Fayans wrote: > Hi Jan, Simo > > On 10/05/2015 02:15 PM, Jan Pazdziora wrote: >> On Thu, Oct 01, 2015 at 04:33:28PM +0200, Oleg Fayans wrote: >>> >>> 1. >>> Having PTR sync enabled in global DNS configuration and installing >>> client >>> with --enable-dns-updates option, ipa master still does not create a PTR >>> record for the client machine. As a result, ipa-repolica-install >>> throws the >>> following error: >>> >>> ipa : ERROR Reverse DNS resolution of address 192.168.122.171 >>> (f22replica1.pesen.net) failed. Clients may not function properly. >>> Please >>> check your DNS setup. (Note that this check queries IPA DNS directly and >>> ignores /etc/hosts.) >> >> I believe you also need to have the PTR sync enabled in the forward zone >> (pesen.net). >> > > Today I was unable to reproduce this issue with just PTR sync enabled in > global dns configuration. I wonder, what might have caused it. Anyway, > today I hit a number of other issues with replica promotion. > > 1. At one point ipa-replica-install on a configured client has thrown > the following error: > > Configuring ipa-custodia > [1/5]: Generating ipa-custodia config file > [2/5]: Generating ipa-custodia keys > [3/5]: Importing RA Key > [error] HTTPError: 502 Server Error: Proxy Error > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROR 502 Server > Error: Proxy Error > > (corresponding part of the error log of dirsrv attached) Seem like the peer server was unreachable ? Was there a networking problem ? > 2. The second attempt after re-enrolling client resulted in the error of > CA installation: > > Starting replication, please wait until this has completed. > Update in progress, 7 seconds elapsed > Update succeeded > > [4/24]: creating installation admin user > [5/24]: setting up certificate server > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to > configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' > '/tmp/tmpHAJVFG'' returned non-zero exit status 1 > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the > installation logs and the following files/directories for more information: > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL > /var/log/pki-ca-install.log > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL > /var/log/pki/pki-tomcat > [error] RuntimeError: CA configuration failed. > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROR CA > configuration failed. This is due to the known bug with authentication in Dogtag. Endy fixed it upstream. Endy, do you know when the bug will be released in a package we can use for testing ? > Weird thing is that mentioned log files were missing in the system. > > 3. This is probably not related to replica promotions, but anyway: > when I do `ipa host-del --updatedns %client_hostname%` on master, it > does delete the host, but *preserves* dns records (in both zones). > Is --updatedns option not aimed at automatic deletion of dns records? I do not know that it does help, but I tend to use --force when deleting a failed replica. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Oct 5 14:12:09 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 5 Oct 2015 10:12:09 -0400 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <5612745A.2090805@redhat.com> References: <5612745A.2090805@redhat.com> Message-ID: <56128539.7070304@redhat.com> On 05/10/15 09:00, Martin Babinsky wrote: > These patches implement the plumbing required to properly support > canonicalization of Kerberos principals ( > https://fedorahosted.org/freeipa/ticket/3864). > > Setting multiple principal aliases on hosts/services is beyond the scope > of this patchset and should be done after these patches are pushed. > > I will try to send some tests for the patches later this week. > > Please review the hell out of them. LGTM, I do not see any issue at quick visual inspection. What about the performance regression with the indexes ? Is that bug fixed in 389ds ? Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Mon Oct 5 14:33:59 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 5 Oct 2015 09:33:59 -0500 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56127F62.8090705@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> <20151005121541.GA10207@redhat.com> <56127E42.4090306@redhat.com> <56127F62.8090705@redhat.com> Message-ID: <56128A57.3070806@redhat.com> On 10/5/2015 8:47 AM, Simo Sorce wrote: >> 2. The second attempt after re-enrolling client resulted in the error of >> CA installation: >> >> Starting replication, please wait until this has completed. >> Update in progress, 7 seconds elapsed >> Update succeeded >> >> [4/24]: creating installation admin user >> [5/24]: setting up certificate server >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to >> configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' >> '/tmp/tmpHAJVFG'' returned non-zero exit status 1 >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the >> installation logs and the following files/directories for more >> information: >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL >> /var/log/pki-ca-install.log >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL >> /var/log/pki/pki-tomcat >> [error] RuntimeError: CA configuration failed. >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> ipa.ipapython.install.cli.install_tool(Replica): ERROR CA >> configuration failed. > > This is due to the known bug with authentication in Dogtag. Endy fixed > it upstream. > > Endy, > do you know when the bug will be released in a package we can use for > testing ? Here is the bug: https://fedorahosted.org/pki/ticket/1580 I don't think we're ready for a Dogtag 10.3 build, so we may need to cherry-pick it to 10.2.x. I'll check with Matt. -- Endi S. Dewata From tjaalton at ubuntu.com Mon Oct 5 14:44:34 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 5 Oct 2015 17:44:34 +0300 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56127650.9010600@ubuntu.com> References: <56127650.9010600@ubuntu.com> Message-ID: <56128CD2.10304@ubuntu.com> On 05.10.2015 16:08, Timo Aaltonen wrote: > > Hi > > Here are a few prep patches to get off the list before getting to > discuss how to add Debian platform support.. Here's one more. -- t -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0005-Replace-a-hardcoded-path-to-password.co.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 5 14:46:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 5 Oct 2015 16:46:27 +0200 Subject: [Freeipa-devel] [patch 0021] Include ipatests/test_xmlrpc/data directory into distribution In-Reply-To: <561262D5.2030406@redhat.com> References: <561262D5.2030406@redhat.com> Message-ID: <56128D43.6090502@redhat.com> On 10/05/2015 01:45 PM, Milan Kub?k wrote: > Adds ipatests/test_xmlrpc/data directory and its content into package. > The files are needed for certprofile (and CA ACL) tests. > Patch attached. > > > ACK Pushed to: master: dbfdc1d39b7917236270fe4dff6caf0ccb5cd04c ipa-4-2: c99e0aa6fda2bbbfdd871f78ef246641dee3626c -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Mon Oct 5 15:00:36 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 5 Oct 2015 18:00:36 +0300 Subject: [Freeipa-devel] Remaining issues before adding Debian platform support Message-ID: <56129094.6090802@ubuntu.com> Hi I'm not sure if the goal is to be able to build IPA on Debian from git/tarballs, but here's a list of what would need to be fixed first to get there: - places where usernames have been hardcoded need something like ipaplatform/base/paths.py: apache -> www-data in: * ipaserver/install/httpinstance.py * ipaserver/install/ipa_server_certinstall.py * ipaserver/install/cainstance.py * ipaserver/install/certs.py named -> bind in: * ipaserver/install/bindinstance.py - config/service files that use hardcoded paths in them need to be moved to a template, and use paths.py macros: * install/conf/ipa.conf * init/systemd/ipa_memcached.service - same but with hardcoded usernames * init/ipa_memcached.conf - ipaserver/install/httpinstance.py needs to run "a2enmod/a2dismod nss" because libapache2-mod-nss doesn't enable it on install (can't remember why, but there was a good reason..) - various places using Fedora-specific libpaths (/usr/lib vs. /usr/lib64), whereas on Debian these are /usr/lib/, see https://wiki.debian.org/Multiarch/Tuples * ipaserver/install/ldapupdate.py * ipapython/certmonger.py * ipaserver/install/certs.py * ipaserver/install/ipa_backup.py * ipaserver/install/ipa_restore.py - ntp daemon defaults use a different variable name (OPTIONS vs NTPD_OPTS), and quotes (" vs. ') * ipaserver/install/ntpinstance.py - "Include conf.d/ipa-rewrite.conf" in httpinstance.py needs to use an absolute path with HTTPD_CONF_D, or HTTPD_CONF_D repurposed to only have 'conf.d' on Fedora and then conf-enabled on Debian - install/share/bind.named.conf.template needs to drop the default zone on Debian, since that's already configured via includes (-> bind fails to start), so a template file with an exception for Debian would fix it - Makefile needs to use --install-layout=deb for setup.py - ipa-client/ipa-install/ipa-client-automount needs to check for variable named 'NEED_GSSD' on debian, so ipaplatform/base/vars.py? (same for NTPD_OPTS) There.. that should be all I think :) Oh, forgot that currently dnssec needs to be disabled by some heavy patching, because 9.10.x isn't packaged yet.. -- t From sbose at redhat.com Mon Oct 5 15:28:45 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 5 Oct 2015 17:28:45 +0200 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal In-Reply-To: <20150903152205.GP22106@redhat.com> References: <20150903144220.GO22106@redhat.com> <20150903152205.GP22106@redhat.com> Message-ID: <20151005152845.GC19585@p.redhat.com> On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote: > 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. The patch looks good and works as advertised. I've tested in a IPA domain which trusts two different forests. All requests to the forest roots and child domains where properly redirected. I tested with your krb5 test build and with MIT Kerberos 1.14 which contains the needed fix. Nevertheless there are a view points I want to discuss: - missing support for AD's Alternative Domain Suffixes, this is important to allow AD users to login in with their "Email-Address" (which is the typical reference for a user name with an alternative domain suffix). I think this is not strictly related to the given ticket, so it can be solved in the context of a new ticket, do you agree? - referrals from outside. If I call 'kinit -E admin at IPA.DOMAIN' from a client in a trusted AD forest I get a 'Client not found in database' error because AD tends to use lower case domain names in the referal response. The request is still properly send to the IPA KDC because DNS does not care about the case. The IPA KDC processes the request with the principal 'user\@IPA.DOMAIN at ipa.domain' until ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue it detects that the principal is from the local realm. I think it would be good to enhance your patch to handle this case. - S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across domain and forest boundaries (I tested this in a setup with 2 AD forests with request going from a child domain to a child domain in the other forest. Unfortunately it is currently not working with IPA in neither direction (I guess the case issue from above might be the reason for the incoming request to fail). Here I think a new ticket would to good as well because some research might be needed and the issue might even be in the MIT code. (If you want to run some tests I can give you access to my test environment.) Let me know if you prefer to handle the issues with other tickets, then I would ACK the patch as it is. bye, Sumit > > -- > / Alexander Bokovoy From mbasti at redhat.com Mon Oct 5 15:46:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 5 Oct 2015 17:46:33 +0200 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56127E02.2090907@ubuntu.com> References: <56127650.9010600@ubuntu.com> <56127B96.30000@redhat.com> <56127D04.4080005@redhat.com> <56127E02.2090907@ubuntu.com> Message-ID: <56129B59.7050207@redhat.com> On 10/05/2015 03:41 PM, Timo Aaltonen wrote: > On 05.10.2015 16:37, Martin Basti wrote: >> >> On 10/05/2015 03:31 PM, Simo Sorce wrote: >>> On 05/10/15 09:08, Timo Aaltonen wrote: >>>> Hi >>>> >>>> Here are a few prep patches to get off the list before getting to >>>> discuss how to add Debian platform support.. >>>> >>> LGTM. >>> >>> Simo. >>> >>> >> IMO this should be written in this way (I didn't test) >> >> ipautil.run([paths.GENERATE_RNDC_KEY]) > Yes you're right, here's an updated version. > > > ACK Pushed to master: 7059117ec32bfad8ec802d472b0f7d2b6cb12d2a From mbasti at redhat.com Mon Oct 5 17:00:32 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 5 Oct 2015 19:00:32 +0200 Subject: [Freeipa-devel] Remaining issues before adding Debian platform support In-Reply-To: <56129094.6090802@ubuntu.com> References: <56129094.6090802@ubuntu.com> Message-ID: <5612ACB0.9000602@redhat.com> On 10/05/2015 05:00 PM, Timo Aaltonen wrote: > Hi > > I'm not sure if the goal is to be able to build IPA on Debian from > git/tarballs, but here's a list of what would need to be fixed first to > get there: > > - places where usernames have been hardcoded need something like > ipaplatform/base/paths.py: > apache -> www-data in: > * ipaserver/install/httpinstance.py > * ipaserver/install/ipa_server_certinstall.py > * ipaserver/install/cainstance.py > * ipaserver/install/certs.py this can be extracted to ipaplatform/base/constants.py > named -> bind in: > * ipaserver/install/bindinstance.py this is quite tricky, for named_user the right location is to ipaplatform/base/constants.py for service, you can look in ipaplatform/redhat/services.py there is already mapping named to named.pkcs11, we can do something similar in debian platform specification, debian_system_units['named'] = 'bind.service' However if you want to replace named with bind completely, it requires much more changes. > > - config/service files that use hardcoded paths in them need to be moved > to a template, and use paths.py macros: > * install/conf/ipa.conf > * init/systemd/ipa_memcached.service > > - same but with hardcoded usernames > * init/ipa_memcached.conf A discussion with other developer is needed how to resolve these files > > - ipaserver/install/httpinstance.py needs to run "a2enmod/a2dismod nss" > because libapache2-mod-nss doesn't enable it on install (can't remember > why, but there was a good reason..) We did installer changes, Honza may know if this is possible. > > - various places using Fedora-specific libpaths (/usr/lib vs. > /usr/lib64), whereas on Debian these are /usr/lib/, see > https://wiki.debian.org/Multiarch/Tuples I might be wrong, but I found different issues: > * ipaserver/install/ldapupdate.py this affects update files, and the same issue is for ldif files We can replace path '/var/lib(64)' with substitute variable in those files, and create a platform specific method to determine the correct path, or just substitute with value from ipaplatform/base/paths > * ipapython/certmonger.py > * ipaserver/install/certs.py > * ipaserver/install/ipa_backup.py > * ipaserver/install/ipa_restore.py Here for libpath we can use ipaplatform task.py or path.py if it is enough The occurrences of /var/lib/ipa/backup should be in ipaplatform/paths > > - ntp daemon defaults use a different variable name (OPTIONS vs > NTPD_OPTS), and quotes (" vs. ') > * ipaserver/install/ntpinstance.py IMO here also default pools should be excluded to constants as a list of ntp servers per platform. OPTIONS can be excluded to ipaplatform/constants.py Probably the " or ' issue can be handled in the same way > > - "Include conf.d/ipa-rewrite.conf" in httpinstance.py needs to use an > absolute path with HTTPD_CONF_D, or HTTPD_CONF_D repurposed to only have > 'conf.d' on Fedora and then conf-enabled on Debian ok > > - install/share/bind.named.conf.template needs to drop the default zone > on Debian, since that's already configured via includes (-> bind fails > to start), so a template file with an exception for Debian would fix it The solution here can be augeas, but I'm not sure if we will able to move to augeas soon enough. This is the same issue as with ipa.conf > > - Makefile needs to use --install-layout=deb for setup.py > > - ipa-client/ipa-install/ipa-client-automount needs to check for > variable named 'NEED_GSSD' on debian, so ipaplatform/base/vars.py? (same > for NTPD_OPTS) Leaving this for others. > > > There.. that should be all I think :) Oh, forgot that currently dnssec > needs to be disabled by some heavy patching, because 9.10.x isn't > packaged yet.. I'm willing to send patch to disable DNSSEC installation if you want. Is there a chance to get 9.10.x with pkcs11 support? Can you please open a ticket? Thank you for this investigation Martin^2 From mbasti at redhat.com Mon Oct 5 17:29:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 5 Oct 2015 19:29:38 +0200 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56128CD2.10304@ubuntu.com> References: <56127650.9010600@ubuntu.com> <56128CD2.10304@ubuntu.com> Message-ID: <5612B382.5030204@redhat.com> On 10/05/2015 04:44 PM, Timo Aaltonen wrote: > On 05.10.2015 16:08, Timo Aaltonen wrote: >> Hi >> >> Here are a few prep patches to get off the list before getting to >> discuss how to add Debian platform support.. > Here's one more. > > > > > ACK Pushed to master: 7c32ecaa0ebdfc879d6d2286974987b9fee7082e -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Tue Oct 6 05:19:11 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 6 Oct 2015 07:19:11 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <56128539.7070304@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> Message-ID: <561359CF.7060909@redhat.com> On 05/10/15 16:12, Simo Sorce wrote: > On 05/10/15 09:00, Martin Babinsky wrote: >> These patches implement the plumbing required to properly support >> canonicalization of Kerberos principals ( >> https://fedorahosted.org/freeipa/ticket/3864). >> >> Setting multiple principal aliases on hosts/services is beyond the scope >> of this patchset and should be done after these patches are pushed. >> >> I will try to send some tests for the patches later this week. >> >> Please review the hell out of them. > > LGTM, I do not see any issue at quick visual inspection. > What about the performance regression with the indexes ? Is that bug > fixed in 389ds ? > > Simo. > > The issue is still there. Thierry investigated this in 389 DS and IIUC he is not sure if it's bug or completely missing feature. Therefore we still don't know how much time is needed there. -- David Kupka From pspacek at redhat.com Tue Oct 6 07:46:08 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 6 Oct 2015 09:46:08 +0200 Subject: [Freeipa-devel] [PATCH 0058] Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limit Message-ID: <56137C40.7080603@redhat.com> Hello, Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limits. https://bugzilla.redhat.com/show_bug.cgi?id=1268027 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0058-Avoid-ipa-dnskeysync-replica-ipa-ods-exporter-crashe.patch Type: text/x-patch Size: 2369 bytes Desc: not available URL: From tbordaz at redhat.com Tue Oct 6 07:51:40 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 06 Oct 2015 09:51:40 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <561359CF.7060909@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> Message-ID: <56137D8C.3090401@redhat.com> On 10/06/2015 07:19 AM, David Kupka wrote: > On 05/10/15 16:12, Simo Sorce wrote: >> On 05/10/15 09:00, Martin Babinsky wrote: >>> These patches implement the plumbing required to properly support >>> canonicalization of Kerberos principals ( >>> https://fedorahosted.org/freeipa/ticket/3864). >>> >>> Setting multiple principal aliases on hosts/services is beyond the >>> scope >>> of this patchset and should be done after these patches are pushed. >>> >>> I will try to send some tests for the patches later this week. >>> >>> Please review the hell out of them. >> >> LGTM, I do not see any issue at quick visual inspection. >> What about the performance regression with the indexes ? Is that bug >> fixed in 389ds ? >> >> Simo. >> >> > > The issue is still there. Thierry investigated this in 389 DS and IIUC > he is not sure if it's bug or completely missing feature. Therefore we > still don't know how much time is needed there. > Hi, that is correct. I can reproduce the problem. Although the matching rule (in my test caseIgnoreIA5Match) is found, it has no registered indexing function, so the setting (nsMatchingRule) is ignored. I do not know if the indexing function is missing or there is a bug so that the matching rule "forget" to register it. This feature is documented but I can not find any QA test around it, so I do not know yet if it is a regression or if it was not enabled at all. I do not expect rapid progress on it. How urgent is it ? 7.3 ? For the moment I can think to only two workarounds: * use filtered matching rule (preferred) * change the attribute syntax/matching rule, in the schema (I would discourage this one because changing the schema is risky) thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Oct 6 08:10:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 6 Oct 2015 10:10:40 +0200 Subject: [Freeipa-devel] [PATCH 0058] Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limit In-Reply-To: <56137C40.7080603@redhat.com> References: <56137C40.7080603@redhat.com> Message-ID: <56138200.5020508@redhat.com> On 10/06/2015 09:46 AM, Petr Spacek wrote: > Hello, > > Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding > LDAP limits. > > https://bugzilla.redhat.com/show_bug.cgi?id=1268027 > NACK ************* Module ipa-dnskeysync-replica daemons/dnssec/ipa-dnskeysync-replica:156: [E0602(undefined-variable), ] Undefined variable 'api') ************* Module ipa-ods-exporter daemons/dnssec/ipa-ods-exporter:505: [E0602(undefined-variable), ] Undefined variable 'api') From pspacek at redhat.com Tue Oct 6 08:28:50 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 6 Oct 2015 10:28:50 +0200 Subject: [Freeipa-devel] [PATCH 0058] Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limit In-Reply-To: <56138200.5020508@redhat.com> References: <56137C40.7080603@redhat.com> <56138200.5020508@redhat.com> Message-ID: <56138642.50400@redhat.com> On 6.10.2015 10:10, Martin Basti wrote: > On 10/06/2015 09:46 AM, Petr Spacek wrote: >> Hello, >> >> Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding >> LDAP limits. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1268027 >> > NACK > > ************* Module ipa-dnskeysync-replica > daemons/dnssec/ipa-dnskeysync-replica:156: [E0602(undefined-variable), ] > Undefined variable 'api') > ************* Module ipa-ods-exporter > daemons/dnssec/ipa-ods-exporter:505: [E0602(undefined-variable), ] Undefined > variable 'api') Sorry, I'm idiot. Fixed patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0058-2-Avoid-ipa-dnskeysync-replica-ipa-ods-exporter-crashe.patch Type: text/x-patch Size: 2750 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 6 10:02:07 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 6 Oct 2015 12:02:07 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <56121119.10906@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> <560D31E8.6000707@redhat.com> <560E65DA.6030204@redhat.com> <56121119.10906@redhat.com> Message-ID: <56139C1F.2070009@redhat.com> On 10/05/2015 07:56 AM, Jan Cholasta wrote: > On 2.10.2015 13:09, Petr Viktorin wrote: >> On 10/01/2015 03:15 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 1.10.2015 13:01, Martin Basti wrote: >>>> >>>> >>>> On 09/30/2015 10:25 AM, Petr Viktorin wrote: >>>>> 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. >> [...] >>>>> >>>> LGTM >>>> >>>> I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and >>>> everything works >>> >>> Patches 713-719: ACK >>> >>> >>> Patch 720: >>> >>> You missed: >>> >>> ipa-client/ipa-install/ipa-client-install:32: from ConfigParser >>> import RawConfigParser >> >> >> Thanks, fixed. >> >>> Patches 721-722: ACK >>> >>> >>> Patch 723: >>> >>> Why the "NoneType = type(None)" in parameters.py? It is used only at: >>> >>> ipalib/parameters.py:388: type = NoneType # Ouch, this wont be very >>> useful in the real world! >> >> I believe this is less confusing than `type = type(None)`, but I can >> change that if needed. > > I don't care which one is used TBH, just that it is done consistently > accross the whole patch, and this seemed like the simpler thing to do. OK, changed. >>> Patch 724: >>> >>> The SSHPublicKey class was written with the assumption that "str" means >>> binary data, so unless I'm missing something, you only need to replace >>> "str" with "bytes". >> >> It specifically did take non-binary data as str: >> >> - if isinstance(key, str) and key[:3] != '\0\0\0': >> - key = key.decode(encoding) > > I don't follow, this is quite obviously binary data. It reads: "If key > is binary and does not start with 3 null bytes, decode it to text using > the specified encoding." Sorry, I meant binary data. >> I've removed this for Python 3, where text data shouldn't be in bytes. >> >> Since this means the '\0\0\0' check is skipped in __init__ under Python >> 3, I've added it also to _parse_raw. > > When the SSH integration feature was first introduced, SSH public keys > were stored in the raw binary form in LDAP, i.e. not text data. We still > need to support that, so support for binary data and the 3 null check > must remain in SSHPublicKey. > >> >> It's not necessary to dispatch to "_parse_raw" or "_parse_base64 or >> _parse_openssh" based on type, but I believe this makes the control flow >> clearer to follow. >> >>> Patch 725: ACK >> >> > > -- Petr Viktorin From pviktori at redhat.com Tue Oct 6 10:04:16 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 6 Oct 2015 12:04:16 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <56121119.10906@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> <560D31E8.6000707@redhat.com> <560E65DA.6030204@redhat.com> <56121119.10906@redhat.com> Message-ID: <56139CA0.9030202@redhat.com> On 10/05/2015 07:56 AM, Jan Cholasta wrote: > On 2.10.2015 13:09, Petr Viktorin wrote: >> On 10/01/2015 03:15 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 1.10.2015 13:01, Martin Basti wrote: >>>> >>>> >>>> On 09/30/2015 10:25 AM, Petr Viktorin wrote: >>>>> 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. >> [...] >>>>> >>>> LGTM >>>> >>>> I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and >>>> everything works >>> >>> Patches 713-719: ACK >>> >>> >>> Patch 720: >>> >>> You missed: >>> >>> ipa-client/ipa-install/ipa-client-install:32: from ConfigParser >>> import RawConfigParser >> >> >> Thanks, fixed. >> >>> Patches 721-722: ACK >>> >>> >>> Patch 723: >>> >>> Why the "NoneType = type(None)" in parameters.py? It is used only at: >>> >>> ipalib/parameters.py:388: type = NoneType # Ouch, this wont be very >>> useful in the real world! >> >> I believe this is less confusing than `type = type(None)`, but I can >> change that if needed. > > I don't care which one is used TBH, just that it is done consistently > accross the whole patch, and this seemed like the simpler thing to do. OK, changed. >>> Patch 724: >>> >>> The SSHPublicKey class was written with the assumption that "str" means >>> binary data, so unless I'm missing something, you only need to replace >>> "str" with "bytes". >> >> It specifically did take non-binary data as str: >> >> - if isinstance(key, str) and key[:3] != '\0\0\0': >> - key = key.decode(encoding) > > I don't follow, this is quite obviously binary data. It reads: "If key > is binary and does not start with 3 null bytes, decode it to text using > the specified encoding." Right, it's text (non-binary) data encoded in str (bytes), so it needs to be encoded. >> I've removed this for Python 3, where text data shouldn't be in bytes. >> >> Since this means the '\0\0\0' check is skipped in __init__ under Python >> 3, I've added it also to _parse_raw. > > When the SSH integration feature was first introduced, SSH public keys > were stored in the raw binary form in LDAP, i.e. not text data. We still > need to support that, so support for binary data and the 3 null check > must remain in SSHPublicKey. Changed, updated patches attached. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0713.4-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.4-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.4-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.4-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.4-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.4-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.4-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.4-Use-six.moves.configparser-instead-of-ConfigParser.patch Type: text/x-patch Size: 12096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0721.4-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.4-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.4-Remove-uses-of-the-types-module.patch Type: text/x-patch Size: 12964 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0724.4-ipapython.ssh-Port-to-Python-3.patch Type: text/x-patch Size: 4629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0725.4-Appease-pylint.patch Type: text/x-patch Size: 1277 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 6 10:05:46 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 6 Oct 2015 12:05:46 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <56139C1F.2070009@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> <560D31E8.6000707@redhat.com> <560E65DA.6030204@redhat.com> <56121119.10906@redhat.com> <56139C1F.2070009@redhat.com> Message-ID: <56139CFA.3090601@redhat.com> Please ignore that mail, I sent an unfinished draft by mistake. On 10/06/2015 12:02 PM, Petr Viktorin wrote: [...] > > OK, changed. > > >>>> Patch 724: >>>> >>>> The SSHPublicKey class was written with the assumption that "str" means >>>> binary data, so unless I'm missing something, you only need to replace >>>> "str" with "bytes". >>> >>> It specifically did take non-binary data as str: >>> >>> - if isinstance(key, str) and key[:3] != '\0\0\0': >>> - key = key.decode(encoding) >> >> I don't follow, this is quite obviously binary data. It reads: "If key >> is binary and does not start with 3 null bytes, decode it to text using >> the specified encoding." > > Sorry, I meant binary data. > -- Petr Viktorin From tbabej at redhat.com Tue Oct 6 11:17:48 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 6 Oct 2015 13:17:48 +0200 Subject: [Freeipa-devel] Remaining issues before adding Debian platform support In-Reply-To: <5612ACB0.9000602@redhat.com> References: <56129094.6090802@ubuntu.com> <5612ACB0.9000602@redhat.com> Message-ID: <5613ADDC.1020602@redhat.com> On 10/05/2015 07:00 PM, Martin Basti wrote: > > > On 10/05/2015 05:00 PM, Timo Aaltonen wrote: >> Hi >> >> I'm not sure if the goal is to be able to build IPA on Debian from >> git/tarballs, but here's a list of what would need to be fixed first to >> get there: >> >> - places where usernames have been hardcoded need something like >> ipaplatform/base/paths.py: >> apache -> www-data in: >> * ipaserver/install/httpinstance.py >> * ipaserver/install/ipa_server_certinstall.py >> * ipaserver/install/cainstance.py >> * ipaserver/install/certs.py > this can be extracted to ipaplatform/base/constants.py > Yes, constants.py can be leveraged for this purpose. We added it not that long ago, so you may have missed it. Task left here is to actually abstract those values. >> named -> bind in: >> * ipaserver/install/bindinstance.py > this is quite tricky, > for named_user the right location is to ipaplatform/base/constants.py > > for service, you can look in ipaplatform/redhat/services.py there is > already mapping named to named.pkcs11, we can do something similar in > debian platform specification, debian_system_units['named'] = > 'bind.service' Correct. Debian should define its own services.py where the name of the service can be overridden. > However if you want to replace named with bind completely, it requires > much more changes. > Martin, what are the effort necessary here? >> >> - config/service files that use hardcoded paths in them need to be moved >> to a template, and use paths.py macros: >> * install/conf/ipa.conf >> * init/systemd/ipa_memcached.service >> >> - same but with hardcoded usernames >> * init/ipa_memcached.conf > A discussion with other developer is needed how to resolve these files Converting to templates sounds resonable to me. We already have machinery to do this (ipautil.template_file), so this is a straightforward change. >> >> - ipaserver/install/httpinstance.py needs to run "a2enmod/a2dismod nss" >> because libapache2-mod-nss doesn't enable it on install (can't remember >> why, but there was a good reason..) > We did installer changes, Honza may know if this is possible. This may be a step which calls out to a platform task - by default, this would be an empty operation, on Debian, it would run whatever pre-setup steps needed. I wonder if we should generalize this, but probably not before a need arises. >> >> - various places using Fedora-specific libpaths (/usr/lib vs. >> /usr/lib64), whereas on Debian these are /usr/lib/, see >> https://wiki.debian.org/Multiarch/Tuples > I might be wrong, but I found different issues: >> * ipaserver/install/ldapupdate.py > this affects update files, and the same issue is for ldif files > We can replace path '/var/lib(64)' with substitute variable in those > files, and create a platform specific method to determine the correct > path, or just substitute with value from ipaplatform/base/paths >> * ipapython/certmonger.py >> * ipaserver/install/certs.py >> * ipaserver/install/ipa_backup.py >> * ipaserver/install/ipa_restore.py > Here for libpath we can use ipaplatform task.py or path.py if it is enough > The occurrences of /var/lib/ipa/backup should be in ipaplatform/paths Constants or Paths namespace should handle this case. >> >> - ntp daemon defaults use a different variable name (OPTIONS vs >> NTPD_OPTS), and quotes (" vs. ') >> * ipaserver/install/ntpinstance.py > IMO here also default pools should be excluded to constants as a list of > ntp servers per platform. > OPTIONS can be excluded to ipaplatform/constants.py > Probably the " or ' issue can be handled in the same way Constants can probably handle this, if not, a platform specific task can be used. >> >> - "Include conf.d/ipa-rewrite.conf" in httpinstance.py needs to use an >> absolute path with HTTPD_CONF_D, or HTTPD_CONF_D repurposed to only have >> 'conf.d' on Fedora and then conf-enabled on Debian > ok Probably a full path should be used here. >> >> - install/share/bind.named.conf.template needs to drop the default zone >> on Debian, since that's already configured via includes (-> bind fails >> to start), so a template file with an exception for Debian would fix it > The solution here can be augeas, but I'm not sure if we will able to > move to augeas soon enough. > This is the same issue as with ipa.conf We don't need to wait for augueas, just have a platform task (doing nothing on Fedora) that will alter the named.conf file during its generation. >> >> - Makefile needs to use --install-layout=deb for setup.py I guess we can have a platform env variable for the Makefile? >> >> - ipa-client/ipa-install/ipa-client-automount needs to check for >> variable named 'NEED_GSSD' on debian, so ipaplatform/base/vars.py? (same >> for NTPD_OPTS) > Leaving this for others. It can be abstracted into a platform specific task. >> >> >> There.. that should be all I think :) Oh, forgot that currently dnssec >> needs to be disabled by some heavy patching, because 9.10.x isn't >> packaged yet.. Thanks for enumerating the issues Timo, I filed a ticket summing this up: https://fedorahosted.org/freeipa/ticket/5343 From simo at redhat.com Tue Oct 6 11:35:03 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 6 Oct 2015 07:35:03 -0400 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <56137D8C.3090401@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> Message-ID: <5613B1E7.9060007@redhat.com> On 06/10/15 03:51, thierry bordaz wrote: > On 10/06/2015 07:19 AM, David Kupka wrote: >> On 05/10/15 16:12, Simo Sorce wrote: >>> On 05/10/15 09:00, Martin Babinsky wrote: >>>> These patches implement the plumbing required to properly support >>>> canonicalization of Kerberos principals ( >>>> https://fedorahosted.org/freeipa/ticket/3864). >>>> >>>> Setting multiple principal aliases on hosts/services is beyond the >>>> scope >>>> of this patchset and should be done after these patches are pushed. >>>> >>>> I will try to send some tests for the patches later this week. >>>> >>>> Please review the hell out of them. >>> >>> LGTM, I do not see any issue at quick visual inspection. >>> What about the performance regression with the indexes ? Is that bug >>> fixed in 389ds ? >>> >>> Simo. >>> >>> >> >> The issue is still there. Thierry investigated this in 389 DS and IIUC >> he is not sure if it's bug or completely missing feature. Therefore we >> still don't know how much time is needed there. >> > Hi, > that is correct. > I can reproduce the problem. Although the matching rule (in my test > caseIgnoreIA5Match) is found, it has no registered indexing function, so > the setting (nsMatchingRule) is ignored. > I do not know if the indexing function is missing or there is a bug so > that the matching rule "forget" to register it. > This feature is documented but I can not find any QA test around it, so > I do not know yet if it is a regression or if it was not enabled at all. > > I do not expect rapid progress on it. How urgent is it ? 7.3 ? > For the moment I can think to only two workarounds: > > * use filtered matching rule (preferred) > * change the attribute syntax/matching rule, in the schema (I would > discourage this one because changing the schema is risky) We can't change the syntax at this point. Well this patchset is blocked until the 389 ds bug is fixed (the performance regression is too big to just put it in and hope) so I guess we'll have to negotiate a time for the fix. Simo. -- Simo Sorce * Red Hat, Inc * New York From dkupka at redhat.com Tue Oct 6 12:04:56 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 6 Oct 2015 14:04:56 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <5613B1E7.9060007@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> Message-ID: <5613B8E8.3030006@redhat.com> On 06/10/15 13:35, Simo Sorce wrote: > On 06/10/15 03:51, thierry bordaz wrote: >> On 10/06/2015 07:19 AM, David Kupka wrote: >>> On 05/10/15 16:12, Simo Sorce wrote: >>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>> These patches implement the plumbing required to properly support >>>>> canonicalization of Kerberos principals ( >>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>> >>>>> Setting multiple principal aliases on hosts/services is beyond the >>>>> scope >>>>> of this patchset and should be done after these patches are pushed. >>>>> >>>>> I will try to send some tests for the patches later this week. >>>>> >>>>> Please review the hell out of them. >>>> >>>> LGTM, I do not see any issue at quick visual inspection. >>>> What about the performance regression with the indexes ? Is that bug >>>> fixed in 389ds ? >>>> >>>> Simo. >>>> >>>> >>> >>> The issue is still there. Thierry investigated this in 389 DS and IIUC >>> he is not sure if it's bug or completely missing feature. Therefore we >>> still don't know how much time is needed there. >>> >> Hi, >> that is correct. >> I can reproduce the problem. Although the matching rule (in my test >> caseIgnoreIA5Match) is found, it has no registered indexing function, so >> the setting (nsMatchingRule) is ignored. >> I do not know if the indexing function is missing or there is a bug so >> that the matching rule "forget" to register it. >> This feature is documented but I can not find any QA test around it, so >> I do not know yet if it is a regression or if it was not enabled at all. >> >> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >> For the moment I can think to only two workarounds: >> >> * use filtered matching rule (preferred) >> * change the attribute syntax/matching rule, in the schema (I would >> discourage this one because changing the schema is risky) > > We can't change the syntax at this point. > > Well this patchset is blocked until the 389 ds bug is fixed (the > performance regression is too big to just put it in and hope) so I guess > we'll have to negotiate a time for the fix. > > Simo. > I agree that we really shouldn't change schema. But I don't think the patches're necessary blocked by this issue. Canonicalization was never supported in FreeIPA and when it is not requested the performance is not effected at all. We could merge patches as soon as they're carefully reviewed and tested to avoid tedious rebasing and start using the new functionality when 389 DS gets fixed. -- David Kupka From simo at redhat.com Tue Oct 6 12:32:29 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 6 Oct 2015 08:32:29 -0400 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <5613B8E8.3030006@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> Message-ID: <5613BF5D.4040500@redhat.com> On 06/10/15 08:04, David Kupka wrote: > On 06/10/15 13:35, Simo Sorce wrote: >> On 06/10/15 03:51, thierry bordaz wrote: >>> On 10/06/2015 07:19 AM, David Kupka wrote: >>>> On 05/10/15 16:12, Simo Sorce wrote: >>>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>>> These patches implement the plumbing required to properly support >>>>>> canonicalization of Kerberos principals ( >>>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>>> >>>>>> Setting multiple principal aliases on hosts/services is beyond the >>>>>> scope >>>>>> of this patchset and should be done after these patches are pushed. >>>>>> >>>>>> I will try to send some tests for the patches later this week. >>>>>> >>>>>> Please review the hell out of them. >>>>> >>>>> LGTM, I do not see any issue at quick visual inspection. >>>>> What about the performance regression with the indexes ? Is that bug >>>>> fixed in 389ds ? >>>>> >>>>> Simo. >>>>> >>>>> >>>> >>>> The issue is still there. Thierry investigated this in 389 DS and IIUC >>>> he is not sure if it's bug or completely missing feature. Therefore we >>>> still don't know how much time is needed there. >>>> >>> Hi, >>> that is correct. >>> I can reproduce the problem. Although the matching rule (in my test >>> caseIgnoreIA5Match) is found, it has no registered indexing function, so >>> the setting (nsMatchingRule) is ignored. >>> I do not know if the indexing function is missing or there is a bug so >>> that the matching rule "forget" to register it. >>> This feature is documented but I can not find any QA test around it, so >>> I do not know yet if it is a regression or if it was not enabled at all. >>> >>> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >>> For the moment I can think to only two workarounds: >>> >>> * use filtered matching rule (preferred) >>> * change the attribute syntax/matching rule, in the schema (I would >>> discourage this one because changing the schema is risky) >> >> We can't change the syntax at this point. >> >> Well this patchset is blocked until the 389 ds bug is fixed (the >> performance regression is too big to just put it in and hope) so I guess >> we'll have to negotiate a time for the fix. >> >> Simo. >> > > I agree that we really shouldn't change schema. > > But I don't think the patches're necessary blocked by this issue. > Canonicalization was never supported in FreeIPA and when it is not > requested the performance is not effected at all. We could merge patches > as soon as they're carefully reviewed and tested to avoid tedious > rebasing and start using the new functionality when 389 DS gets fixed. The fact we didn't do canonicalization this way doesn't mean clients aren't asking for it. I think Windows clients ask for canonicalization by default, and in SSSD I see we turn on by default krb5_canonicalize in the IPA nd LDAP case (oddly enough not in the AD case ?) So SSSD's authentication requests would end up hitting this case all the time if I am reading the code correctly (CCed Jakub to confirm/dispel this). Simo. -- Simo Sorce * Red Hat, Inc * New York From mkubik at redhat.com Tue Oct 6 13:01:44 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 6 Oct 2015 15:01:44 +0200 Subject: [Freeipa-devel] [patch 0022] ipatests: remove the ipatests specific config from ipaplatform Message-ID: <5613C638.4050805@redhat.com> To keep the test specific configuration in the ipatest package. Patch attached. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ipa42-mkubik-0022-ipatests-remove-the-ipatests-specific-config-from-ip.patch Type: text/x-patch Size: 3426 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0022-ipatests-remove-the-ipatests-specific-config-from-ip.patch Type: text/x-patch Size: 3402 bytes Desc: not available URL: From mkubik at redhat.com Tue Oct 6 13:57:49 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 6 Oct 2015 15:57:49 +0200 Subject: [Freeipa-devel] [patch 0022] ipatests: remove the ipatests specific config from ipaplatform In-Reply-To: <5613C638.4050805@redhat.com> References: <5613C638.4050805@redhat.com> Message-ID: <5613D35D.7040900@redhat.com> On 10/06/2015 03:01 PM, Milan Kub?k wrote: > To keep the test specific configuration in the ipatest package. > > Patch attached. > > > Self NACK. This is not necessary in upstream. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Tue Oct 6 15:06:39 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 6 Oct 2015 17:06:39 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56127F62.8090705@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> <20151005121541.GA10207@redhat.com> <56127E42.4090306@redhat.com> <56127F62.8090705@redhat.com> Message-ID: <20151006150639.GA29158@redhat.com> On Mon, Oct 05, 2015 at 09:47:14AM -0400, Simo Sorce wrote: > On 05/10/15 09:42, Oleg Fayans wrote: > >1. At one point ipa-replica-install on a configured client has thrown > >the following error: > > > >Configuring ipa-custodia > > [1/5]: Generating ipa-custodia config file > > [2/5]: Generating ipa-custodia keys > > [3/5]: Importing RA Key > > [error] HTTPError: 502 Server Error: Proxy Error > >Your system may be partly configured. > >Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > >ipa.ipapython.install.cli.install_tool(Replica): ERROR 502 Server > >Error: Proxy Error > > > >(corresponding part of the error log of dirsrv attached) > > Seem like the peer server was unreachable ? > Was there a networking problem ? I've hit the same issue, during demo today, on a third replica I was creating. I was using four VMs on my laptop so no networking issue should have caused that. On the replica (being promoted), /var/log/ipareplica-install.log ends with On the master, in the error_log, I see [Tue Oct 06 13:22:33.196769 2015] [wsgi:error] [pid 10789] ipa: INFO: [jsonserver_session] admin at EXAMPLE.TEST: service_add(u'HTTP/ipa-4.example.test at EXAMPLE.TEST', version=u'2.112'): SUCCESS [Tue Oct 06 13:22:39.231882 2015] [wsgi:error] [pid 10788] ipa: INFO: [xmlserver] host/ipa-4.example.test at EXAMPLE.TEST: cert_request(u'MIIDWDCCAkACAQAwHTEbMBkGA1UEAxMSaXBhLTQuZXhhbXBsZS50ZXN0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn1pFdI1FuH1ad882x27i+oi3alabIt1hZjeGyT2zfEWaLajgAcDtT1RjWWFzrWtn9YJAe+3cm7R21MI8eFS1aCBlPaRgBLtefaakQy99k8p3IC8LwZxX9bvPPTuZVuF73DYXmaQAgpe/W7TLhCSFwZqht5D8aG0B7qm2E+mpclqKdlbk9egq8K8zFxs4mbLAuEd95wpSBJWnuaTPwRzrjpniCdl5OFof+ImTIMTVS6+5RUxB6KCi5WpGLbrAZWpHZ80a+weo0RK098r1GMT7LSTTZvOmJ22d15Ub0vQXTqVgAMVtt221vEZ1ZhRsLTbeh89JsDKOonNWk6VwOsYHnQIDAQABoIH1MCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIHLBgkqhkiG9w0BCQ4xgb0wgbowgYcGA1UdEQEBAAR9MHugNAYKKwYBBAGCNxQCA6AmDCRIVFRQL2lwYS00LmV4YW1wbGUudGVzdEBFWEFNUExFLlRFU1SgQwYGKwYBBQICoDkwN6AOGwxFWEFNUExFLlRFU1ShJTAjoAMCAQGhHDAaGwRIVFRQGxJpcGEtNC5leGFtcGxlLnRlc3QwDAYDVR0TAQH/BAIwADAgBgNVHQ4BAQAEFgQUZsVqOSFYBWZnFs42WMXGAag8w20wDQYJKoZIhvcNAQELBQADggEBAJDlTLM1Iyb4We61xIXttSReAbi0seO/ZevSiPN+orHdr+YLSDpbS6CSXm5X9Asvlo8iu0iRFrj/CUJAyPu+M7v+lfr3VwrKErycrczt5O4xgGPGfs0XODSlwQOG57SUyQyLXdyLPJtks/ah/LkfbCevew0cjhSnjEN7RpbV6Azh05vMyzF6J7NXlRLFzDDcz099Tug4Siuwsi/Y3AD0b+IR6I1ZOfLKzzzSEu+sC32JzaVythN3TbPqjeyGy/on3JsQTlznzn2LEVVoPioyF1oHyI7hG1OheTNjCoZXgfJUp1Ftct6YhsfhzglORcbmqDL00DdCU/789G5IworCCYo=', principal=u'HTTP/ipa-4.example.test at EXAMPLE.TEST', add=True, version=u'2.51'): SUCCESS [Tue Oct 06 13:22:47.652434 2015] [proxy_http:error] [pid 1394] (20014)Internal error: [client 192.168.100.229:49031] AH01102: error reading status line from remote server httpd-UDS:0 [Tue Oct 06 13:22:47.652476 2015] [proxy:error] [pid 1394] [client 192.168.100.229:49031] AH00898: Error reading from remote server returned by /ipa/keys/ra/ipaCert [Tue Oct 06 13:24:31.017069 2015] [wsgi:error] [pid 10789] ipa: INFO: [jsonserver_kerb] admin at EXAMPLE.TEST: ping(): SUCCESS -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Tue Oct 6 15:35:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 6 Oct 2015 17:35:27 +0200 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <5612B382.5030204@redhat.com> References: <56127650.9010600@ubuntu.com> <56128CD2.10304@ubuntu.com> <5612B382.5030204@redhat.com> Message-ID: <5613EA3F.9020706@redhat.com> On 10/05/2015 07:29 PM, Martin Basti wrote: > > > On 10/05/2015 04:44 PM, Timo Aaltonen wrote: >> On 05.10.2015 16:08, Timo Aaltonen wrote: >>> Hi >>> >>> Here are a few prep patches to get off the list before getting to >>> discuss how to add Debian platform support.. >> Here's one more. >> >> >> >> >> > ACK > > Pushed to master: 7c32ecaa0ebdfc879d6d2286974987b9fee7082e > > Pushed to ipa-4-2: 181c814e55611c64e8137a6edce6229c0199c4c5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Oct 6 15:35:34 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 6 Oct 2015 17:35:34 +0200 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56129B59.7050207@redhat.com> References: <56127650.9010600@ubuntu.com> <56127B96.30000@redhat.com> <56127D04.4080005@redhat.com> <56127E02.2090907@ubuntu.com> <56129B59.7050207@redhat.com> Message-ID: <5613EA46.4090901@redhat.com> On 10/05/2015 05:46 PM, Martin Basti wrote: > > > On 10/05/2015 03:41 PM, Timo Aaltonen wrote: >> On 05.10.2015 16:37, Martin Basti wrote: >>> >>> On 10/05/2015 03:31 PM, Simo Sorce wrote: >>>> On 05/10/15 09:08, Timo Aaltonen wrote: >>>>> Hi >>>>> >>>>> Here are a few prep patches to get off the list before getting to >>>>> discuss how to add Debian platform support.. >>>>> >>>> LGTM. >>>> >>>> Simo. >>>> >>>> >>> IMO this should be written in this way (I didn't test) >>> >>> ipautil.run([paths.GENERATE_RNDC_KEY]) >> Yes you're right, here's an updated version. >> >> >> > ACK > > Pushed to master: 7059117ec32bfad8ec802d472b0f7d2b6cb12d2a > Pushed to ipa-4-2: b8a2104fb55026275067bb3d8732dbf5612bb2e8 The elders of FreeIPA decided that this should go to ipa-4-2 too https://fedorahosted.org/freeipa/ticket/5343 From jhrozek at redhat.com Tue Oct 6 15:52:37 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 6 Oct 2015 17:52:37 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <5613BF5D.4040500@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> <5613BF5D.4040500@redhat.com> Message-ID: <20151006155237.GJ3048@hendrix> On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: > On 06/10/15 08:04, David Kupka wrote: > >On 06/10/15 13:35, Simo Sorce wrote: > >>On 06/10/15 03:51, thierry bordaz wrote: > >>>On 10/06/2015 07:19 AM, David Kupka wrote: > >>>>On 05/10/15 16:12, Simo Sorce wrote: > >>>>>On 05/10/15 09:00, Martin Babinsky wrote: > >>>>>>These patches implement the plumbing required to properly support > >>>>>>canonicalization of Kerberos principals ( > >>>>>>https://fedorahosted.org/freeipa/ticket/3864). > >>>>>> > >>>>>>Setting multiple principal aliases on hosts/services is beyond the > >>>>>>scope > >>>>>>of this patchset and should be done after these patches are pushed. > >>>>>> > >>>>>>I will try to send some tests for the patches later this week. > >>>>>> > >>>>>>Please review the hell out of them. > >>>>> > >>>>>LGTM, I do not see any issue at quick visual inspection. > >>>>>What about the performance regression with the indexes ? Is that bug > >>>>>fixed in 389ds ? > >>>>> > >>>>>Simo. > >>>>> > >>>>> > >>>> > >>>>The issue is still there. Thierry investigated this in 389 DS and IIUC > >>>>he is not sure if it's bug or completely missing feature. Therefore we > >>>>still don't know how much time is needed there. > >>>> > >>>Hi, > >>>that is correct. > >>>I can reproduce the problem. Although the matching rule (in my test > >>>caseIgnoreIA5Match) is found, it has no registered indexing function, so > >>>the setting (nsMatchingRule) is ignored. > >>>I do not know if the indexing function is missing or there is a bug so > >>>that the matching rule "forget" to register it. > >>>This feature is documented but I can not find any QA test around it, so > >>>I do not know yet if it is a regression or if it was not enabled at all. > >>> > >>>I do not expect rapid progress on it. How urgent is it ? 7.3 ? > >>>For the moment I can think to only two workarounds: > >>> > >>> * use filtered matching rule (preferred) > >>> * change the attribute syntax/matching rule, in the schema (I would > >>> discourage this one because changing the schema is risky) > >> > >>We can't change the syntax at this point. > >> > >>Well this patchset is blocked until the 389 ds bug is fixed (the > >>performance regression is too big to just put it in and hope) so I guess > >>we'll have to negotiate a time for the fix. > >> > >>Simo. > >> > > > >I agree that we really shouldn't change schema. > > > >But I don't think the patches're necessary blocked by this issue. > >Canonicalization was never supported in FreeIPA and when it is not > >requested the performance is not effected at all. We could merge patches > >as soon as they're carefully reviewed and tested to avoid tedious > >rebasing and start using the new functionality when 389 DS gets fixed. > > The fact we didn't do canonicalization this way doesn't mean clients aren't > asking for it. > > I think Windows clients ask for canonicalization by default, and in SSSD I > see we turn on by default krb5_canonicalize in the IPA nd LDAP case (oddly > enough not in the AD case ?) > > So SSSD's authentication requests would end up hitting this case all the > time if I am reading the code correctly (CCed Jakub to confirm/dispel this). We ask for canonicalization always in IPA and LDAP, but also whenever enterprise principals are used, which is true for AD provider. From mbasti at redhat.com Tue Oct 6 16:09:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 6 Oct 2015 18:09:45 +0200 Subject: [Freeipa-devel] [PATCH 0054] Update FreeIPA package description In-Reply-To: <56122CE7.5060200@redhat.com> References: <56122CE7.5060200@redhat.com> Message-ID: <5613F249.9070807@redhat.com> On 10/05/2015 09:55 AM, Petr Spacek wrote: > On 2.10.2015 14:32, Gabe Alford wrote: >> Bump for review. > Sorry for delay. I like the new text, ACK. > > Petr^2 Spacek > >> On Mon, Sep 21, 2015 at 9:37 AM, Gabe Alford wrote: >> >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/5284 >>> >>> Thanks, >>> >>> Gabe Patch needs rebase, I did it before push. Pushed to master: a6d9c40f14ef608946a88c86d8fe7c9793225e44 Pushed to ipa-4-2: 0667794ef65caab69bc6389f49b76ab7f37fae37 From simo at redhat.com Tue Oct 6 16:26:14 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 6 Oct 2015 12:26:14 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <20151006150639.GA29158@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> <20151005121541.GA10207@redhat.com> <56127E42.4090306@redhat.com> <56127F62.8090705@redhat.com> <20151006150639.GA29158@redhat.com> Message-ID: <5613F626.8060706@redhat.com> On 06/10/15 11:06, Jan Pazdziora wrote: > On Mon, Oct 05, 2015 at 09:47:14AM -0400, Simo Sorce wrote: >> On 05/10/15 09:42, Oleg Fayans wrote: >>> 1. At one point ipa-replica-install on a configured client has thrown >>> the following error: >>> >>> Configuring ipa-custodia >>> [1/5]: Generating ipa-custodia config file >>> [2/5]: Generating ipa-custodia keys >>> [3/5]: Importing RA Key >>> [error] HTTPError: 502 Server Error: Proxy Error >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR 502 Server >>> Error: Proxy Error >>> >>> (corresponding part of the error log of dirsrv attached) >> >> Seem like the peer server was unreachable ? >> Was there a networking problem ? > > I've hit the same issue, during demo today, on a third replica I was > creating. I was using four VMs on my laptop so no networking issue > should have caused that. > > On the replica (being promoted), /var/log/ipareplica-install.log ends with > > On the master, in the error_log, I see > > [Tue Oct 06 13:22:33.196769 2015] [wsgi:error] [pid 10789] ipa: INFO: [jsonserver_session] admin at EXAMPLE.TEST: service_add(u'HTTP/ipa-4.example.test at EXAMPLE.TEST', version=u'2.112'): SUCCESS > [Tue Oct 06 13:22:39.231882 2015] [wsgi:error] [pid 10788] ipa: INFO: [xmlserver] host/ipa-4.example.test at EXAMPLE.TEST: cert_request(u'MIIDWDCCAkACAQAwHTEbMBkGA1UEAxMSaXBhLTQuZXhhbXBsZS50ZXN0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn1pFdI1FuH1ad882x27i+oi3alabIt1hZjeGyT2zfEWaLajgAcDtT1RjWWFzrWtn9YJAe+3cm7R21MI8eFS1aCBlPaRgBLtefaakQy99k8p3IC8LwZxX9bvPPTuZVuF73DYXmaQAgpe/W7TLhCSFwZqht5D8aG0B7qm2E+mpclqKdlbk9egq8K8zFxs4mbLAuEd95wpSBJWnuaTPwRzrjpniCdl5OFof+ImTIMTVS6+5RUxB6KCi5WpGLbrAZWpHZ80a+weo0RK098r1GMT7LSTTZvOmJ22d15Ub0vQXTqVgAMVtt221vEZ1ZhRsLTbeh89JsDKOonNWk6VwOsYHnQIDAQABoIH1MCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIHLBgkqhkiG9w0BCQ4xgb0wgbowgYcGA1UdEQEBAAR9MHugNAYKKwYBBAGCNxQCA6AmDCRIVFRQL2lwYS00LmV4YW1wbGUudGVzdEBFWEFNUExFLlRFU1SgQwYGKwYBBQICoDkwN6AOGwxFWEFNUExFLlRFU1ShJTAjoAMCAQGhHDAaGwRIVFRQGxJpcGEtNC5leGFtcGxlLnRlc3QwDAYDVR0TAQH/BAIwADAgBgNVHQ4BAQAEFgQUZsVqOSFYBWZnFs42WMXGAag8w20wDQYJKoZIhvcNAQELBQADggEBAJDlTLM1Iyb4We61xIXttSReAbi0seO/ZevSiPN+orHdr+YL! SDpbS6CSXm 5X9Asvlo8iu0iRFrj/CUJAyPu+M7v+lfr3VwrKErycrczt5O4xgGPGfs0XODSlwQOG57SUyQyLXdyLPJtks/ah/LkfbCevew0cjhSnjEN7RpbV6Azh05vMyzF6J7NXlRLFzDDcz099Tug4Siuwsi/Y3AD0b+IR6I1ZOfLKzzzSEu+sC32JzaVythN3TbPqjeyGy/on3JsQTlznzn2LEVVoPioyF1oHyI7hG1OheTNjCoZXgfJUp1Ftct6YhsfhzglORcbmqDL00DdCU/789G5IworCCYo=', principal=u'HTTP/ipa-4.example.test at EXAMPLE.TEST', add=True, version=u'2.51'): SUCCESS > [Tue Oct 06 13:22:47.652434 2015] [proxy_http:error] [pid 1394] (20014)Internal error: [client 192.168.100.229:49031] AH01102: error reading status line from remote server httpd-UDS:0 > [Tue Oct 06 13:22:47.652476 2015] [proxy:error] [pid 1394] [client 192.168.100.229:49031] AH00898: Error reading from remote server returned by /ipa/keys/ra/ipaCert > [Tue Oct 06 13:24:31.017069 2015] [wsgi:error] [pid 10789] ipa: INFO: [jsonserver_kerb] admin at EXAMPLE.TEST: ping(): SUCCESS Was custodia running ? Can you check its log file ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tjaalton at ubuntu.com Tue Oct 6 18:58:04 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 6 Oct 2015 21:58:04 +0300 Subject: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions Message-ID: <561419BC.5080707@ubuntu.com> Hi So here's the first batch of quick patches for ticket #5343. They're only compile-tested so far (so no stupid mistakes I hope), as I don't have 4.2+ working yet. Wonder how the quotes in the last patch work, but at least make-lint didn't laugh too hard.. -- t -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0006-ipaplatform-Add-HTTPD_USER-to-constants-and-use-it.patch Type: text/x-patch Size: 6107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0007-ipaplatform-Add-NAMED_USER-and-user-it.patch Type: text/x-patch Size: 1911 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0008-httpinstance-Use-full-path-via-HTTPD_CONF_D-for-Incl.patch Type: text/x-patch Size: 1238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0009-ipaplatform-Add-SECURE_NFS_VAR-to-constants.patch Type: text/x-patch Size: 1781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0010-ipaplatform-Add-NTP_OPTS_VAR-and-NTP_OPTS_QUOTE-to-c.patch Type: text/x-patch Size: 2952 bytes Desc: not available URL: From jpazdziora at redhat.com Tue Oct 6 20:16:16 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 6 Oct 2015 22:16:16 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5613F626.8060706@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> <20151005121541.GA10207@redhat.com> <56127E42.4090306@redhat.com> <56127F62.8090705@redhat.com> <20151006150639.GA29158@redhat.com> <5613F626.8060706@redhat.com> Message-ID: <20151006201616.GA13558@redhat.com> On Tue, Oct 06, 2015 at 12:26:14PM -0400, Simo Sorce wrote: > > Was custodia running ? > Can you check its log file ? /etc/ipa/custodia/custodia.conf suggests auditlog = /var/log/ipa-custodia.audit.log but that file does not exist at all. So either it was not running, or it failed to create that log file. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From slaznick at redhat.com Wed Oct 7 07:55:13 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 7 Oct 2015 09:55:13 +0200 Subject: [Freeipa-devel] [PATCHES 0002-0008] [RFE] Implement iCal based time managment in HBAC Message-ID: <5614CFE1.7030705@redhat.com> Hi, The moment's here, I'd like to share my code with you now. Let me comment on some additions from my last post here in August. The methods for testing HBAC rules in hbactest module were modified so that a time zone can now also be picked in case there are some rules with the "host" time zone in the rule time policy. I also added few tests that test setting accessTime values. The most important update of the previous month is the addition of negative values to the time rules language. Most of the keywords (all, except for timeofday and year) now accept negative values and negative value ranges. This should be useful for cases when the user should only be allowed access e.g. in the last 7 days of a month, last few weeks of a year etc. Also, it is a similar behavior to what iCalendar has. The addition of negative values also made me re-think the ways the week of a year should be calculated. There are no 0th weeks of year anymore, a week of year can hold values ranging from 1 to 53 where the 1st week of a year may appear even on a date of the previous year (if 1st January is Tue-Thu) or the 52nd or 53rd week may appear on a date of the following year (when 31st December is Thu-Sat). If my explanation seems rather rough, please see https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html. The latter caused some changes to be made in my SSSD code. These changes took the most of my time last month alongside with generally polishing the code and adding comments where I thought necessary. I will push my SSSD code to the sssd-devel mailing list as a follow-up to this mail. Another thing - I updated the design page on the FreeIPA wiki, so please check it out, too (http://www.freeipa.org/page/V4/Time-Based_Account_Policies). Last thing I would like to mention - there is now a copr repo with both sssd and freeipa with time-based policies (https://copr.fedoraproject.org/coprs/stlaz/freeipa-sssd-timerules/). This was Martin K.'s idea and I think it's pretty dandy :) As the patches I am posting only contain CLI for HBAC time policies, you might be pleased that the repo includes at least basic WebUI for this purpose (although the WebUI is for some reason not updating the page on rule addition properly, I will be hopefully looking into that shortly). You will still need mkosek/freeipa-master copr repo for some dependencies. Should it not work properly for you, please, send me an email, it's my first time taking care of a copr repo. That's it from me for now, thank you for your patience with my emails, Standa -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0002-Added-time-based-policies-types-to-LDAP-schema.patch Type: text/x-patch Size: 3028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0003-Added-methods-for-setting-time-based-policies.patch Type: text/x-patch Size: 33972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0004-Added-the-repeat-keyword.patch Type: text/x-patch Size: 5556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0005-HBAC-test-module-support-for-time-based-policies.patch Type: text/x-patch Size: 4118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0006-Removed-old-AccessTime-parameter-tests.patch Type: text/x-patch Size: 2389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0007-Tests-for-HBAC-time-rules-language.patch Type: text/x-patch Size: 10201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0008-Added-negative-values-to-the-HBAC-time-policies.patch Type: text/x-patch Size: 9477 bytes Desc: not available URL: From jcholast at redhat.com Wed Oct 7 08:27:52 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 7 Oct 2015 10:27:52 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <56139CA0.9030202@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> <560D31E8.6000707@redhat.com> <560E65DA.6030204@redhat.com> <56121119.10906@redhat.com> <56139CA0.9030202@redhat.com> Message-ID: <5614D788.4050205@redhat.com> On 6.10.2015 12:04, Petr Viktorin wrote: > On 10/05/2015 07:56 AM, Jan Cholasta wrote: >> On 2.10.2015 13:09, Petr Viktorin wrote: >>> On 10/01/2015 03:15 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 1.10.2015 13:01, Martin Basti wrote: >>>>> >>>>> >>>>> On 09/30/2015 10:25 AM, Petr Viktorin wrote: >>>>>> 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. >>> [...] >>>>>> >>>>> LGTM >>>>> >>>>> I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and >>>>> everything works >>>> >>>> Patches 713-719: ACK >>>> >>>> >>>> Patch 720: >>>> >>>> You missed: >>>> >>>> ipa-client/ipa-install/ipa-client-install:32: from ConfigParser >>>> import RawConfigParser >>> >>> >>> Thanks, fixed. >>> >>>> Patches 721-722: ACK >>>> >>>> >>>> Patch 723: >>>> >>>> Why the "NoneType = type(None)" in parameters.py? It is used only at: >>>> >>>> ipalib/parameters.py:388: type = NoneType # Ouch, this wont be very >>>> useful in the real world! >>> >>> I believe this is less confusing than `type = type(None)`, but I can >>> change that if needed. >> >> I don't care which one is used TBH, just that it is done consistently >> accross the whole patch, and this seemed like the simpler thing to do. > > OK, changed. > >>>> Patch 724: >>>> >>>> The SSHPublicKey class was written with the assumption that "str" means >>>> binary data, so unless I'm missing something, you only need to replace >>>> "str" with "bytes". >>> >>> It specifically did take non-binary data as str: >>> >>> - if isinstance(key, str) and key[:3] != '\0\0\0': >>> - key = key.decode(encoding) >> >> I don't follow, this is quite obviously binary data. It reads: "If key >> is binary and does not start with 3 null bytes, decode it to text using >> the specified encoding." > > Right, it's text (non-binary) data encoded in str (bytes), so it needs > to be encoded. > >>> I've removed this for Python 3, where text data shouldn't be in bytes. >>> >>> Since this means the '\0\0\0' check is skipped in __init__ under Python >>> 3, I've added it also to _parse_raw. >> >> When the SSH integration feature was first introduced, SSH public keys >> were stored in the raw binary form in LDAP, i.e. not text data. We still >> need to support that, so support for binary data and the 3 null check >> must remain in SSHPublicKey. > > Changed, updated patches attached. Thanks, ACK. I took the liberty of amending patch 718 to silence this pylint false positive I was getting on F22: ipalib/plugins/otptoken.py:496: [E1101(no-member), HTTPSHandler.https_open] Instance of 'HTTPSHandler' has no 'do_open' member) Pushed to master: f82d3da1e8e5dc1d0716201af5abb724a8e78fde BTW, in patch 724, binascii.Error is handled in addition to TypeError with base64.b64decode(). There are multiple places where base64.b64decode() is used in IPA where only TypeError is handled. Are you planning on fixing this as well? Honza -- Jan Cholasta From tbabej at redhat.com Wed Oct 7 10:51:10 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 7 Oct 2015 12:51:10 +0200 Subject: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions In-Reply-To: <561419BC.5080707@ubuntu.com> References: <561419BC.5080707@ubuntu.com> Message-ID: <20151007105110.GA27006@redhat.com> On Tue, Oct 06, 2015 at 09:58:04PM +0300, Timo Aaltonen wrote: > > Hi > > So here's the first batch of quick patches for ticket #5343. They're > only compile-tested so far (so no stupid mistakes I hope), as I don't > have 4.2+ working yet. Wonder how the quotes in the last patch work, but > at least make-lint didn't laugh too hard.. > > -- > t Hi, overall this looks good, couple of comments inline. > From 15b30829c53a7e02ddc997c17559d755b751c9d6 Mon Sep 17 00:00:00 2001 > From: Timo Aaltonen > Date: Tue, 6 Oct 2015 16:02:37 +0300 > Subject: [PATCH 1/2] ipaplatform: Add HTTPD_USER to constants > > https://fedorahosted.org/freeipa/ticket/5343 > --- > ipaplatform/base/constants.py | 1 + > ipaserver/install/cainstance.py | 3 ++- > ipaserver/install/certs.py | 3 ++- > ipaserver/install/httpinstance.py | 11 ++++++----- > ipaserver/install/ipa_server_certinstall.py | 3 ++- > 5 files changed, 13 insertions(+), 8 deletions(-) > > diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py > index cef829e2d3886db00ae6d0299ddcf325d1add80e..3f78822f99d9fbe815901301f4e6855105e73eea 100644 > --- a/ipaplatform/base/constants.py > +++ b/ipaplatform/base/constants.py > @@ -8,4 +8,5 @@ This base platform module exports platform dependant constants. > > > class BaseConstantsNamespace(object): > + HTTPD_USER = "apache" > IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" > diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py > index c4788816ab702e9409c9bc44a91fcbd95dce018d..6deaef57c025cb55da9fcaf7620a54565f6701c7 100644 > --- a/ipaserver/install/cainstance.py > +++ b/ipaserver/install/cainstance.py > @@ -48,6 +48,7 @@ from ipalib import pkcs10, x509 > from ipalib import errors > > from ipaplatform import services > +from ipaplatform.constants import constants > from ipaplatform.paths import paths > from ipaplatform.tasks import tasks > > @@ -1103,7 +1104,7 @@ class CAInstance(DogtagInstance): > os.chmod(self.ra_agent_db + "/key3.db", 0o640) > os.chmod(self.ra_agent_db + "/secmod.db", 0o640) > > - pent = pwd.getpwnam("apache") > + pent = pwd.getpwnam(constants.HTTPD_USER) > os.chown(self.ra_agent_db + "/cert8.db", 0, pent.pw_gid ) > os.chown(self.ra_agent_db + "/key3.db", 0, pent.pw_gid ) > os.chown(self.ra_agent_db + "/secmod.db", 0, pent.pw_gid ) > diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py > index 3e07ee398fa47beb02f54940a0246d58ae2267ae..d85344ede993840845af63c377525699425a9382 100644 > --- a/ipaserver/install/certs.py > +++ b/ipaserver/install/certs.py > @@ -42,6 +42,7 @@ from ipalib import pkcs10, x509, api > from ipalib.errors import CertificateOperationError > from ipalib.text import _ > from ipaplatform import services > +from ipaplatform.constants import constants > from ipaplatform.paths import paths > > # Apache needs access to this database so we need to create it > @@ -519,7 +520,7 @@ class CertDB(object): > f.close() > pwdfile.close() > # TODO: replace explicit uid by a platform-specific one > - self.set_perms(self.pwd_conf, uid="apache") > + self.set_perms(self.pwd_conf, uid=constants.HTTPD_USER) > > def find_root_cert(self, nickname): > """ > diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py > index ee4853a3f9a8a42bd050fd8b208fc2419c323512..a7fdfb1a21a8c62f57503cfaca68b30e4f26244f 100644 > --- a/ipaserver/install/httpinstance.py > +++ b/ipaserver/install/httpinstance.py > @@ -41,6 +41,7 @@ import ipapython.errors > from ipaserver.install import sysupgrade > from ipalib import api > from ipalib import errors > +from ipaplatform.constants import constants > from ipaplatform.tasks import tasks > from ipaplatform.paths import paths > from ipaplatform import services > @@ -52,7 +53,7 @@ SELINUX_BOOLEAN_SETTINGS = dict( > ) > > KDCPROXY_USER = 'kdcproxy' > - > +HTTPD_USER = constants.HTTPD_USER > > def httpd_443_configured(): > """ > @@ -188,14 +189,14 @@ class HTTPInstance(service.Service): > self.move_service(self.principal) > self.add_cert_to_service() > > - pent = pwd.getpwnam("apache") > + pent = pwd.getpwnam(HTTPD_USER) > os.chown(paths.IPA_KEYTAB, pent.pw_uid, pent.pw_gid) > > def remove_httpd_ccache(self): > # Clean up existing ccache > # Make sure that empty env is passed to avoid passing KRB5CCNAME from > # current env > - ipautil.run(['kdestroy', '-A'], runas='apache', raiseonerr=False, env={}) > + ipautil.run(['kdestroy', '-A'], runas=HTTPD_USER, raiseonerr=False, env={}) > > def __configure_http(self): > target_fname = paths.HTTPD_IPA_CONF > @@ -324,7 +325,7 @@ class HTTPInstance(service.Service): > os.chmod(certs.NSS_DIR + "/secmod.db", 0o660) > os.chmod(certs.NSS_DIR + "/pwdfile.txt", 0o660) > > - pent = pwd.getpwnam("apache") > + pent = pwd.getpwnam(HTTPD_USER) > os.chown(certs.NSS_DIR + "/cert8.db", 0, pent.pw_gid ) > os.chown(certs.NSS_DIR + "/key3.db", 0, pent.pw_gid ) > os.chown(certs.NSS_DIR + "/secmod.db", 0, pent.pw_gid ) > @@ -493,7 +494,7 @@ class HTTPInstance(service.Service): > pass > > # Remove the ccache file for the HTTPD service > - ipautil.run([paths.KDESTROY, '-c', paths.KRB5CC_HTTPD], runas='apache', > + ipautil.run([paths.KDESTROY, '-c', paths.KRB5CC_HTTPD], runas=HTTPD_USER, > raiseonerr=False) > > # Remove the configuration files we create > diff --git a/ipaserver/install/ipa_server_certinstall.py b/ipaserver/install/ipa_server_certinstall.py > index e90b2abd6644c71bc3b567af5ac74c8368df1b15..ac0b0274e4e36db4ea6fb695afb527e2b83a8c77 100644 > --- a/ipaserver/install/ipa_server_certinstall.py > +++ b/ipaserver/install/ipa_server_certinstall.py > @@ -24,6 +24,7 @@ import os.path > import pwd > import optparse > > +from ipaplatform.constants import constants > from ipaplatform.paths import paths > from ipapython import admintool > from ipapython.dn import DN > @@ -151,7 +152,7 @@ class ServerCertInstall(admintool.AdminTool): > os.chmod(os.path.join(dirname, 'key3.db'), 0o640) > os.chmod(os.path.join(dirname, 'secmod.db'), 0o640) > > - pent = pwd.getpwnam("apache") > + pent = pwd.getpwnam(constants.HTTPD_USER) > os.chown(os.path.join(dirname, 'cert8.db'), 0, pent.pw_gid) > os.chown(os.path.join(dirname, 'key3.db'), 0, pent.pw_gid) > os.chown(os.path.join(dirname, 'secmod.db'), 0, pent.pw_gid) > -- > 2.5.0 > > From 77be9a8b67a49ca263e82dde5bf87d432ca64922 Mon Sep 17 00:00:00 2001 > From: Timo Aaltonen > Date: Tue, 6 Oct 2015 16:27:21 +0300 > Subject: [PATCH 2/2] ipaplatform: Add NAMED_USER to constants > > https://fedorahosted.org/freeipa/ticket/5343 > --- > ipaplatform/base/constants.py | 1 + > ipaserver/install/bindinstance.py | 3 ++- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py > index 3f78822f99d9fbe815901301f4e6855105e73eea..9a1237106d47b93c6cbe50b139b92cbcc0a745ff 100644 > --- a/ipaplatform/base/constants.py > +++ b/ipaplatform/base/constants.py > @@ -10,3 +10,4 @@ This base platform module exports platform dependant constants. > class BaseConstantsNamespace(object): > HTTPD_USER = "apache" > IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" > + NAMED_USER = "named" > diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py > index e8fdb3b83317f996959e4123b481f353c2f056c9..2cbf30202f30bd80c01a6399ecff3a6406316825 100644 > --- a/ipaserver/install/bindinstance.py > +++ b/ipaserver/install/bindinstance.py > @@ -39,6 +39,7 @@ from ipapython.dn import DN > import ipalib > from ipalib import api, errors > from ipaplatform import services > +from ipaplatform.constants import constants > from ipaplatform.paths import paths > from ipaplatform.tasks import tasks > from ipalib.util import (validate_zonemgr_str, normalize_zonemgr, > @@ -561,7 +562,7 @@ class BindInstance(service.Service): > suffix = ipautil.dn_attribute_property('_suffix') > > def setup(self, fqdn, ip_addresses, realm_name, domain_name, forwarders, ntp, > - reverse_zones, named_user="named", zonemgr=None, > + reverse_zones, named_user=constants.NAMED_USER, zonemgr=None, > ca_configured=None, no_dnssec_validation=False): > self.named_user = named_user > self.fqdn = fqdn > -- > 2.5.0 > > From 52945c313e975aa3371bb3275b4ff42707e13e89 Mon Sep 17 00:00:00 2001 > From: Timo Aaltonen > Date: Tue, 6 Oct 2015 16:43:09 +0300 > Subject: [PATCH] httpinstance: Use full path via HTTPD_CONF_D for Include. > > https://fedorahosted.org/freeipa/ticket/5343 > --- > ipaserver/install/httpinstance.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py > index a7fdfb1a21a8c62f57503cfaca68b30e4f26244f..16139ef34d846ad8dd4780745f647b9ad5aad772 100644 > --- a/ipaserver/install/httpinstance.py > +++ b/ipaserver/install/httpinstance.py > @@ -249,7 +249,7 @@ class HTTPInstance(service.Service): > > def __add_include(self): > """This should run after __set_mod_nss_port so is already backed up""" > - if installutils.update_file(paths.HTTPD_NSS_CONF, '', 'Include conf.d/ipa-rewrite.conf\n') != 0: > + if installutils.update_file(paths.HTTPD_NSS_CONF, '', 'Include ' + paths.HTTPD_CONF_D + '/ipa-rewrite.conf\n') != 0: Please use os.path.join here, so that we avoid reliance on the particular format of paths.HTTPD_CONF_D (without trailing slash in this case) > print("Adding Include conf.d/ipa-rewrite to %s failed." % paths.HTTPD_NSS_CONF) > > def configure_certmonger_renewal_guard(self): > -- > 2.5.0 > > From 1ca29f9e6188487862d77ea1458e6ff84b371103 Mon Sep 17 00:00:00 2001 > From: Timo Aaltonen > Date: Tue, 6 Oct 2015 16:35:24 +0300 > Subject: [PATCH] ipaplatform: Add SECURE_NFS_VAR to constants > > https://fedorahosted.org/freeipa/ticket/5343 > --- > ipa-client/ipa-install/ipa-client-automount | 3 ++- > ipaplatform/base/constants.py | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount > index 5e4ab1396aeb6311be1ace8f5c74ce9760fee408..ab7fe3b62b40376d03d87fdef103eedc7aa50cdf 100755 > --- a/ipa-client/ipa-install/ipa-client-automount > +++ b/ipa-client/ipa-install/ipa-client-automount > @@ -40,6 +40,7 @@ from ipaclient import ipadiscovery > from ipaclient import ipachangeconf > from ipapython.ipa_log_manager import * > from ipapython.dn import DN > +from ipaplatform.constants import constants > from ipaplatform.tasks import tasks > from ipaplatform import services > from ipaplatform.paths import paths > @@ -309,7 +310,7 @@ def configure_nfs(fstore, statestore): > Configure secure NFS > """ > replacevars = { > - 'SECURE_NFS': 'yes', > + constants.SECURE_NFS_VAR: 'yes', > } > ipautil.backup_config_and_replace_variables(fstore, > paths.SYSCONFIG_NFS, replacevars=replacevars) > diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py > index 9a1237106d47b93c6cbe50b139b92cbcc0a745ff..191d3de2c9bf8c6d1a9e39366a5bf9142b8c139f 100644 > --- a/ipaplatform/base/constants.py > +++ b/ipaplatform/base/constants.py > @@ -11,3 +11,4 @@ class BaseConstantsNamespace(object): > HTTPD_USER = "apache" > IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" > NAMED_USER = "named" > + SECURE_NFS_VAR = "SECURE_NFS" Can we add a helpful comment what a constant describes here? I think we should start this convention for any non-obvious platform constants, so that any new platform maintainer has an easy job figuring out what platform constant actually holds. > -- > 2.5.0 > > From 83a6ddec954a07f78be330bdaa71b53d01d0e1c0 Mon Sep 17 00:00:00 2001 > From: Timo Aaltonen > Date: Tue, 6 Oct 2015 18:46:00 +0300 > Subject: [PATCH] ipaplatform: Add NTP_OPTS_VAR and NTP_OPTS_QUOTE to constants > > https://fedorahosted.org/freeipa/ticket/5343 > --- > ipaplatform/base/constants.py | 2 ++ > ipaserver/install/ntpinstance.py | 14 +++++++++----- > 2 files changed, 11 insertions(+), 5 deletions(-) > > diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py > index 191d3de2c9bf8c6d1a9e39366a5bf9142b8c139f..aafc7b412cc0fc913a332417ae12b6caad619330 100644 > --- a/ipaplatform/base/constants.py > +++ b/ipaplatform/base/constants.py > @@ -11,4 +11,6 @@ class BaseConstantsNamespace(object): > HTTPD_USER = "apache" > IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" > NAMED_USER = "named" > + NTP_OPTS_VAR = "OPTIONS" > + NTP_OPTS_QUOTE = "\"" Probably a comment is needed here as well. > SECURE_NFS_VAR = "SECURE_NFS" > diff --git a/ipaserver/install/ntpinstance.py b/ipaserver/install/ntpinstance.py > index 1fef6fd3e8931615b201ce25beaac8bb6c945a01..567dec6e97588792c5331a5dc425cc8220930f82 100644 > --- a/ipaserver/install/ntpinstance.py > +++ b/ipaserver/install/ntpinstance.py > @@ -21,9 +21,13 @@ > from ipaserver.install import service > from ipapython import sysrestore > from ipapython import ipautil > +from ipaplatform.constants import constants > from ipaplatform.paths import paths > from ipapython.ipa_log_manager import * > > +NTPD_OPTS_VAR = constants.NTPD_OPTS_VAR > +NTPD_OPTS_QUOTE = constants.NTPD_OPTS_QUOTE > + > class NTPInstance(service.Service): > def __init__(self, fstore=None): > service.Service.__init__(self, "ntpd", service_desc="NTP daemon") > @@ -106,9 +110,9 @@ class NTPInstance(service.Service): > fd.close() > for line in lines: > sline = line.strip() > - if not sline.startswith('OPTIONS'): > + if not sline.startswith(NTPD_OPTS_VAR): > continue > - sline = sline.replace('"', '') > + sline = sline.replace(NTPD_OPTS_QUOTE, '') > for opt in needopts: > if sline.find(opt['val']) != -1: > opt['need'] = False > @@ -124,12 +128,12 @@ class NTPInstance(service.Service): > for line in lines: > if not done: > sline = line.strip() > - if not sline.startswith('OPTIONS'): > + if not sline.startswith(NTPD_OPTS_VAR): > fd.write(line) > continue > - sline = sline.replace('"', '') > + sline = sline.replace(NTPD_OPTS_QUOTE, '') > (variable, opts) = sline.split('=', 1) > - fd.write('OPTIONS="%s %s"\n' % (opts, ' '.join(newopts))) > + fd.write(NTPD_OPTS_VAR + '="%s %s"\n' % (opts, ' '.join(newopts))) > done = True > else: > fd.write(line) > -- > 2.5.0 > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From tbabej at redhat.com Wed Oct 7 11:15:15 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 7 Oct 2015 13:15:15 +0200 Subject: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions In-Reply-To: <20151007105110.GA27006@redhat.com> References: <561419BC.5080707@ubuntu.com> <20151007105110.GA27006@redhat.com> Message-ID: <20151007111515.GA7578@redhat.com> On Wed, Oct 07, 2015 at 12:51:10PM +0200, Tomas Babej wrote: > On Tue, Oct 06, 2015 at 09:58:04PM +0300, Timo Aaltonen wrote: > > > > Hi > > > > So here's the first batch of quick patches for ticket #5343. They're > > only compile-tested so far (so no stupid mistakes I hope), as I don't > > have 4.2+ working yet. Wonder how the quotes in the last patch work, but > > at least make-lint didn't laugh too hard.. > > > > -- > > t > > Hi, > > overall this looks good, couple of comments inline. > Additionally, there are some legitimate lint failures: ************* Module ipaserver.install.ntpinstance ipaserver/install/ntpinstance.py:28: [E1101(no-member), ] Instance of 'FedoraConstantsNamespace' has no 'NTPD_OPTS_VAR' member) ipaserver/install/ntpinstance.py:29: [E1101(no-member), ] Instance of 'FedoraConstantsNamespace' has no 'NTPD_OPTS_QUOTE' member) ************* Module ipaserver.install.httpinstance ipaserver/install/httpinstance.py:252: [E1101(no-member), HTTPInstance.__add_include] Instance of 'FedoraPathNamespace' has no 'HTTPD_CONF_D' member) "NTPD*" vars are defined as "NTP*" in the Namespace and HTTPD_CONF_D should be HTTPD_CONF_D_DIR. HTH, Tomas From mbasti at redhat.com Wed Oct 7 12:35:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 14:35:53 +0200 Subject: [Freeipa-devel] [PATCH 0058] Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limit In-Reply-To: <56138642.50400@redhat.com> References: <56137C40.7080603@redhat.com> <56138200.5020508@redhat.com> <56138642.50400@redhat.com> Message-ID: <561511A9.1090903@redhat.com> On 10/06/2015 10:28 AM, Petr Spacek wrote: > On 6.10.2015 10:10, Martin Basti wrote: >> On 10/06/2015 09:46 AM, Petr Spacek wrote: >>> Hello, >>> >>> Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding >>> LDAP limits. >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1268027 >>> >> NACK >> >> ************* Module ipa-dnskeysync-replica >> daemons/dnssec/ipa-dnskeysync-replica:156: [E0602(undefined-variable), ] >> Undefined variable 'api') >> ************* Module ipa-ods-exporter >> daemons/dnssec/ipa-ods-exporter:505: [E0602(undefined-variable), ] Undefined >> variable 'api') > Sorry, I'm idiot. Fixed patch is attached. > ACK Pushed to: master: 0b797da56095801bfa80653465c04bae0809df8d ipa-4-2: 5841d495f081c635394cda09abe36be020d32d84 From dkupka at redhat.com Wed Oct 7 13:10:16 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 7 Oct 2015 15:10:16 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <20151006155237.GJ3048@hendrix> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> <5613BF5D.4040500@redhat.com> <20151006155237.GJ3048@hendrix> Message-ID: <561519B8.1010206@redhat.com> On 06/10/15 17:52, Jakub Hrozek wrote: > On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: >> On 06/10/15 08:04, David Kupka wrote: >>> On 06/10/15 13:35, Simo Sorce wrote: >>>> On 06/10/15 03:51, thierry bordaz wrote: >>>>> On 10/06/2015 07:19 AM, David Kupka wrote: >>>>>> On 05/10/15 16:12, Simo Sorce wrote: >>>>>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>>>>> These patches implement the plumbing required to properly support >>>>>>>> canonicalization of Kerberos principals ( >>>>>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>>>>> >>>>>>>> Setting multiple principal aliases on hosts/services is beyond the >>>>>>>> scope >>>>>>>> of this patchset and should be done after these patches are pushed. >>>>>>>> >>>>>>>> I will try to send some tests for the patches later this week. >>>>>>>> >>>>>>>> Please review the hell out of them. >>>>>>> >>>>>>> LGTM, I do not see any issue at quick visual inspection. >>>>>>> What about the performance regression with the indexes ? Is that bug >>>>>>> fixed in 389ds ? >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>>> >>>>>> >>>>>> The issue is still there. Thierry investigated this in 389 DS and IIUC >>>>>> he is not sure if it's bug or completely missing feature. Therefore we >>>>>> still don't know how much time is needed there. >>>>>> >>>>> Hi, >>>>> that is correct. >>>>> I can reproduce the problem. Although the matching rule (in my test >>>>> caseIgnoreIA5Match) is found, it has no registered indexing function, so >>>>> the setting (nsMatchingRule) is ignored. >>>>> I do not know if the indexing function is missing or there is a bug so >>>>> that the matching rule "forget" to register it. >>>>> This feature is documented but I can not find any QA test around it, so >>>>> I do not know yet if it is a regression or if it was not enabled at all. >>>>> >>>>> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >>>>> For the moment I can think to only two workarounds: >>>>> >>>>> * use filtered matching rule (preferred) >>>>> * change the attribute syntax/matching rule, in the schema (I would >>>>> discourage this one because changing the schema is risky) >>>> >>>> We can't change the syntax at this point. >>>> >>>> Well this patchset is blocked until the 389 ds bug is fixed (the >>>> performance regression is too big to just put it in and hope) so I guess >>>> we'll have to negotiate a time for the fix. >>>> >>>> Simo. >>>> >>> >>> I agree that we really shouldn't change schema. >>> >>> But I don't think the patches're necessary blocked by this issue. >>> Canonicalization was never supported in FreeIPA and when it is not >>> requested the performance is not effected at all. We could merge patches >>> as soon as they're carefully reviewed and tested to avoid tedious >>> rebasing and start using the new functionality when 389 DS gets fixed. >> >> The fact we didn't do canonicalization this way doesn't mean clients aren't >> asking for it. >> >> I think Windows clients ask for canonicalization by default, and in SSSD I >> see we turn on by default krb5_canonicalize in the IPA nd LDAP case (oddly >> enough not in the AD case ?) >> >> So SSSD's authentication requests would end up hitting this case all the >> time if I am reading the code correctly (CCed Jakub to confirm/dispel this). > > We ask for canonicalization always in IPA and LDAP, but also whenever > enterprise principals are used, which is true for AD provider. > Then SSSD will hit this every time it requests ticket on behalf of user. But to be sure what the impact would be I've once again set up FreeIPA server with 10K users and run some tests. 1) 3 LDAP searches (caseIgnoreIA5Match, caseExactIA5Match, without specifying the matching rule). Results (http://fpaste.org/275847/44221770/raw/) shows that unindexed search takes ~100 times longer than indexed. 2) kinit with and without requested canonicalization. As we use kinit to get the ticket it makes sense to check what will the performance hit be when we run kinit as a whole and not just an isolated LDAP search. The results (http://fpaste.org/275848/21793144/raw/) shows that with canonicalization it takes ~2 times longer than without it. While this is nothing to be happy about it's certainly better than I would expect. -- David Kupka From ofayans at redhat.com Wed Oct 7 14:13:25 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 7 Oct 2015 16:13:25 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 Message-ID: <56152885.7050201@redhat.com> subj -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0009-Added-a-workaround-for-ticket-N-5348.patch Type: text/x-patch Size: 2045 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 7 14:26:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 16:26:12 +0200 Subject: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions In-Reply-To: <20151007105110.GA27006@redhat.com> References: <561419BC.5080707@ubuntu.com> <20151007105110.GA27006@redhat.com> Message-ID: <56152B84.2020503@redhat.com> thanks comments inline On 10/07/2015 12:51 PM, Tomas Babej wrote: > On Tue, Oct 06, 2015 at 09:58:04PM +0300, Timo Aaltonen wrote: >> Hi >> >> So here's the first batch of quick patches for ticket #5343. They're >> only compile-tested so far (so no stupid mistakes I hope), as I don't >> have 4.2+ working yet. Wonder how the quotes in the last patch work, but >> at least make-lint didn't laugh too hard.. >> >> -- >> t > Hi, > > overall this looks good, couple of comments inline. > >> From 15b30829c53a7e02ddc997c17559d755b751c9d6 Mon Sep 17 00:00:00 2001 >> From: Timo Aaltonen >> Date: Tue, 6 Oct 2015 16:02:37 +0300 >> Subject: [PATCH 1/2] ipaplatform: Add HTTPD_USER to constants >> >> https://fedorahosted.org/freeipa/ticket/5343 >> --- >> ipaplatform/base/constants.py | 1 + >> ipaserver/install/cainstance.py | 3 ++- >> ipaserver/install/certs.py | 3 ++- >> ipaserver/install/httpinstance.py | 11 ++++++----- >> ipaserver/install/ipa_server_certinstall.py | 3 ++- >> 5 files changed, 13 insertions(+), 8 deletions(-) >> >> diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py >> index cef829e2d3886db00ae6d0299ddcf325d1add80e..3f78822f99d9fbe815901301f4e6855105e73eea 100644 >> --- a/ipaplatform/base/constants.py >> +++ b/ipaplatform/base/constants.py >> @@ -8,4 +8,5 @@ This base platform module exports platform dependant constants. >> >> >> class BaseConstantsNamespace(object): >> + HTTPD_USER = "apache" >> IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" >> diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py >> index c4788816ab702e9409c9bc44a91fcbd95dce018d..6deaef57c025cb55da9fcaf7620a54565f6701c7 100644 >> --- a/ipaserver/install/cainstance.py >> +++ b/ipaserver/install/cainstance.py >> @@ -48,6 +48,7 @@ from ipalib import pkcs10, x509 >> from ipalib import errors >> >> from ipaplatform import services >> +from ipaplatform.constants import constants >> from ipaplatform.paths import paths >> from ipaplatform.tasks import tasks >> >> @@ -1103,7 +1104,7 @@ class CAInstance(DogtagInstance): >> os.chmod(self.ra_agent_db + "/key3.db", 0o640) >> os.chmod(self.ra_agent_db + "/secmod.db", 0o640) >> >> - pent = pwd.getpwnam("apache") >> + pent = pwd.getpwnam(constants.HTTPD_USER) >> os.chown(self.ra_agent_db + "/cert8.db", 0, pent.pw_gid ) >> os.chown(self.ra_agent_db + "/key3.db", 0, pent.pw_gid ) >> os.chown(self.ra_agent_db + "/secmod.db", 0, pent.pw_gid ) >> diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py >> index 3e07ee398fa47beb02f54940a0246d58ae2267ae..d85344ede993840845af63c377525699425a9382 100644 >> --- a/ipaserver/install/certs.py >> +++ b/ipaserver/install/certs.py >> @@ -42,6 +42,7 @@ from ipalib import pkcs10, x509, api >> from ipalib.errors import CertificateOperationError >> from ipalib.text import _ >> from ipaplatform import services >> +from ipaplatform.constants import constants >> from ipaplatform.paths import paths >> >> # Apache needs access to this database so we need to create it >> @@ -519,7 +520,7 @@ class CertDB(object): >> f.close() >> pwdfile.close() >> # TODO: replace explicit uid by a platform-specific one This TODO can be removed with this patch >> - self.set_perms(self.pwd_conf, uid="apache") >> + self.set_perms(self.pwd_conf, uid=constants.HTTPD_USER) >> >> def find_root_cert(self, nickname): >> """ >> diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py >> index ee4853a3f9a8a42bd050fd8b208fc2419c323512..a7fdfb1a21a8c62f57503cfaca68b30e4f26244f 100644 >> --- a/ipaserver/install/httpinstance.py >> +++ b/ipaserver/install/httpinstance.py >> @@ -41,6 +41,7 @@ import ipapython.errors >> from ipaserver.install import sysupgrade >> from ipalib import api >> from ipalib import errors >> +from ipaplatform.constants import constants >> from ipaplatform.tasks import tasks >> from ipaplatform.paths import paths >> from ipaplatform import services >> @@ -52,7 +53,7 @@ SELINUX_BOOLEAN_SETTINGS = dict( >> ) >> >> KDCPROXY_USER = 'kdcproxy' >> - >> +HTTPD_USER = constants.HTTPD_USER >> >> def httpd_443_configured(): >> """ >> @@ -188,14 +189,14 @@ class HTTPInstance(service.Service): >> self.move_service(self.principal) >> self.add_cert_to_service() >> >> - pent = pwd.getpwnam("apache") >> + pent = pwd.getpwnam(HTTPD_USER) >> os.chown(paths.IPA_KEYTAB, pent.pw_uid, pent.pw_gid) >> >> def remove_httpd_ccache(self): >> # Clean up existing ccache >> # Make sure that empty env is passed to avoid passing KRB5CCNAME from >> # current env >> - ipautil.run(['kdestroy', '-A'], runas='apache', raiseonerr=False, env={}) >> + ipautil.run(['kdestroy', '-A'], runas=HTTPD_USER, raiseonerr=False, env={}) >> >> def __configure_http(self): >> target_fname = paths.HTTPD_IPA_CONF >> @@ -324,7 +325,7 @@ class HTTPInstance(service.Service): >> os.chmod(certs.NSS_DIR + "/secmod.db", 0o660) >> os.chmod(certs.NSS_DIR + "/pwdfile.txt", 0o660) >> >> - pent = pwd.getpwnam("apache") >> + pent = pwd.getpwnam(HTTPD_USER) >> os.chown(certs.NSS_DIR + "/cert8.db", 0, pent.pw_gid ) >> os.chown(certs.NSS_DIR + "/key3.db", 0, pent.pw_gid ) >> os.chown(certs.NSS_DIR + "/secmod.db", 0, pent.pw_gid ) >> @@ -493,7 +494,7 @@ class HTTPInstance(service.Service): >> pass >> >> # Remove the ccache file for the HTTPD service >> - ipautil.run([paths.KDESTROY, '-c', paths.KRB5CC_HTTPD], runas='apache', >> + ipautil.run([paths.KDESTROY, '-c', paths.KRB5CC_HTTPD], runas=HTTPD_USER, >> raiseonerr=False) >> >> # Remove the configuration files we create >> diff --git a/ipaserver/install/ipa_server_certinstall.py b/ipaserver/install/ipa_server_certinstall.py >> index e90b2abd6644c71bc3b567af5ac74c8368df1b15..ac0b0274e4e36db4ea6fb695afb527e2b83a8c77 100644 >> --- a/ipaserver/install/ipa_server_certinstall.py >> +++ b/ipaserver/install/ipa_server_certinstall.py >> @@ -24,6 +24,7 @@ import os.path >> import pwd >> import optparse >> >> +from ipaplatform.constants import constants >> from ipaplatform.paths import paths >> from ipapython import admintool >> from ipapython.dn import DN >> @@ -151,7 +152,7 @@ class ServerCertInstall(admintool.AdminTool): >> os.chmod(os.path.join(dirname, 'key3.db'), 0o640) >> os.chmod(os.path.join(dirname, 'secmod.db'), 0o640) >> >> - pent = pwd.getpwnam("apache") >> + pent = pwd.getpwnam(constants.HTTPD_USER) >> os.chown(os.path.join(dirname, 'cert8.db'), 0, pent.pw_gid) >> os.chown(os.path.join(dirname, 'key3.db'), 0, pent.pw_gid) >> os.chown(os.path.join(dirname, 'secmod.db'), 0, pent.pw_gid) >> -- >> 2.5.0 >> >> From 77be9a8b67a49ca263e82dde5bf87d432ca64922 Mon Sep 17 00:00:00 2001 >> From: Timo Aaltonen >> Date: Tue, 6 Oct 2015 16:27:21 +0300 >> Subject: [PATCH 2/2] ipaplatform: Add NAMED_USER to constants >> >> https://fedorahosted.org/freeipa/ticket/5343 >> --- >> ipaplatform/base/constants.py | 1 + >> ipaserver/install/bindinstance.py | 3 ++- >> 2 files changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py >> index 3f78822f99d9fbe815901301f4e6855105e73eea..9a1237106d47b93c6cbe50b139b92cbcc0a745ff 100644 >> --- a/ipaplatform/base/constants.py >> +++ b/ipaplatform/base/constants.py >> @@ -10,3 +10,4 @@ This base platform module exports platform dependant constants. >> class BaseConstantsNamespace(object): >> HTTPD_USER = "apache" >> IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" >> + NAMED_USER = "named" >> diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py >> index e8fdb3b83317f996959e4123b481f353c2f056c9..2cbf30202f30bd80c01a6399ecff3a6406316825 100644 >> --- a/ipaserver/install/bindinstance.py >> +++ b/ipaserver/install/bindinstance.py >> @@ -39,6 +39,7 @@ from ipapython.dn import DN >> import ipalib >> from ipalib import api, errors >> from ipaplatform import services >> +from ipaplatform.constants import constants >> from ipaplatform.paths import paths >> from ipaplatform.tasks import tasks >> from ipalib.util import (validate_zonemgr_str, normalize_zonemgr, >> @@ -561,7 +562,7 @@ class BindInstance(service.Service): >> suffix = ipautil.dn_attribute_property('_suffix') >> >> def setup(self, fqdn, ip_addresses, realm_name, domain_name, forwarders, ntp, >> - reverse_zones, named_user="named", zonemgr=None, >> + reverse_zones, named_user=constants.NAMED_USER, zonemgr=None, >> ca_configured=None, no_dnssec_validation=False): >> self.named_user = named_user >> self.fqdn = fqdn >> -- >> 2.5.0 >> >> From 52945c313e975aa3371bb3275b4ff42707e13e89 Mon Sep 17 00:00:00 2001 >> From: Timo Aaltonen >> Date: Tue, 6 Oct 2015 16:43:09 +0300 >> Subject: [PATCH] httpinstance: Use full path via HTTPD_CONF_D for Include. >> >> https://fedorahosted.org/freeipa/ticket/5343 >> --- >> ipaserver/install/httpinstance.py | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py >> index a7fdfb1a21a8c62f57503cfaca68b30e4f26244f..16139ef34d846ad8dd4780745f647b9ad5aad772 100644 >> --- a/ipaserver/install/httpinstance.py >> +++ b/ipaserver/install/httpinstance.py >> @@ -249,7 +249,7 @@ class HTTPInstance(service.Service): >> >> def __add_include(self): >> """This should run after __set_mod_nss_port so is already backed up""" >> - if installutils.update_file(paths.HTTPD_NSS_CONF, '', 'Include conf.d/ipa-rewrite.conf\n') != 0: >> + if installutils.update_file(paths.HTTPD_NSS_CONF, '', 'Include ' + paths.HTTPD_CONF_D + '/ipa-rewrite.conf\n') != 0: > Please use os.path.join here, so that we avoid reliance on the > particular format of paths.HTTPD_CONF_D (without trailing slash in this > case) yes, please use os.path.join(), and also there is too much pluses, please use python format string 'include {path}\n'.format(path=os.join(paths.HTTPD_CONF_D, 'ipa-rewrite-conf')) (not tested) or you can use HTTPD_IPA_REWRITE_CONF from paths > >> print("Adding Include conf.d/ipa-rewrite to %s failed." % paths.HTTPD_NSS_CONF) >> >> def configure_certmonger_renewal_guard(self): >> -- >> 2.5.0 >> >> From 1ca29f9e6188487862d77ea1458e6ff84b371103 Mon Sep 17 00:00:00 2001 >> From: Timo Aaltonen >> Date: Tue, 6 Oct 2015 16:35:24 +0300 >> Subject: [PATCH] ipaplatform: Add SECURE_NFS_VAR to constants >> >> https://fedorahosted.org/freeipa/ticket/5343 >> --- >> ipa-client/ipa-install/ipa-client-automount | 3 ++- >> ipaplatform/base/constants.py | 1 + >> 2 files changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount >> index 5e4ab1396aeb6311be1ace8f5c74ce9760fee408..ab7fe3b62b40376d03d87fdef103eedc7aa50cdf 100755 >> --- a/ipa-client/ipa-install/ipa-client-automount >> +++ b/ipa-client/ipa-install/ipa-client-automount >> @@ -40,6 +40,7 @@ from ipaclient import ipadiscovery >> from ipaclient import ipachangeconf >> from ipapython.ipa_log_manager import * >> from ipapython.dn import DN >> +from ipaplatform.constants import constants >> from ipaplatform.tasks import tasks >> from ipaplatform import services >> from ipaplatform.paths import paths >> @@ -309,7 +310,7 @@ def configure_nfs(fstore, statestore): >> Configure secure NFS >> """ >> replacevars = { >> - 'SECURE_NFS': 'yes', >> + constants.SECURE_NFS_VAR: 'yes', >> } >> ipautil.backup_config_and_replace_variables(fstore, >> paths.SYSCONFIG_NFS, replacevars=replacevars) >> diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py >> index 9a1237106d47b93c6cbe50b139b92cbcc0a745ff..191d3de2c9bf8c6d1a9e39366a5bf9142b8c139f 100644 >> --- a/ipaplatform/base/constants.py >> +++ b/ipaplatform/base/constants.py >> @@ -11,3 +11,4 @@ class BaseConstantsNamespace(object): >> HTTPD_USER = "apache" >> IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" >> NAMED_USER = "named" >> + SECURE_NFS_VAR = "SECURE_NFS" > Can we add a helpful comment what a constant describes here? I think we > should start this convention for any non-obvious platform constants, so > that any new platform maintainer has an easy job figuring out what > platform constant actually holds. > >> -- >> 2.5.0 >> >> From 83a6ddec954a07f78be330bdaa71b53d01d0e1c0 Mon Sep 17 00:00:00 2001 >> From: Timo Aaltonen >> Date: Tue, 6 Oct 2015 18:46:00 +0300 >> Subject: [PATCH] ipaplatform: Add NTP_OPTS_VAR and NTP_OPTS_QUOTE to constants >> >> https://fedorahosted.org/freeipa/ticket/5343 >> --- >> ipaplatform/base/constants.py | 2 ++ >> ipaserver/install/ntpinstance.py | 14 +++++++++----- >> 2 files changed, 11 insertions(+), 5 deletions(-) >> >> diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py >> index 191d3de2c9bf8c6d1a9e39366a5bf9142b8c139f..aafc7b412cc0fc913a332417ae12b6caad619330 100644 >> --- a/ipaplatform/base/constants.py >> +++ b/ipaplatform/base/constants.py >> @@ -11,4 +11,6 @@ class BaseConstantsNamespace(object): >> HTTPD_USER = "apache" >> IPA_DNS_PACKAGE_NAME = "freeipa-server-dns" >> NAMED_USER = "named" >> + NTP_OPTS_VAR = "OPTIONS" >> + NTP_OPTS_QUOTE = "\"" > Probably a comment is needed here as well. > >> SECURE_NFS_VAR = "SECURE_NFS" >> diff --git a/ipaserver/install/ntpinstance.py b/ipaserver/install/ntpinstance.py >> index 1fef6fd3e8931615b201ce25beaac8bb6c945a01..567dec6e97588792c5331a5dc425cc8220930f82 100644 >> --- a/ipaserver/install/ntpinstance.py >> +++ b/ipaserver/install/ntpinstance.py >> @@ -21,9 +21,13 @@ >> from ipaserver.install import service >> from ipapython import sysrestore >> from ipapython import ipautil >> +from ipaplatform.constants import constants >> from ipaplatform.paths import paths >> from ipapython.ipa_log_manager import * >> >> +NTPD_OPTS_VAR = constants.NTPD_OPTS_VAR >> +NTPD_OPTS_QUOTE = constants.NTPD_OPTS_QUOTE >> + >> class NTPInstance(service.Service): >> def __init__(self, fstore=None): >> service.Service.__init__(self, "ntpd", service_desc="NTP daemon") >> @@ -106,9 +110,9 @@ class NTPInstance(service.Service): >> fd.close() >> for line in lines: >> sline = line.strip() >> - if not sline.startswith('OPTIONS'): >> + if not sline.startswith(NTPD_OPTS_VAR): >> continue >> - sline = sline.replace('"', '') >> + sline = sline.replace(NTPD_OPTS_QUOTE, '') >> for opt in needopts: >> if sline.find(opt['val']) != -1: >> opt['need'] = False >> @@ -124,12 +128,12 @@ class NTPInstance(service.Service): >> for line in lines: >> if not done: >> sline = line.strip() >> - if not sline.startswith('OPTIONS'): >> + if not sline.startswith(NTPD_OPTS_VAR): >> fd.write(line) >> continue >> - sline = sline.replace('"', '') >> + sline = sline.replace(NTPD_OPTS_QUOTE, '') >> (variable, opts) = sline.split('=', 1) >> - fd.write('OPTIONS="%s %s"\n' % (opts, ' '.join(newopts))) >> + fd.write(NTPD_OPTS_VAR + '="%s %s"\n' % (opts, ' '.join(newopts))) >> done = True >> else: >> fd.write(line) >> -- >> 2.5.0 >> >> -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Oct 7 14:28:29 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 7 Oct 2015 16:28:29 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56152885.7050201@redhat.com> References: <56152885.7050201@redhat.com> Message-ID: <56152C0D.7000007@redhat.com> On 10/07/2015 04:13 PM, Oleg Fayans wrote: > subj I would suggest using standard FreeIPA format of refering to tickets, i.e. URL. I would also suggest including ticket URL in patch description so that people can easily find it: http://www.freeipa.org/page/Contribute/Patch_Format Martin From mbasti at redhat.com Wed Oct 7 14:30:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 16:30:50 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56152885.7050201@redhat.com> References: <56152885.7050201@redhat.com> Message-ID: <56152C9A.1050202@redhat.com> On 10/07/2015 04:13 PM, Oleg Fayans wrote: > subj > > > Workaround looks good, but I prefer not to push it in upstream tests, because it is not test failure. Why is there this sleep, this might be useful in upstream tests too, but what is the reason to add sleep there? # verify signatures + time.sleep(1) args = [ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Wed Oct 7 15:06:20 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 07 Oct 2015 17:06:20 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <561519B8.1010206@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> <5613BF5D.4040500@redhat.com> <20151006155237.GJ3048@hendrix> <561519B8.1010206@redhat.com> Message-ID: <561534EC.90506@redhat.com> On 10/07/2015 03:10 PM, David Kupka wrote: > On 06/10/15 17:52, Jakub Hrozek wrote: >> On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: >>> On 06/10/15 08:04, David Kupka wrote: >>>> On 06/10/15 13:35, Simo Sorce wrote: >>>>> On 06/10/15 03:51, thierry bordaz wrote: >>>>>> On 10/06/2015 07:19 AM, David Kupka wrote: >>>>>>> On 05/10/15 16:12, Simo Sorce wrote: >>>>>>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>>>>>> These patches implement the plumbing required to properly support >>>>>>>>> canonicalization of Kerberos principals ( >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>>>>>> >>>>>>>>> Setting multiple principal aliases on hosts/services is beyond >>>>>>>>> the >>>>>>>>> scope >>>>>>>>> of this patchset and should be done after these patches are >>>>>>>>> pushed. >>>>>>>>> >>>>>>>>> I will try to send some tests for the patches later this week. >>>>>>>>> >>>>>>>>> Please review the hell out of them. >>>>>>>> >>>>>>>> LGTM, I do not see any issue at quick visual inspection. >>>>>>>> What about the performance regression with the indexes ? Is >>>>>>>> that bug >>>>>>>> fixed in 389ds ? >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> The issue is still there. Thierry investigated this in 389 DS >>>>>>> and IIUC >>>>>>> he is not sure if it's bug or completely missing feature. >>>>>>> Therefore we >>>>>>> still don't know how much time is needed there. >>>>>>> >>>>>> Hi, >>>>>> that is correct. >>>>>> I can reproduce the problem. Although the matching rule (in my test >>>>>> caseIgnoreIA5Match) is found, it has no registered indexing >>>>>> function, so >>>>>> the setting (nsMatchingRule) is ignored. >>>>>> I do not know if the indexing function is missing or there is a >>>>>> bug so >>>>>> that the matching rule "forget" to register it. >>>>>> This feature is documented but I can not find any QA test around >>>>>> it, so >>>>>> I do not know yet if it is a regression or if it was not enabled >>>>>> at all. >>>>>> >>>>>> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >>>>>> For the moment I can think to only two workarounds: >>>>>> >>>>>> * use filtered matching rule (preferred) >>>>>> * change the attribute syntax/matching rule, in the schema (I >>>>>> would >>>>>> discourage this one because changing the schema is risky) >>>>> >>>>> We can't change the syntax at this point. >>>>> >>>>> Well this patchset is blocked until the 389 ds bug is fixed (the >>>>> performance regression is too big to just put it in and hope) so I >>>>> guess >>>>> we'll have to negotiate a time for the fix. >>>>> >>>>> Simo. >>>>> >>>> >>>> I agree that we really shouldn't change schema. >>>> >>>> But I don't think the patches're necessary blocked by this issue. >>>> Canonicalization was never supported in FreeIPA and when it is not >>>> requested the performance is not effected at all. We could merge >>>> patches >>>> as soon as they're carefully reviewed and tested to avoid tedious >>>> rebasing and start using the new functionality when 389 DS gets fixed. >>> >>> The fact we didn't do canonicalization this way doesn't mean clients >>> aren't >>> asking for it. >>> >>> I think Windows clients ask for canonicalization by default, and in >>> SSSD I >>> see we turn on by default krb5_canonicalize in the IPA nd LDAP case >>> (oddly >>> enough not in the AD case ?) >>> >>> So SSSD's authentication requests would end up hitting this case all >>> the >>> time if I am reading the code correctly (CCed Jakub to >>> confirm/dispel this). >> >> We ask for canonicalization always in IPA and LDAP, but also whenever >> enterprise principals are used, which is true for AD provider. >> > > Then SSSD will hit this every time it requests ticket on behalf of user. > But to be sure what the impact would be I've once again set up FreeIPA > server with 10K users and run some tests. > > 1) 3 LDAP searches (caseIgnoreIA5Match, caseExactIA5Match, without > specifying the matching rule). > Results (http://fpaste.org/275847/44221770/raw/) shows that unindexed > search takes ~100 times longer than indexed. > > 2) kinit with and without requested canonicalization. > > As we use kinit to get the ticket it makes sense to check what will > the performance hit be when we run kinit as a whole and not just an > isolated LDAP search. > The results (http://fpaste.org/275848/21793144/raw/) shows that with > canonicalization it takes ~2 times longer than without it. > While this is nothing to be happy about it's certainly better than I > would expect. > Clearly we need to make the search indexed. In your deployment you defined: dn: uid=user1000098,cn=users,cn=accounts,dc=example,dc=test uid: user1000098 givenName: Test sn: User1000098 cn: Test User1000098 initials: TU homeDirectory: /home/user1000098 gecos: Test User1000098 loginShell: /bin/sh mail: user1000098 at example.test uidNumber: 7611001000098 gidNumber: 7611001000098 displayName: Test User1000098 *krbPrincipalName: user1000098 at EXAMPLE.TEST* *krbCanonicalName: user1000098 at EXAMPLE.TEST* memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry ipaUniqueID: 6048c4ac-6cdd-11e5-a0af-080027987dcb mepManagedEntry: cn=user1000098,cn=groups,cn=accounts,dc=example,dc=test Would it be an option to create a new attribute, 'krbNonCanonicalName' (containing the krbprincipal) but with a 'caseignoreIA5' syntax ? If this attribute is indexed, your lookup from a raw principal would user "(krbNonCanonicalname=user10000098 at EXAMPLE.TEST)" thanks theirry -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Oct 7 15:29:47 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 7 Oct 2015 11:29:47 -0400 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <561534EC.90506@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> <5613BF5D.4040500@redhat.com> <20151006155237.GJ3048@hendrix> <561519B8.1010206@redhat.com> <561534EC.90506@redhat.com> Message-ID: <56153A6B.1020902@redhat.com> On 07/10/15 11:06, thierry bordaz wrote: > On 10/07/2015 03:10 PM, David Kupka wrote: >> On 06/10/15 17:52, Jakub Hrozek wrote: >>> On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: >>>> On 06/10/15 08:04, David Kupka wrote: >>>>> On 06/10/15 13:35, Simo Sorce wrote: >>>>>> On 06/10/15 03:51, thierry bordaz wrote: >>>>>>> On 10/06/2015 07:19 AM, David Kupka wrote: >>>>>>>> On 05/10/15 16:12, Simo Sorce wrote: >>>>>>>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>>>>>>> These patches implement the plumbing required to properly support >>>>>>>>>> canonicalization of Kerberos principals ( >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>>>>>>> >>>>>>>>>> Setting multiple principal aliases on hosts/services is beyond >>>>>>>>>> the >>>>>>>>>> scope >>>>>>>>>> of this patchset and should be done after these patches are >>>>>>>>>> pushed. >>>>>>>>>> >>>>>>>>>> I will try to send some tests for the patches later this week. >>>>>>>>>> >>>>>>>>>> Please review the hell out of them. >>>>>>>>> >>>>>>>>> LGTM, I do not see any issue at quick visual inspection. >>>>>>>>> What about the performance regression with the indexes ? Is >>>>>>>>> that bug >>>>>>>>> fixed in 389ds ? >>>>>>>>> >>>>>>>>> Simo. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> The issue is still there. Thierry investigated this in 389 DS >>>>>>>> and IIUC >>>>>>>> he is not sure if it's bug or completely missing feature. >>>>>>>> Therefore we >>>>>>>> still don't know how much time is needed there. >>>>>>>> >>>>>>> Hi, >>>>>>> that is correct. >>>>>>> I can reproduce the problem. Although the matching rule (in my test >>>>>>> caseIgnoreIA5Match) is found, it has no registered indexing >>>>>>> function, so >>>>>>> the setting (nsMatchingRule) is ignored. >>>>>>> I do not know if the indexing function is missing or there is a >>>>>>> bug so >>>>>>> that the matching rule "forget" to register it. >>>>>>> This feature is documented but I can not find any QA test around >>>>>>> it, so >>>>>>> I do not know yet if it is a regression or if it was not enabled >>>>>>> at all. >>>>>>> >>>>>>> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >>>>>>> For the moment I can think to only two workarounds: >>>>>>> >>>>>>> * use filtered matching rule (preferred) >>>>>>> * change the attribute syntax/matching rule, in the schema (I >>>>>>> would >>>>>>> discourage this one because changing the schema is risky) >>>>>> >>>>>> We can't change the syntax at this point. >>>>>> >>>>>> Well this patchset is blocked until the 389 ds bug is fixed (the >>>>>> performance regression is too big to just put it in and hope) so I >>>>>> guess >>>>>> we'll have to negotiate a time for the fix. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> I agree that we really shouldn't change schema. >>>>> >>>>> But I don't think the patches're necessary blocked by this issue. >>>>> Canonicalization was never supported in FreeIPA and when it is not >>>>> requested the performance is not effected at all. We could merge >>>>> patches >>>>> as soon as they're carefully reviewed and tested to avoid tedious >>>>> rebasing and start using the new functionality when 389 DS gets fixed. >>>> >>>> The fact we didn't do canonicalization this way doesn't mean clients >>>> aren't >>>> asking for it. >>>> >>>> I think Windows clients ask for canonicalization by default, and in >>>> SSSD I >>>> see we turn on by default krb5_canonicalize in the IPA nd LDAP case >>>> (oddly >>>> enough not in the AD case ?) >>>> >>>> So SSSD's authentication requests would end up hitting this case all >>>> the >>>> time if I am reading the code correctly (CCed Jakub to >>>> confirm/dispel this). >>> >>> We ask for canonicalization always in IPA and LDAP, but also whenever >>> enterprise principals are used, which is true for AD provider. >>> >> >> Then SSSD will hit this every time it requests ticket on behalf of user. >> But to be sure what the impact would be I've once again set up FreeIPA >> server with 10K users and run some tests. >> >> 1) 3 LDAP searches (caseIgnoreIA5Match, caseExactIA5Match, without >> specifying the matching rule). >> Results (http://fpaste.org/275847/44221770/raw/) shows that unindexed >> search takes ~100 times longer than indexed. >> >> 2) kinit with and without requested canonicalization. >> >> As we use kinit to get the ticket it makes sense to check what will >> the performance hit be when we run kinit as a whole and not just an >> isolated LDAP search. >> The results (http://fpaste.org/275848/21793144/raw/) shows that with >> canonicalization it takes ~2 times longer than without it. >> While this is nothing to be happy about it's certainly better than I >> would expect. >> > Clearly we need to make the search indexed. > In your deployment you defined: > > dn: uid=user1000098,cn=users,cn=accounts,dc=example,dc=test > uid: user1000098 > givenName: Test > sn: User1000098 > cn: Test User1000098 > initials: TU > homeDirectory: /home/user1000098 > gecos: Test User1000098 > loginShell: /bin/sh > mail: user1000098 at example.test > uidNumber: 7611001000098 > gidNumber: 7611001000098 > displayName: Test User1000098 > *krbPrincipalName: user1000098 at EXAMPLE.TEST* > *krbCanonicalName: user1000098 at EXAMPLE.TEST* > memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test > objectClass: ipaobject > objectClass: person > objectClass: top > objectClass: ipasshuser > objectClass: inetorgperson > objectClass: organizationalperson > objectClass: krbticketpolicyaux > objectClass: krbprincipalaux > objectClass: inetuser > objectClass: posixaccount > objectClass: ipaSshGroupOfPubKeys > objectClass: mepOriginEntry > ipaUniqueID: 6048c4ac-6cdd-11e5-a0af-080027987dcb > mepManagedEntry: > cn=user1000098,cn=groups,cn=accounts,dc=example,dc=test > > Would it be an option to create a new attribute, 'krbNonCanonicalName' > (containing the krbprincipal) but with a 'caseignoreIA5' syntax ? > If this attribute is indexed, your lookup from a raw principal would > user "(krbNonCanonicalname=user10000098 at EXAMPLE.TEST)" It is not an option, no changing attributes, no changing syntaxes, if DS can't be fixed we'll need to adopt a completely different strategy we discussed already previously. However it would be much nicer if we could fix DS to allow to create (and use) indexes for matching rules that are not defined in the schema. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Wed Oct 7 15:32:04 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 07 Oct 2015 17:32:04 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <56153A6B.1020902@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> <5613BF5D.4040500@redhat.com> <20151006155237.GJ3048@hendrix> <561519B8.1010206@redhat.com> <561534EC.90506@redhat.com> <56153A6B.1020902@redhat.com> Message-ID: <56153AF4.9040607@redhat.com> On 10/07/2015 05:29 PM, Simo Sorce wrote: > On 07/10/15 11:06, thierry bordaz wrote: >> On 10/07/2015 03:10 PM, David Kupka wrote: >>> On 06/10/15 17:52, Jakub Hrozek wrote: >>>> On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: >>>>> On 06/10/15 08:04, David Kupka wrote: >>>>>> On 06/10/15 13:35, Simo Sorce wrote: >>>>>>> On 06/10/15 03:51, thierry bordaz wrote: >>>>>>>> On 10/06/2015 07:19 AM, David Kupka wrote: >>>>>>>>> On 05/10/15 16:12, Simo Sorce wrote: >>>>>>>>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>>>>>>>> These patches implement the plumbing required to properly >>>>>>>>>>> support >>>>>>>>>>> canonicalization of Kerberos principals ( >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>>>>>>>> >>>>>>>>>>> Setting multiple principal aliases on hosts/services is beyond >>>>>>>>>>> the >>>>>>>>>>> scope >>>>>>>>>>> of this patchset and should be done after these patches are >>>>>>>>>>> pushed. >>>>>>>>>>> >>>>>>>>>>> I will try to send some tests for the patches later this week. >>>>>>>>>>> >>>>>>>>>>> Please review the hell out of them. >>>>>>>>>> >>>>>>>>>> LGTM, I do not see any issue at quick visual inspection. >>>>>>>>>> What about the performance regression with the indexes ? Is >>>>>>>>>> that bug >>>>>>>>>> fixed in 389ds ? >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> The issue is still there. Thierry investigated this in 389 DS >>>>>>>>> and IIUC >>>>>>>>> he is not sure if it's bug or completely missing feature. >>>>>>>>> Therefore we >>>>>>>>> still don't know how much time is needed there. >>>>>>>>> >>>>>>>> Hi, >>>>>>>> that is correct. >>>>>>>> I can reproduce the problem. Although the matching rule (in my >>>>>>>> test >>>>>>>> caseIgnoreIA5Match) is found, it has no registered indexing >>>>>>>> function, so >>>>>>>> the setting (nsMatchingRule) is ignored. >>>>>>>> I do not know if the indexing function is missing or there is a >>>>>>>> bug so >>>>>>>> that the matching rule "forget" to register it. >>>>>>>> This feature is documented but I can not find any QA test around >>>>>>>> it, so >>>>>>>> I do not know yet if it is a regression or if it was not enabled >>>>>>>> at all. >>>>>>>> >>>>>>>> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >>>>>>>> For the moment I can think to only two workarounds: >>>>>>>> >>>>>>>> * use filtered matching rule (preferred) >>>>>>>> * change the attribute syntax/matching rule, in the schema (I >>>>>>>> would >>>>>>>> discourage this one because changing the schema is risky) >>>>>>> >>>>>>> We can't change the syntax at this point. >>>>>>> >>>>>>> Well this patchset is blocked until the 389 ds bug is fixed (the >>>>>>> performance regression is too big to just put it in and hope) so I >>>>>>> guess >>>>>>> we'll have to negotiate a time for the fix. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> I agree that we really shouldn't change schema. >>>>>> >>>>>> But I don't think the patches're necessary blocked by this issue. >>>>>> Canonicalization was never supported in FreeIPA and when it is not >>>>>> requested the performance is not effected at all. We could merge >>>>>> patches >>>>>> as soon as they're carefully reviewed and tested to avoid tedious >>>>>> rebasing and start using the new functionality when 389 DS gets >>>>>> fixed. >>>>> >>>>> The fact we didn't do canonicalization this way doesn't mean clients >>>>> aren't >>>>> asking for it. >>>>> >>>>> I think Windows clients ask for canonicalization by default, and in >>>>> SSSD I >>>>> see we turn on by default krb5_canonicalize in the IPA nd LDAP case >>>>> (oddly >>>>> enough not in the AD case ?) >>>>> >>>>> So SSSD's authentication requests would end up hitting this case all >>>>> the >>>>> time if I am reading the code correctly (CCed Jakub to >>>>> confirm/dispel this). >>>> >>>> We ask for canonicalization always in IPA and LDAP, but also whenever >>>> enterprise principals are used, which is true for AD provider. >>>> >>> >>> Then SSSD will hit this every time it requests ticket on behalf of >>> user. >>> But to be sure what the impact would be I've once again set up FreeIPA >>> server with 10K users and run some tests. >>> >>> 1) 3 LDAP searches (caseIgnoreIA5Match, caseExactIA5Match, without >>> specifying the matching rule). >>> Results (http://fpaste.org/275847/44221770/raw/) shows that unindexed >>> search takes ~100 times longer than indexed. >>> >>> 2) kinit with and without requested canonicalization. >>> >>> As we use kinit to get the ticket it makes sense to check what will >>> the performance hit be when we run kinit as a whole and not just an >>> isolated LDAP search. >>> The results (http://fpaste.org/275848/21793144/raw/) shows that with >>> canonicalization it takes ~2 times longer than without it. >>> While this is nothing to be happy about it's certainly better than I >>> would expect. >>> >> Clearly we need to make the search indexed. >> In your deployment you defined: >> >> dn: uid=user1000098,cn=users,cn=accounts,dc=example,dc=test >> uid: user1000098 >> givenName: Test >> sn: User1000098 >> cn: Test User1000098 >> initials: TU >> homeDirectory: /home/user1000098 >> gecos: Test User1000098 >> loginShell: /bin/sh >> mail: user1000098 at example.test >> uidNumber: 7611001000098 >> gidNumber: 7611001000098 >> displayName: Test User1000098 >> *krbPrincipalName: user1000098 at EXAMPLE.TEST* >> *krbCanonicalName: user1000098 at EXAMPLE.TEST* >> memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test >> objectClass: ipaobject >> objectClass: person >> objectClass: top >> objectClass: ipasshuser >> objectClass: inetorgperson >> objectClass: organizationalperson >> objectClass: krbticketpolicyaux >> objectClass: krbprincipalaux >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: ipaSshGroupOfPubKeys >> objectClass: mepOriginEntry >> ipaUniqueID: 6048c4ac-6cdd-11e5-a0af-080027987dcb >> mepManagedEntry: >> cn=user1000098,cn=groups,cn=accounts,dc=example,dc=test >> >> Would it be an option to create a new attribute, 'krbNonCanonicalName' >> (containing the krbprincipal) but with a 'caseignoreIA5' syntax ? >> If this attribute is indexed, your lookup from a raw principal would >> user "(krbNonCanonicalname=user10000098 at EXAMPLE.TEST)" > > It is not an option, no changing attributes, no changing syntaxes, if > DS can't be fixed we'll need to adopt a completely different strategy > we discussed already previously. > However it would be much nicer if we could fix DS to allow to create > (and use) indexes for matching rules that are not defined in the schema. Ok I understand... and agree. Let's investigate what's need to be done in DS :-) > > Simo. > From edewata at redhat.com Wed Oct 7 21:20:14 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 7 Oct 2015 16:20:14 -0500 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56128A57.3070806@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <560D4438.40401@redhat.com> <20151005121541.GA10207@redhat.com> <56127E42.4090306@redhat.com> <56127F62.8090705@redhat.com> <56128A57.3070806@redhat.com> Message-ID: <56158C8E.9000209@redhat.com> On 10/5/2015 9:33 AM, Endi Sukma Dewata wrote: > On 10/5/2015 8:47 AM, Simo Sorce wrote: >>> 2. The second attempt after re-enrolling client resulted in the error of >>> CA installation: >>> >> This is due to the known bug with authentication in Dogtag. Endy fixed >> it upstream. >> >> Endy, >> do you know when the bug will be released in a package we can use for >> testing ? > > Here is the bug: https://fedorahosted.org/pki/ticket/1580 > > I don't think we're ready for a Dogtag 10.3 build, so we may need to > cherry-pick it to 10.2.x. I'll check with Matt. > The fix is now available in the following build: http://koji.fedoraproject.org/koji/buildinfo?buildID=689985 Please also provide a feedback: https://bodhi.fedoraproject.org/updates/FEDORA-2015-cea85c052a Thanks! -- Endi S. Dewata From ofayans at redhat.com Thu Oct 8 07:13:16 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 8 Oct 2015 09:13:16 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56152C9A.1050202@redhat.com> References: <56152885.7050201@redhat.com> <56152C9A.1050202@redhat.com> Message-ID: <5616178C.1000500@redhat.com> Hi Martin On 10/07/2015 04:30 PM, Martin Basti wrote: > > > On 10/07/2015 04:13 PM, Oleg Fayans wrote: >> subj >> >> >> > Workaround looks good, but I prefer not to push it in upstream tests, > because it is not test failure. I agree, we should rather fix the original issue. But as a temporary solution, to satisfy downstream, it could do. > > Why is there this sleep, this might be useful in upstream tests too, but > what is the reason to add sleep there? Without it I kept getting this error: E CalledProcessError: Command '['drill', '@localhost', '-k', '/etc/trusted-key.key', '-S', 'example.test.', 'SOA']' returned non-zero exit status 29 with --pdb option, though, my attempts to re-run the command succeeded, so I assumed it was a timing issue, and indeed, this 1 second sleep helped. > > # verify signatures > + time.sleep(1) > args = [ > > Attached is an updated version of the patch with Martin's remarks taken into account -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0009.1-Added-a-workaround-for-ticket-N-5348.patch Type: text/x-patch Size: 2166 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 8 08:37:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 10:37:26 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <5616178C.1000500@redhat.com> References: <56152885.7050201@redhat.com> <56152C9A.1050202@redhat.com> <5616178C.1000500@redhat.com> Message-ID: <56162B46.102@redhat.com> On 10/08/2015 09:13 AM, Oleg Fayans wrote: > Hi Martin > > On 10/07/2015 04:30 PM, Martin Basti wrote: >> >> >> On 10/07/2015 04:13 PM, Oleg Fayans wrote: >>> subj >>> >>> >>> >> Workaround looks good, but I prefer not to push it in upstream tests, >> because it is not test failure. > I agree, we should rather fix the original issue. But as a temporary > solution, to satisfy downstream, it could do. >> >> Why is there this sleep, this might be useful in upstream tests too, but >> what is the reason to add sleep there? > > Without it I kept getting this error: > E CalledProcessError: Command '['drill', '@localhost', '-k', > '/etc/trusted-key.key', '-S', 'example.test.', 'SOA']' returned > non-zero exit status 29 > > with --pdb option, though, my attempts to re-run the command > succeeded, so I assumed it was a timing issue, and indeed, this 1 > second sleep helped. > >> >> # verify signatures >> + time.sleep(1) >> args = [ >> >> > > Attached is an updated version of the patch with Martin's remarks > taken into account > Can you please send this as separate patch? I would like to push this one. From jpazdziora at redhat.com Thu Oct 8 08:44:41 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 8 Oct 2015 10:44:41 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56152885.7050201@redhat.com> References: <56152885.7050201@redhat.com> Message-ID: <20151008084441.GA29919@redhat.com> On Wed, Oct 07, 2015 at 04:13:25PM +0200, Oleg Fayans wrote: > subj > > -- > Oleg Fayans > Quality Engineer > FreeIPA team > RedHat. > From 7ab1afe5e9a8f6b28be2d5b92423eccec61248a0 Mon Sep 17 00:00:00 2001 > From: Oleg Fayans > Date: Wed, 7 Oct 2015 16:08:30 +0200 > Subject: [PATCH] Added a workaround for ticket N 5348 > > After creating signed root zone, the server requires named.service restart for dig > requests to this zone to start displaying the key. > --- > ipatests/test_integration/test_dnssec.py | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/ipatests/test_integration/test_dnssec.py b/ipatests/test_integration/test_dnssec.py > index 098b227f6543fa221ed6c75d1e98e9f056761977..b63c6ce4795c53c5c2dd604783c321835d8a689b 100644 > --- a/ipatests/test_integration/test_dnssec.py > +++ b/ipatests/test_integration/test_dnssec.py > @@ -280,7 +280,10 @@ class TestInstallDNSSECFirst(IntegrationTest): > "--ns-rec=" + self.master.hostname > ] > self.master.run_command(args) > - > + # A workaround for ticket N 5348 > + time.sleep(20) > + self.master.run_command(["systemctl", "restart", "named-pkcs11.service"]) When the ticket is addressed and these workarounds are no longer needed -- what is our process for finding these workarounds and reverting them, so that the tests test the real, expected behaviour? Also, instead of blind sleeps, wouldn't it be better to have some polling for status of the services we are waiting for? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From dkupka at redhat.com Thu Oct 8 09:03:57 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 8 Oct 2015 11:03:57 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <56153AF4.9040607@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> <5613BF5D.4040500@redhat.com> <20151006155237.GJ3048@hendrix> <561519B8.1010206@redhat.com> <561534EC.90506@redhat.com> <56153A6B.1020902@redhat.com> <56153AF4.9040607@redhat.com> Message-ID: <5616317D.7090504@redhat.com> On 07/10/15 17:32, thierry bordaz wrote: > On 10/07/2015 05:29 PM, Simo Sorce wrote: >> On 07/10/15 11:06, thierry bordaz wrote: >>> On 10/07/2015 03:10 PM, David Kupka wrote: >>>> On 06/10/15 17:52, Jakub Hrozek wrote: >>>>> On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: >>>>>> On 06/10/15 08:04, David Kupka wrote: >>>>>>> On 06/10/15 13:35, Simo Sorce wrote: >>>>>>>> On 06/10/15 03:51, thierry bordaz wrote: >>>>>>>>> On 10/06/2015 07:19 AM, David Kupka wrote: >>>>>>>>>> On 05/10/15 16:12, Simo Sorce wrote: >>>>>>>>>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>>>>>>>>> These patches implement the plumbing required to properly >>>>>>>>>>>> support >>>>>>>>>>>> canonicalization of Kerberos principals ( >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>>>>>>>>> >>>>>>>>>>>> Setting multiple principal aliases on hosts/services is beyond >>>>>>>>>>>> the >>>>>>>>>>>> scope >>>>>>>>>>>> of this patchset and should be done after these patches are >>>>>>>>>>>> pushed. >>>>>>>>>>>> >>>>>>>>>>>> I will try to send some tests for the patches later this week. >>>>>>>>>>>> >>>>>>>>>>>> Please review the hell out of them. >>>>>>>>>>> >>>>>>>>>>> LGTM, I do not see any issue at quick visual inspection. >>>>>>>>>>> What about the performance regression with the indexes ? Is >>>>>>>>>>> that bug >>>>>>>>>>> fixed in 389ds ? >>>>>>>>>>> >>>>>>>>>>> Simo. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The issue is still there. Thierry investigated this in 389 DS >>>>>>>>>> and IIUC >>>>>>>>>> he is not sure if it's bug or completely missing feature. >>>>>>>>>> Therefore we >>>>>>>>>> still don't know how much time is needed there. >>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> that is correct. >>>>>>>>> I can reproduce the problem. Although the matching rule (in my >>>>>>>>> test >>>>>>>>> caseIgnoreIA5Match) is found, it has no registered indexing >>>>>>>>> function, so >>>>>>>>> the setting (nsMatchingRule) is ignored. >>>>>>>>> I do not know if the indexing function is missing or there is a >>>>>>>>> bug so >>>>>>>>> that the matching rule "forget" to register it. >>>>>>>>> This feature is documented but I can not find any QA test around >>>>>>>>> it, so >>>>>>>>> I do not know yet if it is a regression or if it was not enabled >>>>>>>>> at all. >>>>>>>>> >>>>>>>>> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >>>>>>>>> For the moment I can think to only two workarounds: >>>>>>>>> >>>>>>>>> * use filtered matching rule (preferred) >>>>>>>>> * change the attribute syntax/matching rule, in the schema (I >>>>>>>>> would >>>>>>>>> discourage this one because changing the schema is risky) >>>>>>>> >>>>>>>> We can't change the syntax at this point. >>>>>>>> >>>>>>>> Well this patchset is blocked until the 389 ds bug is fixed (the >>>>>>>> performance regression is too big to just put it in and hope) so I >>>>>>>> guess >>>>>>>> we'll have to negotiate a time for the fix. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> I agree that we really shouldn't change schema. >>>>>>> >>>>>>> But I don't think the patches're necessary blocked by this issue. >>>>>>> Canonicalization was never supported in FreeIPA and when it is not >>>>>>> requested the performance is not effected at all. We could merge >>>>>>> patches >>>>>>> as soon as they're carefully reviewed and tested to avoid tedious >>>>>>> rebasing and start using the new functionality when 389 DS gets >>>>>>> fixed. >>>>>> >>>>>> The fact we didn't do canonicalization this way doesn't mean clients >>>>>> aren't >>>>>> asking for it. >>>>>> >>>>>> I think Windows clients ask for canonicalization by default, and in >>>>>> SSSD I >>>>>> see we turn on by default krb5_canonicalize in the IPA nd LDAP case >>>>>> (oddly >>>>>> enough not in the AD case ?) >>>>>> >>>>>> So SSSD's authentication requests would end up hitting this case all >>>>>> the >>>>>> time if I am reading the code correctly (CCed Jakub to >>>>>> confirm/dispel this). >>>>> >>>>> We ask for canonicalization always in IPA and LDAP, but also whenever >>>>> enterprise principals are used, which is true for AD provider. >>>>> >>>> >>>> Then SSSD will hit this every time it requests ticket on behalf of >>>> user. >>>> But to be sure what the impact would be I've once again set up FreeIPA >>>> server with 10K users and run some tests. >>>> >>>> 1) 3 LDAP searches (caseIgnoreIA5Match, caseExactIA5Match, without >>>> specifying the matching rule). >>>> Results (http://fpaste.org/275847/44221770/raw/) shows that unindexed >>>> search takes ~100 times longer than indexed. >>>> >>>> 2) kinit with and without requested canonicalization. >>>> >>>> As we use kinit to get the ticket it makes sense to check what will >>>> the performance hit be when we run kinit as a whole and not just an >>>> isolated LDAP search. >>>> The results (http://fpaste.org/275848/21793144/raw/) shows that with >>>> canonicalization it takes ~2 times longer than without it. >>>> While this is nothing to be happy about it's certainly better than I >>>> would expect. >>>> >>> Clearly we need to make the search indexed. >>> In your deployment you defined: >>> >>> dn: uid=user1000098,cn=users,cn=accounts,dc=example,dc=test >>> uid: user1000098 >>> givenName: Test >>> sn: User1000098 >>> cn: Test User1000098 >>> initials: TU >>> homeDirectory: /home/user1000098 >>> gecos: Test User1000098 >>> loginShell: /bin/sh >>> mail: user1000098 at example.test >>> uidNumber: 7611001000098 >>> gidNumber: 7611001000098 >>> displayName: Test User1000098 >>> *krbPrincipalName: user1000098 at EXAMPLE.TEST* >>> *krbCanonicalName: user1000098 at EXAMPLE.TEST* >>> memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test >>> objectClass: ipaobject >>> objectClass: person >>> objectClass: top >>> objectClass: ipasshuser >>> objectClass: inetorgperson >>> objectClass: organizationalperson >>> objectClass: krbticketpolicyaux >>> objectClass: krbprincipalaux >>> objectClass: inetuser >>> objectClass: posixaccount >>> objectClass: ipaSshGroupOfPubKeys >>> objectClass: mepOriginEntry >>> ipaUniqueID: 6048c4ac-6cdd-11e5-a0af-080027987dcb >>> mepManagedEntry: >>> cn=user1000098,cn=groups,cn=accounts,dc=example,dc=test >>> >>> Would it be an option to create a new attribute, 'krbNonCanonicalName' >>> (containing the krbprincipal) but with a 'caseignoreIA5' syntax ? >>> If this attribute is indexed, your lookup from a raw principal would >>> user "(krbNonCanonicalname=user10000098 at EXAMPLE.TEST)" >> >> It is not an option, no changing attributes, no changing syntaxes, if >> DS can't be fixed we'll need to adopt a completely different strategy >> we discussed already previously. >> However it would be much nicer if we could fix DS to allow to create >> (and use) indexes for matching rules that are not defined in the schema. > Ok I understand... and agree. Let's investigate what's need to be done > in DS :-) >> >> Simo. >> > Thierry is focused mainly on integration of 389 DS and FreeIPA. Since this is a general 389 DS issue and it is not related specifically to FreeIPA could we ask 389 DS upstream for a fix? In general extensible matching never uses indices. I believe this is severe enough to be considered major issue by upstream. -- David Kupka From ofayans at redhat.com Thu Oct 8 09:12:37 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 8 Oct 2015 11:12:37 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <20151008084441.GA29919@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> Message-ID: <56163385.7090100@redhat.com> Hi Jan, On 10/08/2015 10:44 AM, Jan Pazdziora wrote: > On Wed, Oct 07, 2015 at 04:13:25PM +0200, Oleg Fayans wrote: >> subj >> >> -- >> Oleg Fayans >> Quality Engineer >> FreeIPA team >> RedHat. > >> From 7ab1afe5e9a8f6b28be2d5b92423eccec61248a0 Mon Sep 17 00:00:00 2001 >> From: Oleg Fayans >> Date: Wed, 7 Oct 2015 16:08:30 +0200 >> Subject: [PATCH] Added a workaround for ticket N 5348 >> >> After creating signed root zone, the server requires named.service restart for dig >> requests to this zone to start displaying the key. >> --- >> ipatests/test_integration/test_dnssec.py | 12 +++++++++--- >> 1 file changed, 9 insertions(+), 3 deletions(-) >> >> diff --git a/ipatests/test_integration/test_dnssec.py b/ipatests/test_integration/test_dnssec.py >> index 098b227f6543fa221ed6c75d1e98e9f056761977..b63c6ce4795c53c5c2dd604783c321835d8a689b 100644 >> --- a/ipatests/test_integration/test_dnssec.py >> +++ b/ipatests/test_integration/test_dnssec.py >> @@ -280,7 +280,10 @@ class TestInstallDNSSECFirst(IntegrationTest): >> "--ns-rec=" + self.master.hostname >> ] >> self.master.run_command(args) >> - >> + # A workaround for ticket N 5348 >> + time.sleep(20) >> + self.master.run_command(["systemctl", "restart", "named-pkcs11.service"]) > > When the ticket is addressed and these workarounds are no longer > needed -- what is our process for finding these workarounds and > reverting them, so that the tests test the real, expected behaviour? As per discussion with Martin Basti, it was decided that this workaround will only be applied to the current 4-2 branch, not to the upstream. In upstream the issue itself will (supposedly) be solved > > Also, instead of blind sleeps, wouldn't it be better to have some > polling for status of the services we are waiting for? Since we still do not know what exactly causes the issue, it is really hard to figure out what is it that we should be polling. Otherwise I am really anti-blind-sleeps myself. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From tbordaz at redhat.com Thu Oct 8 09:11:48 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 08 Oct 2015 11:11:48 +0200 Subject: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization In-Reply-To: <5616317D.7090504@redhat.com> References: <5612745A.2090805@redhat.com> <56128539.7070304@redhat.com> <561359CF.7060909@redhat.com> <56137D8C.3090401@redhat.com> <5613B1E7.9060007@redhat.com> <5613B8E8.3030006@redhat.com> <5613BF5D.4040500@redhat.com> <20151006155237.GJ3048@hendrix> <561519B8.1010206@redhat.com> <561534EC.90506@redhat.com> <56153A6B.1020902@redhat.com> <56153AF4.9040607@redhat.com> <5616317D.7090504@redhat.com> Message-ID: <56163354.1030806@redhat.com> On 10/08/2015 11:03 AM, David Kupka wrote: > On 07/10/15 17:32, thierry bordaz wrote: >> On 10/07/2015 05:29 PM, Simo Sorce wrote: >>> On 07/10/15 11:06, thierry bordaz wrote: >>>> On 10/07/2015 03:10 PM, David Kupka wrote: >>>>> On 06/10/15 17:52, Jakub Hrozek wrote: >>>>>> On Tue, Oct 06, 2015 at 08:32:29AM -0400, Simo Sorce wrote: >>>>>>> On 06/10/15 08:04, David Kupka wrote: >>>>>>>> On 06/10/15 13:35, Simo Sorce wrote: >>>>>>>>> On 06/10/15 03:51, thierry bordaz wrote: >>>>>>>>>> On 10/06/2015 07:19 AM, David Kupka wrote: >>>>>>>>>>> On 05/10/15 16:12, Simo Sorce wrote: >>>>>>>>>>>> On 05/10/15 09:00, Martin Babinsky wrote: >>>>>>>>>>>>> These patches implement the plumbing required to properly >>>>>>>>>>>>> support >>>>>>>>>>>>> canonicalization of Kerberos principals ( >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3864). >>>>>>>>>>>>> >>>>>>>>>>>>> Setting multiple principal aliases on hosts/services is >>>>>>>>>>>>> beyond >>>>>>>>>>>>> the >>>>>>>>>>>>> scope >>>>>>>>>>>>> of this patchset and should be done after these patches are >>>>>>>>>>>>> pushed. >>>>>>>>>>>>> >>>>>>>>>>>>> I will try to send some tests for the patches later this >>>>>>>>>>>>> week. >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the hell out of them. >>>>>>>>>>>> >>>>>>>>>>>> LGTM, I do not see any issue at quick visual inspection. >>>>>>>>>>>> What about the performance regression with the indexes ? Is >>>>>>>>>>>> that bug >>>>>>>>>>>> fixed in 389ds ? >>>>>>>>>>>> >>>>>>>>>>>> Simo. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The issue is still there. Thierry investigated this in 389 DS >>>>>>>>>>> and IIUC >>>>>>>>>>> he is not sure if it's bug or completely missing feature. >>>>>>>>>>> Therefore we >>>>>>>>>>> still don't know how much time is needed there. >>>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> that is correct. >>>>>>>>>> I can reproduce the problem. Although the matching rule (in my >>>>>>>>>> test >>>>>>>>>> caseIgnoreIA5Match) is found, it has no registered indexing >>>>>>>>>> function, so >>>>>>>>>> the setting (nsMatchingRule) is ignored. >>>>>>>>>> I do not know if the indexing function is missing or there is a >>>>>>>>>> bug so >>>>>>>>>> that the matching rule "forget" to register it. >>>>>>>>>> This feature is documented but I can not find any QA test around >>>>>>>>>> it, so >>>>>>>>>> I do not know yet if it is a regression or if it was not enabled >>>>>>>>>> at all. >>>>>>>>>> >>>>>>>>>> I do not expect rapid progress on it. How urgent is it ? 7.3 ? >>>>>>>>>> For the moment I can think to only two workarounds: >>>>>>>>>> >>>>>>>>>> * use filtered matching rule (preferred) >>>>>>>>>> * change the attribute syntax/matching rule, in the schema (I >>>>>>>>>> would >>>>>>>>>> discourage this one because changing the schema is risky) >>>>>>>>> >>>>>>>>> We can't change the syntax at this point. >>>>>>>>> >>>>>>>>> Well this patchset is blocked until the 389 ds bug is fixed (the >>>>>>>>> performance regression is too big to just put it in and hope) >>>>>>>>> so I >>>>>>>>> guess >>>>>>>>> we'll have to negotiate a time for the fix. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>>> >>>>>>>> >>>>>>>> I agree that we really shouldn't change schema. >>>>>>>> >>>>>>>> But I don't think the patches're necessary blocked by this issue. >>>>>>>> Canonicalization was never supported in FreeIPA and when it is not >>>>>>>> requested the performance is not effected at all. We could merge >>>>>>>> patches >>>>>>>> as soon as they're carefully reviewed and tested to avoid tedious >>>>>>>> rebasing and start using the new functionality when 389 DS gets >>>>>>>> fixed. >>>>>>> >>>>>>> The fact we didn't do canonicalization this way doesn't mean >>>>>>> clients >>>>>>> aren't >>>>>>> asking for it. >>>>>>> >>>>>>> I think Windows clients ask for canonicalization by default, and in >>>>>>> SSSD I >>>>>>> see we turn on by default krb5_canonicalize in the IPA nd LDAP case >>>>>>> (oddly >>>>>>> enough not in the AD case ?) >>>>>>> >>>>>>> So SSSD's authentication requests would end up hitting this case >>>>>>> all >>>>>>> the >>>>>>> time if I am reading the code correctly (CCed Jakub to >>>>>>> confirm/dispel this). >>>>>> >>>>>> We ask for canonicalization always in IPA and LDAP, but also >>>>>> whenever >>>>>> enterprise principals are used, which is true for AD provider. >>>>>> >>>>> >>>>> Then SSSD will hit this every time it requests ticket on behalf of >>>>> user. >>>>> But to be sure what the impact would be I've once again set up >>>>> FreeIPA >>>>> server with 10K users and run some tests. >>>>> >>>>> 1) 3 LDAP searches (caseIgnoreIA5Match, caseExactIA5Match, without >>>>> specifying the matching rule). >>>>> Results (http://fpaste.org/275847/44221770/raw/) shows that unindexed >>>>> search takes ~100 times longer than indexed. >>>>> >>>>> 2) kinit with and without requested canonicalization. >>>>> >>>>> As we use kinit to get the ticket it makes sense to check what will >>>>> the performance hit be when we run kinit as a whole and not just an >>>>> isolated LDAP search. >>>>> The results (http://fpaste.org/275848/21793144/raw/) shows that with >>>>> canonicalization it takes ~2 times longer than without it. >>>>> While this is nothing to be happy about it's certainly better than I >>>>> would expect. >>>>> >>>> Clearly we need to make the search indexed. >>>> In your deployment you defined: >>>> >>>> dn: uid=user1000098,cn=users,cn=accounts,dc=example,dc=test >>>> uid: user1000098 >>>> givenName: Test >>>> sn: User1000098 >>>> cn: Test User1000098 >>>> initials: TU >>>> homeDirectory: /home/user1000098 >>>> gecos: Test User1000098 >>>> loginShell: /bin/sh >>>> mail: user1000098 at example.test >>>> uidNumber: 7611001000098 >>>> gidNumber: 7611001000098 >>>> displayName: Test User1000098 >>>> *krbPrincipalName: user1000098 at EXAMPLE.TEST* >>>> *krbCanonicalName: user1000098 at EXAMPLE.TEST* >>>> memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test >>>> objectClass: ipaobject >>>> objectClass: person >>>> objectClass: top >>>> objectClass: ipasshuser >>>> objectClass: inetorgperson >>>> objectClass: organizationalperson >>>> objectClass: krbticketpolicyaux >>>> objectClass: krbprincipalaux >>>> objectClass: inetuser >>>> objectClass: posixaccount >>>> objectClass: ipaSshGroupOfPubKeys >>>> objectClass: mepOriginEntry >>>> ipaUniqueID: 6048c4ac-6cdd-11e5-a0af-080027987dcb >>>> mepManagedEntry: >>>> cn=user1000098,cn=groups,cn=accounts,dc=example,dc=test >>>> >>>> Would it be an option to create a new attribute, 'krbNonCanonicalName' >>>> (containing the krbprincipal) but with a 'caseignoreIA5' syntax ? >>>> If this attribute is indexed, your lookup from a raw principal would >>>> user "(krbNonCanonicalname=user10000098 at EXAMPLE.TEST)" >>> >>> It is not an option, no changing attributes, no changing syntaxes, if >>> DS can't be fixed we'll need to adopt a completely different strategy >>> we discussed already previously. >>> However it would be much nicer if we could fix DS to allow to create >>> (and use) indexes for matching rules that are not defined in the >>> schema. >> Ok I understand... and agree. Let's investigate what's need to be done >> in DS :-) >>> >>> Simo. >>> >> > > Thierry is focused mainly on integration of 389 DS and FreeIPA. Since > this is a general 389 DS issue and it is not related specifically to > FreeIPA could we ask 389 DS upstream for a fix? > In general extensible matching never uses indices. I believe this is > severe enough to be considered major issue by upstream. Hello David, There is an upstream ticket tracking this issue (https://fedorahosted.org/389/ticket/48270). I started looking at it and discussing with DS team it requires more investigation to determine the amount of work to do. So far it is planned that I will continue this investigation and I expect to complete this evaluation next week. Now who will implement the fix, this is not decided yet. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Thu Oct 8 09:18:45 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 8 Oct 2015 11:18:45 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56163385.7090100@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> Message-ID: <20151008091845.GA32648@redhat.com> On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: > > > >When the ticket is addressed and these workarounds are no longer > >needed -- what is our process for finding these workarounds and > >reverting them, so that the tests test the real, expected behaviour? > > As per discussion with Martin Basti, it was decided that this workaround > will only be applied to the current 4-2 branch, not to the upstream. In That sounds like a reasonable plan for this issue. > upstream the issue itself will (supposedly) be solved Except currently it's not, so (IIUIC) you will keep having nondeterministic failures in master. I was mostly interested in the general approach that we have to workarounds -- how do we track them, how do we make sure they don't stick in tests forever, even after the issue was already properly addressed. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From ofayans at redhat.com Thu Oct 8 09:18:48 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 8 Oct 2015 11:18:48 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56162B46.102@redhat.com> References: <56152885.7050201@redhat.com> <56152C9A.1050202@redhat.com> <5616178C.1000500@redhat.com> <56162B46.102@redhat.com> Message-ID: <561634F8.5090801@redhat.com> Done On 10/08/2015 10:37 AM, Martin Basti wrote: > > > On 10/08/2015 09:13 AM, Oleg Fayans wrote: >> Hi Martin >> >> On 10/07/2015 04:30 PM, Martin Basti wrote: >>> >>> >>> On 10/07/2015 04:13 PM, Oleg Fayans wrote: >>>> subj >>>> >>>> >>>> >>> Workaround looks good, but I prefer not to push it in upstream tests, >>> because it is not test failure. >> I agree, we should rather fix the original issue. But as a temporary >> solution, to satisfy downstream, it could do. >>> >>> Why is there this sleep, this might be useful in upstream tests too, but >>> what is the reason to add sleep there? >> >> Without it I kept getting this error: >> E CalledProcessError: Command '['drill', '@localhost', '-k', >> '/etc/trusted-key.key', '-S', 'example.test.', 'SOA']' returned >> non-zero exit status 29 >> >> with --pdb option, though, my attempts to re-run the command >> succeeded, so I assumed it was a timing issue, and indeed, this 1 >> second sleep helped. >> >>> >>> # verify signatures >>> + time.sleep(1) >>> args = [ >>> >>> >> >> Attached is an updated version of the patch with Martin's remarks >> taken into account >> > Can you please send this as separate patch? I would like to push this one. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0010-Fixed-a-timing-issue-with-drill-returning-non-zero-e.patch Type: text/x-patch Size: 912 bytes Desc: not available URL: From abokovoy at redhat.com Thu Oct 8 10:36:23 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Oct 2015 13:36:23 +0300 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal In-Reply-To: <20151005152845.GC19585@p.redhat.com> References: <20150903144220.GO22106@redhat.com> <20150903152205.GP22106@redhat.com> <20151005152845.GC19585@p.redhat.com> Message-ID: <20151008103623.GH19089@redhat.com> On Mon, 05 Oct 2015, Sumit Bose wrote: >On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote: >> 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. > >The patch looks good and works as advertised. I've tested in a IPA >domain which trusts two different forests. All requests to the forest >roots and child domains where properly redirected. I tested with your >krb5 test build and with MIT Kerberos 1.14 which contains the needed >fix. > >Nevertheless there are a view points I want to discuss: > >- missing support for AD's Alternative Domain Suffixes, this is > important to allow AD users to login in with their "Email-Address" > (which is the typical reference for a user name with an alternative > domain suffix). I think this is not strictly related to the given > ticket, so it can be solved in the context of a new ticket, do you > agree? Yes, please add a separate ticket. We need to do a bit more here: - extend schema to allow adding the attribute for alternative domain suffixes - switch to use different DCE RPC call to retrieve forest trust information. We can do it now that we have a call-out mechanism and can isolate access to TDO credentials (this is long standing issue first identified by Metze as part of cross-forest trust support for Samba 4.3) - Make possible to associate alternative domain suffixes with IPA realm. We have support for realm domains already but we don't allow to use them yet for the same call as in the above item. >- referrals from outside. If I call 'kinit -E admin at IPA.DOMAIN' from a > client in a trusted AD forest I get a 'Client not found in database' > error because AD tends to use lower case domain names in the referal > response. The request is still properly send to the IPA KDC because > DNS does not care about the case. The IPA KDC processes the request > with the principal 'user\@IPA.DOMAIN at ipa.domain' until > ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue > it detects that the principal is from the local realm. I think it > would be good to enhance your patch to handle this case. This is a separate bug too. Please file a ticket. >- S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across > domain and forest boundaries (I tested this in a setup with 2 AD > forests with request going from a child domain to a child domain in > the other forest. Unfortunately it is currently not working with IPA > in neither direction (I guess the case issue from above might be the > reason for the incoming request to fail). Here I think a new ticket > would to good as well because some research might be needed and the > issue might even be in the MIT code. (If you want to run some tests I > can give you access to my test environment.) I think we want to have this working, thus a ticket is due here. This is something we'll most likely require for some advanced 2FA operations for AD users. >Let me know if you prefer to handle the issues with other tickets, then >I would ACK the patch as it is. Please file separate tickets. -- / Alexander Bokovoy From mbasti at redhat.com Thu Oct 8 11:12:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 13:12:56 +0200 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal In-Reply-To: <20151008103623.GH19089@redhat.com> References: <20150903144220.GO22106@redhat.com> <20150903152205.GP22106@redhat.com> <20151005152845.GC19585@p.redhat.com> <20151008103623.GH19089@redhat.com> Message-ID: <56164FB8.4010108@redhat.com> On 10/08/2015 12:36 PM, Alexander Bokovoy wrote: > On Mon, 05 Oct 2015, Sumit Bose wrote: >> On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote: >>> 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. >> >> The patch looks good and works as advertised. I've tested in a IPA >> domain which trusts two different forests. All requests to the forest >> roots and child domains where properly redirected. I tested with your >> krb5 test build and with MIT Kerberos 1.14 which contains the needed >> fix. >> >> Nevertheless there are a view points I want to discuss: >> >> - missing support for AD's Alternative Domain Suffixes, this is >> important to allow AD users to login in with their "Email-Address" >> (which is the typical reference for a user name with an alternative >> domain suffix). I think this is not strictly related to the given >> ticket, so it can be solved in the context of a new ticket, do you >> agree? > Yes, please add a separate ticket. We need to do a bit more here: > - extend schema to allow adding the attribute for alternative domain > suffixes > - switch to use different DCE RPC call to retrieve forest trust > information. We can do it now that we have a call-out mechanism and > can isolate access to TDO credentials (this is long standing issue > first identified by Metze as part of cross-forest trust support for > Samba 4.3) > - Make possible to associate alternative domain suffixes with IPA > realm. We have support for realm domains already but we don't allow > to use them yet for the same call as in the above item. > >> - referrals from outside. If I call 'kinit -E admin at IPA.DOMAIN' from a >> client in a trusted AD forest I get a 'Client not found in database' >> error because AD tends to use lower case domain names in the referal >> response. The request is still properly send to the IPA KDC because >> DNS does not care about the case. The IPA KDC processes the request >> with the principal 'user\@IPA.DOMAIN at ipa.domain' until >> ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue >> it detects that the principal is from the local realm. I think it >> would be good to enhance your patch to handle this case. > This is a separate bug too. Please file a ticket. > > >> - S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across >> domain and forest boundaries (I tested this in a setup with 2 AD >> forests with request going from a child domain to a child domain in >> the other forest. Unfortunately it is currently not working with IPA >> in neither direction (I guess the case issue from above might be the >> reason for the incoming request to fail). Here I think a new ticket >> would to good as well because some research might be needed and the >> issue might even be in the MIT code. (If you want to run some tests I >> can give you access to my test environment.) > I think we want to have this working, thus a ticket is due here. This is > something we'll most likely require for some advanced 2FA operations for > AD users. > >> Let me know if you prefer to handle the issues with other tickets, then >> I would ACK the patch as it is. > Please file separate tickets. > Summit, Alexander, is this patch ACKed or not? Martin From sbose at redhat.com Thu Oct 8 11:18:57 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 8 Oct 2015 13:18:57 +0200 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal In-Reply-To: <56164FB8.4010108@redhat.com> References: <20150903144220.GO22106@redhat.com> <20150903152205.GP22106@redhat.com> <20151005152845.GC19585@p.redhat.com> <20151008103623.GH19089@redhat.com> <56164FB8.4010108@redhat.com> Message-ID: <20151008111857.GO30474@p.redhat.com> On Thu, Oct 08, 2015 at 01:12:56PM +0200, Martin Basti wrote: > > > On 10/08/2015 12:36 PM, Alexander Bokovoy wrote: > >On Mon, 05 Oct 2015, Sumit Bose wrote: > >>On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote: > >>>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. > >> > >>The patch looks good and works as advertised. I've tested in a IPA > >>domain which trusts two different forests. All requests to the forest > >>roots and child domains where properly redirected. I tested with your > >>krb5 test build and with MIT Kerberos 1.14 which contains the needed > >>fix. > >> > >>Nevertheless there are a view points I want to discuss: > >> > >>- missing support for AD's Alternative Domain Suffixes, this is > >> important to allow AD users to login in with their "Email-Address" > >> (which is the typical reference for a user name with an alternative > >> domain suffix). I think this is not strictly related to the given > >> ticket, so it can be solved in the context of a new ticket, do you > >> agree? > >Yes, please add a separate ticket. We need to do a bit more here: > >- extend schema to allow adding the attribute for alternative domain > > suffixes > >- switch to use different DCE RPC call to retrieve forest trust > > information. We can do it now that we have a call-out mechanism and > > can isolate access to TDO credentials (this is long standing issue > > first identified by Metze as part of cross-forest trust support for > > Samba 4.3) > >- Make possible to associate alternative domain suffixes with IPA > > realm. We have support for realm domains already but we don't allow > > to use them yet for the same call as in the above item. > > > >>- referrals from outside. If I call 'kinit -E admin at IPA.DOMAIN' from a > >> client in a trusted AD forest I get a 'Client not found in database' > >> error because AD tends to use lower case domain names in the referal > >> response. The request is still properly send to the IPA KDC because > >> DNS does not care about the case. The IPA KDC processes the request > >> with the principal 'user\@IPA.DOMAIN at ipa.domain' until > >> ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue > >> it detects that the principal is from the local realm. I think it > >> would be good to enhance your patch to handle this case. > >This is a separate bug too. Please file a ticket. > > > > > >>- S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across > >> domain and forest boundaries (I tested this in a setup with 2 AD > >> forests with request going from a child domain to a child domain in > >> the other forest. Unfortunately it is currently not working with IPA > >> in neither direction (I guess the case issue from above might be the > >> reason for the incoming request to fail). Here I think a new ticket > >> would to good as well because some research might be needed and the > >> issue might even be in the MIT code. (If you want to run some tests I > >> can give you access to my test environment.) > >I think we want to have this working, thus a ticket is due here. This is > >something we'll most likely require for some advanced 2FA operations for > >AD users. > > > >>Let me know if you prefer to handle the issues with other tickets, then > >>I would ACK the patch as it is. > >Please file separate tickets. > > > > Summit, Alexander, is this patch ACKed or not? yes, ACK, I'll file the tickets mentioned above. bye, Sumit > > Martin From mbasti at redhat.com Thu Oct 8 11:53:15 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 13:53:15 +0200 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal In-Reply-To: <20151008111857.GO30474@p.redhat.com> References: <20150903144220.GO22106@redhat.com> <20150903152205.GP22106@redhat.com> <20151005152845.GC19585@p.redhat.com> <20151008103623.GH19089@redhat.com> <56164FB8.4010108@redhat.com> <20151008111857.GO30474@p.redhat.com> Message-ID: <5616592B.5060504@redhat.com> On 10/08/2015 01:18 PM, Sumit Bose wrote: > On Thu, Oct 08, 2015 at 01:12:56PM +0200, Martin Basti wrote: >> >> On 10/08/2015 12:36 PM, Alexander Bokovoy wrote: >>> On Mon, 05 Oct 2015, Sumit Bose wrote: >>>> On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote: >>>>> 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. >>>> The patch looks good and works as advertised. I've tested in a IPA >>>> domain which trusts two different forests. All requests to the forest >>>> roots and child domains where properly redirected. I tested with your >>>> krb5 test build and with MIT Kerberos 1.14 which contains the needed >>>> fix. >>>> >>>> Nevertheless there are a view points I want to discuss: >>>> >>>> - missing support for AD's Alternative Domain Suffixes, this is >>>> important to allow AD users to login in with their "Email-Address" >>>> (which is the typical reference for a user name with an alternative >>>> domain suffix). I think this is not strictly related to the given >>>> ticket, so it can be solved in the context of a new ticket, do you >>>> agree? >>> Yes, please add a separate ticket. We need to do a bit more here: >>> - extend schema to allow adding the attribute for alternative domain >>> suffixes >>> - switch to use different DCE RPC call to retrieve forest trust >>> information. We can do it now that we have a call-out mechanism and >>> can isolate access to TDO credentials (this is long standing issue >>> first identified by Metze as part of cross-forest trust support for >>> Samba 4.3) >>> - Make possible to associate alternative domain suffixes with IPA >>> realm. We have support for realm domains already but we don't allow >>> to use them yet for the same call as in the above item. >>> >>>> - referrals from outside. If I call 'kinit -E admin at IPA.DOMAIN' from a >>>> client in a trusted AD forest I get a 'Client not found in database' >>>> error because AD tends to use lower case domain names in the referal >>>> response. The request is still properly send to the IPA KDC because >>>> DNS does not care about the case. The IPA KDC processes the request >>>> with the principal 'user\@IPA.DOMAIN at ipa.domain' until >>>> ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue >>>> it detects that the principal is from the local realm. I think it >>>> would be good to enhance your patch to handle this case. >>> This is a separate bug too. Please file a ticket. >>> >>> >>>> - S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across >>>> domain and forest boundaries (I tested this in a setup with 2 AD >>>> forests with request going from a child domain to a child domain in >>>> the other forest. Unfortunately it is currently not working with IPA >>>> in neither direction (I guess the case issue from above might be the >>>> reason for the incoming request to fail). Here I think a new ticket >>>> would to good as well because some research might be needed and the >>>> issue might even be in the MIT code. (If you want to run some tests I >>>> can give you access to my test environment.) >>> I think we want to have this working, thus a ticket is due here. This is >>> something we'll most likely require for some advanced 2FA operations for >>> AD users. >>> >>>> Let me know if you prefer to handle the issues with other tickets, then >>>> I would ACK the patch as it is. >>> Please file separate tickets. >>> >> Summit, Alexander, is this patch ACKed or not? > yes, ACK, I'll file the tickets mentioned above. > > bye, > Sumit > >> Martin Pushed to: master: 766438aba018037cffadadaf11eb92024be4fe01 ipa-4-2: 47a8d4fdf177cf6f4a061cdd24f66ac8153b3fcb From mbasti at redhat.com Thu Oct 8 12:06:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 14:06:56 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <20151008091845.GA32648@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> Message-ID: <56165C60.2030406@redhat.com> On 10/08/2015 11:18 AM, Jan Pazdziora wrote: > On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>> When the ticket is addressed and these workarounds are no longer >>> needed -- what is our process for finding these workarounds and >>> reverting them, so that the tests test the real, expected behaviour? >> As per discussion with Martin Basti, it was decided that this workaround >> will only be applied to the current 4-2 branch, not to the upstream. In > That sounds like a reasonable plan for this issue. > >> upstream the issue itself will (supposedly) be solved > Except currently it's not, so (IIUIC) you will keep having > nondeterministic failures in master. > > I was mostly interested in the general approach that we have to > workarounds -- how do we track them, how do we make sure they don't > stick in tests forever, even after the issue was already properly > addressed. > I'm not sure if there is a formal process how to work with workarounds. Usually, we open ticket, push workaround there, and leave ticket opened until the issue is fixed. If there is no time to do proper fix and workaround works well we close ticket and open new ticket in further milestones. I do not remember if we have a similar issue with test workaround in past. Martin From ofayans at redhat.com Thu Oct 8 12:08:01 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 8 Oct 2015 14:08:01 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <20151008091845.GA32648@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> Message-ID: <56165CA1.3010701@redhat.com> Hi, On 10/08/2015 11:18 AM, Jan Pazdziora wrote: > On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>> >>> When the ticket is addressed and these workarounds are no longer >>> needed -- what is our process for finding these workarounds and >>> reverting them, so that the tests test the real, expected behaviour? >> >> As per discussion with Martin Basti, it was decided that this workaround >> will only be applied to the current 4-2 branch, not to the upstream. In > > That sounds like a reasonable plan for this issue. > >> upstream the issue itself will (supposedly) be solved > > Except currently it's not, so (IIUIC) you will keep having > nondeterministic failures in master. > > I was mostly interested in the general approach that we have to > workarounds -- how do we track them, how do we make sure they don't > stick in tests forever, even after the issue was already properly > addressed. > That's actually a great point. I personally would like tickets to have one more field: "workaround" containing the address of a workaround in the format "path_to_the_file:line_number" or better even - a commit id of this workaround, so that once the ticket is resolved, we could easily find what to reverse. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mkosek at redhat.com Thu Oct 8 12:39:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 8 Oct 2015 14:39:44 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56165CA1.3010701@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> Message-ID: <56166410.5020407@redhat.com> On 10/08/2015 02:08 PM, Oleg Fayans wrote: > Hi, > > On 10/08/2015 11:18 AM, Jan Pazdziora wrote: >> On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>>> >>>> When the ticket is addressed and these workarounds are no longer >>>> needed -- what is our process for finding these workarounds and >>>> reverting them, so that the tests test the real, expected behaviour? >>> >>> As per discussion with Martin Basti, it was decided that this workaround >>> will only be applied to the current 4-2 branch, not to the upstream. In >> >> That sounds like a reasonable plan for this issue. >> >>> upstream the issue itself will (supposedly) be solved >> >> Except currently it's not, so (IIUIC) you will keep having >> nondeterministic failures in master. >> >> I was mostly interested in the general approach that we have to >> workarounds -- how do we track them, how do we make sure they don't >> stick in tests forever, even after the issue was already properly >> addressed. >> > That's actually a great point. I personally would like tickets to have one more > field: "workaround" containing the address of a workaround in the format > "path_to_the_file:line_number" or better even - a commit id of this workaround, > so that once the ticket is resolved, we could easily find what to reverse. > Please don't add any more trac fields, there is too many of them already :-) Keyword may serve better for now... From mkosek at redhat.com Thu Oct 8 12:41:10 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 8 Oct 2015 14:41:10 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56165C60.2030406@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165C60.2030406@redhat.com> Message-ID: <56166466.7040903@redhat.com> On 10/08/2015 02:06 PM, Martin Basti wrote: > > > On 10/08/2015 11:18 AM, Jan Pazdziora wrote: >> On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>>> When the ticket is addressed and these workarounds are no longer >>>> needed -- what is our process for finding these workarounds and >>>> reverting them, so that the tests test the real, expected behaviour? >>> As per discussion with Martin Basti, it was decided that this workaround >>> will only be applied to the current 4-2 branch, not to the upstream. In >> That sounds like a reasonable plan for this issue. >> >>> upstream the issue itself will (supposedly) be solved >> Except currently it's not, so (IIUIC) you will keep having >> nondeterministic failures in master. >> >> I was mostly interested in the general approach that we have to >> workarounds -- how do we track them, how do we make sure they don't >> stick in tests forever, even after the issue was already properly >> addressed. >> > I'm not sure if there is a formal process how to work with workarounds. > > Usually, we open ticket, push workaround there, and leave ticket opened until > the issue is fixed. > If there is no time to do proper fix and workaround works well we close ticket > and open new ticket in further milestones. > > I do not remember if we have a similar issue with test workaround in past. Can we anyhow utilize "wait_for_dns" knob we added for making DNS tests reliable? From mbasti at redhat.com Thu Oct 8 12:48:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 14:48:19 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56166466.7040903@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165C60.2030406@redhat.com> <56166466.7040903@redhat.com> Message-ID: <56166613.4070003@redhat.com> On 10/08/2015 02:41 PM, Martin Kosek wrote: > On 10/08/2015 02:06 PM, Martin Basti wrote: >> >> On 10/08/2015 11:18 AM, Jan Pazdziora wrote: >>> On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>>>> When the ticket is addressed and these workarounds are no longer >>>>> needed -- what is our process for finding these workarounds and >>>>> reverting them, so that the tests test the real, expected behaviour? >>>> As per discussion with Martin Basti, it was decided that this workaround >>>> will only be applied to the current 4-2 branch, not to the upstream. In >>> That sounds like a reasonable plan for this issue. >>> >>>> upstream the issue itself will (supposedly) be solved >>> Except currently it's not, so (IIUIC) you will keep having >>> nondeterministic failures in master. >>> >>> I was mostly interested in the general approach that we have to >>> workarounds -- how do we track them, how do we make sure they don't >>> stick in tests forever, even after the issue was already properly >>> addressed. >>> >> I'm not sure if there is a formal process how to work with workarounds. >> >> Usually, we open ticket, push workaround there, and leave ticket opened until >> the issue is fixed. >> If there is no time to do proper fix and workaround works well we close ticket >> and open new ticket in further milestones. >> >> I do not remember if we have a similar issue with test workaround in past. > Can we anyhow utilize "wait_for_dns" knob we added for making DNS tests reliable? No, I already do that when records in CI test are created, there is polling. The first part of oleg's workaround has nothing common with timing issue, only restart of named process will help The second part, I do not know why there is 1sec delay needed, because presence of signed records was detected in step before, so DNSKEY record must be available, and probably this is caused by named internals, that DNSKEY record is available later than signed records of zone. I don think so that extending testing for all types of DNSSEC records is worth it and 1sec is enough for bind to be ready. Martin From mbasti at redhat.com Thu Oct 8 12:50:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 14:50:07 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56166410.5020407@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> Message-ID: <5616667F.2010002@redhat.com> On 10/08/2015 02:39 PM, Martin Kosek wrote: > On 10/08/2015 02:08 PM, Oleg Fayans wrote: >> Hi, >> >> On 10/08/2015 11:18 AM, Jan Pazdziora wrote: >>> On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>>>> When the ticket is addressed and these workarounds are no longer >>>>> needed -- what is our process for finding these workarounds and >>>>> reverting them, so that the tests test the real, expected behaviour? >>>> As per discussion with Martin Basti, it was decided that this workaround >>>> will only be applied to the current 4-2 branch, not to the upstream. In >>> That sounds like a reasonable plan for this issue. >>> >>>> upstream the issue itself will (supposedly) be solved >>> Except currently it's not, so (IIUIC) you will keep having >>> nondeterministic failures in master. >>> >>> I was mostly interested in the general approach that we have to >>> workarounds -- how do we track them, how do we make sure they don't >>> stick in tests forever, even after the issue was already properly >>> addressed. >>> >> That's actually a great point. I personally would like tickets to have one more >> field: "workaround" containing the address of a workaround in the format >> "path_to_the_file:line_number" or better even - a commit id of this workaround, >> so that once the ticket is resolved, we could easily find what to reverse. >> > Please don't add any more trac fields, there is too many of them already :-) > Keyword may serve better for now... > +1 new trac field for a few workarounds per year is not worth it. From pspacek at redhat.com Thu Oct 8 13:34:17 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 8 Oct 2015 15:34:17 +0200 Subject: [Freeipa-devel] terminology: "main/primary/? DNS domain" for FreeIPA Message-ID: <561670D9.7080801@redhat.com> Hello list, I'm in process of reviewing and fixing some of our docs and it seems that we do not have established term for The Domain user specified during ipa-server-install. Term "DNS domain" is not specific enough because FreeIPA can manage multiple DNS domains but only one of them contains SRV records. Term "IdM domain" sounds too vague for the same reasons. What about "primary DNS domain"? Or "primary IdM domain"? What term is used in AD world? My google-fu is weak on this. Ideas are more than welcome! -- Petr^2 Spacek From sgallagh at redhat.com Thu Oct 8 15:02:35 2015 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 8 Oct 2015 11:02:35 -0400 Subject: [Freeipa-devel] terminology: "main/primary/? DNS domain" for FreeIPA In-Reply-To: <561670D9.7080801@redhat.com> References: <561670D9.7080801@redhat.com> Message-ID: <5616858B.9070105@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/08/2015 09:34 AM, Petr Spacek wrote: > Hello list, > > I'm in process of reviewing and fixing some of our docs and it > seems that we do not have established term for The Domain user > specified during ipa-server-install. > > Term "DNS domain" is not specific enough because FreeIPA can manage > multiple DNS domains but only one of them contains SRV records. > Term "IdM domain" sounds too vague for the same reasons. > > What about "primary DNS domain"? Or "primary IdM domain"? > > What term is used in AD world? My google-fu is weak on this. > > Ideas are more than welcome! > In active directory, they use the term "Forest" to describe a top-level domain. The first domain created always has the same name as the forest (so: e.g. example.com). When adding new servers, you are given the option of adding a new domain to an existing forest (which then becomes subdomain.example.com) or creating a new forest. (Or creating a replica server of an existing domain, of course). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlYWhYgACgkQeiVVYja6o6PVsACfV+AUb7TiBFiEaQBI4M0pS8cD 4KYAn2eajHx9K8JsMDc8R4Yjv8s4jHrp =Pil0 -----END PGP SIGNATURE----- From pviktori at redhat.com Thu Oct 8 15:17:01 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 8 Oct 2015 17:17:01 +0200 Subject: [Freeipa-devel] [PATCHES] More Python 3 porting In-Reply-To: <5614D788.4050205@redhat.com> References: <55FC2707.5060709@redhat.com> <560150B7.4060405@redhat.com> <5602BB4B.4060206@redhat.com> <560B9C6C.2040600@redhat.com> <560D128C.9000105@redhat.com> <560D31E8.6000707@redhat.com> <560E65DA.6030204@redhat.com> <56121119.10906@redhat.com> <56139CA0.9030202@redhat.com> <5614D788.4050205@redhat.com> Message-ID: <561688ED.3060104@redhat.com> On 10/07/2015 10:27 AM, Jan Cholasta wrote: > On 6.10.2015 12:04, Petr Viktorin wrote: >> On 10/05/2015 07:56 AM, Jan Cholasta wrote: >>> On 2.10.2015 13:09, Petr Viktorin wrote: >>>> On 10/01/2015 03:15 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 1.10.2015 13:01, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 09/30/2015 10:25 AM, Petr Viktorin wrote: >>>>>>> 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. >>>> [...] >>>>>>> >>>>>> LGTM >>>>>> >>>>>> I ran xmlrpc tests, DNSSEC ci tests, backup and restore CI test and >>>>>> everything works >>>>> >>>>> Patches 713-719: ACK >>>>> >>>>> >>>>> Patch 720: >>>>> >>>>> You missed: >>>>> >>>>> ipa-client/ipa-install/ipa-client-install:32: from ConfigParser >>>>> import RawConfigParser >>>> >>>> >>>> Thanks, fixed. >>>> >>>>> Patches 721-722: ACK >>>>> >>>>> >>>>> Patch 723: >>>>> >>>>> Why the "NoneType = type(None)" in parameters.py? It is used only at: >>>>> >>>>> ipalib/parameters.py:388: type = NoneType # Ouch, this wont be >>>>> very >>>>> useful in the real world! >>>> >>>> I believe this is less confusing than `type = type(None)`, but I can >>>> change that if needed. >>> >>> I don't care which one is used TBH, just that it is done consistently >>> accross the whole patch, and this seemed like the simpler thing to do. >> >> OK, changed. >> >>>>> Patch 724: >>>>> >>>>> The SSHPublicKey class was written with the assumption that "str" >>>>> means >>>>> binary data, so unless I'm missing something, you only need to replace >>>>> "str" with "bytes". >>>> >>>> It specifically did take non-binary data as str: >>>> >>>> - if isinstance(key, str) and key[:3] != '\0\0\0': >>>> - key = key.decode(encoding) >>> >>> I don't follow, this is quite obviously binary data. It reads: "If key >>> is binary and does not start with 3 null bytes, decode it to text using >>> the specified encoding." >> >> Right, it's text (non-binary) data encoded in str (bytes), so it needs >> to be encoded. >> >>>> I've removed this for Python 3, where text data shouldn't be in bytes. >>>> >>>> Since this means the '\0\0\0' check is skipped in __init__ under Python >>>> 3, I've added it also to _parse_raw. >>> >>> When the SSH integration feature was first introduced, SSH public keys >>> were stored in the raw binary form in LDAP, i.e. not text data. We still >>> need to support that, so support for binary data and the 3 null check >>> must remain in SSHPublicKey. >> >> Changed, updated patches attached. > > Thanks, ACK. > > I took the liberty of amending patch 718 to silence this pylint false > positive I was getting on F22: > > ipalib/plugins/otptoken.py:496: [E1101(no-member), > HTTPSHandler.https_open] Instance of 'HTTPSHandler' has no 'do_open' > member) Thanks! > Pushed to master: f82d3da1e8e5dc1d0716201af5abb724a8e78fde > > BTW, in patch 724, binascii.Error is handled in addition to TypeError > with base64.b64decode(). There are multiple places where > base64.b64decode() is used in IPA where only TypeError is handled. Are > you planning on fixing this as well? I'll go through them to make sure we're handling them correctly. -- Petr Viktorin From pviktori at redhat.com Thu Oct 8 15:17:45 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 8 Oct 2015 17:17:45 +0200 Subject: [Freeipa-devel] [PATCHES] More Python3 porting Message-ID: <56168919.10209@redhat.com> Hello, Here is another batch of Python 3 porting patches. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0725-Do-not-compare-types-that-are-not-comparable-in-Pyth.patch Type: text/x-patch Size: 2885 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0726-x509-Port-to-Python-3.patch Type: text/x-patch Size: 2914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0727-Rename-caught-exception-for-use-outside-the-except-b.patch Type: text/x-patch Size: 2045 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0728-test_ipalib.test_frontend-Port-unbound-method-tests-.patch Type: text/x-patch Size: 2575 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0729-ipalib.aci-Port-to-Python-3.patch Type: text/x-patch Size: 8146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0730-Add-message-property-to-IPA-s-errors-and-warnings-un.patch Type: text/x-patch Size: 1386 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0731-test_keyring-Use-str-e-instead-of-e.message-for-exce.patch Type: text/x-patch Size: 926 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0732-ipalib.parameters-Handle-0-prefixed-octal-format-of-.patch Type: text/x-patch Size: 1695 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0733-ipalib.parameters-Require-bytes-for-Bytes.pattern.patch Type: text/x-patch Size: 1868 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0734-rpc-Name-argument-to-KerberosError.patch Type: text/x-patch Size: 941 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0735-Alias-long-to-int-under-Python-3.patch Type: text/x-patch Size: 1840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0736-ipaldap-Remove-extraneous-long-included-in-six.int_t.patch Type: text/x-patch Size: 922 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 8 15:19:01 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 8 Oct 2015 17:19:01 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.2.2 Message-ID: <56168965.5070307@redhat.com> The FreeIPA team would like to announce FreeIPA v4.2.2 security 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.2 == FreeIPA 4.2.0 introduced Key Archival Agent (KRA) support. This release fixes CVE-2015-5284. The CVE affects IPA servers where ipa-kra-install was run. Read manual instructions if your system was affected . === Bug fixes === * CVE-2015-5284: ipa-kra-install included certificate and private key in world readable file. * Firefox configuration steps were adjusted to new extension signing policy. * ipa-restore does not overwrite files with local users/groups * ipa-restore now works with KRA installed * Fixed an integer underflow bug in libotp which prevented from syncing TOTP tokens under certain circumstances. * winsync-migrate properly handles collisions in the names of external group * Fixed regression where installation of CA failed on CA-less server #5288. * Vault operations now works on a replica without KRA installed (assuming that at least one replica has KRA installed). #5302 === Enhancements === * Improved performance of search in Web UI's dialog for adding e.g. users to e.g. sudo rules. * Modified vault access control and added commands for managing vault containers. #5250 * Added support for generating client referrals for trusted domain principals. Note that bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844 has to be fixed in MIT Kerberos packages to allow client referrals from FreeIPA KDC to be processed. == 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.1 == === Abhijeet Kasurde (1) === * Updated number of legacy permission in ipatests === Alexander Bokovoy (1) === * client referral support for trusted domain principals === Christian Heimes (1) === * Handle timeout error in ipa-httpd-kdcproxy === Gabe Alford (4) === * Add Chromium configuration note to ssbrowser * Standardize minvalue for ipasearchrecordlimit and ipasesarchsizelimit for unlimited minvalue * dnssec option missing in ipa-dns-install man page * Update FreeIPA package description === Jan Cholasta (16) === * config: allow user/host attributes with tagging options * baseldap: make subtree deletion optional in LDAPDelete * vault: set owner to current user on container creation * vault: update access control * vault: add permissions and administrator privilege * install: support KRA update * install: Support overriding knobs in subclasses * install: Add common base class for server and replica install * install: Move unattended option to the general help section * install: create kdcproxy user during server install * platform: add option to create home directory when adding user * install: fix kdcproxy user home directory * install: fix ipa-server-install fail on missing --forwarder * install: fix KRA agent PEM file permissions * install: always export KRA agent PEM file * vault: select a server with KRA for vault operations === Martin Babinsky (5) === * load RA backend plugins during standalone CA install on CA-less IPA master * destroy httpd ccache after stopping the service * ipa-server-install: mark master_password Knob as deprecated * re-kinit after ipa-restore in backup/restore CI tests * do not overwrite files with local users/groups when restoring authconfig === Martin Ba?ti (11) === * FIX vault tests * Server Upgrade: backup CS.cfg when dogtag is turned off * IPA Restore: allows to specify files that should be removed * DNSSEC: improve CI test * DNSSEC CI: test master migration * backup CI: test DNS/DNSSEC after backup and restore * Limit max age of replication changelog * Server Upgrade: addifnew should not create entry * CI: backup and restore with KRA * Replica inst. fix: do not require -r, -a, -p options in unattended mode * Fix import get_reverse_zone_default in tasks === Milan Kub?k (4) === * ipatests: Add Certprofile tracker class implementation * ipatests: Add basic tests for certificate profile plugin * ipatests: configure Network Manager not to manage resolv.conf * Include ipatests/test_xmlrpc/data directory into distribution. === Nathaniel McCallum (1) === * Fix an integer underflow bug in libotp === Oleg Fayans (1) === * Added a proper workaround for dnssec test failures in Beaker environment === Petr Voborn?k (4) === * vault: add vault container commands * webui: use manual Firefox configuration for Firefox >= 40 * webui: improve performance of search in association dialog * Become IPA 4.2.2 === Petr ?pa?ek (1) === * Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limits === Timo Aaltonen (2) === * paths: Add GENERATE_RNDC_KEY. * httpinstance: Replace a hardcoded path to password.conf with HTTPD_PASSWORD_CONF === Tom?? Babej (4) === * winsync: Add inetUser objectclass to the passsync sysaccount * ipa-backup: Add mechanism to store empty directory structure * winsync-migrate: Convert entity names to posix friendly strings * winsync-migrate: Properly handle collisions in the names of external groups -- Petr Vobornik From mbasti at redhat.com Thu Oct 8 15:58:15 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 17:58:15 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320] installer: allow to modify dse.ldif during installation Message-ID: <56169297.2010006@redhat.com> The attached patches fix following tickets: https://fedorahosted.org/freeipa/ticket/4949 https://fedorahosted.org/freeipa/ticket/4048 https://fedorahosted.org/freeipa/ticket/1930 With these patches, an administrator can specify LDIF file that contains modifications to be applied to dse.ldif right after creation of DS instance. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0318-Make-offline-LDIF-modify-more-robust.patch Type: text/x-patch Size: 10300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0319-Add-method-to-read-changes-from-LDIF.patch Type: text/x-patch Size: 2931 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0320-Add-option-to-specify-LDIF-file-that-contains-DS-con.patch Type: text/x-patch Size: 7878 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 8 16:53:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 18:53:55 +0200 Subject: [Freeipa-devel] [PATCHES 0321 - 0322] CI: vault CI test Message-ID: <56169FA3.5060607@redhat.com> Patches attached. Tests for https://fedorahosted.org/freeipa/ticket/5302 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0321-CI-Test-add-setup_kra-options-into-install-scripts.patch Type: text/x-patch Size: 3787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0322-CI-TEST-Vault.patch Type: text/x-patch Size: 7489 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Oct 8 17:09:37 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 8 Oct 2015 19:09:37 +0200 Subject: [Freeipa-devel] [PATCH 0078-0081] ipa-client-install autodiscovery code improvements Message-ID: <5616A351.9090901@redhat.com> These patches fix https://fedorahosted.org/freeipa/ticket/4305 Actually only the last patch does the work itself (suppress autodiscovery when installing client on master), but when I saw the state of autodiscovery code I have taken the liberty to clean it up a bit. Patch #78 has separate versions for master and 4-2 branch, other patches should apply on top of it in both branches. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0081-do-not-perform-autodiscovery-when-installing-client-.patch Type: text/x-patch Size: 2548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0080-ipa-client-install-store-server-domain-realm-info-in.patch Type: text/x-patch Size: 9473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0079-ipa-client-install-fix-formatting-of-perform_discove.patch Type: text/x-patch Size: 9752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0078-ipa-client-install-factor-DNS-discovery-to-a-separat.patch Type: text/x-patch Size: 12475 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0078-ipa-client-install-factor-DNS-discovery-to-a-separat.patch Type: text/x-patch Size: 12469 bytes Desc: not available URL: From simo at redhat.com Thu Oct 8 18:55:50 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 8 Oct 2015 14:55:50 -0400 Subject: [Freeipa-devel] terminology: "main/primary/? DNS domain" for FreeIPA In-Reply-To: <561670D9.7080801@redhat.com> References: <561670D9.7080801@redhat.com> Message-ID: <5616BC36.8050709@redhat.com> On 08/10/15 09:34, Petr Spacek wrote: > Hello list, > > I'm in process of reviewing and fixing some of our docs and it seems that we > do not have established term for The Domain user specified during > ipa-server-install. > > Term "DNS domain" is not specific enough because FreeIPA can manage multiple > DNS domains but only one of them contains SRV records. Term "IdM domain" > sounds too vague for the same reasons. We should make it easy to publish SRV records on any domain, if a client is in a different DNS domain it should still be able to discover the IPA servers. > What about "primary DNS domain"? Or "primary IdM domain"? What's "primary" about it ? The fact that the Realm is named after it ? I guess that could work, but it wouldn't necessarily be accurate if you decide to move tto use poredominantly another different DNS domain during the lifetime of an install. > What term is used in AD world? My google-fu is weak on this. There is no such term because, mostly, in the AD world there is only one DNS domain that matters, the one that corresponds 1-1 to the Realm name. So there is only The AD Domain Name. > Ideas are more than welcome! I guess primary is ok, I draw a blank on what else could be used right now. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkubik at redhat.com Fri Oct 9 07:01:46 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 9 Oct 2015 09:01:46 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <5616667F.2010002@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> Message-ID: <5617665A.2080204@redhat.com> On 10/08/2015 02:50 PM, Martin Basti wrote: > > > On 10/08/2015 02:39 PM, Martin Kosek wrote: >> On 10/08/2015 02:08 PM, Oleg Fayans wrote: >>> Hi, >>> >>> On 10/08/2015 11:18 AM, Jan Pazdziora wrote: >>>> On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>>>>> When the ticket is addressed and these workarounds are no longer >>>>>> needed -- what is our process for finding these workarounds and >>>>>> reverting them, so that the tests test the real, expected behaviour? >>>>> As per discussion with Martin Basti, it was decided that this >>>>> workaround >>>>> will only be applied to the current 4-2 branch, not to the >>>>> upstream. In >>>> That sounds like a reasonable plan for this issue. >>>> >>>>> upstream the issue itself will (supposedly) be solved >>>> Except currently it's not, so (IIUIC) you will keep having >>>> nondeterministic failures in master. >>>> >>>> I was mostly interested in the general approach that we have to >>>> workarounds -- how do we track them, how do we make sure they don't >>>> stick in tests forever, even after the issue was already properly >>>> addressed. >>>> >>> That's actually a great point. I personally would like tickets to >>> have one more >>> field: "workaround" containing the address of a workaround in the >>> format >>> "path_to_the_file:line_number" or better even - a commit id of this >>> workaround, >>> so that once the ticket is resolved, we could easily find what to >>> reverse. >>> >> Please don't add any more trac fields, there is too many of them >> already :-) >> Keyword may serve better for now... >> > +1 > > new trac field for a few workarounds per year is not worth it. > Perhaps we could use pytest's expected fail (xfail) or skip marker. [1] It would prevent test from failing in the report and once the underlying issue is fixed, it will raise as an unexpected pass. It could be used as a temporary solution, once the issue is fixed, we would remove the mark from the test. This would probably need some workflow to be defined for these cases. [1]: https://pytest.org/latest/skipping.html -- Milan Kubik From mkubik at redhat.com Fri Oct 9 07:14:33 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 9 Oct 2015 09:14:33 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <5617665A.2080204@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> <5617665A.2080204@redhat.com> Message-ID: <56176959.80500@redhat.com> On 10/09/2015 09:01 AM, Milan Kub?k wrote: > On 10/08/2015 02:50 PM, Martin Basti wrote: >> >> >> On 10/08/2015 02:39 PM, Martin Kosek wrote: >>> On 10/08/2015 02:08 PM, Oleg Fayans wrote: >>>> Hi, >>>> >>>> On 10/08/2015 11:18 AM, Jan Pazdziora wrote: >>>>> On Thu, Oct 08, 2015 at 11:12:37AM +0200, Oleg Fayans wrote: >>>>>>> When the ticket is addressed and these workarounds are no longer >>>>>>> needed -- what is our process for finding these workarounds and >>>>>>> reverting them, so that the tests test the real, expected >>>>>>> behaviour? >>>>>> As per discussion with Martin Basti, it was decided that this >>>>>> workaround >>>>>> will only be applied to the current 4-2 branch, not to the >>>>>> upstream. In >>>>> That sounds like a reasonable plan for this issue. >>>>> >>>>>> upstream the issue itself will (supposedly) be solved >>>>> Except currently it's not, so (IIUIC) you will keep having >>>>> nondeterministic failures in master. >>>>> >>>>> I was mostly interested in the general approach that we have to >>>>> workarounds -- how do we track them, how do we make sure they don't >>>>> stick in tests forever, even after the issue was already properly >>>>> addressed. >>>>> >>>> That's actually a great point. I personally would like tickets to >>>> have one more >>>> field: "workaround" containing the address of a workaround in the >>>> format >>>> "path_to_the_file:line_number" or better even - a commit id of this >>>> workaround, >>>> so that once the ticket is resolved, we could easily find what to >>>> reverse. >>>> >>> Please don't add any more trac fields, there is too many of them >>> already :-) >>> Keyword may serve better for now... >>> >> +1 >> >> new trac field for a few workarounds per year is not worth it. >> > Perhaps we could use pytest's expected fail (xfail) or skip marker. > [1] It would prevent test from failing in the report and once the > underlying issue is fixed, it will raise as an unexpected pass. > > It could be used as a temporary solution, once the issue is fixed, we > would remove the mark from the test. This would probably need some > workflow to be defined for these cases. > > [1]: https://pytest.org/latest/skipping.html > I write faster than I read. The issue at hand here is diffeerent use case. :) -- Milan Kubik From pspacek at redhat.com Fri Oct 9 07:14:36 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 9 Oct 2015 09:14:36 +0200 Subject: [Freeipa-devel] [PATCH 0078-0081] ipa-client-install autodiscovery code improvements In-Reply-To: <5616A351.9090901@redhat.com> References: <5616A351.9090901@redhat.com> Message-ID: <5617695C.4010503@redhat.com> On 8.10.2015 19:09, Martin Babinsky wrote: > These patches fix https://fedorahosted.org/freeipa/ticket/4305 > > Actually only the last patch does the work itself (suppress autodiscovery when > installing client on master), but when I saw the state of autodiscovery code I > have taken the liberty to clean it up a bit. > > Patch #78 has separate versions for master and 4-2 branch, other patches > should apply on top of it in both branches. Uh, I have to say that I'm not big fan of this patch. This will simply hide fact that your DNS is terribly misconfigured and other things will fail later on. Also, even if we decide that it is what we want, I'm not sure what are implications for the master. Will it configure to use SSSD for auto-discovery as a fallback (when services on local master are not running)? If not, what will happen when IPA is not running on that particular master? Will the admin be able to log-in with IPA credentials? Nitpicks: > + if options.on_master: > + set_ipa_domain_params(ds, options.server, options.domain, > + options.realm_name, CACERT) It seems that set_ipa_domain_params should be class method of "ds" because it touches only instance variables and nothing else: -- Petr^2 Spacek From jpazdziora at redhat.com Fri Oct 9 07:15:41 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 9 Oct 2015 09:15:41 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <5617665A.2080204@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> <5617665A.2080204@redhat.com> Message-ID: <20151009071541.GI32648@redhat.com> On Fri, Oct 09, 2015 at 09:01:46AM +0200, Milan Kub?k wrote: > > Perhaps we could use pytest's expected fail (xfail) or skip marker. [1] It > would prevent test from failing in the report and once the underlying issue > is fixed, it will raise as an unexpected pass. > > It could be used as a temporary solution, once the issue is fixed, we would > remove the mark from the test. This would probably need some workflow to be > defined for these cases. That works but please note that this is not about test passing or failing, this is about some extra steps needed in the test body to achieve deterministic situation in which running that final check makes sense. I can imagine that simple # workaround 5348 time.sleep(20) and then some script which would find all these comments and compare them to resolved tickets might be enough. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From tbabej at redhat.com Fri Oct 9 08:31:32 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 9 Oct 2015 10:31:32 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <20151009071541.GI32648@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> <5617665A.2080204@redhat.com> <20151009071541.GI32648@redhat.com> Message-ID: <56177B64.2060201@redhat.com> On 10/09/2015 09:15 AM, Jan Pazdziora wrote: > On Fri, Oct 09, 2015 at 09:01:46AM +0200, Milan Kub?k wrote: >> >> Perhaps we could use pytest's expected fail (xfail) or skip marker. [1] It >> would prevent test from failing in the report and once the underlying issue >> is fixed, it will raise as an unexpected pass. >> >> It could be used as a temporary solution, once the issue is fixed, we would >> remove the mark from the test. This would probably need some workflow to be >> defined for these cases. > > That works but please note that this is not about test passing or > failing, this is about some extra steps needed in the test body to > achieve deterministic situation in which running that final check > makes sense. > > I can imagine that simple > > # workaround 5348 > time.sleep(20) > > and then some script which would find all these comments and compare > them to resolved tickets might be enough. > I like this idea the most. Keeping this information in Trac is not much practical. Having a note in the comment annotating the particular workaround, however, is quite neat. Imho we can start such convention. Keeping a keyword in a comment is not a heavy process. Also, I wouldn't be strict about it, as we already have a couple of workarounds, and not every time a workaround has a exact mapping to a particular ticket. Tomas From jpazdziora at redhat.com Fri Oct 9 09:03:46 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 9 Oct 2015 11:03:46 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56177B64.2060201@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> <5617665A.2080204@redhat.com> <20151009071541.GI32648@redhat.com> <56177B64.2060201@redhat.com> Message-ID: <20151009090346.GN32648@redhat.com> On Fri, Oct 09, 2015 at 10:31:32AM +0200, Tomas Babej wrote: > > a heavy process. Also, I wouldn't be strict about it, as we already have > a couple of workarounds, and not every time a workaround has a exact > mapping to a particular ticket. Frankly, this worries me much more than not having ticket for some trivial change to the code base. If there's workaround in tests, it's some action that we do but users/admins don't in their real setups. And that can cause failures for our users that we don't see or even no longer know about because in our tests, we've cleverly worked around them. Either that workaround step is needed and needs to be documented, or that step should not be needed and there should be a ticket describing the issue. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From pspacek at redhat.com Fri Oct 9 09:45:45 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 9 Oct 2015 11:45:45 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <20151009090346.GN32648@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> <5617665A.2080204@redhat.com> <20151009071541.GI32648@redhat.com> <56177B64.2060201@redhat.com> <20151009090346.GN32648@redhat.com> Message-ID: <56178CC9.8030504@redhat.com> On 9.10.2015 11:03, Jan Pazdziora wrote: > On Fri, Oct 09, 2015 at 10:31:32AM +0200, Tomas Babej wrote: >> >> a heavy process. Also, I wouldn't be strict about it, as we already have >> a couple of workarounds, and not every time a workaround has a exact >> mapping to a particular ticket. > > Frankly, this worries me much more than not having ticket for some > trivial change to the code base. > > If there's workaround in tests, it's some action that we do but > users/admins don't in their real setups. And that can cause failures > for our users that we don't see or even no longer know about because > in our tests, we've cleverly worked around them. > > Either that workaround step is needed and needs to be documented, or > that step should not be needed and there should be a ticket describing > the issue. +1 -- Petr^2 Spacek From pspacek at redhat.com Fri Oct 9 09:47:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 9 Oct 2015 11:47:52 +0200 Subject: [Freeipa-devel] [PATCH 0078-0081] ipa-client-install autodiscovery code improvements In-Reply-To: <5617695C.4010503@redhat.com> References: <5616A351.9090901@redhat.com> <5617695C.4010503@redhat.com> Message-ID: <56178D48.6050403@redhat.com> On 9.10.2015 09:14, Petr Spacek wrote: > On 8.10.2015 19:09, Martin Babinsky wrote: >> These patches fix https://fedorahosted.org/freeipa/ticket/4305 >> >> Actually only the last patch does the work itself (suppress autodiscovery when >> installing client on master), but when I saw the state of autodiscovery code I >> have taken the liberty to clean it up a bit. >> >> Patch #78 has separate versions for master and 4-2 branch, other patches >> should apply on top of it in both branches. > > Uh, I have to say that I'm not big fan of this patch. This will simply hide > fact that your DNS is terribly misconfigured and other things will fail later on. To underline this point, this exercise will not be necessary when https://fedorahosted.org/freeipa/ticket/5087 is solved (some incomplete patches are on the list already) because the problem should be detected before installation even starts. Personally I would rather finish #5087 and do not spend more time on #4305. Petr^2 Spacek > Also, even if we decide that it is what we want, I'm not sure what are > implications for the master. Will it configure to use SSSD for auto-discovery > as a fallback (when services on local master are not running)? > > If not, what will happen when IPA is not running on that particular master? > Will the admin be able to log-in with IPA credentials? > > > Nitpicks: >> + if options.on_master: >> + set_ipa_domain_params(ds, options.server, options.domain, >> + options.realm_name, CACERT) > > It seems that set_ipa_domain_params should be class method of "ds" because it > touches only instance variables and nothing else:-- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek From mbabinsk at redhat.com Fri Oct 9 10:47:00 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 9 Oct 2015 12:47:00 +0200 Subject: [Freeipa-devel] [PATCH 0078-0081] ipa-client-install autodiscovery code improvements In-Reply-To: <56178D48.6050403@redhat.com> References: <5616A351.9090901@redhat.com> <5617695C.4010503@redhat.com> <56178D48.6050403@redhat.com> Message-ID: <56179B24.2080207@redhat.com> On 10/09/2015 11:47 AM, Petr Spacek wrote: > On 9.10.2015 09:14, Petr Spacek wrote: >> On 8.10.2015 19:09, Martin Babinsky wrote: >>> These patches fix https://fedorahosted.org/freeipa/ticket/4305 >>> >>> Actually only the last patch does the work itself (suppress autodiscovery when >>> installing client on master), but when I saw the state of autodiscovery code I >>> have taken the liberty to clean it up a bit. >>> >>> Patch #78 has separate versions for master and 4-2 branch, other patches >>> should apply on top of it in both branches. >> >> Uh, I have to say that I'm not big fan of this patch. This will simply hide >> fact that your DNS is terribly misconfigured and other things will fail later on. > > To underline this point, this exercise will not be necessary when > https://fedorahosted.org/freeipa/ticket/5087 is solved (some incomplete > patches are on the list already) because the problem should be detected before > installation even starts. > > Personally I would rather finish #5087 and do not spend more time on #4305. > > Petr^2 Spacek > > >> Also, even if we decide that it is what we want, I'm not sure what are >> implications for the master. Will it configure to use SSSD for auto-discovery >> as a fallback (when services on local master are not running)? >> >> If not, what will happen when IPA is not running on that particular master? >> Will the admin be able to log-in with IPA credentials? >> >> >> Nitpicks: >>> + if options.on_master: >>> + set_ipa_domain_params(ds, options.server, options.domain, >>> + options.realm_name, CACERT) >> >> It seems that set_ipa_domain_params should be class method of "ds" because it >> touches only instance variables and nothing else:-- > Petr^2 Spacek > So should we abandon these patches altogether and close the ticket as WONTFIX? -- Martin^3 Babinsky From janorel at gmail.com Fri Oct 9 11:21:44 2015 From: janorel at gmail.com (Jan Orel) Date: Fri, 9 Oct 2015 13:21:44 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN Message-ID: Hello, this patch removes (IMHO) redundat check in cert_show, which fails when host tries to re-submit certificate of different host/service which he can manage. I also reported the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1269089 I tired to run the tests as well and it doesn't seem to break anything. Any feedpack appriciated. Jan Orel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-xorel-0001-Cert-show-remove-check.patch Type: text/x-patch Size: 1254 bytes Desc: not available URL: From sbose at redhat.com Fri Oct 9 11:23:18 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 9 Oct 2015 13:23:18 +0200 Subject: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal In-Reply-To: <20151008103623.GH19089@redhat.com> References: <20150903144220.GO22106@redhat.com> <20150903152205.GP22106@redhat.com> <20151005152845.GC19585@p.redhat.com> <20151008103623.GH19089@redhat.com> Message-ID: <20151009112318.GS30474@p.redhat.com> On Thu, Oct 08, 2015 at 01:36:23PM +0300, Alexander Bokovoy wrote: > On Mon, 05 Oct 2015, Sumit Bose wrote: > >On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote: > >>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. > > > >The patch looks good and works as advertised. I've tested in a IPA > >domain which trusts two different forests. All requests to the forest > >roots and child domains where properly redirected. I tested with your > >krb5 test build and with MIT Kerberos 1.14 which contains the needed > >fix. > > > >Nevertheless there are a view points I want to discuss: > > > >- missing support for AD's Alternative Domain Suffixes, this is > > important to allow AD users to login in with their "Email-Address" > > (which is the typical reference for a user name with an alternative > > domain suffix). I think this is not strictly related to the given > > ticket, so it can be solved in the context of a new ticket, do you > > agree? > Yes, please add a separate ticket. We need to do a bit more here: > - extend schema to allow adding the attribute for alternative domain > suffixes > - switch to use different DCE RPC call to retrieve forest trust > information. We can do it now that we have a call-out mechanism and > can isolate access to TDO credentials (this is long standing issue > first identified by Metze as part of cross-forest trust support for > Samba 4.3) > - Make possible to associate alternative domain suffixes with IPA > realm. We have support for realm domains already but we don't allow > to use them yet for the same call as in the above item. https://fedorahosted.org/freeipa/ticket/5354 > > >- referrals from outside. If I call 'kinit -E admin at IPA.DOMAIN' from a > > client in a trusted AD forest I get a 'Client not found in database' > > error because AD tends to use lower case domain names in the referal > > response. The request is still properly send to the IPA KDC because > > DNS does not care about the case. The IPA KDC processes the request > > with the principal 'user\@IPA.DOMAIN at ipa.domain' until > > ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue > > it detects that the principal is from the local realm. I think it > > would be good to enhance your patch to handle this case. > This is a separate bug too. Please file a ticket. https://fedorahosted.org/freeipa/ticket/5356 > > > >- S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across > > domain and forest boundaries (I tested this in a setup with 2 AD > > forests with request going from a child domain to a child domain in > > the other forest. Unfortunately it is currently not working with IPA > > in neither direction (I guess the case issue from above might be the > > reason for the incoming request to fail). Here I think a new ticket > > would to good as well because some research might be needed and the > > issue might even be in the MIT code. (If you want to run some tests I > > can give you access to my test environment.) > I think we want to have this working, thus a ticket is due here. This is > something we'll most likely require for some advanced 2FA operations for > AD users. https://fedorahosted.org/freeipa/ticket/5357 bye, Sumit > > >Let me know if you prefer to handle the issues with other tickets, then > >I would ACK the patch as it is. > Please file separate tickets. > > -- > / Alexander Bokovoy From pbrezina at redhat.com Fri Oct 9 11:35:47 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Fri, 09 Oct 2015 13:35:47 +0200 Subject: [Freeipa-devel] HOWTO: Troubleshooting SUDO Message-ID: <5617A693.6080204@redhat.com> Hi, I just submitted a sudo troubleshooting guide [1]. If you find anything missing, please, let me know. [1] https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO From slaznick at redhat.com Fri Oct 9 11:46:17 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 9 Oct 2015 13:46:17 +0200 Subject: [Freeipa-devel] [PATCH 0009] WebUI: Disappearing automember rule expressions Message-ID: <5617A909.8060508@redhat.com> Hi, please see the patch attached. Standa L. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0009-Fixes-disappearing-automember-expressions.patch Type: text/x-patch Size: 1217 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 9 12:08:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 9 Oct 2015 14:08:33 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <561634F8.5090801@redhat.com> References: <56152885.7050201@redhat.com> <56152C9A.1050202@redhat.com> <5616178C.1000500@redhat.com> <56162B46.102@redhat.com> <561634F8.5090801@redhat.com> Message-ID: <5617AE41.5020705@redhat.com> On 10/08/2015 11:18 AM, Oleg Fayans wrote: > Done > On 10/08/2015 10:37 AM, Martin Basti wrote: >> >> >> On 10/08/2015 09:13 AM, Oleg Fayans wrote: >>> Hi Martin >>> >>> On 10/07/2015 04:30 PM, Martin Basti wrote: >>>> >>>> >>>> On 10/07/2015 04:13 PM, Oleg Fayans wrote: >>>>> subj >>>>> >>>>> >>>>> >>>> Workaround looks good, but I prefer not to push it in upstream tests, >>>> because it is not test failure. >>> I agree, we should rather fix the original issue. But as a temporary >>> solution, to satisfy downstream, it could do. >>>> >>>> Why is there this sleep, this might be useful in upstream tests >>>> too, but >>>> what is the reason to add sleep there? >>> >>> Without it I kept getting this error: >>> E CalledProcessError: Command '['drill', '@localhost', '-k', >>> '/etc/trusted-key.key', '-S', 'example.test.', 'SOA']' returned >>> non-zero exit status 29 >>> >>> with --pdb option, though, my attempts to re-run the command >>> succeeded, so I assumed it was a timing issue, and indeed, this 1 >>> second sleep helped. >>> >>>> >>>> # verify signatures >>>> + time.sleep(1) >>>> args = [ >>>> >>>> >>> >>> Attached is an updated version of the patch with Martin's remarks >>> taken into account >>> >> Can you please send this as separate patch? I would like to push this >> one. > ACK Pushed to: master: 2b4354f37e7e775dae833d5e2e8824b43800855f ipa-4-2: f076da99946c0405162c88174e771a5cecfe9664 From rcritten at redhat.com Fri Oct 9 12:39:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Oct 2015 08:39:10 -0400 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: References: Message-ID: <5617B56E.7000807@redhat.com> Jan Orel wrote: > Hello, > > this patch removes (IMHO) redundat check in cert_show, which fails when > host tries to re-submit certificate of different host/service which he > can manage. > > I also reported the bug here: > https://bugzilla.redhat.com/show_bug.cgi?id=1269089 > > I tired to run the tests as well and it doesn't seem to break anything. > Any feedpack appriciated. This works around the "Retrieve Certificates from the CA" ACL when done as a host. I guess if the hostname isn't the subject then the host for the subject needs to be read and then look to see if hostname is in the managed_by list. rob From pspacek at redhat.com Fri Oct 9 12:59:28 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 9 Oct 2015 14:59:28 +0200 Subject: [Freeipa-devel] [PATCH 0059] ipa-adtrust-install: Print complete SRV record Message-ID: <5617BA30.2030604@redhat.com> Hello, I found this when reviewing DNS parts of IdM and AD integration guides. ipa-adtrust-install: Print complete SRV records. https://fedorahosted.org/freeipa/ticket/5358 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0059-ipa-adtrust-install-Print-complete-SRV-records.patch Type: text/x-patch Size: 1305 bytes Desc: not available URL: From cheimes at redhat.com Fri Oct 9 13:00:45 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 9 Oct 2015 15:00:45 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: References: Message-ID: <5617BA7D.6040303@redhat.com> On 2015-10-09 13:21, Jan Orel wrote: > Hello, > > this patch removes (IMHO) redundat check in cert_show, which fails when > host tries to re-submit certificate of different host/service which he > can manage. > > I also reported the bug here: > https://bugzilla.redhat.com/show_bug.cgi?id=1269089 > > I tired to run the tests as well and it doesn't seem to break anything. > Any feedpack appriciated. Jan Cholasta, you implemented the check in 2011. What purpose does it have? hostname == CN has been deprecated by RFC 2818 for some time, see https://tools.ietf.org/html/rfc2818#section-3.1 The current check is also not sufficient to prevent forgery. Browsers and modern TLS libraries completely ignore CN when a dNSName SAN extension is present. 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 rcritten at redhat.com Fri Oct 9 13:10:17 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Oct 2015 09:10:17 -0400 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <5617BA7D.6040303@redhat.com> References: <5617BA7D.6040303@redhat.com> Message-ID: <5617BCB9.2030808@redhat.com> Christian Heimes wrote: > On 2015-10-09 13:21, Jan Orel wrote: >> Hello, >> >> this patch removes (IMHO) redundat check in cert_show, which fails when >> host tries to re-submit certificate of different host/service which he >> can manage. >> >> I also reported the bug here: >> https://bugzilla.redhat.com/show_bug.cgi?id=1269089 >> >> I tired to run the tests as well and it doesn't seem to break anything. >> Any feedpack appriciated. > > Jan Cholasta, you implemented the check in 2011. What purpose does it have? > > hostname == CN has been deprecated by RFC 2818 for some time, see > https://tools.ietf.org/html/rfc2818#section-3.1 The current check is > also not sufficient to prevent forgery. Browsers and modern TLS > libraries completely ignore CN when a dNSName SAN extension is present. He just tweaked a pylint error, I did this code. The check isn't perfect (by far) but I don't think forgery is an issue. We're talking about retrieving a public cert, not doing a handshake. I think checking just the common name is ok because of the way IPA issues server certs. I'm not sure if SAN would even come into play in the case of checking this ACL. The only way I see this as being a problem is if a new profile is created for issuing server certs where the CN of the target host isn't in the subject. rob From jcholast at redhat.com Fri Oct 9 13:11:13 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 9 Oct 2015 15:11:13 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <5617BA7D.6040303@redhat.com> References: <5617BA7D.6040303@redhat.com> Message-ID: <5617BCF1.3000705@redhat.com> On 9.10.2015 15:00, Christian Heimes wrote: > On 2015-10-09 13:21, Jan Orel wrote: >> Hello, >> >> this patch removes (IMHO) redundat check in cert_show, which fails when >> host tries to re-submit certificate of different host/service which he >> can manage. >> >> I also reported the bug here: >> https://bugzilla.redhat.com/show_bug.cgi?id=1269089 >> >> I tired to run the tests as well and it doesn't seem to break anything. >> Any feedpack appriciated. > > Jan Cholasta, you implemented the check in 2011. What purpose does it have? I did not, it was added in commit 2e8bae59 by Rob. > > hostname == CN has been deprecated by RFC 2818 for some time, see > https://tools.ietf.org/html/rfc2818#section-3.1 The current check is > also not sufficient to prevent forgery. Browsers and modern TLS > libraries completely ignore CN when a dNSName SAN extension is present. > > Christian > -- Jan Cholasta From cheimes at redhat.com Fri Oct 9 13:21:01 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 9 Oct 2015 15:21:01 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <5617BCF1.3000705@redhat.com> References: <5617BA7D.6040303@redhat.com> <5617BCF1.3000705@redhat.com> Message-ID: <5617BF3D.6090801@redhat.com> On 2015-10-09 15:11, Jan Cholasta wrote: > On 9.10.2015 15:00, Christian Heimes wrote: >> On 2015-10-09 13:21, Jan Orel wrote: >>> Hello, >>> >>> this patch removes (IMHO) redundat check in cert_show, which fails when >>> host tries to re-submit certificate of different host/service which he >>> can manage. >>> >>> I also reported the bug here: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1269089 >>> >>> I tired to run the tests as well and it doesn't seem to break anything. >>> Any feedpack appriciated. >> >> Jan Cholasta, you implemented the check in 2011. What purpose does it >> have? > > I did not, it was added in commit 2e8bae59 by Rob. Sorry, I didn't check the context, just the output of $ git annotate ipalib/plugins/cert.py | grep common_name -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From martinjo84 at gmail.com Fri Oct 9 13:42:26 2015 From: martinjo84 at gmail.com (=?UTF-8?Q?Martin_J=C3=B8rgensen?=) Date: Fri, 9 Oct 2015 15:42:26 +0200 Subject: [Freeipa-devel] LXC NTP Problem Message-ID: Hi I really wont to deploy my freeipa server on LXC, but i cannot complete the installation because of NTP dont run on LXC Containers With --no-ntp wont either run, installation just stop when trying to start ntpd Help Mvh Martin J?rgensen TLF: 28738893 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 9 14:38:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 9 Oct 2015 16:38:36 +0200 Subject: [Freeipa-devel] LXC NTP Problem In-Reply-To: References: Message-ID: <5617D16C.8030703@redhat.com> On 10/09/2015 03:42 PM, Martin J?rgensen wrote: > Hi > I really wont to deploy my freeipa server on LXC, but i cannot > complete the installation because > of NTP dont run on LXC Containers > > With --no-ntp wont either run, installation just stop when trying to > start ntpd > > Help > > > Mvh Martin J?rgensen > TLF: 28738893 > > Hello, can you share log of installation /var/log/ipaserver-install.log I'm not a container guru, but get IPA into containers may be tricky. Here are some docker related materials, which might be useful: http://www.adelton.com/docs/docker/complex-application-in-container https://github.com/adelton/docker-freeipa https://www.freeipa.org/page/Docker Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Oct 9 17:11:54 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 9 Oct 2015 19:11:54 +0200 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <56029DBD.9040403@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> <56014858.4020100@redhat.com> <56029DBD.9040403@redhat.com> Message-ID: <5617F55A.8020202@redhat.com> On 09/23/2015 02:40 PM, Martin Basti wrote: > > > 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. > Updated patchset attached. Also fixed a minor spelling and syntax issues in the original patches. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0362-3-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-3-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-3-realmdomains-Add-validation-that-realmdomain-being-a.patch Type: text/x-patch Size: 5742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0365-3-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-3-realmdomains-Do-not-fail-due-the-ValidationError-whe.patch Type: text/x-patch Size: 1649 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0372-3-tests-Amend-result-assertions-in-realmdomains-tests.patch Type: text/x-patch Size: 9370 bytes Desc: not available URL: From redhatrises at gmail.com Fri Oct 9 17:17:54 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 9 Oct 2015 11:17:54 -0600 Subject: [Freeipa-devel] [PATCH 0056] Enable nsaccountlock in user.py cli Message-ID: Hello, This patch enables nsaccountlock in user.py cli. It is very handy to be able to search and find users with disabled/enabled accounts, etc. That said, I couldn't find why it was no_option in the first place, so I am not 100% sure if it breaks something or the reasoning behind no_option. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0056-Enable-nsaccountlock-in-user.py-for-cli-usage.patch Type: text/x-patch Size: 4141 bytes Desc: not available URL: From redhatrises at gmail.com Fri Oct 9 17:17:55 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 9 Oct 2015 11:17:55 -0600 Subject: [Freeipa-devel] [PATCH 0058] Remove bind configuration detected question Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5351 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0058-Remove-bind-configuration-detected-question.patch Type: text/x-patch Size: 1690 bytes Desc: not available URL: From redhatrises at gmail.com Fri Oct 9 17:17:56 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 9 Oct 2015 11:17:56 -0600 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5341 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0057-Warn-if-no-installation-found-when-running-ipa-serve.patch Type: text/x-patch Size: 1108 bytes Desc: not available URL: From ofayans at redhat.com Fri Oct 9 20:04:28 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 9 Oct 2015 22:04:28 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <20151009090346.GN32648@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> <5617665A.2080204@redhat.com> <20151009071541.GI32648@redhat.com> <56177B64.2060201@redhat.com> <20151009090346.GN32648@redhat.com> Message-ID: <56181DCC.9040604@redhat.com> On 10/09/2015 11:03 AM, Jan Pazdziora wrote: > On Fri, Oct 09, 2015 at 10:31:32AM +0200, Tomas Babej wrote: >> >> a heavy process. Also, I wouldn't be strict about it, as we already have >> a couple of workarounds, and not every time a workaround has a exact >> mapping to a particular ticket. > > Frankly, this worries me much more than not having ticket for some > trivial change to the code base. > > If there's workaround in tests, it's some action that we do but > users/admins don't in their real setups. And that can cause failures > for our users that we don't see or even no longer know about because > in our tests, we've cleverly worked around them. I guess, the global question of whether to do workarounds in tests to make them pass or not is older than the very oldest profession on earth. I must admit, I am on Jan's side here. I would prefer to implement the approach proposed by Milan: mark the test scenario as expected failure (if it is crucial to make the whole run pass), or better even to leave it as it is: just so that each red CI run would remind of the necessity to fix the original issue. This all is a theory, however. What do we do with this particular case? It's an edge case (does anyone except root zone admins sign a root zone?). Should we probably disable the whole scenario? Or just leave it failing as it is? > > Either that workaround step is needed and needs to be documented, or > that step should not be needed and there should be a ticket describing > the issue. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Fri Oct 9 20:50:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 9 Oct 2015 22:50:29 +0200 Subject: [Freeipa-devel] [PATCH] Workaround for trac N 5348 In-Reply-To: <56181DCC.9040604@redhat.com> References: <56152885.7050201@redhat.com> <20151008084441.GA29919@redhat.com> <56163385.7090100@redhat.com> <20151008091845.GA32648@redhat.com> <56165CA1.3010701@redhat.com> <56166410.5020407@redhat.com> <5616667F.2010002@redhat.com> <5617665A.2080204@redhat.com> <20151009071541.GI32648@redhat.com> <56177B64.2060201@redhat.com> <20151009090346.GN32648@redhat.com> <56181DCC.9040604@redhat.com> Message-ID: <56182895.5090003@redhat.com> On 09.10.2015 22:04, Oleg Fayans wrote: > > > On 10/09/2015 11:03 AM, Jan Pazdziora wrote: >> On Fri, Oct 09, 2015 at 10:31:32AM +0200, Tomas Babej wrote: >>> >>> a heavy process. Also, I wouldn't be strict about it, as we already >>> have >>> a couple of workarounds, and not every time a workaround has a exact >>> mapping to a particular ticket. >> >> Frankly, this worries me much more than not having ticket for some >> trivial change to the code base. >> >> If there's workaround in tests, it's some action that we do but >> users/admins don't in their real setups. And that can cause failures >> for our users that we don't see or even no longer know about because >> in our tests, we've cleverly worked around them. > > I guess, the global question of whether to do workarounds in tests to > make them pass or not is older than the very oldest profession on earth. > I must admit, I am on Jan's side here. I would prefer to implement the > approach proposed by Milan: mark the test scenario as expected failure > (if it is crucial to make the whole run pass), or better even to leave > it as it is: just so that each red CI run would remind of the > necessity to fix the original issue. > > This all is a theory, however. What do we do with this particular > case? It's an edge case (does anyone except root zone admins sign a > root zone?). Should we probably disable the whole scenario? Or just > leave it failing as it is? > This bug does not happen just for root zone. Other zones are affected too. I would leave it failing, we have to fix it. >> >> Either that workaround step is needed and needs to be documented, or >> that step should not be needed and there should be a ticket describing >> the issue. >> > From ftweedal at redhat.com Mon Oct 12 01:00:36 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 12 Oct 2015 11:00:36 +1000 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <5617B56E.7000807@redhat.com> References: <5617B56E.7000807@redhat.com> Message-ID: <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> On Fri, Oct 09, 2015 at 08:39:10AM -0400, Rob Crittenden wrote: > Jan Orel wrote: > > Hello, > > > > this patch removes (IMHO) redundat check in cert_show, which fails when > > host tries to re-submit certificate of different host/service which he > > can manage. > > > > I also reported the bug here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1269089 > > > > I tired to run the tests as well and it doesn't seem to break anything. > > Any feedpack appriciated. > > This works around the "Retrieve Certificates from the CA" ACL when done > as a host. > > I guess if the hostname isn't the subject then the host for the subject > needs to be read and then look to see if hostname is in the managed_by list. > > rob > Agreed. The corresponding checks for certificate issuance via cert-request, where the bind principal is a host, check that the subject host (and SAN dNSNames) is "managed by" the bind host. This is checked via `ldap.can_write(dn_of_subject_principal)'. 1. retrieve cert 2. read CN 3. ensure CN refers to a known host principal and call ldap.can_write(...) to ensure bind principal manages it. Cheers, Fraser > -- > 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 pspacek at redhat.com Mon Oct 12 06:47:34 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Oct 2015 08:47:34 +0200 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: References: Message-ID: <561B5786.8070207@redhat.com> Hello Gabe, thank you for your patch! Please note that there might be a case where detection is_ipa_configured() is broken but the user still needs to run the uninstall process to clean it up. Could you amend the patch to respect --force option? In that case the detection should be skipped. Thank you for your time! Petr^2 Spacek On 9.10.2015 19:17, Gabe Alford wrote: > diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py > index 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 100644 > --- a/ipaserver/install/server/install.py > +++ b/ipaserver/install/server/install.py > @@ -954,6 +954,12 @@ def uninstall_check(installer): > > installer._installation_cleanup = False > > + if not is_ipa_configured(): > + print("IPA server is not configured on this system.\n" + > + "If you want to install the IPA server, please install " + > + "it using 'ipa-server-install'.") > + sys.exit(1) > + > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) From jcholast at redhat.com Mon Oct 12 07:16:02 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Oct 2015 09:16:02 +0200 Subject: [Freeipa-devel] [PATCH 502] schema: do not derive ipaVaultPublicKey from ipaPublicKey Message-ID: <561B5E32.2060909@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-502-schema-do-not-derive-ipaVaultPublicKey-from-ipaPubli.patch Type: text/x-patch Size: 2256 bytes Desc: not available URL: From abokovoy at redhat.com Mon Oct 12 07:49:25 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Oct 2015 10:49:25 +0300 Subject: [Freeipa-devel] [PATCH 502] schema: do not derive ipaVaultPublicKey from ipaPublicKey In-Reply-To: <561B5E32.2060909@redhat.com> References: <561B5E32.2060909@redhat.com> Message-ID: <20151012074925.GA4873@redhat.com> On Mon, 12 Oct 2015, Jan Cholasta wrote: >Hi, > >the attached patch fixes . ACK, given Thierry's comment #32 in the bug https://bugzilla.redhat.com/show_bug.cgi?id=1267782 -- / Alexander Bokovoy From pspacek at redhat.com Mon Oct 12 08:43:05 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Oct 2015 10:43:05 +0200 Subject: [Freeipa-devel] [PATCH 0078-0081] ipa-client-install autodiscovery code improvements In-Reply-To: <56179B24.2080207@redhat.com> References: <5616A351.9090901@redhat.com> <5617695C.4010503@redhat.com> <56178D48.6050403@redhat.com> <56179B24.2080207@redhat.com> Message-ID: <561B7299.4080108@redhat.com> On 9.10.2015 12:47, Martin Babinsky wrote: > On 10/09/2015 11:47 AM, Petr Spacek wrote: >> On 9.10.2015 09:14, Petr Spacek wrote: >>> On 8.10.2015 19:09, Martin Babinsky wrote: >>>> These patches fix https://fedorahosted.org/freeipa/ticket/4305 >>>> >>>> Actually only the last patch does the work itself (suppress autodiscovery >>>> when >>>> installing client on master), but when I saw the state of autodiscovery >>>> code I >>>> have taken the liberty to clean it up a bit. >>>> >>>> Patch #78 has separate versions for master and 4-2 branch, other patches >>>> should apply on top of it in both branches. >>> >>> Uh, I have to say that I'm not big fan of this patch. This will simply hide >>> fact that your DNS is terribly misconfigured and other things will fail >>> later on. >> >> To underline this point, this exercise will not be necessary when >> https://fedorahosted.org/freeipa/ticket/5087 is solved (some incomplete >> patches are on the list already) because the problem should be detected before >> installation even starts. >> >> Personally I would rather finish #5087 and do not spend more time on #4305. >> >> Petr^2 Spacek >> >> >>> Also, even if we decide that it is what we want, I'm not sure what are >>> implications for the master. Will it configure to use SSSD for auto-discovery >>> as a fallback (when services on local master are not running)? >>> >>> If not, what will happen when IPA is not running on that particular master? >>> Will the admin be able to log-in with IPA credentials? >>> >>> >>> Nitpicks: >>>> + if options.on_master: >>>> + set_ipa_domain_params(ds, options.server, options.domain, >>>> + options.realm_name, CACERT) >>> >>> It seems that set_ipa_domain_params should be class method of "ds" because it >>> touches only instance variables and nothing else:-- >> Petr^2 Spacek >> > > So should we abandon these patches altogether and close the ticket as WONTFIX? Generally, yes if David is able to finish his patches. -- Petr^2 Spacek From mbabinsk at redhat.com Mon Oct 12 10:30:42 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 12 Oct 2015 12:30:42 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320] installer: allow to modify dse.ldif during installation In-Reply-To: <56169297.2010006@redhat.com> References: <56169297.2010006@redhat.com> Message-ID: <561B8BD2.2050301@redhat.com> On 10/08/2015 05:58 PM, Martin Basti wrote: > The attached patches fix following tickets: > https://fedorahosted.org/freeipa/ticket/4949 > https://fedorahosted.org/freeipa/ticket/4048 > https://fedorahosted.org/freeipa/ticket/1930 > > With these patches, an administrator can specify LDIF file that contains > modifications to be applied to dse.ldif right after creation of DS > instance. > > Hi, Functionally the paches work as expected. However I have following nitpicks: in patch 318: 1.) there is a typo in ModifyLDIF class docstring: + Operations keep the order in whihc were specified per DN. in patch 320: 1.) you should use 'os.path.join' to construct FS paths: - dse_filename = '%s/%s' % ( + dse_filename = os.path.join( paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % self.serverid, - 'dse.ldif', + 'dse.ldif' ) 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to LDIF containing the mod operations to dse.ldif. However, the knob name sounds like the option accepts the path of dse.ldif itself. I propose to rename the knob to something more in-line with the supposed function, like 'dse_mods_file'. -- Martin^3 Babinsky From mbasti at redhat.com Mon Oct 12 10:41:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Oct 2015 12:41:13 +0200 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <5617F55A.8020202@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> <56014858.4020100@redhat.com> <56029DBD.9040403@redhat.com> <5617F55A.8020202@redhat.com> Message-ID: <561B8E49.2000601@redhat.com> On 09.10.2015 19:11, Tomas Babej wrote: > > On 09/23/2015 02:40 PM, Martin Basti wrote: >> >> 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. >> > Updated patchset attached. Also fixed a minor spelling and syntax issues > in the original patches. > > Tomas ACK, unfortunately, patch "realmdomains: Issue a warning when automated management of realmdomains" failed to apply on top of ipa-4-2 branch. From mbasti at redhat.com Mon Oct 12 10:44:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Oct 2015 12:44:27 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <55B0A9F0.4010602@redhat.com> References: <55B0A9F0.4010602@redhat.com> Message-ID: <561B8F0B.4070907@redhat.com> On 23.07.2015 10:46, Ludwig Krispenz wrote: > The attached patch moves the cleaning of the RUV into the topology > plugin. > > I encountered a problem when removing a replica, which disconnects the > topology, but it was fixed with my WIP for #5072. > > I want to keep these issues separate, so please review and test the > patch and let me know about issues found > > Ludwig > > Is this patch still valid and pending review? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon Oct 12 10:50:51 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 12 Oct 2015 06:50:51 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <561B8E49.2000601@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> <56014858.4020100@redhat.com> <56029DBD.9040403@redhat.com> <5617F55A.8020202@redhat.com> <561B8E49.2000601@redhat.com> Message-ID: <1278174092.22984786.1444647051840.JavaMail.zimbra@redhat.com> ----- Original Message ----- From: "Martin Basti" To: "Tomas Babej" Cc: "freeipa-devel" Sent: Monday, October 12, 2015 12:41:13 PM Subject: Re: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements >On 09.10.2015 19:11, Tomas Babej wrote: >> >> On 09/23/2015 02:40 PM, Martin Basti wrote: >>> >>> 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. >>> >> Updated patchset attached. Also fixed a minor spelling and syntax issues >> in the original patches. >> >> Tomas >ACK, >unfortunately, patch "realmdomains: Issue a warning when automated >management of realmdomains" failed to apply on top of ipa-4-2 branch. Attaching rebased patchset. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0362-idoverride-Ignore-ValidationErrors-when-converting-t.patch Type: text/x-patch Size: 2583 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 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: 0364-realmdomains-Add-validation-that-realmdomain-being-a.patch Type: text/x-patch Size: 5742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 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: 0366-realmdomains-Do-not-fail-due-the-ValidationError-whe.patch Type: text/x-patch Size: 1649 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0372-tests-Amend-result-assertions-in-realmdomains-tests.patch Type: text/x-patch Size: 9370 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 12 11:05:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Oct 2015 13:05:21 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320] installer: allow to modify dse.ldif during installation In-Reply-To: <561B8BD2.2050301@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> Message-ID: <561B93F1.70202@redhat.com> On 12.10.2015 12:30, Martin Babinsky wrote: > On 10/08/2015 05:58 PM, Martin Basti wrote: >> The attached patches fix following tickets: >> https://fedorahosted.org/freeipa/ticket/4949 >> https://fedorahosted.org/freeipa/ticket/4048 >> https://fedorahosted.org/freeipa/ticket/1930 >> >> With these patches, an administrator can specify LDIF file that contains >> modifications to be applied to dse.ldif right after creation of DS >> instance. >> >> > Hi, > > Functionally the paches work as expected. However I have following > nitpicks: > > in patch 318: > > 1.) there is a typo in ModifyLDIF class docstring: > > + Operations keep the order in whihc were specified per DN. > > in patch 320: > > 1.) you should use 'os.path.join' to construct FS paths: > > > - dse_filename = '%s/%s' % ( > + dse_filename = os.path.join( > paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % self.serverid, > - 'dse.ldif', > + 'dse.ldif' > ) > > 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to > LDIF containing the mod operations to dse.ldif. However, the knob name > sounds like the option accepts the path of dse.ldif itself. I propose > to rename the knob to something more in-line with the supposed > function, like 'dse_mods_file'. > Users might not know what dse means, I would suggest to name option as 'dirsrv_config_mods' then. From lkrispen at redhat.com Mon Oct 12 11:17:34 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 12 Oct 2015 13:17:34 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <561B8F0B.4070907@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> Message-ID: <561B96CE.9060404@redhat.com> On 10/12/2015 12:44 PM, Martin Basti wrote: > > > On 23.07.2015 10:46, Ludwig Krispenz wrote: >> The attached patch moves the cleaning of the RUV into the topology >> plugin. >> >> I encountered a problem when removing a replica, which disconnects >> the topology, but it was fixed with my WIP for #5072. >> >> I want to keep these issues separate, so please review and test the >> patch and let me know about issues found >> >> Ludwig >> >> > > Is this patch still valid and pending review? it should be still valid, waiting for review, wanted to rebase after topology/promotion patches have been checked in and resend -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Mon Oct 12 11:37:18 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 12 Oct 2015 13:37:18 +0200 Subject: [Freeipa-devel] [PATCHES 0321 - 0322] CI: vault CI test In-Reply-To: <56169FA3.5060607@redhat.com> References: <56169FA3.5060607@redhat.com> Message-ID: <561B9B6E.1060906@redhat.com> On 10/08/2015 06:53 PM, Martin Basti wrote: > Patches attached. > > Tests for https://fedorahosted.org/freeipa/ticket/5302 > > LGTM, ACK. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Mon Oct 12 11:38:07 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 12 Oct 2015 13:38:07 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall Message-ID: <561B9B9F.90002@redhat.com> Fixes https://fedorahosted.org/freeipa/ticket/5243 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0082-remove-Kerberos-authenticators-after-service-uninsta.patch Type: text/x-patch Size: 5564 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 12 11:45:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Oct 2015 13:45:29 +0200 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <1278174092.22984786.1444647051840.JavaMail.zimbra@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> <56014858.4020100@redhat.com> <56029DBD.9040403@redhat.com> <5617F55A.8020202@redhat.com> <561B8E49.2000601@redhat.com> <1278174092.22984786.1444647051840.JavaMail.zimbra@redhat.com> Message-ID: <561B9D59.4020508@redhat.com> On 12.10.2015 12:50, Tomas Babej wrote: > > ----- Original Message ----- > From: "Martin Basti" > To: "Tomas Babej" > Cc: "freeipa-devel" > Sent: Monday, October 12, 2015 12:41:13 PM > Subject: Re: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements > > > >> On 09.10.2015 19:11, Tomas Babej wrote: >>> On 09/23/2015 02:40 PM, Martin Basti wrote: >>>> 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. >>>> >>> Updated patchset attached. Also fixed a minor spelling and syntax issues >>> in the original patches. >>> >>> Tomas >> ACK, >> unfortunately, patch "realmdomains: Issue a warning when automated >> management of realmdomains" failed to apply on top of ipa-4-2 branch. > Attaching rebased patchset. Pushed to master: 12840e0bfa545341c448276c4803a49cbae63e8a You sent different patch 362 for ipa-4-2 than it should be. From tbabej at redhat.com Mon Oct 12 12:02:44 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 12 Oct 2015 08:02:44 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <561B9D59.4020508@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> <56014858.4020100@redhat.com> <56029DBD.9040403@redhat.com> <5617F55A.8020202@redhat.com> <561B8E49.2000601@redhat.com> <1278174092.22984786.1444647051840.JavaMail.zimbra@redhat.com> <561B9D59.4020508@redhat.com> Message-ID: <52987400.22999838.1444651364752.JavaMail.zimbra@redhat.com> >On 12.10.2015 12:50, Tomas Babej wrote: >> >> ----- Original Message ----- >> From: "Martin Basti" >> To: "Tomas Babej" >> Cc: "freeipa-devel" >> Sent: Monday, October 12, 2015 12:41:13 PM >> Subject: Re: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements >> >> >> >>> On 09.10.2015 19:11, Tomas Babej wrote: >>>> On 09/23/2015 02:40 PM, Martin Basti wrote: >>>>> 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. >>>>> >>>> Updated patchset attached. Also fixed a minor spelling and syntax issues >>>> in the original patches. >>>> >>>> Tomas >>> ACK, >>> unfortunately, patch "realmdomains: Issue a warning when automated >>> management of realmdomains" failed to apply on top of ipa-4-2 branch. >> Attaching rebased patchset. >Pushed to master: 12840e0bfa545341c448276c4803a49cbae63e8a >You sent different patch 362 for ipa-4-2 than it should be. Yeah, I shifted the whole patchset by one patch somehow.. Correct version attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: 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: 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: 0364-realmdomains-Add-validation-that-realmdomain-being-a.patch Type: text/x-patch Size: 5742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 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: 0366-realmdomains-Do-not-fail-due-the-ValidationError-whe.patch Type: text/x-patch Size: 1649 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0372-tests-Amend-result-assertions-in-realmdomains-tests.patch Type: text/x-patch Size: 9370 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 12 12:40:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Oct 2015 14:40:55 +0200 Subject: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements In-Reply-To: <52987400.22999838.1444651364752.JavaMail.zimbra@redhat.com> References: <55E83D5A.2050804@redhat.com> <20150903143418.GN22106@redhat.com> <56014858.4020100@redhat.com> <56029DBD.9040403@redhat.com> <5617F55A.8020202@redhat.com> <561B8E49.2000601@redhat.com> <1278174092.22984786.1444647051840.JavaMail.zimbra@redhat.com> <561B9D59.4020508@redhat.com> <52987400.22999838.1444651364752.JavaMail.zimbra@redhat.com> Message-ID: <561BAA57.7010401@redhat.com> On 12.10.2015 14:02, Tomas Babej wrote: >> On 12.10.2015 12:50, Tomas Babej wrote: >>> ----- Original Message ----- >>> From: "Martin Basti" >>> To: "Tomas Babej" >>> Cc: "freeipa-devel" >>> Sent: Monday, October 12, 2015 12:41:13 PM >>> Subject: Re: [Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements >>> >>> >>> >>>> On 09.10.2015 19:11, Tomas Babej wrote: >>>>> On 09/23/2015 02:40 PM, Martin Basti wrote: >>>>>> 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. >>>>>> >>>>> Updated patchset attached. Also fixed a minor spelling and syntax issues >>>>> in the original patches. >>>>> >>>>> Tomas >>>> ACK, >>>> unfortunately, patch "realmdomains: Issue a warning when automated >>>> management of realmdomains" failed to apply on top of ipa-4-2 branch. >>> Attaching rebased patchset. >> Pushed to master: 12840e0bfa545341c448276c4803a49cbae63e8a >> You sent different patch 362 for ipa-4-2 than it should be. > Yeah, I shifted the whole patchset by one patch somehow.. > > Correct version attached. Pushed to ipa-4-2: 291aa25acd5df24b8bcc36fc02f6af0cc4f7d0f9 From jcholast at redhat.com Mon Oct 12 13:11:09 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Oct 2015 15:11:09 +0200 Subject: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected in export_kra_agent_pem Message-ID: <561BB16D.6030202@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-503-upgrade-make-sure-ldap2-is-connected-in-export_kra_a.patch Type: text/x-patch Size: 1071 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 12 13:18:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Oct 2015 15:18:23 +0200 Subject: [Freeipa-devel] [PATCHES 0321 - 0322] CI: vault CI test In-Reply-To: <561B9B6E.1060906@redhat.com> References: <56169FA3.5060607@redhat.com> <561B9B6E.1060906@redhat.com> Message-ID: <561BB31F.6030409@redhat.com> On 12.10.2015 13:37, Milan Kub?k wrote: > On 10/08/2015 06:53 PM, Martin Basti wrote: >> Patches attached. >> >> Tests for https://fedorahosted.org/freeipa/ticket/5302 >> >> > LGTM, ACK. > > -- > Milan Kubik Pushed to: ipa-4-2: ad345b4e2572cbc5ce26501f4a73fc4eb02bfaf0 master: 573d3323afa558c791fc0ad2a788b75e33144481 -------------- next part -------------- An HTML attachment was scrubbed... URL: From amarecek at redhat.com Mon Oct 12 13:45:51 2015 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Mon, 12 Oct 2015 09:45:51 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected in export_kra_agent_pem In-Reply-To: <561BB16D.6030202@redhat.com> References: <561BB16D.6030202@redhat.com> Message-ID: <1866326804.28853314.1444657551005.JavaMail.zimbra@redhat.com> Hello, the patch looks good but pep8 cries: # pep8 ipaserver/install/server/upgrade.py ipaserver/install/server/upgrade.py:53:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:68:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:83:25: E261 at least two spaces before inline comment ipaserver/install/server/upgrade.py:88:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:94:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:96:13: E225 missing whitespace around operator ipaserver/install/server/upgrade.py:109:80: E501 line too long (93 > 79 characters) ipaserver/install/server/upgrade.py:111:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:131:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:151:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:172:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:179:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:192:80: E501 line too long (108 > 79 characters) ipaserver/install/server/upgrade.py:196:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:217:49: E231 missing whitespace after ',' ipaserver/install/server/upgrade.py:222:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:228:80: E501 line too long (83 > 79 characters) ipaserver/install/server/upgrade.py:264:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:277:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:333:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:366:80: E501 line too long (82 > 79 characters) ipaserver/install/server/upgrade.py:414:49: E251 unexpected spaces around keyword / parameter equals ipaserver/install/server/upgrade.py:414:51: E251 unexpected spaces around keyword / parameter equals ipaserver/install/server/upgrade.py:441:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:455:56: E127 continuation line over-indented for visual indent ipaserver/install/server/upgrade.py:459:25: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:487:37: E126 continuation line over-indented for hanging indent ipaserver/install/server/upgrade.py:494:17: E126 continuation line over-indented for hanging indent ipaserver/install/server/upgrade.py:503:80: E501 line too long (81 > 79 characters) ipaserver/install/server/upgrade.py:504:25: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:511:80: E501 line too long (81 > 79 characters) ipaserver/install/server/upgrade.py:517:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:538:80: E501 line too long (83 > 79 characters) ipaserver/install/server/upgrade.py:539:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:541:80: E501 line too long (82 > 79 characters) ipaserver/install/server/upgrade.py:542:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:551:80: E501 line too long (89 > 79 characters) ipaserver/install/server/upgrade.py:552:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:554:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:556:80: E501 line too long (86 > 79 characters) ipaserver/install/server/upgrade.py:557:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:561:80: E501 line too long (91 > 79 characters) ipaserver/install/server/upgrade.py:562:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:577:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:603:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:606:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:611:80: E501 line too long (80 > 79 characters) ipaserver/install/server/upgrade.py:616:80: E501 line too long (81 > 79 characters) ipaserver/install/server/upgrade.py:619:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:627:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:640:80: E501 line too long (85 > 79 characters) ipaserver/install/server/upgrade.py:643:80: E501 line too long (84 > 79 characters) ipaserver/install/server/upgrade.py:644:21: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:652:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:664:80: E501 line too long (84 > 79 characters) ipaserver/install/server/upgrade.py:666:17: E126 continuation line over-indented for hanging indent ipaserver/install/server/upgrade.py:672:80: E501 line too long (85 > 79 characters) ipaserver/install/server/upgrade.py:675:80: E501 line too long (86 > 79 characters) ipaserver/install/server/upgrade.py:676:21: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:679:80: E501 line too long (95 > 79 characters) ipaserver/install/server/upgrade.py:681:80: E501 line too long (82 > 79 characters) ipaserver/install/server/upgrade.py:684:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:699:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:702:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:707:80: E501 line too long (84 > 79 characters) ipaserver/install/server/upgrade.py:714:80: E501 line too long (81 > 79 characters) ipaserver/install/server/upgrade.py:716:80: E501 line too long (80 > 79 characters) ipaserver/install/server/upgrade.py:717:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:721:5: E303 too many blank lines (2) ipaserver/install/server/upgrade.py:724:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:733:80: E501 line too long (84 > 79 characters) ipaserver/install/server/upgrade.py:738:80: E501 line too long (86 > 79 characters) ipaserver/install/server/upgrade.py:739:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:741:80: E501 line too long (86 > 79 characters) ipaserver/install/server/upgrade.py:742:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:746:80: E501 line too long (85 > 79 characters) ipaserver/install/server/upgrade.py:747:80: E501 line too long (94 > 79 characters) ipaserver/install/server/upgrade.py:754:80: E501 line too long (81 > 79 characters) ipaserver/install/server/upgrade.py:756:80: E501 line too long (89 > 79 characters) ipaserver/install/server/upgrade.py:757:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:761:5: E303 too many blank lines (2) ipaserver/install/server/upgrade.py:761:80: E501 line too long (86 > 79 characters) ipaserver/install/server/upgrade.py:764:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:781:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:786:80: E501 line too long (80 > 79 characters) ipaserver/install/server/upgrade.py:794:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:798:5: E303 too many blank lines (2) ipaserver/install/server/upgrade.py:801:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:872:80: E501 line too long (80 > 79 characters) ipaserver/install/server/upgrade.py:924:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:940:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:949:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:967:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:968:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:971:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:999:80: E501 line too long (81 > 79 characters) ipaserver/install/server/upgrade.py:1003:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:1004:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:1007:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:1069:19: E222 multiple spaces after operator ipaserver/install/server/upgrade.py:1288:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:1301:1: E302 expected 2 blank lines, found 1 ipaserver/install/server/upgrade.py:1307:17: E225 missing whitespace around operator ipaserver/install/server/upgrade.py:1334:80: E501 line too long (81 > 79 characters) ipaserver/install/server/upgrade.py:1339:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:1341:17: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:1389:13: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:1399:21: E128 continuation line under-indented for visual indent ipaserver/install/server/upgrade.py:1400:30: E225 missing whitespace around operator ipaserver/install/server/upgrade.py:1440:80: E501 line too long (80 > 79 characters) ipaserver/install/server/upgrade.py:1465:14: E111 indentation is not a multiple of four ipaserver/install/server/upgrade.py:1519:27: E126 continuation line over-indented for hanging indent ipaserver/install/server/upgrade.py:1531:26: E126 continuation line over-indented for hanging indent ipaserver/install/server/upgrade.py:1583:80: E501 line too long (96 > 79 characters) ipaserver/install/server/upgrade.py:1601:26: E128 continuation line under-indented for visual indent ----- Original Message ----- > From: "Jan Cholasta" > To: "freeipa-devel" > Sent: Monday, October 12, 2015 3:11:09 PM > Subject: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected in export_kra_agent_pem > > Hi, > > the attached patch fixes . > > Honza > > -- > Jan Cholasta > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From amarecek at redhat.com Mon Oct 12 13:47:08 2015 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Mon, 12 Oct 2015 09:47:08 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected in export_kra_agent_pem In-Reply-To: <1866326804.28853314.1444657551005.JavaMail.zimbra@redhat.com> References: <561BB16D.6030202@redhat.com> <1866326804.28853314.1444657551005.JavaMail.zimbra@redhat.com> Message-ID: <377546396.28854073.1444657628245.JavaMail.zimbra@redhat.com> ok, it's not fault of patch itself, ACK ----- Original Message ----- > From: "Ale? Mare?ek" > To: "Jan Cholasta" > Cc: "freeipa-devel" > Sent: Monday, October 12, 2015 3:45:51 PM > Subject: Re: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected in export_kra_agent_pem > > Hello, > the patch looks good but pep8 cries: > > # pep8 ipaserver/install/server/upgrade.py > ipaserver/install/server/upgrade.py:53:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:68:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:83:25: E261 at least two spaces before > inline comment > ipaserver/install/server/upgrade.py:88:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:94:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:96:13: E225 missing whitespace around > operator > ipaserver/install/server/upgrade.py:109:80: E501 line too long (93 > 79 > characters) > ipaserver/install/server/upgrade.py:111:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:131:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:151:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:172:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:179:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:192:80: E501 line too long (108 > 79 > characters) > ipaserver/install/server/upgrade.py:196:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:217:49: E231 missing whitespace after ',' > ipaserver/install/server/upgrade.py:222:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:228:80: E501 line too long (83 > 79 > characters) > ipaserver/install/server/upgrade.py:264:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:277:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:333:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:366:80: E501 line too long (82 > 79 > characters) > ipaserver/install/server/upgrade.py:414:49: E251 unexpected spaces around > keyword / parameter equals > ipaserver/install/server/upgrade.py:414:51: E251 unexpected spaces around > keyword / parameter equals > ipaserver/install/server/upgrade.py:441:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:455:56: E127 continuation line > over-indented for visual indent > ipaserver/install/server/upgrade.py:459:25: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:487:37: E126 continuation line > over-indented for hanging indent > ipaserver/install/server/upgrade.py:494:17: E126 continuation line > over-indented for hanging indent > ipaserver/install/server/upgrade.py:503:80: E501 line too long (81 > 79 > characters) > ipaserver/install/server/upgrade.py:504:25: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:511:80: E501 line too long (81 > 79 > characters) > ipaserver/install/server/upgrade.py:517:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:538:80: E501 line too long (83 > 79 > characters) > ipaserver/install/server/upgrade.py:539:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:541:80: E501 line too long (82 > 79 > characters) > ipaserver/install/server/upgrade.py:542:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:551:80: E501 line too long (89 > 79 > characters) > ipaserver/install/server/upgrade.py:552:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:554:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:556:80: E501 line too long (86 > 79 > characters) > ipaserver/install/server/upgrade.py:557:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:561:80: E501 line too long (91 > 79 > characters) > ipaserver/install/server/upgrade.py:562:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:577:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:603:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:606:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:611:80: E501 line too long (80 > 79 > characters) > ipaserver/install/server/upgrade.py:616:80: E501 line too long (81 > 79 > characters) > ipaserver/install/server/upgrade.py:619:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:627:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:640:80: E501 line too long (85 > 79 > characters) > ipaserver/install/server/upgrade.py:643:80: E501 line too long (84 > 79 > characters) > ipaserver/install/server/upgrade.py:644:21: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:652:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:664:80: E501 line too long (84 > 79 > characters) > ipaserver/install/server/upgrade.py:666:17: E126 continuation line > over-indented for hanging indent > ipaserver/install/server/upgrade.py:672:80: E501 line too long (85 > 79 > characters) > ipaserver/install/server/upgrade.py:675:80: E501 line too long (86 > 79 > characters) > ipaserver/install/server/upgrade.py:676:21: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:679:80: E501 line too long (95 > 79 > characters) > ipaserver/install/server/upgrade.py:681:80: E501 line too long (82 > 79 > characters) > ipaserver/install/server/upgrade.py:684:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:699:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:702:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:707:80: E501 line too long (84 > 79 > characters) > ipaserver/install/server/upgrade.py:714:80: E501 line too long (81 > 79 > characters) > ipaserver/install/server/upgrade.py:716:80: E501 line too long (80 > 79 > characters) > ipaserver/install/server/upgrade.py:717:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:721:5: E303 too many blank lines (2) > ipaserver/install/server/upgrade.py:724:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:733:80: E501 line too long (84 > 79 > characters) > ipaserver/install/server/upgrade.py:738:80: E501 line too long (86 > 79 > characters) > ipaserver/install/server/upgrade.py:739:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:741:80: E501 line too long (86 > 79 > characters) > ipaserver/install/server/upgrade.py:742:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:746:80: E501 line too long (85 > 79 > characters) > ipaserver/install/server/upgrade.py:747:80: E501 line too long (94 > 79 > characters) > ipaserver/install/server/upgrade.py:754:80: E501 line too long (81 > 79 > characters) > ipaserver/install/server/upgrade.py:756:80: E501 line too long (89 > 79 > characters) > ipaserver/install/server/upgrade.py:757:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:761:5: E303 too many blank lines (2) > ipaserver/install/server/upgrade.py:761:80: E501 line too long (86 > 79 > characters) > ipaserver/install/server/upgrade.py:764:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:781:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:786:80: E501 line too long (80 > 79 > characters) > ipaserver/install/server/upgrade.py:794:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:798:5: E303 too many blank lines (2) > ipaserver/install/server/upgrade.py:801:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:872:80: E501 line too long (80 > 79 > characters) > ipaserver/install/server/upgrade.py:924:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:940:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:949:1: E302 expected 2 blank lines, found > 1 > ipaserver/install/server/upgrade.py:967:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:968:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:971:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:999:80: E501 line too long (81 > 79 > characters) > ipaserver/install/server/upgrade.py:1003:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:1004:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:1007:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:1069:19: E222 multiple spaces after > operator > ipaserver/install/server/upgrade.py:1288:1: E302 expected 2 blank lines, > found 1 > ipaserver/install/server/upgrade.py:1301:1: E302 expected 2 blank lines, > found 1 > ipaserver/install/server/upgrade.py:1307:17: E225 missing whitespace around > operator > ipaserver/install/server/upgrade.py:1334:80: E501 line too long (81 > 79 > characters) > ipaserver/install/server/upgrade.py:1339:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:1341:17: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:1389:13: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:1399:21: E128 continuation line > under-indented for visual indent > ipaserver/install/server/upgrade.py:1400:30: E225 missing whitespace around > operator > ipaserver/install/server/upgrade.py:1440:80: E501 line too long (80 > 79 > characters) > ipaserver/install/server/upgrade.py:1465:14: E111 indentation is not a > multiple of four > ipaserver/install/server/upgrade.py:1519:27: E126 continuation line > over-indented for hanging indent > ipaserver/install/server/upgrade.py:1531:26: E126 continuation line > over-indented for hanging indent > ipaserver/install/server/upgrade.py:1583:80: E501 line too long (96 > 79 > characters) > ipaserver/install/server/upgrade.py:1601:26: E128 continuation line > under-indented for visual indent > > > ----- Original Message ----- > > From: "Jan Cholasta" > > To: "freeipa-devel" > > Sent: Monday, October 12, 2015 3:11:09 PM > > Subject: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected > > in export_kra_agent_pem > > > > Hi, > > > > the attached patch fixes . > > > > Honza > > > > -- > > Jan Cholasta > > > > -- > > 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 > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > From jcholast at redhat.com Mon Oct 12 13:49:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Oct 2015 15:49:06 +0200 Subject: [Freeipa-devel] [PATCH 502] schema: do not derive ipaVaultPublicKey from ipaPublicKey In-Reply-To: <20151012074925.GA4873@redhat.com> References: <561B5E32.2060909@redhat.com> <20151012074925.GA4873@redhat.com> Message-ID: <561BBA52.5030006@redhat.com> On 12.10.2015 09:49, Alexander Bokovoy wrote: > On Mon, 12 Oct 2015, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . > ACK, given Thierry's comment #32 in the bug > https://bugzilla.redhat.com/show_bug.cgi?id=1267782 Thanks. Pushed to: master: 275e1482de279081ca90ee2951bf379fbdab887f ipa-4-2: e92da55444d6b35b25246af811d6c30eee39d93b -- Jan Cholasta From jcholast at redhat.com Mon Oct 12 13:51:53 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Oct 2015 15:51:53 +0200 Subject: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected in export_kra_agent_pem In-Reply-To: <377546396.28854073.1444657628245.JavaMail.zimbra@redhat.com> References: <561BB16D.6030202@redhat.com> <1866326804.28853314.1444657551005.JavaMail.zimbra@redhat.com> <377546396.28854073.1444657628245.JavaMail.zimbra@redhat.com> Message-ID: <561BBAF9.7040407@redhat.com> Thanks. Pushed to: master: 61bdbd6e47b2cd2a62f7e50a6a6cbd2e272470d9 ipa-4-2: 9182f40ac549fc0104878a5599c9effe4f80c3ec On 12.10.2015 15:47, Ale? Mare?ek wrote: > ok, it's not fault of patch itself, ACK > > ----- Original Message ----- >> From: "Ale? Mare?ek" >> To: "Jan Cholasta" >> Cc: "freeipa-devel" >> Sent: Monday, October 12, 2015 3:45:51 PM >> Subject: Re: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected in export_kra_agent_pem >> >> Hello, >> the patch looks good but pep8 cries: >> >> # pep8 ipaserver/install/server/upgrade.py >> ipaserver/install/server/upgrade.py:53:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:68:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:83:25: E261 at least two spaces before >> inline comment >> ipaserver/install/server/upgrade.py:88:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:94:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:96:13: E225 missing whitespace around >> operator >> ipaserver/install/server/upgrade.py:109:80: E501 line too long (93 > 79 >> characters) >> ipaserver/install/server/upgrade.py:111:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:131:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:151:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:172:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:179:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:192:80: E501 line too long (108 > 79 >> characters) >> ipaserver/install/server/upgrade.py:196:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:217:49: E231 missing whitespace after ',' >> ipaserver/install/server/upgrade.py:222:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:228:80: E501 line too long (83 > 79 >> characters) >> ipaserver/install/server/upgrade.py:264:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:277:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:333:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:366:80: E501 line too long (82 > 79 >> characters) >> ipaserver/install/server/upgrade.py:414:49: E251 unexpected spaces around >> keyword / parameter equals >> ipaserver/install/server/upgrade.py:414:51: E251 unexpected spaces around >> keyword / parameter equals >> ipaserver/install/server/upgrade.py:441:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:455:56: E127 continuation line >> over-indented for visual indent >> ipaserver/install/server/upgrade.py:459:25: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:487:37: E126 continuation line >> over-indented for hanging indent >> ipaserver/install/server/upgrade.py:494:17: E126 continuation line >> over-indented for hanging indent >> ipaserver/install/server/upgrade.py:503:80: E501 line too long (81 > 79 >> characters) >> ipaserver/install/server/upgrade.py:504:25: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:511:80: E501 line too long (81 > 79 >> characters) >> ipaserver/install/server/upgrade.py:517:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:538:80: E501 line too long (83 > 79 >> characters) >> ipaserver/install/server/upgrade.py:539:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:541:80: E501 line too long (82 > 79 >> characters) >> ipaserver/install/server/upgrade.py:542:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:551:80: E501 line too long (89 > 79 >> characters) >> ipaserver/install/server/upgrade.py:552:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:554:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:556:80: E501 line too long (86 > 79 >> characters) >> ipaserver/install/server/upgrade.py:557:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:561:80: E501 line too long (91 > 79 >> characters) >> ipaserver/install/server/upgrade.py:562:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:577:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:603:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:606:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:611:80: E501 line too long (80 > 79 >> characters) >> ipaserver/install/server/upgrade.py:616:80: E501 line too long (81 > 79 >> characters) >> ipaserver/install/server/upgrade.py:619:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:627:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:640:80: E501 line too long (85 > 79 >> characters) >> ipaserver/install/server/upgrade.py:643:80: E501 line too long (84 > 79 >> characters) >> ipaserver/install/server/upgrade.py:644:21: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:652:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:664:80: E501 line too long (84 > 79 >> characters) >> ipaserver/install/server/upgrade.py:666:17: E126 continuation line >> over-indented for hanging indent >> ipaserver/install/server/upgrade.py:672:80: E501 line too long (85 > 79 >> characters) >> ipaserver/install/server/upgrade.py:675:80: E501 line too long (86 > 79 >> characters) >> ipaserver/install/server/upgrade.py:676:21: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:679:80: E501 line too long (95 > 79 >> characters) >> ipaserver/install/server/upgrade.py:681:80: E501 line too long (82 > 79 >> characters) >> ipaserver/install/server/upgrade.py:684:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:699:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:702:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:707:80: E501 line too long (84 > 79 >> characters) >> ipaserver/install/server/upgrade.py:714:80: E501 line too long (81 > 79 >> characters) >> ipaserver/install/server/upgrade.py:716:80: E501 line too long (80 > 79 >> characters) >> ipaserver/install/server/upgrade.py:717:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:721:5: E303 too many blank lines (2) >> ipaserver/install/server/upgrade.py:724:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:733:80: E501 line too long (84 > 79 >> characters) >> ipaserver/install/server/upgrade.py:738:80: E501 line too long (86 > 79 >> characters) >> ipaserver/install/server/upgrade.py:739:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:741:80: E501 line too long (86 > 79 >> characters) >> ipaserver/install/server/upgrade.py:742:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:746:80: E501 line too long (85 > 79 >> characters) >> ipaserver/install/server/upgrade.py:747:80: E501 line too long (94 > 79 >> characters) >> ipaserver/install/server/upgrade.py:754:80: E501 line too long (81 > 79 >> characters) >> ipaserver/install/server/upgrade.py:756:80: E501 line too long (89 > 79 >> characters) >> ipaserver/install/server/upgrade.py:757:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:761:5: E303 too many blank lines (2) >> ipaserver/install/server/upgrade.py:761:80: E501 line too long (86 > 79 >> characters) >> ipaserver/install/server/upgrade.py:764:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:781:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:786:80: E501 line too long (80 > 79 >> characters) >> ipaserver/install/server/upgrade.py:794:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:798:5: E303 too many blank lines (2) >> ipaserver/install/server/upgrade.py:801:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:872:80: E501 line too long (80 > 79 >> characters) >> ipaserver/install/server/upgrade.py:924:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:940:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:949:1: E302 expected 2 blank lines, found >> 1 >> ipaserver/install/server/upgrade.py:967:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:968:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:971:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:999:80: E501 line too long (81 > 79 >> characters) >> ipaserver/install/server/upgrade.py:1003:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:1004:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:1007:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:1069:19: E222 multiple spaces after >> operator >> ipaserver/install/server/upgrade.py:1288:1: E302 expected 2 blank lines, >> found 1 >> ipaserver/install/server/upgrade.py:1301:1: E302 expected 2 blank lines, >> found 1 >> ipaserver/install/server/upgrade.py:1307:17: E225 missing whitespace around >> operator >> ipaserver/install/server/upgrade.py:1334:80: E501 line too long (81 > 79 >> characters) >> ipaserver/install/server/upgrade.py:1339:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:1341:17: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:1389:13: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:1399:21: E128 continuation line >> under-indented for visual indent >> ipaserver/install/server/upgrade.py:1400:30: E225 missing whitespace around >> operator >> ipaserver/install/server/upgrade.py:1440:80: E501 line too long (80 > 79 >> characters) >> ipaserver/install/server/upgrade.py:1465:14: E111 indentation is not a >> multiple of four >> ipaserver/install/server/upgrade.py:1519:27: E126 continuation line >> over-indented for hanging indent >> ipaserver/install/server/upgrade.py:1531:26: E126 continuation line >> over-indented for hanging indent >> ipaserver/install/server/upgrade.py:1583:80: E501 line too long (96 > 79 >> characters) >> ipaserver/install/server/upgrade.py:1601:26: E128 continuation line >> under-indented for visual indent >> >> >> ----- Original Message ----- >>> From: "Jan Cholasta" >>> To: "freeipa-devel" >>> Sent: Monday, October 12, 2015 3:11:09 PM >>> Subject: [Freeipa-devel] [PATCH 503] upgrade: make sure ldap2 is connected >>> in export_kra_agent_pem >>> >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >>> -- >>> Jan Cholasta >>> >>> -- >>> 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 >> >> -- >> 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 >> -- Jan Cholasta From mbabinsk at redhat.com Mon Oct 12 14:35:25 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 12 Oct 2015 16:35:25 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records Message-ID: <561BC52D.6030301@redhat.com> https://fedorahosted.org/freeipa/ticket/5200 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0083-perform-an-unlimited-search-for-reverse-zones-when-a.patch Type: text/x-patch Size: 981 bytes Desc: not available URL: From redhatrises at gmail.com Mon Oct 12 15:12:19 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 12 Oct 2015 09:12:19 -0600 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: <561B5786.8070207@redhat.com> References: <561B5786.8070207@redhat.com> Message-ID: Thanks, Petr. Updated patch attached. Gabe On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek wrote: > Hello Gabe, > > thank you for your patch! > > Please note that there might be a case where detection is_ipa_configured() > is > broken but the user still needs to run the uninstall process to clean it > up. > > Could you amend the patch to respect --force option? In that case the > detection should be skipped. > > Thank you for your time! > > Petr^2 Spacek > > On 9.10.2015 19:17, Gabe Alford wrote: > > diff --git a/ipaserver/install/server/install.py > b/ipaserver/install/server/install.py > > index > 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 > 100644 > > --- a/ipaserver/install/server/install.py > > +++ b/ipaserver/install/server/install.py > > @@ -954,6 +954,12 @@ def uninstall_check(installer): > > > > installer._installation_cleanup = False > > > > + if not is_ipa_configured(): > > + print("IPA server is not configured on this system.\n" + > > + "If you want to install the IPA server, please install " + > > + "it using 'ipa-server-install'.") > > + sys.exit(1) > > + > > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) > > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) > > -- > 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-0057-2-Warn-if-no-installation-found-when-running-ipa-serve.patch Type: text/x-patch Size: 2088 bytes Desc: not available URL: From janorel at gmail.com Mon Oct 12 15:28:37 2015 From: janorel at gmail.com (Jan Orel) Date: Mon, 12 Oct 2015 17:28:37 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> References: <5617B56E.7000807@redhat.com> <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> Message-ID: > Agreed. The corresponding checks for certificate issuance via > cert-request, where the bind principal is a host, check that the > subject host (and SAN dNSNames) is "managed by" the bind host. > This is checked via `ldap.can_write(dn_of_subject_principal)'. > > 1. retrieve cert > 2. read CN > 3. ensure CN refers to a known host principal > and call ldap.can_write(...) to ensure bind principal > manages it. > Thanks for the feedback. Attaching new patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-xorel-0001-2-cert-show-verify-write-access-to-userCertificate.patch Type: text/x-patch Size: 2085 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 12 15:51:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Oct 2015 17:51:50 +0200 Subject: [Freeipa-devel] [PATCHES 0321 - 0322] CI: vault CI test In-Reply-To: <561BB31F.6030409@redhat.com> References: <56169FA3.5060607@redhat.com> <561B9B6E.1060906@redhat.com> <561BB31F.6030409@redhat.com> Message-ID: <561BD716.2030606@redhat.com> On 12.10.2015 15:18, Martin Basti wrote: > > > On 12.10.2015 13:37, Milan Kub?k wrote: >> On 10/08/2015 06:53 PM, Martin Basti wrote: >>> Patches attached. >>> >>> Tests for https://fedorahosted.org/freeipa/ticket/5302 >>> >>> >> LGTM, ACK. >> >> -- >> Milan Kubik > Pushed to: > ipa-4-2: ad345b4e2572cbc5ce26501f4a73fc4eb02bfaf0 > master: 573d3323afa558c791fc0ad2a788b75e33144481 > > > I accidentally pushed just one patch, here is the rest Pushed to: ipa-4-2: a23b1ca0562707562dac16b4ecd352e1fd571b0f master: 5f3784520b5183a75f85b3c235b1e9178c0d5e2f -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Mon Oct 12 15:57:36 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 12 Oct 2015 17:57:36 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface Message-ID: <561BD870.8040107@redhat.com> https://fedorahosted.org/freeipa/ticket/5222 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0084-hide-topology-segment-direction-in-topology-command-.patch Type: text/x-patch Size: 4516 bytes Desc: not available URL: From rcritten at redhat.com Mon Oct 12 16:00:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2015 12:00:10 -0400 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: References: <5617B56E.7000807@redhat.com> <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> Message-ID: <561BD90A.9080000@redhat.com> Jan Orel wrote: >> Agreed. The corresponding checks for certificate issuance via >> cert-request, where the bind principal is a host, check that the >> subject host (and SAN dNSNames) is "managed by" the bind host. >> This is checked via `ldap.can_write(dn_of_subject_principal)'. >> >> 1. retrieve cert >> 2. read CN >> 3. ensure CN refers to a known host principal >> and call ldap.can_write(...) to ensure bind principal >> manages it. >> > > Thanks for the feedback. Attaching new patch. > The restriction was there so that hosts had limited visibility. This applies that limitation to all users. I think the host check needs to be re-added. Also, every host is not guaranteed to have a krbPrincipalAux (it can be unenrolled). I assume you used this to cover managed services as well, that's why the broad search base? rob From jcholast at redhat.com Tue Oct 13 06:31:48 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Oct 2015 08:31:48 +0200 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: References: <561B5786.8070207@redhat.com> Message-ID: <561CA554.505@redhat.com> Hi, I don't think this is the correct approach. We are aiming to have idempotent installers, which means that running uninstall on a system without IPA installed should be a no-op. This is the current behavior, so your patch is actually moving us back. The proper fix would be to *remove* the check from install (as opposed to adding it to uninstall), but this requires the install code to be idempotent, and we're not there yet. I'm OK with making this a warning, but don't make it a fatal error and/or require --force. Honza On 12.10.2015 17:12, Gabe Alford wrote: > Thanks, Petr. Updated patch attached. > > Gabe > > On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek > wrote: > > Hello Gabe, > > thank you for your patch! > > Please note that there might be a case where detection > is_ipa_configured() is > broken but the user still needs to run the uninstall process to > clean it up. > > Could you amend the patch to respect --force option? In that case the > detection should be skipped. > > Thank you for your time! > > Petr^2 Spacek > > On 9.10.2015 19:17, Gabe Alford wrote: > > diff --git a/ipaserver/install/server/install.py > b/ipaserver/install/server/install.py > > index > 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 > 100644 > > --- a/ipaserver/install/server/install.py > > +++ b/ipaserver/install/server/install.py > > @@ -954,6 +954,12 @@ def uninstall_check(installer): > > > > installer._installation_cleanup = False > > > > + if not is_ipa_configured(): > > + print("IPA server is not configured on this system.\n" + > > + "If you want to install the IPA server, please > install " + > > + "it using 'ipa-server-install'.") > > + sys.exit(1) > > + > > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) > > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) > > -- > 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 > > > > -- Jan Cholasta From pspacek at redhat.com Tue Oct 13 06:39:03 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Oct 2015 08:39:03 +0200 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: <561CA554.505@redhat.com> References: <561B5786.8070207@redhat.com> <561CA554.505@redhat.com> Message-ID: <561CA707.3050800@redhat.com> Hello Gabe, I would like to apologize for the confusion regarding this patch and the repeated reworking. Unfortunately Honza's position is not mentioned in the ticket so you could not know what to do, but Honza is our "installer architect" so he has final say. Petr^2 Spacek On 13.10.2015 08:31, Jan Cholasta wrote: > Hi, > > I don't think this is the correct approach. We are aiming to have idempotent > installers, which means that running uninstall on a system without IPA > installed should be a no-op. This is the current behavior, so your patch is > actually moving us back. > > The proper fix would be to *remove* the check from install (as opposed to > adding it to uninstall), but this requires the install code to be idempotent, > and we're not there yet. > > I'm OK with making this a warning, but don't make it a fatal error and/or > require --force. > > Honza > > On 12.10.2015 17:12, Gabe Alford wrote: >> Thanks, Petr. Updated patch attached. >> >> Gabe >> >> On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek > > wrote: >> >> Hello Gabe, >> >> thank you for your patch! >> >> Please note that there might be a case where detection >> is_ipa_configured() is >> broken but the user still needs to run the uninstall process to >> clean it up. >> >> Could you amend the patch to respect --force option? In that case the >> detection should be skipped. >> >> Thank you for your time! >> >> Petr^2 Spacek >> >> On 9.10.2015 19:17, Gabe Alford wrote: >> > diff --git a/ipaserver/install/server/install.py >> b/ipaserver/install/server/install.py >> > index >> >> 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 >> >> 100644 >> > --- a/ipaserver/install/server/install.py >> > +++ b/ipaserver/install/server/install.py >> > @@ -954,6 +954,12 @@ def uninstall_check(installer): >> > >> > installer._installation_cleanup = False >> > >> > + if not is_ipa_configured(): >> > + print("IPA server is not configured on this system.\n" + >> > + "If you want to install the IPA server, please >> install " + >> > + "it using 'ipa-server-install'.") >> > + sys.exit(1) >> > + >> > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) >> > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) From pspacek at redhat.com Tue Oct 13 07:17:39 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Oct 2015 09:17:39 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561B9B9F.90002@redhat.com> References: <561B9B9F.90002@redhat.com> Message-ID: <561CB013.2080406@redhat.com> On 12.10.2015 13:38, Martin Babinsky wrote: > > each service possessing Kerberos keytab wiil now remove it and destroy any > associated credentials cache during its uninstall > > https://fedorahosted.org/freeipa/ticket/5243 BTW some time ago Simo proposed that we should remove caches and old keytabs during *install* so problems caused by failing uninstallation will be fixed on repeated install. This is yet another step towards idempotent installer. To me this makes more sense than doing so on uninstall. Does it make sense to you, too? -- Petr^2 Spacek From mbabinsk at redhat.com Tue Oct 13 07:34:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Oct 2015 09:34:39 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CB013.2080406@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> Message-ID: <561CB40F.7020405@redhat.com> On 10/13/2015 09:17 AM, Petr Spacek wrote: > On 12.10.2015 13:38, Martin Babinsky wrote: >> >> each service possessing Kerberos keytab wiil now remove it and destroy any >> associated credentials cache during its uninstall >> >> https://fedorahosted.org/freeipa/ticket/5243 > > BTW some time ago Simo proposed that we should remove caches and old keytabs > during *install* so problems caused by failing uninstallation will be fixed on > repeated install. This is yet another step towards idempotent installer. > > To me this makes more sense than doing so on uninstall. Does it make sense to > you, too? > If the problem is formulated like this (the endpoint is that services have their keytabs) then it makes more sense to me. I will rework the patch accordingly. -- Martin^3 Babinsky From pspacek at redhat.com Tue Oct 13 07:36:38 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Oct 2015 09:36:38 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <561BC52D.6030301@redhat.com> References: <561BC52D.6030301@redhat.com> Message-ID: <561CB486.2020906@redhat.com> On 12.10.2015 16:35, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5200 > --- > ipalib/plugins/dns.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): > if prefixlen is None: > revzone = None > > - result = api.Command['dnszone_find']()['result'] > + result = api.Command['dnszone_find'](sizelimit=0)['result'] > + NACK, this just increases the limit because LDAP server will enforce a per-user limit. > for zone in result: > zonename = zone['idnsname'][0] > if (revdns.is_subdomain(zonename.make_absolute()) and Generic solution should use dns.resolver.zone_for_name() to find DNS zone matching the reverse name. This should also implicitly cover CNAME/DNAME redirections per RFC2317. Using DNS implicitly means that a zone will always be found (at least the root zone :-). For this reason I would change final error message > reason=_('DNS reverse zone for IP address %(addr)s not found') to something like: reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not managed by this server') These changes should fix it without adding other artificial limitation. -- Petr^2 Spacek From jcholast at redhat.com Tue Oct 13 07:40:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Oct 2015 09:40:38 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <560D3381.1090108@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> <560AE70B.5020700@redhat.com> <560D05C3.5020005@redhat.com> <560D0AFE.6020204@redhat.com> <560D0D5E.5090604@redhat.com> <560D1C2F.5080606@redhat.com> <560D3381.1090108@redhat.com> Message-ID: <561CB576.1050705@redhat.com> On 1.10.2015 15:22, Simo Sorce wrote: > On 01/10/15 07:42, Jan Cholasta wrote: >> Hi, >> >> I have just imported python-jwcrypto, custodia and pki-core-10.2.7 into >> mkosek/freeipa-master as well, to (hopefully) make things easier. >> >> Simo, custodia failed to build F22, any idea why? See >> . >> > > On the surface it looks like a missing dependency on cffi, though I am > not sure why we'd need it, maybe the tests are downloading cryptography > to build it for non-system python versions ? The issue is that the %autosetup macro does not apply patches on F22. I verified this on a F22 VM with "rpmspec -P custodia.spec". I fixed this by replacing "%autosetup" with "%setup -q" and "%patch -P 01 -p 1". -- Jan Cholasta From ofayans at redhat.com Tue Oct 13 08:02:04 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 13 Oct 2015 10:02:04 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561BD870.8040107@redhat.com> References: <561BD870.8040107@redhat.com> Message-ID: <561CBA7C.1090003@redhat.com> NACK UI still shows the connectivity information at http:///ipa/ui/#/e/topologysuffix/topologysegment/realm CLI is OK, though On 10/12/2015 05:57 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5222 > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pspacek at redhat.com Tue Oct 13 08:04:54 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Oct 2015 10:04:54 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CB40F.7020405@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> Message-ID: <561CBB26.5000707@redhat.com> On 13.10.2015 09:34, Martin Babinsky wrote: > On 10/13/2015 09:17 AM, Petr Spacek wrote: >> On 12.10.2015 13:38, Martin Babinsky wrote: >>> >>> each service possessing Kerberos keytab wiil now remove it and destroy any >>> associated credentials cache during its uninstall >>> >>> https://fedorahosted.org/freeipa/ticket/5243 >> >> BTW some time ago Simo proposed that we should remove caches and old keytabs >> during *install* so problems caused by failing uninstallation will be fixed on >> repeated install. This is yet another step towards idempotent installer. >> >> To me this makes more sense than doing so on uninstall. Does it make sense to >> you, too? >> > > If the problem is formulated like this (the endpoint is that services have > their keytabs) then it makes more sense to me. I will rework the patch > accordingly. Adding Simo to Cc, so we can be sure that we understood it properly :-) Simo, does it make sense to do that on installation rather than installation? -- Petr^2 Spacek From pvoborni at redhat.com Tue Oct 13 08:15:50 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Oct 2015 10:15:50 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CBA7C.1090003@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> Message-ID: <561CBDB6.7000202@redhat.com> On 10/13/2015 10:02 AM, Oleg Fayans wrote: > NACK > > UI still shows the connectivity information at > > http:///ipa/ui/#/e/topologysuffix/topologysegment/realm Showing it is correct and desired - both in CLI and Web UI. The end state should be that UIs will create new segments with direction=both and they will not allow to modify it. So the issue, ticket #5222 is IMO about, is that CLI asks for a value in interactive prompt which could be used to change the value from both to some other. > > CLI is OK, though > > On 10/12/2015 05:57 PM, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5222 >> -- Petr Vobornik From jcholast at redhat.com Tue Oct 13 08:18:02 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Oct 2015 10:18:02 +0200 Subject: [Freeipa-devel] [PATCH 504] vault: fix service name normalization Message-ID: <561CBE3A.5090003@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-504-vault-fix-service-name-normalization.patch Type: text/x-patch Size: 1073 bytes Desc: not available URL: From ofayans at redhat.com Tue Oct 13 08:37:45 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 13 Oct 2015 10:37:45 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CBDB6.7000202@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> Message-ID: <561CC2D9.7080707@redhat.com> On 10/13/2015 10:15 AM, Petr Vobornik wrote: > On 10/13/2015 10:02 AM, Oleg Fayans wrote: >> NACK >> >> UI still shows the connectivity information at >> >> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm > > Showing it is correct and desired - both in CLI and Web UI. Well, CLI does not show the connectivity information at both topologysegment-find and topologysegment-show. I guess, it's no use in showing the parameters of a segment, that you are not able to change anyway. It unnecessarily perplexes the users. In any case we should be consistent in what we show in CLI and UI. Either hide in both or show in both. And in my opinion is that it's better to hide :) > > The end state should be that UIs will create new segments with > direction=both and they will not allow to modify it. > > So the issue, ticket #5222 is IMO about, is that CLI asks for a value in > interactive prompt which could be used to change the value from both to > some other. > >> >> CLI is OK, though >> >> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5222 >>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From lkrispen at redhat.com Tue Oct 13 08:41:20 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 13 Oct 2015 10:41:20 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CBDB6.7000202@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> Message-ID: <561CC3B0.6050103@redhat.com> On 10/13/2015 10:15 AM, Petr Vobornik wrote: > On 10/13/2015 10:02 AM, Oleg Fayans wrote: >> NACK >> >> UI still shows the connectivity information at >> >> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm > > Showing it is correct and desired - both in CLI and Web UI. agree, it is also information helpful in trouble shooting > > The end state should be that UIs will create new segments with > direction=both and they will not allow to modify it. > > So the issue, ticket #5222 is IMO about, is that CLI asks for a value > in interactive prompt which could be used to change the value from > both to some other. > >> >> CLI is OK, though >> >> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5222 >>> From mbabinsk at redhat.com Tue Oct 13 10:19:03 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Oct 2015 12:19:03 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CBDB6.7000202@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> Message-ID: <561CDA97.4040909@redhat.com> On 10/13/2015 10:15 AM, Petr Vobornik wrote: > On 10/13/2015 10:02 AM, Oleg Fayans wrote: >> NACK >> >> UI still shows the connectivity information at >> >> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm > > Showing it is correct and desired - both in CLI and Web UI. > So IIUC the segment connectivity should not be asked interactively, but when topology-show command is run it should show up in the output? > The end state should be that UIs will create new segments with > direction=both and they will not allow to modify it. > > So the issue, ticket #5222 is IMO about, is that CLI asks for a value in > interactive prompt which could be used to change the value from both to > some other. > >> >> CLI is OK, though >> >> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5222 >>> -- Martin^3 Babinsky From tbabej at redhat.com Tue Oct 13 10:21:09 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 12:21:09 +0200 Subject: [Freeipa-devel] [PATCH 373-374] idoverrides: Ignore SID conversion error and add coverage Message-ID: <561CDB15.2080206@redhat.com> Hi, this couple of patches fixes and improves the coverage for referential integrity of ID overrides. Note: Last test in the patch 374 is supposed to be failing (for now). https://fedorahosted.org/freeipa/ticket/5322 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0373-idoverride-Ignore-ValidationErrors-when-converting-t.patch Type: text/x-patch Size: 2583 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0374-tests-Add-tests-for-idoverride-object-integrity.patch Type: text/x-patch Size: 7794 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 13 10:24:32 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Oct 2015 12:24:32 +0200 Subject: [Freeipa-devel] [PATCH 504] vault: fix service name normalization In-Reply-To: <561CBE3A.5090003@redhat.com> References: <561CBE3A.5090003@redhat.com> Message-ID: <561CDBE0.9010300@redhat.com> On 13.10.2015 10:18, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Decided to use a slightly different approach, updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-504.1-vault-fix-private-service-vault-creation.patch Type: text/x-patch Size: 3860 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 13 10:34:57 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Oct 2015 12:34:57 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CDA97.4040909@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561CDA97.4040909@redhat.com> Message-ID: <561CDE51.1000202@redhat.com> On 10/13/2015 12:19 PM, Martin Babinsky wrote: > On 10/13/2015 10:15 AM, Petr Vobornik wrote: >> On 10/13/2015 10:02 AM, Oleg Fayans wrote: >>> NACK >>> >>> UI still shows the connectivity information at >>> >>> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm >> >> Showing it is correct and desired - both in CLI and Web UI. >> > > So IIUC the segment connectivity should not be asked interactively, but > when topology-show command is run it should show up in the output? That's correct. > >> The end state should be that UIs will create new segments with >> direction=both and they will not allow to modify it. >> >> So the issue, ticket #5222 is IMO about, is that CLI asks for a value in >> interactive prompt which could be used to change the value from both to >> some other. >> >>> >>> CLI is OK, though >>> >>> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5222 >>>> > > -- Petr Vobornik From ofayans at redhat.com Tue Oct 13 10:43:57 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 13 Oct 2015 12:43:57 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CDE51.1000202@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561CDA97.4040909@redhat.com> <561CDE51.1000202@redhat.com> Message-ID: <561CE06D.8010707@redhat.com> Hi guys, On 10/13/2015 12:34 PM, Petr Vobornik wrote: > On 10/13/2015 12:19 PM, Martin Babinsky wrote: >> On 10/13/2015 10:15 AM, Petr Vobornik wrote: >>> On 10/13/2015 10:02 AM, Oleg Fayans wrote: >>>> NACK >>>> >>>> UI still shows the connectivity information at >>>> >>>> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm >>> >>> Showing it is correct and desired - both in CLI and Web UI. >>> >> >> So IIUC the segment connectivity should not be asked interactively, but >> when topology-show command is run it should show up in the output? > > That's correct. Still I do not understand what's the point in showing the user parameters which he can not possibly change. Is there a use-case when the connectivity can be anything else than "both"? If not, why should we complicate the output? > >> >>> The end state should be that UIs will create new segments with >>> direction=both and they will not allow to modify it. >>> >>> So the issue, ticket #5222 is IMO about, is that CLI asks for a value in >>> interactive prompt which could be used to change the value from both to >>> some other. >>> >>>> >>>> CLI is OK, though >>>> >>>> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5222 >>>>> >> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From tbabej at redhat.com Tue Oct 13 10:49:04 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 12:49:04 +0200 Subject: [Freeipa-devel] [PATCH 0059] ipa-adtrust-install: Print complete SRV record In-Reply-To: <5617BA30.2030604@redhat.com> References: <5617BA30.2030604@redhat.com> Message-ID: <561CE1A0.5010203@redhat.com> On 10/09/2015 02:59 PM, Petr Spacek wrote: > Hello, > > I found this when reviewing DNS parts of IdM and AD integration guides. > > ipa-adtrust-install: Print complete SRV records. > https://fedorahosted.org/freeipa/ticket/5358 > > > ACK, generates correct output. _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 389 master _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 master _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 master _ldap._tcp.dc._msdcs IN SRV 0 100 389 master _kerberos._tcp.dc._msdcs IN SRV 0 100 88 master _kerberos._udp.dc._msdcs IN SRV 0 100 88 master Tomas From lkrispen at redhat.com Tue Oct 13 10:55:02 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 13 Oct 2015 12:55:02 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CE06D.8010707@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561CDA97.4040909@redhat.com> <561CDE51.1000202@redhat.com> <561CE06D.8010707@redhat.com> Message-ID: <561CE306.90704@redhat.com> On 10/13/2015 12:43 PM, Oleg Fayans wrote: > Hi guys, > > On 10/13/2015 12:34 PM, Petr Vobornik wrote: >> On 10/13/2015 12:19 PM, Martin Babinsky wrote: >>> On 10/13/2015 10:15 AM, Petr Vobornik wrote: >>>> On 10/13/2015 10:02 AM, Oleg Fayans wrote: >>>>> NACK >>>>> >>>>> UI still shows the connectivity information at >>>>> >>>>> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm >>>> >>>> Showing it is correct and desired - both in CLI and Web UI. >>>> >>> >>> So IIUC the segment connectivity should not be asked interactively, but >>> when topology-show command is run it should show up in the output? >> >> That's correct. > > Still I do not understand what's the point in showing the user > parameters which he can not possibly change. Is there a use-case when > the connectivity can be anything else than "both"? If not, why should > we complicate the output? it's the property of a segment. After the segment is created also leftnode and rightnode can no longer be changed - would you hide them ? during replica install all segments are initially created from an agreement as left-right and then merged, the connectivity could indicate a failure during install. it is just informational, but it doesn't hurt beingthere > >> >>> >>>> The end state should be that UIs will create new segments with >>>> direction=both and they will not allow to modify it. >>>> >>>> So the issue, ticket #5222 is IMO about, is that CLI asks for a >>>> value in >>>> interactive prompt which could be used to change the value from >>>> both to >>>> some other. >>>> >>>>> >>>>> CLI is OK, though >>>>> >>>>> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5222 >>>>>> >>> >>> >> >> > From tbabej at redhat.com Tue Oct 13 11:13:13 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 13:13:13 +0200 Subject: [Freeipa-devel] [PATCH 0009] WebUI: Disappearing automember rule expressions In-Reply-To: <5617A909.8060508@redhat.com> References: <5617A909.8060508@redhat.com> Message-ID: <561CE749.4070208@redhat.com> On 10/09/2015 01:46 PM, Stanislav Laznicka wrote: > Hi, > please see the patch attached. > > Standa L. > > ACK, works as desired. Tomas From jpazdziora at redhat.com Tue Oct 13 11:14:18 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 13 Oct 2015 13:14:18 +0200 Subject: [Freeipa-devel] [PATCH 5] The delegation uris are not set, match message to code Message-ID: <20151013111418.GA357@redhat.com> One-liner. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -------------- next part -------------- >From 612495129cb84fca972c0331adc591ea59dafd21 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora Date: Tue, 13 Oct 2015 13:07:24 +0200 Subject: [PATCH] The delegation uris are not set, match message to code. --- ipa-client/ipa-install/ipa-client-install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index c50ea67cbf9b878c4b5aab4ae83cd9d46ee503cf..e38a0f2f970087791b18fff3137bdb1bc9ac2470 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -2194,7 +2194,7 @@ def configure_firefox(options, statestore, domain): root_logger.debug("Firefox preferences directory found '%s'." % preferences_dir) preferences_fname = os.path.join(preferences_dir, FIREFOX_PREFERENCES_FILENAME) update_txt = ipautil.template_str(FIREFOX_CONFIG_TEMPLATE, dict(DOMAIN=domain)) - root_logger.debug("Firefox trusted and delegation uris will be set as '.%s' domain." % domain) + root_logger.debug("Firefox trusted uris will be set as '.%s' domain." % domain) root_logger.debug("Firefox configuration will be stored in '%s' file." % preferences_fname) try: -- 2.4.3 From tbabej at redhat.com Tue Oct 13 11:18:15 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 13:18:15 +0200 Subject: [Freeipa-devel] [PATCH 5] The delegation uris are not set, match message to code In-Reply-To: <20151013111418.GA357@redhat.com> References: <20151013111418.GA357@redhat.com> Message-ID: <561CE877.6070702@redhat.com> On 10/13/2015 01:14 PM, Jan Pazdziora wrote: > > One-liner. > > > ACK, network.negotiate-auth.delegation-uris is indeed not being set. Tomas From tbabej at redhat.com Tue Oct 13 11:21:00 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 13:21:00 +0200 Subject: [Freeipa-devel] [PATCH 5] The delegation uris are not set, match message to code In-Reply-To: <561CE877.6070702@redhat.com> References: <20151013111418.GA357@redhat.com> <561CE877.6070702@redhat.com> Message-ID: <561CE91C.603@redhat.com> On 10/13/2015 01:18 PM, Tomas Babej wrote: > > > On 10/13/2015 01:14 PM, Jan Pazdziora wrote: >> >> One-liner. >> >> >> > > ACK, network.negotiate-auth.delegation-uris is indeed not being set. > > Tomas > Pushed to master: 9d7abfaf7a97f3ea0831d1870898c00b7e8d93e3 From ofayans at redhat.com Tue Oct 13 11:26:30 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 13 Oct 2015 13:26:30 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CE306.90704@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561CDA97.4040909@redhat.com> <561CDE51.1000202@redhat.com> <561CE06D.8010707@redhat.com> <561CE306.90704@redhat.com> Message-ID: <561CEA66.8010806@redhat.com> Hi Ludwig, On 10/13/2015 12:55 PM, Ludwig Krispenz wrote: > > On 10/13/2015 12:43 PM, Oleg Fayans wrote: >> Hi guys, >> >> On 10/13/2015 12:34 PM, Petr Vobornik wrote: >>> On 10/13/2015 12:19 PM, Martin Babinsky wrote: >>>> On 10/13/2015 10:15 AM, Petr Vobornik wrote: >>>>> On 10/13/2015 10:02 AM, Oleg Fayans wrote: >>>>>> NACK >>>>>> >>>>>> UI still shows the connectivity information at >>>>>> >>>>>> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm >>>>> >>>>> Showing it is correct and desired - both in CLI and Web UI. >>>>> >>>> >>>> So IIUC the segment connectivity should not be asked interactively, but >>>> when topology-show command is run it should show up in the output? >>> >>> That's correct. >> >> Still I do not understand what's the point in showing the user >> parameters which he can not possibly change. Is there a use-case when >> the connectivity can be anything else than "both"? If not, why should >> we complicate the output? > it's the property of a segment. After the segment is created also > leftnode and rightnode can no longer be changed - would you hide them ? > during replica install all segments are initially created from an > agreement as left-right and then merged, the connectivity could indicate > a failure during install. Oh, OK, that's a fair point. Thank you for clarification! Then - yes, let's return this info into the output of topologysegment-find and *-show commands > it is just informational, but it doesn't hurt beingthere > >> >>> >>>> >>>>> The end state should be that UIs will create new segments with >>>>> direction=both and they will not allow to modify it. >>>>> >>>>> So the issue, ticket #5222 is IMO about, is that CLI asks for a >>>>> value in >>>>> interactive prompt which could be used to change the value from >>>>> both to >>>>> some other. >>>>> >>>>>> >>>>>> CLI is OK, though >>>>>> >>>>>> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5222 >>>>>>> >>>> >>>> >>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Tue Oct 13 11:37:47 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Oct 2015 13:37:47 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <561CB486.2020906@redhat.com> References: <561BC52D.6030301@redhat.com> <561CB486.2020906@redhat.com> Message-ID: <561CED0B.9090009@redhat.com> On 10/13/2015 09:36 AM, Petr Spacek wrote: > On 12.10.2015 16:35, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5200 >> --- >> ipalib/plugins/dns.py | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >> index 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 100644 >> --- a/ipalib/plugins/dns.py >> +++ b/ipalib/plugins/dns.py >> @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): >> if prefixlen is None: >> revzone = None >> >> - result = api.Command['dnszone_find']()['result'] >> + result = api.Command['dnszone_find'](sizelimit=0)['result'] >> + > > NACK, this just increases the limit because LDAP server will enforce a > per-user limit. > >> for zone in result: >> zonename = zone['idnsname'][0] >> if (revdns.is_subdomain(zonename.make_absolute()) and > > Generic solution should use dns.resolver.zone_for_name() to find DNS zone > matching the reverse name. This should also implicitly cover CNAME/DNAME > redirections per RFC2317. > > Using DNS implicitly means that a zone will always be found (at least the root > zone :-). For this reason I would change final error message >> reason=_('DNS reverse zone for IP address %(addr)s not found') > to something like: > reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not managed > by this server') > > > These changes should fix it without adding other artificial limitation. > Thank you for clarification Petr. Attaching the reworked patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0083.1-perform-more-robust-search-for-reverse-zones-when-ad.patch Type: text/x-patch Size: 2777 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 13 11:57:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Oct 2015 13:57:50 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CBB26.5000707@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> <561CBB26.5000707@redhat.com> Message-ID: <561CF1BE.3040906@redhat.com> On 13.10.2015 10:04, Petr Spacek wrote: > On 13.10.2015 09:34, Martin Babinsky wrote: >> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>> associated credentials cache during its uninstall >>>> >>>> https://fedorahosted.org/freeipa/ticket/5243 >>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>> during *install* so problems caused by failing uninstallation will be fixed on >>> repeated install. This is yet another step towards idempotent installer. >>> >>> To me this makes more sense than doing so on uninstall. Does it make sense to >>> you, too? >>> >> If the problem is formulated like this (the endpoint is that services have >> their keytabs) then it makes more sense to me. I will rework the patch >> accordingly. > Adding Simo to Cc, so we can be sure that we understood it properly :-) > > Simo, does it make sense to do that on installation rather than installation? > I would like to keep removing keytabs during uninstall too, IPA should clean own mess. Martin2 From tbabej at redhat.com Tue Oct 13 12:01:28 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 14:01:28 +0200 Subject: [Freeipa-devel] [PATCH 0066] ipactl: Do not start/stop/restart single service multiple times In-Reply-To: <55DEA936.4040709@redhat.com> References: <55DDBC2C.7040807@redhat.com> <55DDE009.8010404@redhat.com> <55DEA936.4040709@redhat.com> Message-ID: <561CF298.60707@redhat.com> On 08/27/2015 08:07 AM, David Kupka wrote: > On 26/08/15 17:49, Tomas Babej wrote: >> >> >> On 08/26/2015 03:16 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/5248 >>> >>> >> >> +def deduplicate(lst): >> + new_lst = [] >> + s = set(lst) >> + for i in lst: >> + if i in s: >> + s.remove(i) >> + new_lst.append(i) >> + >> + return new_lst >> + >> >> Imho, this method deserves a docstring or at least a comment. It is not >> entrirely clear from the name, that its job is to remove the duplicates >> while preserving the order of the entries. >> > > You're right, line or two could not hurt. Patch attached. Obvious ACK from me. Pushed to: master: 5ff4170ff9cab64d3527001de8214cb30439e3e3 ipa-4-2: 9e3d0d6f591496a2370a14832f7c0c399a16b2ea From abokovoy at redhat.com Tue Oct 13 12:15:21 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Oct 2015 15:15:21 +0300 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CF1BE.3040906@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> <561CBB26.5000707@redhat.com> <561CF1BE.3040906@redhat.com> Message-ID: <20151013121521.GR5076@redhat.com> On Tue, 13 Oct 2015, Martin Basti wrote: > > >On 13.10.2015 10:04, Petr Spacek wrote: >>On 13.10.2015 09:34, Martin Babinsky wrote: >>>On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>>On 12.10.2015 13:38, Martin Babinsky wrote: >>>>>each service possessing Kerberos keytab wiil now remove it and destroy any >>>>>associated credentials cache during its uninstall >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/5243 >>>>BTW some time ago Simo proposed that we should remove caches and old keytabs >>>>during *install* so problems caused by failing uninstallation will be fixed on >>>>repeated install. This is yet another step towards idempotent installer. >>>> >>>>To me this makes more sense than doing so on uninstall. Does it make sense to >>>>you, too? >>>> >>>If the problem is formulated like this (the endpoint is that services have >>>their keytabs) then it makes more sense to me. I will rework the patch >>>accordingly. >>Adding Simo to Cc, so we can be sure that we understood it properly :-) >> >>Simo, does it make sense to do that on installation rather than installation? >> > >I would like to keep removing keytabs during uninstall too, IPA should >clean own mess. It is better to remove on installation because we know what the state of the system should be after install. On uninstall we cannot be guaranteed that we wouldn't remove something that wasn't used anymore. Note that removing /etc/krb5.keytab doesn't mean that, for example, Apache will be unusable on this system if it was previously configured. In the ideal environment you don't even need /etc/krb5.conf to have it accepting Kerberos authentication. -- / Alexander Bokovoy From tbabej at redhat.com Tue Oct 13 12:15:27 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 14:15:27 +0200 Subject: [Freeipa-devel] [PATCHES] More Python3 porting In-Reply-To: <56168919.10209@redhat.com> References: <56168919.10209@redhat.com> Message-ID: <561CF5DF.5080304@redhat.com> On 10/08/2015 05:17 PM, Petr Viktorin wrote: > Hello, > Here is another batch of Python 3 porting patches. > I went through the patches both code-wise and functional-tests wise (xmlrpc, CI, manual). Looks&works fine. ACK, thanks for the patchset. Tomas From tbabej at redhat.com Tue Oct 13 12:18:12 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Oct 2015 14:18:12 +0200 Subject: [Freeipa-devel] [PATCHES] More Python3 porting In-Reply-To: <561CF5DF.5080304@redhat.com> References: <56168919.10209@redhat.com> <561CF5DF.5080304@redhat.com> Message-ID: <561CF684.1040606@redhat.com> On 10/13/2015 02:15 PM, Tomas Babej wrote: > > > On 10/08/2015 05:17 PM, Petr Viktorin wrote: >> Hello, >> Here is another batch of Python 3 porting patches. >> > > I went through the patches both code-wise and functional-tests wise > (xmlrpc, CI, manual). Looks&works fine. > > ACK, thanks for the patchset. > > Tomas > Pushed to master: 88fc27da529e2d098a10bac4abb280a0445dfa5f From pvoborni at redhat.com Tue Oct 13 12:18:31 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Oct 2015 14:18:31 +0200 Subject: [Freeipa-devel] [PATCH 504] vault: fix service name normalization In-Reply-To: <561CDBE0.9010300@redhat.com> References: <561CBE3A.5090003@redhat.com> <561CDBE0.9010300@redhat.com> Message-ID: <561CF697.8080402@redhat.com> On 10/13/2015 12:24 PM, Jan Cholasta wrote: > On 13.10.2015 10:18, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Decided to use a slightly different approach, updated patch attached. > Works for me, ACK -- Petr Vobornik From jcholast at redhat.com Tue Oct 13 12:34:27 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Oct 2015 14:34:27 +0200 Subject: [Freeipa-devel] [PATCH 504] vault: fix service name normalization In-Reply-To: <561CF697.8080402@redhat.com> References: <561CBE3A.5090003@redhat.com> <561CDBE0.9010300@redhat.com> <561CF697.8080402@redhat.com> Message-ID: <561CFA53.6080305@redhat.com> On 13.10.2015 14:18, Petr Vobornik wrote: > On 10/13/2015 12:24 PM, Jan Cholasta wrote: >> On 13.10.2015 10:18, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Decided to use a slightly different approach, updated patch attached. >> > > Works for me, ACK Thanks. Pushed to: master: 2f3450249ded2c14d2ca55f15bdcace7007a6ebb ipa-4-2: 285043e3880cf11ed7edd39f2918c1fcdc623cc9 -- Jan Cholasta From simo at redhat.com Tue Oct 13 12:50:32 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Oct 2015 08:50:32 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561CB576.1050705@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> <560AE70B.5020700@redhat.com> <560D05C3.5020005@redhat.com> <560D0AFE.6020204@redhat.com> <560D0D5E.5090604@redhat.com> <560D1C2F.5080606@redhat.com> <560D3381.1090108@redhat.com> <561CB576.1050705@redhat.com> Message-ID: <561CFE18.20103@redhat.com> On 13/10/15 03:40, Jan Cholasta wrote: > On 1.10.2015 15:22, Simo Sorce wrote: >> On 01/10/15 07:42, Jan Cholasta wrote: >>> Hi, >>> >>> I have just imported python-jwcrypto, custodia and pki-core-10.2.7 into >>> mkosek/freeipa-master as well, to (hopefully) make things easier. >>> >>> Simo, custodia failed to build F22, any idea why? See >>> . >>> >>> >> >> On the surface it looks like a missing dependency on cffi, though I am >> not sure why we'd need it, maybe the tests are downloading cryptography >> to build it for non-system python versions ? > > The issue is that the %autosetup macro does not apply patches on F22. I > verified this on a F22 VM with "rpmspec -P custodia.spec". I fixed this > by replacing "%autosetup" with "%setup -q" and "%patch -P 01 -p 1". Ah great, thanks! Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Oct 13 12:52:37 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Oct 2015 08:52:37 -0400 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CBB26.5000707@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> <561CBB26.5000707@redhat.com> Message-ID: <561CFE95.3070703@redhat.com> On 13/10/15 04:04, Petr Spacek wrote: > On 13.10.2015 09:34, Martin Babinsky wrote: >> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>> >>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>> associated credentials cache during its uninstall >>>> >>>> https://fedorahosted.org/freeipa/ticket/5243 >>> >>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>> during *install* so problems caused by failing uninstallation will be fixed on >>> repeated install. This is yet another step towards idempotent installer. >>> >>> To me this makes more sense than doing so on uninstall. Does it make sense to >>> you, too? >>> >> >> If the problem is formulated like this (the endpoint is that services have >> their keytabs) then it makes more sense to me. I will rework the patch >> accordingly. > > Adding Simo to Cc, so we can be sure that we understood it properly :-) > > Simo, does it make sense to do that on installation rather than installation? Actually on a server re-install it may make sense to check if the keytab is valid and keep it if it is. Make sure you do not break promotion by removing the host keytab or keytabs that have been legitimately created in the client. But otherwise the direction is good. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Oct 13 12:58:01 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Oct 2015 14:58:01 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CFE95.3070703@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> <561CBB26.5000707@redhat.com> <561CFE95.3070703@redhat.com> Message-ID: <561CFFD9.20408@redhat.com> On 13.10.2015 14:52, Simo Sorce wrote: > On 13/10/15 04:04, Petr Spacek wrote: >> On 13.10.2015 09:34, Martin Babinsky wrote: >>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>> >>>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>>> associated credentials cache during its uninstall >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>> >>>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>>> during *install* so problems caused by failing uninstallation will be >>>> fixed on >>>> repeated install. This is yet another step towards idempotent installer. >>>> >>>> To me this makes more sense than doing so on uninstall. Does it make sense to >>>> you, too? >>>> >>> >>> If the problem is formulated like this (the endpoint is that services have >>> their keytabs) then it makes more sense to me. I will rework the patch >>> accordingly. >> >> Adding Simo to Cc, so we can be sure that we understood it properly :-) >> >> Simo, does it make sense to do that on installation rather than installation? > > Actually on a server re-install it may make sense to check if the keytab is > valid and keep it if it is. > Make sure you do not break promotion by removing the host keytab or keytabs > that have been legitimately created in the client. I would expect that keytabs created in client installation should not be touched/overwritten at all in server install, right? In other words: ipa-client-install and ipa-replica-promote should be totally separate tools and do not duplicate functionality. -- Petr^2 Spacek From simo at redhat.com Tue Oct 13 13:08:14 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Oct 2015 09:08:14 -0400 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CFFD9.20408@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> <561CBB26.5000707@redhat.com> <561CFE95.3070703@redhat.com> <561CFFD9.20408@redhat.com> Message-ID: <561D023E.3040500@redhat.com> On 13/10/15 08:58, Petr Spacek wrote: > On 13.10.2015 14:52, Simo Sorce wrote: >> On 13/10/15 04:04, Petr Spacek wrote: >>> On 13.10.2015 09:34, Martin Babinsky wrote: >>>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>>> >>>>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>>>> associated credentials cache during its uninstall >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>>> >>>>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>>>> during *install* so problems caused by failing uninstallation will be >>>>> fixed on >>>>> repeated install. This is yet another step towards idempotent installer. >>>>> >>>>> To me this makes more sense than doing so on uninstall. Does it make sense to >>>>> you, too? >>>>> >>>> >>>> If the problem is formulated like this (the endpoint is that services have >>>> their keytabs) then it makes more sense to me. I will rework the patch >>>> accordingly. >>> >>> Adding Simo to Cc, so we can be sure that we understood it properly :-) >>> >>> Simo, does it make sense to do that on installation rather than installation? >> >> Actually on a server re-install it may make sense to check if the keytab is >> valid and keep it if it is. >> Make sure you do not break promotion by removing the host keytab or keytabs >> that have been legitimately created in the client. > > I would expect that keytabs created in client installation should not be > touched/overwritten at all in server install, right? > > In other words: ipa-client-install and ipa-replica-promote should be totally > separate tools and do not duplicate functionality. They don't. But there is no ipa-replica-promote, just ipa-replica-install, which will do promotion (and in future will do client install as well if client is not already installed before going on with promotion code). Simo. -- Simo Sorce * Red Hat, Inc * New York From redhatrises at gmail.com Tue Oct 13 13:15:40 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 13 Oct 2015 07:15:40 -0600 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: <561CA707.3050800@redhat.com> References: <561B5786.8070207@redhat.com> <561CA554.505@redhat.com> <561CA707.3050800@redhat.com> Message-ID: No worries Petr. All a part of the review process. I have attached an updated patch that prints only a warning message. thanks, Gabe On Tue, Oct 13, 2015 at 12:39 AM, Petr Spacek wrote: > Hello Gabe, > > I would like to apologize for the confusion regarding this patch and the > repeated reworking. > > Unfortunately Honza's position is not mentioned in the ticket so you could > not > know what to do, but Honza is our "installer architect" so he has final > say. > > Petr^2 Spacek > > On 13.10.2015 08:31, Jan Cholasta wrote: > > Hi, > > > > I don't think this is the correct approach. We are aiming to have > idempotent > > installers, which means that running uninstall on a system without IPA > > installed should be a no-op. This is the current behavior, so your patch > is > > actually moving us back. > > > > The proper fix would be to *remove* the check from install (as opposed to > > adding it to uninstall), but this requires the install code to be > idempotent, > > and we're not there yet. > > > > I'm OK with making this a warning, but don't make it a fatal error and/or > > require --force. > > > > Honza > > > > On 12.10.2015 17:12, Gabe Alford wrote: > >> Thanks, Petr. Updated patch attached. > >> > >> Gabe > >> > >> On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek >> > wrote: > >> > >> Hello Gabe, > >> > >> thank you for your patch! > >> > >> Please note that there might be a case where detection > >> is_ipa_configured() is > >> broken but the user still needs to run the uninstall process to > >> clean it up. > >> > >> Could you amend the patch to respect --force option? In that case > the > >> detection should be skipped. > >> > >> Thank you for your time! > >> > >> Petr^2 Spacek > >> > >> On 9.10.2015 19:17, Gabe Alford wrote: > >> > diff --git a/ipaserver/install/server/install.py > >> b/ipaserver/install/server/install.py > >> > index > >> > >> > 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 > >> > >> 100644 > >> > --- a/ipaserver/install/server/install.py > >> > +++ b/ipaserver/install/server/install.py > >> > @@ -954,6 +954,12 @@ def uninstall_check(installer): > >> > > >> > installer._installation_cleanup = False > >> > > >> > + if not is_ipa_configured(): > >> > + print("IPA server is not configured on this system.\n" + > >> > + "If you want to install the IPA server, please > >> install " + > >> > + "it using 'ipa-server-install'.") > >> > + sys.exit(1) > >> > + > >> > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) > >> > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0057-3-Warn-if-no-installation-found-when-running-ipa-serve.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Oct 13 13:32:07 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Oct 2015 15:32:07 +0200 Subject: [Freeipa-devel] [PATCH 373-374] idoverrides: Ignore SID conversion error and add coverage In-Reply-To: <561CDB15.2080206@redhat.com> References: <561CDB15.2080206@redhat.com> Message-ID: <561D07D7.6060909@redhat.com> On 10/13/2015 12:21 PM, Tomas Babej wrote: > Hi, > > this couple of patches fixes and improves the coverage for referential > integrity of ID overrides. > > Note: Last test in the patch 374 is supposed to be failing (for now). > > https://fedorahosted.org/freeipa/ticket/5322 > > > Hi Tomas, Patch 373: I still get errors in CLI/WebUI, see http://fpaste.org/278706/47425481/ It seems that there are some other places in idviews code (e.g. idview-show post_callback) that emit unhandled ValidationErrors. Patch 374: ACK -- Martin^3 Babinsky From rcritten at redhat.com Tue Oct 13 13:47:54 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Oct 2015 09:47:54 -0400 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <20151013121521.GR5076@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> <561CBB26.5000707@redhat.com> <561CF1BE.3040906@redhat.com> <20151013121521.GR5076@redhat.com> Message-ID: <561D0B8A.3050105@redhat.com> Alexander Bokovoy wrote: > On Tue, 13 Oct 2015, Martin Basti wrote: >> >> >> On 13.10.2015 10:04, Petr Spacek wrote: >>> On 13.10.2015 09:34, Martin Babinsky wrote: >>>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>>> each service possessing Kerberos keytab wiil now remove it and >>>>>> destroy any >>>>>> associated credentials cache during its uninstall >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>>> BTW some time ago Simo proposed that we should remove caches and >>>>> old keytabs >>>>> during *install* so problems caused by failing uninstallation will >>>>> be fixed on >>>>> repeated install. This is yet another step towards idempotent >>>>> installer. >>>>> >>>>> To me this makes more sense than doing so on uninstall. Does it >>>>> make sense to >>>>> you, too? >>>>> >>>> If the problem is formulated like this (the endpoint is that >>>> services have >>>> their keytabs) then it makes more sense to me. I will rework the patch >>>> accordingly. >>> Adding Simo to Cc, so we can be sure that we understood it properly :-) >>> >>> Simo, does it make sense to do that on installation rather than >>> installation? >>> >> >> I would like to keep removing keytabs during uninstall too, IPA should >> clean own mess. > It is better to remove on installation because we know what the state > of the system should be after install. On uninstall we cannot be > guaranteed that we wouldn't remove something that wasn't used anymore. > > Note that removing /etc/krb5.keytab doesn't mean that, for example, > Apache will be unusable on this system if it was previously configured. > In the ideal environment you don't even need /etc/krb5.conf to have it > accepting Kerberos authentication. See ipa-rmkeytab to safely remove principals by realm. rob From pspacek at redhat.com Tue Oct 13 14:00:22 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Oct 2015 16:00:22 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <561CED0B.9090009@redhat.com> References: <561BC52D.6030301@redhat.com> <561CB486.2020906@redhat.com> <561CED0B.9090009@redhat.com> Message-ID: <561D0E76.1030709@redhat.com> On 13.10.2015 13:37, Martin Babinsky wrote: > On 10/13/2015 09:36 AM, Petr Spacek wrote: >> On 12.10.2015 16:35, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5200 >>> --- >>> ipalib/plugins/dns.py | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>> index >>> 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 >>> 100644 >>> --- a/ipalib/plugins/dns.py >>> +++ b/ipalib/plugins/dns.py >>> @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>> if prefixlen is None: >>> revzone = None >>> >>> - result = api.Command['dnszone_find']()['result'] >>> + result = api.Command['dnszone_find'](sizelimit=0)['result'] >>> + >> >> NACK, this just increases the limit because LDAP server will enforce a >> per-user limit. >> >>> for zone in result: >>> zonename = zone['idnsname'][0] >>> if (revdns.is_subdomain(zonename.make_absolute()) and >> >> Generic solution should use dns.resolver.zone_for_name() to find DNS zone >> matching the reverse name. This should also implicitly cover CNAME/DNAME >> redirections per RFC2317. >> >> Using DNS implicitly means that a zone will always be found (at least the root >> zone :-). For this reason I would change final error message >>> reason=_('DNS reverse zone for IP address %(addr)s not found') >> to something like: >> reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not managed >> by this server') >> >> >> These changes should fix it without adding other artificial limitation. >> > > Thank you for clarification Petr. > > Attaching the reworked patch. > > -- > Martin^3 Babinsky > > freeipa-mbabinsk-0083.1-perform-more-robust-search-for-reverse-zones-when-ad.patch > > > From 463903f4ea4f74efeb02dbb705ca0a54fab81366 Mon Sep 17 00:00:00 2001 > From: Martin Babinsky > Date: Mon, 12 Oct 2015 16:24:50 +0200 > Subject: [PATCH 1/3] perform more robust search for reverse zones when adding > DNS record > > Instead of searching for all zones to identify the correct reverse zone, we > will first ask the resolver to return the name of zone that should contain the > desired record and then see if IPA manages this zone. > > https://fedorahosted.org/freeipa/ticket/5200 > --- > ipalib/plugins/dns.py | 21 +++++++++++++++++---- > 1 file changed, 17 insertions(+), 4 deletions(-) > > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index 84086f4c77d02922f237937d58031cc42d55410e..e3c6ce46168f8b6af607a61af1e3e431cfee32c8 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -531,25 +531,35 @@ def add_forward_record(zone, name, str_address): > pass # the entry already exists and matches > > def get_reverse_zone(ipaddr, prefixlen=None): > + """ > + resolve the reverse zone for IP address and see if it is managed by IPA > + server > + :param ipaddr: host IP address > + :param prefixlen: network prefix length > + :return: tuple containing name of the reverse zone and the name of the > + record > + """ > ip = netaddr.IPAddress(str(ipaddr)) > revdns = DNSName(unicode(ip.reverse_dns)) > + resolved_zone = unicode(dns.resolver.zone_for_name(revdns)) > > if prefixlen is None: > revzone = None > + result = api.Command['dnszone_find'](resolved_zone)['result'] > > - result = api.Command['dnszone_find']()['result'] > for zone in result: > zonename = zone['idnsname'][0] > if (revdns.is_subdomain(zonename.make_absolute()) and > (revzone is None or zonename.is_subdomain(revzone))): > revzone = zonename Oh, wait, this might blow up if there is a disabled DNS zone which is deeper than the one returned from DNS query. Damn, we have opened a Pandora box! ipaserver/install/bindinstance.py has own implementation of get_reverse_zone() + additional menthods find_reverse_zone(). These are using get_reverse_zone_default() from ipalib/util.py which is duplicating code in 'if prefixlen is not None' branch. And of course, are not correct in light of this change. My expectation would be that disabled zones should be ignored... So we should get rid of this mess in the loop and use dnszone_show() which is called at the end. And fix the other places, preferably by deleting duplicate implementations. I would expect that you can store (converted) output of dns.resolver.zone_for_name(revdns) into revzone and delete whole 'if prefixlen is None' branch. > else: > + # if prefixlen is specified, determine the zone name for the network > + # prefix > if ip.version == 4: > pos = 4 - prefixlen / 8 > elif ip.version == 6: > pos = 32 - prefixlen / 4 > - items = ip.reverse_dns.split('.') > - revzone = DNSName(items[pos:]) > + revzone = revdns[pos:] Hmm, and this logic will breaks CNAME/DNAME (RFC2317) handling ... Damn, we need different handling when we intend to create the zone and when we want to manipulate a record in a reverse zone. Grrr. When we want to manipulate a record in existing zone, the whole branch does not make sense and the result of DNS query is what we want and need. On the other hand, we need this when creating *a new zone* from IP address ... Mastin^2, what about zone names with missing period at the end? Is it handled by dnszone_show() internally? We have to discuss all this... > try: > api.Command['dnszone_show'](revzone) > @@ -558,7 +568,10 @@ def get_reverse_zone(ipaddr, prefixlen=None): > > if revzone is None: > raise errors.NotFound( > - reason=_('DNS reverse zone for IP address %(addr)s not found') % dict(addr=ipaddr) > + reason=_( > + 'DNS reverse zone %(resolved_zone)s for IP address ' > + '%(addr)s is not manager by this server') % dict( typo s/manager/managed/ > + addr=ipaddr, resolved_zone=resolved_zone) > ) > > revname = revdns.relativize(revzone) -- Petr^2 Spacek From ldoudova at redhat.com Tue Oct 13 14:09:42 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 13 Oct 2015 16:09:42 +0200 Subject: [Freeipa-devel] Stageuser capability in UI Message-ID: <561D10A6.5090406@redhat.com> Hi, I've been told to do some tests of stageuser UI capabilities ASAP. I think I covered most of the test cases from test plan (http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan) (will check that tomorrow morning, as I need to go soon). I haven't found any really serious bug, but I have found some stuff that I'm not sure is OK: 1. if I display a list of all staged users, I can select users and activate them using the new "Activate" button. However, if I display detailed info of a user and want to activate the user from there, there's no such option under the "Actions" menu. 2. similar to the previous one: if I display a list of all active users, select some of them and click the "Delete" button, I can choose whether I want permanent deletion or just make the user(s) preserved. If I open detailed info of a user, there is "Delete" option under the "Actions" menu, but it does the permanent deletion only, no choice is offered. 3. I completely miss the option to convert preserved user to a staged one (equivalent to CLI command "user-stage"). First two may be just uncomfortable for a user, but the last one definitely skips one ability of the plugin. Lenka From mbasti at redhat.com Tue Oct 13 15:54:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Oct 2015 17:54:59 +0200 Subject: [Freeipa-devel] [PATCH 0056] Enable nsaccountlock in user.py cli In-Reply-To: References: Message-ID: <561D2953.6010308@redhat.com> On 09.10.2015 19:17, Gabe Alford wrote: > Hello, > > This patch enables nsaccountlock in user.py cli. It is very handy to > be able to search and find users with disabled/enabled accounts, etc. > That said, I couldn't find why it was no_option in the first place, so > I am not 100% sure if it breaks something or the reasoning behind > no_option. > > Thanks, > > Gabe > > Hello, https://fedorahosted.org/freeipa/ticket/5366 This patch allows to enable/disable user via user-mod, and we do not want to do this, so NACK for this patch. I'm not sure yet how to write it in elegant way. Martin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From janorel at gmail.com Tue Oct 13 16:22:37 2015 From: janorel at gmail.com (Jan Orel) Date: Tue, 13 Oct 2015 18:22:37 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <561BD90A.9080000@redhat.com> References: <5617B56E.7000807@redhat.com> <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> <561BD90A.9080000@redhat.com> Message-ID: > The restriction was there so that hosts had limited visibility. This > applies that limitation to all users. I think the host check needs to be > re-added. I am confused, correct me if I am wrong, but the "if hostname:" check seems always redundat because it would raise exception before either here: 615 if not bind_principal.startswith('host/'): 616 raise acierr or in validate_principal() > Also, every host is not guaranteed to have a krbPrincipalAux (it can be > unenrolled). I assume you used this to cover managed services as well, > that's why the broad search base? Checking it, even host which is not enrolled have objectClass: krbprincipalaux, but advise me if different search should be used. thanks, jan From mbasti at redhat.com Tue Oct 13 16:38:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Oct 2015 18:38:07 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561B8BD2.2050301@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> Message-ID: <561D336F.3060409@redhat.com> On 12.10.2015 12:30, Martin Babinsky wrote: > On 10/08/2015 05:58 PM, Martin Basti wrote: >> The attached patches fix following tickets: >> https://fedorahosted.org/freeipa/ticket/4949 >> https://fedorahosted.org/freeipa/ticket/4048 >> https://fedorahosted.org/freeipa/ticket/1930 >> >> With these patches, an administrator can specify LDIF file that contains >> modifications to be applied to dse.ldif right after creation of DS >> instance. >> >> > Hi, > > Functionally the paches work as expected. However I have following > nitpicks: > > in patch 318: > > 1.) there is a typo in ModifyLDIF class docstring: > > + Operations keep the order in whihc were specified per DN. > > in patch 320: > > 1.) you should use 'os.path.join' to construct FS paths: > > > - dse_filename = '%s/%s' % ( > + dse_filename = os.path.join( > paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % self.serverid, > - 'dse.ldif', > + 'dse.ldif' > ) > > 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to > LDIF containing the mod operations to dse.ldif. However, the knob name > sounds like the option accepts the path of dse.ldif itself. I propose > to rename the knob to something more in-line with the supposed > function, like 'dse_mods_file'. > Updated patches + CI test attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0318.2-Make-offline-LDIF-modify-more-robust.patch Type: text/x-patch Size: 10755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0319.2-Add-method-to-read-changes-from-LDIF.patch Type: text/x-patch Size: 2957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0320.2-Add-option-to-specify-LDIF-file-that-contains-DS-con.patch Type: text/x-patch Size: 9376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0323.2-CI-installation-with-customized-DS-config.patch Type: text/x-patch Size: 5389 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 13 16:49:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Oct 2015 18:49:58 +0200 Subject: [Freeipa-devel] [PATCHES 0324 - 0325] DNSSEC: warn user if DNSSEC key master is not installed on any replica Message-ID: <561D3636.3030801@redhat.com> https://fedorahosted.org/freeipa/ticket/5290 Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0324-DNSSEC-Remove-service-containers-from-LDAP-after-uni.patch Type: text/x-patch Size: 2440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0325-DNSSEC-warn-user-if-DNSSEC-key-master-is-not-install.patch Type: text/x-patch Size: 5460 bytes Desc: not available URL: From redhatrises at gmail.com Tue Oct 13 16:53:13 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 13 Oct 2015 10:53:13 -0600 Subject: [Freeipa-devel] [PATCH 0056] Enable nsaccountlock in user.py cli In-Reply-To: <561D2953.6010308@redhat.com> References: <561D2953.6010308@redhat.com> Message-ID: Thanks Martin, What about adding no_create and no_update flags? Gabe On Tue, Oct 13, 2015 at 9:54 AM, Martin Basti wrote: > > > On 09.10.2015 19:17, Gabe Alford wrote: > > Hello, > > This patch enables nsaccountlock in user.py cli. It is very handy to be > able to search and find users with disabled/enabled accounts, etc. That > said, I couldn't find why it was no_option in the first place, so I am not > 100% sure if it breaks something or the reasoning behind no_option. > > Thanks, > > Gabe > > > Hello, > > https://fedorahosted.org/freeipa/ticket/5366 > > This patch allows to enable/disable user via user-mod, and we do not want > to do this, so NACK for this patch. > I'm not sure yet how to write it in elegant way. > > Martin. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0056-Enable-nsaccountlock-in-user.py-for-user-find-cli-us.patch Type: text/x-patch Size: 5189 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Oct 13 16:55:23 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Oct 2015 18:55:23 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561CBDB6.7000202@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> Message-ID: <561D377B.5040806@redhat.com> On 10/13/2015 10:15 AM, Petr Vobornik wrote: > On 10/13/2015 10:02 AM, Oleg Fayans wrote: >> NACK >> >> UI still shows the connectivity information at >> >> http:///ipa/ui/#/e/topologysuffix/topologysegment/realm > > Showing it is correct and desired - both in CLI and Web UI. > > The end state should be that UIs will create new segments with > direction=both and they will not allow to modify it. > > So the issue, ticket #5222 is IMO about, is that CLI asks for a value in > interactive prompt which could be used to change the value from both to > some other. > >> >> CLI is OK, though >> >> On 10/12/2015 05:57 PM, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5222 >>> Sending updated patch. Now the connectivity is displayed but can't be manipulated. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0084.1-hide-topology-segment-direction-in-topology-command-.patch Type: text/x-patch Size: 4573 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 13 16:55:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Oct 2015 18:55:33 +0200 Subject: [Freeipa-devel] [PATCH 0058] Remove bind configuration detected question In-Reply-To: References: Message-ID: <561D3785.9090209@redhat.com> On 09.10.2015 19:17, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5351 > > Thanks, > > Gabe > > ACK Pushed to: master: d0bdc37679ef6807d16f2f3b216366834f9d6de0 ipa-4-2: 1d78cbb036760261f8d8e57fc0b7109e9e1c7568 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Oct 13 16:59:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Oct 2015 18:59:53 +0200 Subject: [Freeipa-devel] [PATCH 0056] Enable nsaccountlock in user.py cli In-Reply-To: References: <561D2953.6010308@redhat.com> Message-ID: <561D3889.6020003@redhat.com> On 13.10.2015 18:53, Gabe Alford wrote: > Thanks Martin, > > What about adding no_create and no_update flags? > > Gabe Yes, that may work, also please increment minor version of API and add ticket into commit message (https://fedorahosted.org/freeipa/ticket/5366) Thanks. Martin > > On Tue, Oct 13, 2015 at 9:54 AM, Martin Basti > wrote: > > > > On 09.10.2015 19:17, Gabe Alford wrote: >> Hello, >> >> This patch enables nsaccountlock in user.py cli. It is very handy >> to be able to search and find users with disabled/enabled >> accounts, etc. That said, I couldn't find why it was no_option in >> the first place, so I am not 100% sure if it breaks something or >> the reasoning behind no_option. >> >> Thanks, >> >> Gabe >> >> > Hello, > > https://fedorahosted.org/freeipa/ticket/5366 > > This patch allows to enable/disable user via user-mod, and we do > not want to do this, so NACK for this patch. > I'm not sure yet how to write it in elegant way. > > Martin. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Oct 13 17:04:54 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Oct 2015 19:04:54 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561D377B.5040806@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561D377B.5040806@redhat.com> Message-ID: <561D39B6.4090801@redhat.com> On 10/13/2015 06:55 PM, Martin Babinsky wrote: > mbabinsk - hide segment direction from topology commands Ooops forgot to regenerate API.txt. Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0084.2-hide-topology-segment-direction-in-topology-command-.patch Type: text/x-patch Size: 3014 bytes Desc: not available URL: From redhatrises at gmail.com Tue Oct 13 17:12:14 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 13 Oct 2015 11:12:14 -0600 Subject: [Freeipa-devel] [PATCH 0056] Enable nsaccountlock in user.py cli In-Reply-To: <561D3889.6020003@redhat.com> References: <561D2953.6010308@redhat.com> <561D3889.6020003@redhat.com> Message-ID: Updated patch attached. On Tue, Oct 13, 2015 at 10:59 AM, Martin Basti wrote: > > > On 13.10.2015 18:53, Gabe Alford wrote: > > Thanks Martin, > > What about adding no_create and no_update flags? > > Gabe > > Yes, that may work, also please increment minor version of API and add > ticket into commit message (https://fedorahosted.org/freeipa/ticket/5366) > > > Thanks. > Martin > > > On Tue, Oct 13, 2015 at 9:54 AM, Martin Basti wrote: > >> >> >> On 09.10.2015 19:17, Gabe Alford wrote: >> >> Hello, >> >> This patch enables nsaccountlock in user.py cli. It is very handy to be >> able to search and find users with disabled/enabled accounts, etc. That >> said, I couldn't find why it was no_option in the first place, so I am not >> 100% sure if it breaks something or the reasoning behind no_option. >> >> Thanks, >> >> Gabe >> >> >> Hello, >> >> https://fedorahosted.org/freeipa/ticket/5366 >> >> This patch allows to enable/disable user via user-mod, and we do not want >> to do this, so NACK for this patch. >> I'm not sure yet how to write it in elegant way. >> >> Martin. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0056-2-Enable-nsaccountlock-in-user.py-for-user-find-cli-us.patch Type: text/x-patch Size: 5321 bytes Desc: not available URL: From rcritten at redhat.com Tue Oct 13 17:26:41 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Oct 2015 13:26:41 -0400 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: References: <5617B56E.7000807@redhat.com> <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> <561BD90A.9080000@redhat.com> Message-ID: <561D3ED1.3030700@redhat.com> Jan Orel wrote: >> The restriction was there so that hosts had limited visibility. This >> applies that limitation to all users. I think the host check needs to be >> re-added. > > I am confused, correct me if I am wrong, but the "if hostname:" check > seems always redundat because it would raise exception before > either here: > > 615 if not bind_principal.startswith('host/'): > 616 raise acierr > > or in validate_principal() Anything bound to IPA can potentially retrieve a certificate. This code adds special handling for hosts and probably should cover services as well now that I think about it. I don't think services could be included in ACIs when this was originally written. The idea was that hosts have no need to be able to query random serial numbers so it should be limited to viewing its own. Removing the if hostname: applies this logic to ALL retrieval which is by far overkill and limits all non-admin entries to only be able to view certs they own (or can write) which sort of kills the reason for the 'retrieve certificate' permission. > >> Also, every host is not guaranteed to have a krbPrincipalAux (it can be >> unenrolled). I assume you used this to cover managed services as well, >> that's why the broad search base? > > Checking it, even host which is not enrolled have objectClass: krbprincipalaux, > but advise me if different search should be used. If a host is added with a password (random or otherwise) it won't have this objectclass. I'd make the search filter something like (|(objectclass=ipahost)(objectclass=ipaservice)). rob From mbabinsk at redhat.com Wed Oct 14 06:15:00 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Oct 2015 08:15:00 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CFE95.3070703@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <561CB40F.7020405@redhat.com> <561CBB26.5000707@redhat.com> <561CFE95.3070703@redhat.com> Message-ID: <561DF2E4.7050606@redhat.com> On 10/13/2015 02:52 PM, Simo Sorce wrote: > On 13/10/15 04:04, Petr Spacek wrote: >> On 13.10.2015 09:34, Martin Babinsky wrote: >>> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>>> >>>>> each service possessing Kerberos keytab wiil now remove it and >>>>> destroy any >>>>> associated credentials cache during its uninstall >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5243 >>>> >>>> BTW some time ago Simo proposed that we should remove caches and old >>>> keytabs >>>> during *install* so problems caused by failing uninstallation will >>>> be fixed on >>>> repeated install. This is yet another step towards idempotent >>>> installer. >>>> >>>> To me this makes more sense than doing so on uninstall. Does it make >>>> sense to >>>> you, too? >>>> >>> >>> If the problem is formulated like this (the endpoint is that services >>> have >>> their keytabs) then it makes more sense to me. I will rework the patch >>> accordingly. >> >> Adding Simo to Cc, so we can be sure that we understood it properly :-) >> >> Simo, does it make sense to do that on installation rather than >> installation? > > Actually on a server re-install it may make sense to check if the keytab > is valid and keep it if it is. I'm not sure how can we keep the keytabs when reinstalling the server. We are re-creating the service principals with new keys and thus have to recreate keytabs anyway. I would argue that we should wipe them (and any leftover credentials caches) before installation. But maybe I have missed something. > Make sure you do not break promotion by removing the host keytab or > keytabs that have been legitimately created in the client. > I was not poking host keytabs in my patch specifically for this reason. There is some code in ipa-client-install that handles principal removal from /etc/krb5.keytab during client uninstall. And since this code is run after IPA server uninstall I left it to do its job. > But otherwise the direction is good. > > Simo. > -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Oct 14 07:02:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Oct 2015 09:02:58 +0200 Subject: [Freeipa-devel] [PATCH 0085] remove idoverrides when deleting a user Message-ID: <561DFE22.1040000@redhat.com> This patch fixes a regression which was caused by incorrect refactoring of user-del command in commit c6299a8cfde7d4e4bb9a50e3cf6406667cee0a6f While the `remove_ipaobject_overrides` function was originally called in the execute method, this patch puts it into the pre-callback because: 1.) it is called in pre-callback of group-del 2.) by putting it into pre-callback the overrides are removed for each entry when multiple primary keys are specified (maybe it would be good to have a test case for this?) 3.) since LDAPDelete does not return any entry attributes (it is a delete after all), it is not possible to put it into post-callback without hacking either the function itself or LDAPDelete class 4.) due to this design you have to call it before execution anyway https://fedorahosted.org/freeipa/ticket/5365 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0085-remove-ID-overrides-when-deleting-a-user.patch Type: text/x-patch Size: 1044 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 14 07:45:46 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 14 Oct 2015 09:45:46 +0200 Subject: [Freeipa-devel] Stageuser capability in UI In-Reply-To: <561D10A6.5090406@redhat.com> References: <561D10A6.5090406@redhat.com> Message-ID: <561E082A.4070601@redhat.com> On 10/13/2015 04:09 PM, Lenka Doudova wrote: > Hi, > > I've been told to do some tests of stageuser UI capabilities ASAP. > I think I covered most of the test cases from test plan > (http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan) > (will check that tomorrow morning, as I need to go soon). > I haven't found any really serious bug, but I have found some stuff that > I'm not sure is OK: > > 1. if I display a list of all staged users, I can select users and > activate them using the new "Activate" button. However, if I display > detailed info of a user and want to activate the user from there, > there's no such option under the "Actions" menu. > > 2. similar to the previous one: if I display a list of all active users, > select some of them and click the "Delete" button, I can choose whether > I want permanent deletion or just make the user(s) preserved. If I open > detailed info of a user, there is "Delete" option under the "Actions" > menu, but it does the permanent deletion only, no choice is offered. > > 3. I completely miss the option to convert preserved user to a staged > one (equivalent to CLI command "user-stage"). > > > > First two may be just uncomfortable for a user, but the last one > definitely skips one ability of the plugin. I agree. Please file a track ticket for each item. > > Lenka > -- Petr Vobornik From mbasti at redhat.com Wed Oct 14 07:56:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Oct 2015 09:56:53 +0200 Subject: [Freeipa-devel] [PATCH 0326] Replace tab with space in test_user_plugin Message-ID: <561E0AC5.5090601@redhat.com> Mixing spaces and tabs is not allowed in python3. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0326-Replace-tab-with-space-in-test_user_plugin.py.patch Type: text/x-patch Size: 1100 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Oct 14 08:04:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Oct 2015 10:04:05 +0200 Subject: [Freeipa-devel] [PATCH 0326] Replace tab with space in test_user_plugin In-Reply-To: <561E0AC5.5090601@redhat.com> References: <561E0AC5.5090601@redhat.com> Message-ID: <561E0C75.4040606@redhat.com> On 10/14/2015 09:56 AM, Martin Basti wrote: > Mixing spaces and tabs is not allowed in python3. > > Patch attached. > > ACK -- Martin^3 Babinsky From ldoudova at redhat.com Wed Oct 14 08:08:38 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 14 Oct 2015 10:08:38 +0200 Subject: [Freeipa-devel] Stageuser capability in UI In-Reply-To: <561E082A.4070601@redhat.com> References: <561D10A6.5090406@redhat.com> <561E082A.4070601@redhat.com> Message-ID: <561E0D86.4080003@redhat.com> On 10/14/2015 09:45 AM, Petr Vobornik wrote: > On 10/13/2015 04:09 PM, Lenka Doudova wrote: >> Hi, >> >> I've been told to do some tests of stageuser UI capabilities ASAP. >> I think I covered most of the test cases from test plan >> (http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan) >> (will check that tomorrow morning, as I need to go soon). >> I haven't found any really serious bug, but I have found some stuff that >> I'm not sure is OK: >> >> 1. if I display a list of all staged users, I can select users and >> activate them using the new "Activate" button. However, if I display >> detailed info of a user and want to activate the user from there, >> there's no such option under the "Actions" menu. >> >> 2. similar to the previous one: if I display a list of all active users, >> select some of them and click the "Delete" button, I can choose whether >> I want permanent deletion or just make the user(s) preserved. If I open >> detailed info of a user, there is "Delete" option under the "Actions" >> menu, but it does the permanent deletion only, no choice is offered. >> >> 3. I completely miss the option to convert preserved user to a staged >> one (equivalent to CLI command "user-stage"). >> >> >> >> First two may be just uncomfortable for a user, but the last one >> definitely skips one ability of the plugin. > > I agree. Please file a track ticket for each item. Done: * https://fedorahosted.org/freeipa/ticket/5369 * https://fedorahosted.org/freeipa/ticket/5370 * https://fedorahosted.org/freeipa/ticket/5371 Lenka > >> >> Lenka >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 14 08:15:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Oct 2015 10:15:16 +0200 Subject: [Freeipa-devel] [PATCH 0326] Replace tab with space in test_user_plugin In-Reply-To: <561E0C75.4040606@redhat.com> References: <561E0AC5.5090601@redhat.com> <561E0C75.4040606@redhat.com> Message-ID: <561E0F14.7020608@redhat.com> On 14.10.2015 10:04, Martin Babinsky wrote: > On 10/14/2015 09:56 AM, Martin Basti wrote: >> Mixing spaces and tabs is not allowed in python3. >> >> Patch attached. >> >> > > ACK > Pushed to: master: 16261adc58fb9bfe51c679d6e00d85f21c1f6447 ipa-4-2: 8b66b6f49a568f4171f88c3b4a042f368bc088b8 From mbasti at redhat.com Wed Oct 14 08:52:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Oct 2015 10:52:46 +0200 Subject: [Freeipa-devel] [PATCH 0056] Enable nsaccountlock in user.py cli In-Reply-To: References: <561D2953.6010308@redhat.com> <561D3889.6020003@redhat.com> Message-ID: <561E17DE.9060904@redhat.com> Sorry, we cannot push this patch because I realize that it breaks API compatibility. The proper fix is add this code to find method (not tested) def get_options(self): for option in super(user_find, self).get_options(): if option.name == "nsaccountlock": flags = set(option.flags) flags.remove("no_option") option = option.clone(flags=flags) yield option But I do not like too much this code, we plan to do some ipalib refactoring in IPA 4.4, so we can do there bigger changes and solve this issue in nicer way. If you don't mind, I would postpone this to IPA 4.4, instead of hacking the framework Martin On 13.10.2015 19:12, Gabe Alford wrote: > Updated patch attached. > > On Tue, Oct 13, 2015 at 10:59 AM, Martin Basti > wrote: > > > > On 13.10.2015 18:53, Gabe Alford wrote: >> Thanks Martin, >> >> What about adding no_create and no_update flags? >> >> Gabe > Yes, that may work, also please increment minor version of API and > add ticket into commit message > (https://fedorahosted.org/freeipa/ticket/5366) > > > Thanks. > Martin >> >> On Tue, Oct 13, 2015 at 9:54 AM, Martin Basti > > wrote: >> >> >> >> On 09.10.2015 19:17, Gabe Alford wrote: >>> Hello, >>> >>> This patch enables nsaccountlock in user.py cli. It is very >>> handy to be able to search and find users with >>> disabled/enabled accounts, etc. That said, I couldn't find >>> why it was no_option in the first place, so I am not 100% >>> sure if it breaks something or the reasoning behind no_option. >>> >>> Thanks, >>> >>> Gabe >>> >>> >> Hello, >> >> https://fedorahosted.org/freeipa/ticket/5366 >> >> This patch allows to enable/disable user via user-mod, and we >> do not want to do this, so NACK for this patch. >> I'm not sure yet how to write it in elegant way. >> >> Martin. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 14 10:32:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Oct 2015 12:32:54 +0200 Subject: [Freeipa-devel] [PATCH 0009] WebUI: Disappearing automember rule expressions In-Reply-To: <561CE749.4070208@redhat.com> References: <5617A909.8060508@redhat.com> <561CE749.4070208@redhat.com> Message-ID: <561E2F56.9090707@redhat.com> On 13.10.2015 13:13, Tomas Babej wrote: > > On 10/09/2015 01:46 PM, Stanislav Laznicka wrote: >> Hi, >> please see the patch attached. >> >> Standa L. >> >> > ACK, works as desired. > > Tomas > Pushed to: master: 9d562038addb1e653f91031731f62e91325c1591 ipa-4-2: cbccec68fc3e6314ee35a3a3697e65657d916370 From mbasti at redhat.com Wed Oct 14 10:43:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Oct 2015 12:43:21 +0200 Subject: [Freeipa-devel] [PATCH 0059] ipa-adtrust-install: Print complete SRV record In-Reply-To: <561CE1A0.5010203@redhat.com> References: <5617BA30.2030604@redhat.com> <561CE1A0.5010203@redhat.com> Message-ID: <561E31C9.5070005@redhat.com> On 13.10.2015 12:49, Tomas Babej wrote: > > On 10/09/2015 02:59 PM, Petr Spacek wrote: >> Hello, >> >> I found this when reviewing DNS parts of IdM and AD integration guides. >> >> ipa-adtrust-install: Print complete SRV records. >> https://fedorahosted.org/freeipa/ticket/5358 >> >> >> > ACK, generates correct output. > > _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 389 master > _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 > master > _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 > master > _ldap._tcp.dc._msdcs IN SRV 0 100 389 master > _kerberos._tcp.dc._msdcs IN SRV 0 100 88 master > _kerberos._udp.dc._msdcs IN SRV 0 100 88 master > > Tomas > Pushed to: master: 644bb4fd9d5c406eab0fbeb18d8f9063775ed5d3 ipa-4-2: 6b2dec87acfca71504e689abc523e9d72ae73cd2 From tbabej at redhat.com Wed Oct 14 10:54:19 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Oct 2015 12:54:19 +0200 Subject: [Freeipa-devel] [PATCH 373-374] idoverrides: Ignore SID conversion error and add coverage In-Reply-To: <561D07D7.6060909@redhat.com> References: <561CDB15.2080206@redhat.com> <561D07D7.6060909@redhat.com> Message-ID: <561E345B.3090505@redhat.com> On 10/13/2015 03:32 PM, Martin Babinsky wrote: > On 10/13/2015 12:21 PM, Tomas Babej wrote: >> Hi, >> >> this couple of patches fixes and improves the coverage for referential >> integrity of ID overrides. >> >> Note: Last test in the patch 374 is supposed to be failing (for now). >> >> https://fedorahosted.org/freeipa/ticket/5322 >> >> >> > > Hi Tomas, > > Patch 373: > > I still get errors in CLI/WebUI, see http://fpaste.org/278706/47425481/ > > It seems that there are some other places in idviews code (e.g. > idview-show post_callback) that emit unhandled ValidationErrors. > > Patch 374: ACK > You're right, updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0373-2-idoverride-Ignore-ValidationErrors-when-converting-t.patch Type: text/x-patch Size: 4893 bytes Desc: not available URL: From tbabej at redhat.com Wed Oct 14 11:25:25 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Oct 2015 13:25:25 +0200 Subject: [Freeipa-devel] [PATCH 0085] remove idoverrides when deleting a user In-Reply-To: <561DFE22.1040000@redhat.com> References: <561DFE22.1040000@redhat.com> Message-ID: <561E3BA5.6000205@redhat.com> On 10/14/2015 09:02 AM, Martin Babinsky wrote: > This patch fixes a regression which was caused by incorrect refactoring > of user-del command in commit c6299a8cfde7d4e4bb9a50e3cf6406667cee0a6f > > While the `remove_ipaobject_overrides` function was originally called in > the execute method, this patch puts it into the pre-callback because: > > 1.) it is called in pre-callback of group-del > 2.) by putting it into pre-callback the overrides are removed for each > entry when multiple primary keys are specified (maybe it would be good > to have a test case for this?) > 3.) since LDAPDelete does not return any entry attributes (it is a > delete after all), it is not possible to put it into post-callback > without hacking either the function itself or LDAPDelete class > 4.) due to this design you have to call it before execution anyway > > > https://fedorahosted.org/freeipa/ticket/5365 > ACK. Pushed to: ipa-4-2: bbe7d99086112b047bbcf88fc3d1ddeef72a5368 master: 5484ae014ea991335d2fa2478d94169ad29c0f55 From mbabinsk at redhat.com Wed Oct 14 12:04:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Oct 2015 14:04:39 +0200 Subject: [Freeipa-devel] [PATCH 373-374] idoverrides: Ignore SID conversion error and add coverage In-Reply-To: <561E345B.3090505@redhat.com> References: <561CDB15.2080206@redhat.com> <561D07D7.6060909@redhat.com> <561E345B.3090505@redhat.com> Message-ID: <561E44D7.2040907@redhat.com> On 10/14/2015 12:54 PM, Tomas Babej wrote: > > > On 10/13/2015 03:32 PM, Martin Babinsky wrote: >> On 10/13/2015 12:21 PM, Tomas Babej wrote: >>> Hi, >>> >>> this couple of patches fixes and improves the coverage for referential >>> integrity of ID overrides. >>> >>> Note: Last test in the patch 374 is supposed to be failing (for now). >>> >>> https://fedorahosted.org/freeipa/ticket/5322 >>> >>> >>> >> >> Hi Tomas, >> >> Patch 373: >> >> I still get errors in CLI/WebUI, see http://fpaste.org/278706/47425481/ >> >> It seems that there are some other places in idviews code (e.g. >> idview-show post_callback) that emit unhandled ValidationErrors. >> >> Patch 374: ACK >> > > You're right, updated patch attached. > ACK -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Oct 14 12:13:49 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Oct 2015 14:13:49 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <561D0E76.1030709@redhat.com> References: <561BC52D.6030301@redhat.com> <561CB486.2020906@redhat.com> <561CED0B.9090009@redhat.com> <561D0E76.1030709@redhat.com> Message-ID: <561E46FD.1020404@redhat.com> On 10/13/2015 04:00 PM, Petr Spacek wrote: > On 13.10.2015 13:37, Martin Babinsky wrote: >> On 10/13/2015 09:36 AM, Petr Spacek wrote: >>> On 12.10.2015 16:35, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5200 >>>> --- >>>> ipalib/plugins/dns.py | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>> index >>>> 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 >>>> 100644 >>>> --- a/ipalib/plugins/dns.py >>>> +++ b/ipalib/plugins/dns.py >>>> @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>> if prefixlen is None: >>>> revzone = None >>>> >>>> - result = api.Command['dnszone_find']()['result'] >>>> + result = api.Command['dnszone_find'](sizelimit=0)['result'] >>>> + >>> >>> NACK, this just increases the limit because LDAP server will enforce a >>> per-user limit. >>> >>>> for zone in result: >>>> zonename = zone['idnsname'][0] >>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>> >>> Generic solution should use dns.resolver.zone_for_name() to find DNS zone >>> matching the reverse name. This should also implicitly cover CNAME/DNAME >>> redirections per RFC2317. >>> >>> Using DNS implicitly means that a zone will always be found (at least the root >>> zone :-). For this reason I would change final error message >>>> reason=_('DNS reverse zone for IP address %(addr)s not found') >>> to something like: >>> reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not managed >>> by this server') >>> >>> >>> These changes should fix it without adding other artificial limitation. >>> >> >> Thank you for clarification Petr. >> >> Attaching the reworked patch. >> >> -- >> Martin^3 Babinsky >> >> freeipa-mbabinsk-0083.1-perform-more-robust-search-for-reverse-zones-when-ad.patch >> >> >> From 463903f4ea4f74efeb02dbb705ca0a54fab81366 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Mon, 12 Oct 2015 16:24:50 +0200 >> Subject: [PATCH 1/3] perform more robust search for reverse zones when adding >> DNS record >> >> Instead of searching for all zones to identify the correct reverse zone, we >> will first ask the resolver to return the name of zone that should contain the >> desired record and then see if IPA manages this zone. >> >> https://fedorahosted.org/freeipa/ticket/5200 >> --- >> ipalib/plugins/dns.py | 21 +++++++++++++++++---- >> 1 file changed, 17 insertions(+), 4 deletions(-) >> >> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >> index 84086f4c77d02922f237937d58031cc42d55410e..e3c6ce46168f8b6af607a61af1e3e431cfee32c8 100644 >> --- a/ipalib/plugins/dns.py >> +++ b/ipalib/plugins/dns.py >> @@ -531,25 +531,35 @@ def add_forward_record(zone, name, str_address): >> pass # the entry already exists and matches >> >> def get_reverse_zone(ipaddr, prefixlen=None): >> + """ >> + resolve the reverse zone for IP address and see if it is managed by IPA >> + server >> + :param ipaddr: host IP address >> + :param prefixlen: network prefix length >> + :return: tuple containing name of the reverse zone and the name of the >> + record >> + """ >> ip = netaddr.IPAddress(str(ipaddr)) >> revdns = DNSName(unicode(ip.reverse_dns)) >> + resolved_zone = unicode(dns.resolver.zone_for_name(revdns)) >> >> if prefixlen is None: >> revzone = None >> + result = api.Command['dnszone_find'](resolved_zone)['result'] >> >> - result = api.Command['dnszone_find']()['result'] >> for zone in result: >> zonename = zone['idnsname'][0] >> if (revdns.is_subdomain(zonename.make_absolute()) and >> (revzone is None or zonename.is_subdomain(revzone))): >> revzone = zonename > > Oh, wait, this might blow up if there is a disabled DNS zone which is deeper > than the one returned from DNS query. > > Damn, we have opened a Pandora box! > > ipaserver/install/bindinstance.py has own implementation of get_reverse_zone() > + additional menthods find_reverse_zone(). > These are using get_reverse_zone_default() from ipalib/util.py which is > duplicating code in 'if prefixlen is not None' branch. > > And of course, are not correct in light of this change. > > My expectation would be that disabled zones should be ignored... So we should > get rid of this mess in the loop and use dnszone_show() which is called at the > end. And fix the other places, preferably by deleting duplicate implementations. > > I would expect that you can store (converted) output of > dns.resolver.zone_for_name(revdns) into revzone and delete whole 'if prefixlen > is None' branch. > >> else: >> + # if prefixlen is specified, determine the zone name for the network >> + # prefix >> if ip.version == 4: >> pos = 4 - prefixlen / 8 >> elif ip.version == 6: >> pos = 32 - prefixlen / 4 >> - items = ip.reverse_dns.split('.') >> - revzone = DNSName(items[pos:]) >> + revzone = revdns[pos:] > > Hmm, and this logic will breaks CNAME/DNAME (RFC2317) handling ... Damn, we > need different handling when we intend to create the zone and when we want to > manipulate a record in a reverse zone. Grrr. > > When we want to manipulate a record in existing zone, the whole branch does > not make sense and the result of DNS query is what we want and need. > > On the other hand, we need this when creating *a new zone* from IP address ... > > Mastin^2, what about zone names with missing period at the end? Is it handled > by dnszone_show() internally? > > We have to discuss all this... > >> try: >> api.Command['dnszone_show'](revzone) >> @@ -558,7 +568,10 @@ def get_reverse_zone(ipaddr, prefixlen=None): >> >> if revzone is None: >> raise errors.NotFound( >> - reason=_('DNS reverse zone for IP address %(addr)s not found') % dict(addr=ipaddr) >> + reason=_( >> + 'DNS reverse zone %(resolved_zone)s for IP address ' >> + '%(addr)s is not manager by this server') % dict( > typo s/manager/managed/ > >> + addr=ipaddr, resolved_zone=resolved_zone) >> ) >> >> revname = revdns.relativize(revzone) > After lengthy discussion with Petr^2 I we decided to rework get_reverse_zone function a bit. Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0083.2-perform-more-robust-search-for-reverse-zones-when-ad.patch Type: text/x-patch Size: 3493 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Oct 14 13:51:24 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Oct 2015 15:51:24 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561D336F.3060409@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> Message-ID: <561E5DDC.2090609@redhat.com> On 10/13/2015 06:38 PM, Martin Basti wrote: > > > On 12.10.2015 12:30, Martin Babinsky wrote: >> On 10/08/2015 05:58 PM, Martin Basti wrote: >>> The attached patches fix following tickets: >>> https://fedorahosted.org/freeipa/ticket/4949 >>> https://fedorahosted.org/freeipa/ticket/4048 >>> https://fedorahosted.org/freeipa/ticket/1930 >>> >>> With these patches, an administrator can specify LDIF file that contains >>> modifications to be applied to dse.ldif right after creation of DS >>> instance. >>> >>> >> Hi, >> >> Functionally the paches work as expected. However I have following >> nitpicks: >> >> in patch 318: >> >> 1.) there is a typo in ModifyLDIF class docstring: >> >> + Operations keep the order in whihc were specified per DN. >> >> in patch 320: >> >> 1.) you should use 'os.path.join' to construct FS paths: >> >> >> - dse_filename = '%s/%s' % ( >> + dse_filename = os.path.join( >> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % self.serverid, >> - 'dse.ldif', >> + 'dse.ldif' >> ) >> >> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to >> LDIF containing the mod operations to dse.ldif. However, the knob name >> sounds like the option accepts the path of dse.ldif itself. I propose >> to rename the knob to something more in-line with the supposed >> function, like 'dse_mods_file'. >> > > Updated patches + CI test attached Patches work as expected and CI tests are OK. However it seems that warning level messages are not logged to installer output but only to log file (*waves hand* magic). Maybe it would be a good idea to raise the message level to "error", so that it is immediately obvious to the user that his DSE mods contain an error and cannot be parsed. Also you have a typo in the commit message of patch 320 (s/chages/changes/). -- Martin^3 Babinsky From pspacek at redhat.com Wed Oct 14 14:05:35 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 14 Oct 2015 16:05:35 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <561E46FD.1020404@redhat.com> References: <561BC52D.6030301@redhat.com> <561CB486.2020906@redhat.com> <561CED0B.9090009@redhat.com> <561D0E76.1030709@redhat.com> <561E46FD.1020404@redhat.com> Message-ID: <561E612F.5090205@redhat.com> On 14.10.2015 14:13, Martin Babinsky wrote: > On 10/13/2015 04:00 PM, Petr Spacek wrote: >> On 13.10.2015 13:37, Martin Babinsky wrote: >>> On 10/13/2015 09:36 AM, Petr Spacek wrote: >>>> On 12.10.2015 16:35, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5200 >>>>> --- >>>>> ipalib/plugins/dns.py | 3 ++- >>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>> index >>>>> 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 >>>>> >>>>> 100644 >>>>> --- a/ipalib/plugins/dns.py >>>>> +++ b/ipalib/plugins/dns.py >>>>> @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>>> if prefixlen is None: >>>>> revzone = None >>>>> >>>>> - result = api.Command['dnszone_find']()['result'] >>>>> + result = api.Command['dnszone_find'](sizelimit=0)['result'] >>>>> + >>>> >>>> NACK, this just increases the limit because LDAP server will enforce a >>>> per-user limit. >>>> >>>>> for zone in result: >>>>> zonename = zone['idnsname'][0] >>>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>>> >>>> Generic solution should use dns.resolver.zone_for_name() to find DNS zone >>>> matching the reverse name. This should also implicitly cover CNAME/DNAME >>>> redirections per RFC2317. >>>> >>>> Using DNS implicitly means that a zone will always be found (at least the >>>> root >>>> zone :-). For this reason I would change final error message >>>>> reason=_('DNS reverse zone for IP address %(addr)s not found') >>>> to something like: >>>> reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not >>>> managed >>>> by this server') >>>> >>>> >>>> These changes should fix it without adding other artificial limitation. >>>> >>> >>> Thank you for clarification Petr. >>> >>> Attaching the reworked patch. >>> >>> -- >>> Martin^3 Babinsky >>> >>> freeipa-mbabinsk-0083.1-perform-more-robust-search-for-reverse-zones-when-ad.patch >>> >>> >>> >>> From 463903f4ea4f74efeb02dbb705ca0a54fab81366 Mon Sep 17 00:00:00 2001 >>> From: Martin Babinsky >>> Date: Mon, 12 Oct 2015 16:24:50 +0200 >>> Subject: [PATCH 1/3] perform more robust search for reverse zones when adding >>> DNS record >>> >>> Instead of searching for all zones to identify the correct reverse zone, we >>> will first ask the resolver to return the name of zone that should contain the >>> desired record and then see if IPA manages this zone. >>> >>> https://fedorahosted.org/freeipa/ticket/5200 >>> --- >>> ipalib/plugins/dns.py | 21 +++++++++++++++++---- >>> 1 file changed, 17 insertions(+), 4 deletions(-) >>> >>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>> index >>> 84086f4c77d02922f237937d58031cc42d55410e..e3c6ce46168f8b6af607a61af1e3e431cfee32c8 >>> 100644 >>> --- a/ipalib/plugins/dns.py >>> +++ b/ipalib/plugins/dns.py >>> @@ -531,25 +531,35 @@ def add_forward_record(zone, name, str_address): >>> pass # the entry already exists and matches >>> >>> def get_reverse_zone(ipaddr, prefixlen=None): >>> + """ >>> + resolve the reverse zone for IP address and see if it is managed by IPA >>> + server >>> + :param ipaddr: host IP address >>> + :param prefixlen: network prefix length >>> + :return: tuple containing name of the reverse zone and the name of the >>> + record >>> + """ >>> ip = netaddr.IPAddress(str(ipaddr)) >>> revdns = DNSName(unicode(ip.reverse_dns)) >>> + resolved_zone = unicode(dns.resolver.zone_for_name(revdns)) >>> >>> if prefixlen is None: >>> revzone = None >>> + result = api.Command['dnszone_find'](resolved_zone)['result'] >>> >>> - result = api.Command['dnszone_find']()['result'] >>> for zone in result: >>> zonename = zone['idnsname'][0] >>> if (revdns.is_subdomain(zonename.make_absolute()) and >>> (revzone is None or zonename.is_subdomain(revzone))): >>> revzone = zonename >> >> Oh, wait, this might blow up if there is a disabled DNS zone which is deeper >> than the one returned from DNS query. >> >> Damn, we have opened a Pandora box! >> >> ipaserver/install/bindinstance.py has own implementation of get_reverse_zone() >> + additional menthods find_reverse_zone(). >> These are using get_reverse_zone_default() from ipalib/util.py which is >> duplicating code in 'if prefixlen is not None' branch. >> >> And of course, are not correct in light of this change. >> >> My expectation would be that disabled zones should be ignored... So we should >> get rid of this mess in the loop and use dnszone_show() which is called at the >> end. And fix the other places, preferably by deleting duplicate >> implementations. >> >> I would expect that you can store (converted) output of >> dns.resolver.zone_for_name(revdns) into revzone and delete whole 'if prefixlen >> is None' branch. >> >>> else: >>> + # if prefixlen is specified, determine the zone name for the network >>> + # prefix >>> if ip.version == 4: >>> pos = 4 - prefixlen / 8 >>> elif ip.version == 6: >>> pos = 32 - prefixlen / 4 >>> - items = ip.reverse_dns.split('.') >>> - revzone = DNSName(items[pos:]) >>> + revzone = revdns[pos:] >> >> Hmm, and this logic will breaks CNAME/DNAME (RFC2317) handling ... Damn, we >> need different handling when we intend to create the zone and when we want to >> manipulate a record in a reverse zone. Grrr. >> >> When we want to manipulate a record in existing zone, the whole branch does >> not make sense and the result of DNS query is what we want and need. >> >> On the other hand, we need this when creating *a new zone* from IP address ... >> >> Mastin^2, what about zone names with missing period at the end? Is it handled >> by dnszone_show() internally? >> >> We have to discuss all this... >> >>> try: >>> api.Command['dnszone_show'](revzone) >>> @@ -558,7 +568,10 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>> >>> if revzone is None: >>> raise errors.NotFound( >>> - reason=_('DNS reverse zone for IP address %(addr)s not found') >>> % dict(addr=ipaddr) >>> + reason=_( >>> + 'DNS reverse zone %(resolved_zone)s for IP address ' >>> + '%(addr)s is not manager by this server') % dict( >> typo s/manager/managed/ >> >>> + addr=ipaddr, resolved_zone=resolved_zone) >>> ) >>> >>> revname = revdns.relativize(revzone) >> > > After lengthy discussion with Petr^2 I we decided to rework get_reverse_zone > function a bit. Attaching updated patch. Well, we should get rid of prefixlen parameter. Wipe it from Earth's surface! :-) The assumption here is that this function is always used only for manipulating *records in existing zones*, so the only way to find appropriate reverse zone name is to ask DNS. Derivation based on prefix length makes sense only for deriving reverse zone names from IP addresses *with intent to create the zone*. In all other cases it does not make sense to use prefix. I'm sorry that I was not clear. -- Petr^2 Spacek From mbasti at redhat.com Wed Oct 14 14:10:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Oct 2015 16:10:20 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561E5DDC.2090609@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> Message-ID: <561E624C.2080601@redhat.com> On 14.10.2015 15:51, Martin Babinsky wrote: > On 10/13/2015 06:38 PM, Martin Basti wrote: >> >> >> On 12.10.2015 12:30, Martin Babinsky wrote: >>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>> The attached patches fix following tickets: >>>> https://fedorahosted.org/freeipa/ticket/4949 >>>> https://fedorahosted.org/freeipa/ticket/4048 >>>> https://fedorahosted.org/freeipa/ticket/1930 >>>> >>>> With these patches, an administrator can specify LDIF file that >>>> contains >>>> modifications to be applied to dse.ldif right after creation of DS >>>> instance. >>>> >>>> >>> Hi, >>> >>> Functionally the paches work as expected. However I have following >>> nitpicks: >>> >>> in patch 318: >>> >>> 1.) there is a typo in ModifyLDIF class docstring: >>> >>> + Operations keep the order in whihc were specified per DN. >>> >>> in patch 320: >>> >>> 1.) you should use 'os.path.join' to construct FS paths: >>> >>> >>> - dse_filename = '%s/%s' % ( >>> + dse_filename = os.path.join( >>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % self.serverid, >>> - 'dse.ldif', >>> + 'dse.ldif' >>> ) >>> >>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to >>> LDIF containing the mod operations to dse.ldif. However, the knob name >>> sounds like the option accepts the path of dse.ldif itself. I propose >>> to rename the knob to something more in-line with the supposed >>> function, like 'dse_mods_file'. >>> >> >> Updated patches + CI test attached > > Patches work as expected and CI tests are OK. > > However it seems that warning level messages are not logged to > installer output but only to log file (*waves hand* magic). > > Maybe it would be a good idea to raise the message level to "error", > so that it is immediately obvious to the user that his DSE mods > contain an error and cannot be parsed. > > Also you have a typo in the commit message of patch 320 > (s/chages/changes/). > Updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0318.3-Make-offline-LDIF-modify-more-robust.patch Type: text/x-patch Size: 10753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0319.3-Add-method-to-read-changes-from-LDIF.patch Type: text/x-patch Size: 2951 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0320.3-Add-option-to-specify-LDIF-file-that-contains-DS-con.patch Type: text/x-patch Size: 9377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0323.2-CI-installation-with-customized-DS-config.patch Type: text/x-patch Size: 5389 bytes Desc: not available URL: From tbabej at redhat.com Wed Oct 14 14:13:50 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Oct 2015 16:13:50 +0200 Subject: [Freeipa-devel] [PATCH 373-374] idoverrides: Ignore SID conversion error and add coverage In-Reply-To: <561E44D7.2040907@redhat.com> References: <561CDB15.2080206@redhat.com> <561D07D7.6060909@redhat.com> <561E345B.3090505@redhat.com> <561E44D7.2040907@redhat.com> Message-ID: <561E631E.7070707@redhat.com> On 10/14/2015 02:04 PM, Martin Babinsky wrote: > On 10/14/2015 12:54 PM, Tomas Babej wrote: >> >> >> On 10/13/2015 03:32 PM, Martin Babinsky wrote: >>> On 10/13/2015 12:21 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this couple of patches fixes and improves the coverage for referential >>>> integrity of ID overrides. >>>> >>>> Note: Last test in the patch 374 is supposed to be failing (for now). >>>> >>>> https://fedorahosted.org/freeipa/ticket/5322 >>>> >>>> >>>> >>> >>> Hi Tomas, >>> >>> Patch 373: >>> >>> I still get errors in CLI/WebUI, see http://fpaste.org/278706/47425481/ >>> >>> It seems that there are some other places in idviews code (e.g. >>> idview-show post_callback) that emit unhandled ValidationErrors. >>> >>> Patch 374: ACK >>> >> >> You're right, updated patch attached. >> > ACK > Pushed to: master: eaeb40328cf80f615684ffc692b9416e1c08d544 ipa-4-2: cc085d240dc4c6a02ef39752043059c1d35b591a From redhatrises at gmail.com Wed Oct 14 12:33:16 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 14 Oct 2015 06:33:16 -0600 Subject: [Freeipa-devel] [PATCH 0056] Enable nsaccountlock in user.py cli In-Reply-To: <561E17DE.9060904@redhat.com> References: <561D2953.6010308@redhat.com> <561D3889.6020003@redhat.com> <561E17DE.9060904@redhat.com> Message-ID: Alright. Let's postpone it to 4.4. Gabe On Wed, Oct 14, 2015 at 2:52 AM, Martin Basti wrote: > Sorry, we cannot push this patch because I realize that it breaks API > compatibility. > > The proper fix is add this code to find method (not tested) > > def get_options(self): > for option in super(user_find, self).get_options(): > if option.name == "nsaccountlock": > flags = set(option.flags) > flags.remove("no_option") > option = option.clone(flags=flags) > yield option > > But I do not like too much this code, we plan to do some ipalib > refactoring in IPA 4.4, so we can do there bigger changes and solve this > issue in nicer way. > If you don't mind, I would postpone this to IPA 4.4, instead of hacking > the framework > > Martin > > > On 13.10.2015 19:12, Gabe Alford wrote: > > Updated patch attached. > > On Tue, Oct 13, 2015 at 10:59 AM, Martin Basti < > mbasti at redhat.com> wrote: > >> >> >> On 13.10.2015 18:53, Gabe Alford wrote: >> >> Thanks Martin, >> >> What about adding no_create and no_update flags? >> >> Gabe >> >> Yes, that may work, also please increment minor version of API and add >> ticket into commit message (https://fedorahosted.org/freeipa/ticket/5366) >> >> >> Thanks. >> Martin >> >> >> On Tue, Oct 13, 2015 at 9:54 AM, Martin Basti < >> mbasti at redhat.com> wrote: >> >>> >>> >>> On 09.10.2015 19:17, Gabe Alford wrote: >>> >>> Hello, >>> >>> This patch enables nsaccountlock in user.py cli. It is very handy to be >>> able to search and find users with disabled/enabled accounts, etc. That >>> said, I couldn't find why it was no_option in the first place, so I am not >>> 100% sure if it breaks something or the reasoning behind no_option. >>> >>> Thanks, >>> >>> Gabe >>> >>> >>> Hello, >>> >>> https://fedorahosted.org/freeipa/ticket/5366 >>> >>> This patch allows to enable/disable user via user-mod, and we do not >>> want to do this, so NACK for this patch. >>> I'm not sure yet how to write it in elegant way. >>> >>> Martin. >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 14 15:39:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Oct 2015 17:39:58 +0200 Subject: [Freeipa-devel] [PATCHES 0002-0008] [RFE] Implement iCal based time managment in HBAC In-Reply-To: <5614CFE1.7030705@redhat.com> References: <5614CFE1.7030705@redhat.com> Message-ID: <561E774E.3000007@redhat.com> I just read the code did not testing, maybe I will read design tomorrow. I found a few minor issues 0) You use too much brackets in code, it looks more like C than python: if not(elem): --> if not elem if(len(elempair) > 2) --> if len(elempair) > 2: return(something) --> return something 1) +def _timearg_to_list(time): + ''' + Parses the argument of either of the access time language keywords + + Example: '1-5,12' into [[1,5], 12] + ''' + return (t.split('-') for t in time.split(',')) This will return [['1', '5'], ['12']] please fix example 2) in function _validate_range(keyword, lst, r1, r2, unit, unitlen): I do not like that enumeration and this condition + if not(i): + elold = elnum Can you use instead enumeration just None? elold = None if elold is None: elold = elnum 3) _validate_timeofday(t) I do not like that enumerate (see 2) ) 4) _validate_timeofday(t) There is missing check for values like '1-2-5', '1-2,', (this check is in _validate_range) 5) I do not think that unitlen arg in _validate_range is needed, IMO this is duplicated check, comparison r1, r2 is enough 6) +def validate_accesstime(ugettext, value): This function is not pythonic enough, it looks more like C I suggest something like: params = { name: {'found': False, 'method': method } for name, method in [ ('dayofweek', _validate_dayofweek), ('timeofday', _validate_timeof...), ..... ]} for i, el enumerate(ts): param_name, param_value = el.split('=', 1) try: res = params[param_name]['method'](param_value) if not params[param_name]['found'] else _("multiple blablabla of {param}".format(param=param_name)) params[param_name]['found'] = True except KeyError: res = _(Unknown.....) if res: return res 7) + res = _validate_timeofday(el[10:]) if not(found[TOD]) else \ + _("multiple appearance of timeofday") Please don't use '\', use braces instead 8) - 'externalhost', + 'memberhostgroup', 'externalhost', 'ipatimezone', + 'accesstime', 'accesstimeexclude' Are you sure that 'memberhostgroup' should be added there? I don't think so. 9) def normalize_accesstime(t): IIRC normalize is called before validate, so your precious regular expression may not work as expected, namely: + t = re.sub(r'(\d)([a-z]{2})', r'\1 \2', t) + t = re.sub(r'(\d)\s(d|w|m|y)\s', r'\1\2', t) However when normalization returns unexpected results, validation will be able catch it. IMO we should not do any magic detection, we should force user to have keyword and value pairs separated by space How about depending on '=' character in normalization? parts = re.split('[\s=]', t) eq_signs_pos = [i for i, part in enumeration(parts) if parts=="="] 10) _validate_date() http://stackoverflow.com/questions/16870663/how-do-i-validate-a-date-string-format-in-python I know the solution above is not so detailed in what is wrong, but IMO to print that specified date is not valid should be enough for user. 11) in _validate_date function I see validation for case when dayofmonth is higher than, last day of month. I do not see this check for other cases than 'repeat'. Is it safe to ignore (for example: "dayofmonth=30 monthofyear=2" this HBACrule will never be executed)? 12) + if not('1' <= t[ctlpos] <= '9'): + return _("'repeat': wrong syntax, expected a number after '+'") IMO 0 is digit/number too, and we should allow initial 0 and just ignore them during execution 13) +def _validate_repeat(t): + date1 = t[0:8] what if 't' is shorter than 8 characters? 14) + date2 = t[9:17] if t[8] == '-' else None What if t < 17 characters and t[8] == '-'? 15) + if t[ctlpos] not in ('d', 'w', 'm', 'y'): + return _("'repeat': wrong syntax, d/w/m/y expected") What if there is any continuation after? "repeat=20151003+2m-trolololo" (you can add this to tests :) ) 16) IMO _validate_repeat check looks simple enough to be checked by regexp, and then separate parts tested extra (start, end date, repeat period) 17) +def _validate_ymd_range(y1, m1, d1, y2, m2, d2): Can you instead of this black magic use python datetime object? https://docs.python.org/2/library/datetime.html And then just compare 2 objects with '>' and return error that second date is greater than first. Also datetime object creation will check if date itself. 18) + rule_time = u'timeofday=0000-2359 dayofmonth=1-15,16-31 ' \ + 'dayofyear=23-47,26-77 year=1970-2563' Please use () instead of \ 19) + # no spaces around - sign <-- ~ should be there + t = re.sub(r'\s?~\s?', r'~', t) wouldn't be better to work with ~ since first patch? I mean replace '-' -> '~' in first patch Is common to specify date ranges with '~' ? Personally I wouldn't expected that. 20) Please add design page to the ticket (if exists) https://fedorahosted.org/freeipa/ticket/547 21) PEP8 ./ipalib/plugins/hbacrule.py:190:21: E265 block comment should start with '# ' ./ipatests/test_xmlrpc/test_hbac_plugin.py:38:18: E127 continuation line over-indented for visual indent ./ipatests/test_xmlrpc/test_hbac_plugin.py:38:18: E127 continuation line over-indented for visual indent ./ipatests/test_xmlrpc/test_hbac_plugin.py:101:80: E501 line too long (84 > 79 characters) ./ipalib/plugins/hbactest.py:281:9: E124 closing bracket does not match visual indentation ./ipalib/plugins/hbacrule.py:78:80: E501 line too long (80 > 79 characters) ./ipalib/plugins/hbacrule.py:190:21: E265 block comment should start with '# ' ./ipalib/plugins/hbacrule.py:219:80: E501 line too long (84 > 79 characters) ./ipalib/plugins/hbacrule.py:592:9: E124 closing bracket does not match visual indentation ./ipalib/plugins/hbacrule.py:596:9: E124 closing bracket does not match visual indentation 22) Unwanted lines removal at the end of files/patches * Added methods for setting time-based policies: hbacrule.py * HBAC test module support for time-based policies: hbactest.py * Tests for HBAC time rules language: test_hbactest_plugin.py best regards Martin^2 On 07.10.2015 09:55, Stanislav Laznicka wrote: > Hi, > > The moment's here, I'd like to share my code with you now. Let me > comment on some additions from my last post here in August. > > The methods for testing HBAC rules in hbactest module were modified so > that a time zone can now also be picked in case there are some rules > with the "host" time zone in the rule time policy. I also added few > tests that test setting accessTime values. > > The most important update of the previous month is the addition of > negative values to the time rules language. Most of the keywords (all, > except for timeofday and year) now accept negative values and negative > value ranges. This should be useful for cases when the user should > only be allowed access e.g. in the last 7 days of a month, last few > weeks of a year etc. Also, it is a similar behavior to what iCalendar > has. > > The addition of negative values also made me re-think the ways the > week of a year should be calculated. There are no 0th weeks of year > anymore, a week of year can hold values ranging from 1 to 53 where the > 1st week of a year may appear even on a date of the previous year (if > 1st January is Tue-Thu) or the 52nd or 53rd week may appear on a date > of the following year (when 31st December is Thu-Sat). If my > explanation seems rather rough, please see > https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html. > > The latter caused some changes to be made in my SSSD code. These > changes took the most of my time last month alongside with generally > polishing the code and adding comments where I thought necessary. I > will push my SSSD code to the sssd-devel mailing list as a follow-up > to this mail. > > Another thing - I updated the design page on the FreeIPA wiki, so > please check it out, too > (http://www.freeipa.org/page/V4/Time-Based_Account_Policies). > > Last thing I would like to mention - there is now a copr repo with > both sssd and freeipa with time-based policies > (https://copr.fedoraproject.org/coprs/stlaz/freeipa-sssd-timerules/). > This was Martin K.'s idea and I think it's pretty dandy :) As the > patches I am posting only contain CLI for HBAC time policies, you > might be pleased that the repo includes at least basic WebUI for this > purpose (although the WebUI is for some reason not updating the page > on rule addition properly, I will be hopefully looking into that > shortly). You will still need mkosek/freeipa-master copr repo for some > dependencies. Should it not work properly for you, please, send me an > email, it's my first time taking care of a copr repo. > > That's it from me for now, thank you for your patience with my emails, > Standa > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Oct 15 08:45:08 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Oct 2015 10:45:08 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1443030466.6835.4.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> <56024848.3030005@redhat.com> <1443030466.6835.4.camel@willson.usersys.redhat.com> Message-ID: <561F6794.1040201@redhat.com> On 23.9.2015 19:47, Simo Sorce wrote: > 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. "Add ipa-custodia service": functional ACK 1) freeipa-python is still missing BuildRequires and Requires on python-jwcrypto: On 23.9.2015 08:35, Jan Cholasta wrote: > 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: >>>> 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. "Require a DS version that has working DNA plugin": ACK "Implement replica promotion functionality": 1) You should handle NotFound for the find_entries() call in cainstance.find_ca_server(). 2) You can remove ReplicaCA and ReplicaDNS classes as they are unused. 3) I'm getting this on domain level 0 client: # ipa-replica-install Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639053): No Kerberos credentials available It comes from the "Try out authentication" conn.connect() in promote_check(), because it is missing the ccache kwarg. "Change DNS installer code to use passed in api": ACK "Allow ipa-replica-conncheck to use default creds": 1) ipa-replica-install prompts for admin password twice during connection check: Get credentials to log in to remote master Check SSH connection to remote master admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: Execute check on remote master admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: "Add function to extract CA certs for install": ACK "topology: manage ca replication agreements": functional ACK 1) This 20-replication.update bit does not seem to be related to the patch: # add IPA realm managed suffix to master entry dn: cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX add: objectclass: ipaReplTopoManagedServer add: ipaReplTopoManagedSuffix: $SUFFIX Why is it included? (Petr?) 2) In update_ca_topology, call CAInstance.__update_topology() instead of copy & pasting the code. "enable topology plugin on upgrade": ACK "topology plugin configuration workaround": ACK "handle multiple managed suffixes": ACK "prevent operation on tombstones": ACK "Allow to setup the CA when promoting a replica": ACK "Make checks for existing credentials reusable": ACK "Add low level helper to get domain level": ACK "Allow ipa-ca-install to use the new promotion code": 1) The --replica option was not removed: On 22.9.2015 10:45, Jan Cholasta wrote: > 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) ipa-ca-install prompts for both admin and DM password: # ipa-ca-install -r Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: Directory Manager (existing master) password: DM password should not be required, right? 3) ipa-ca-install fails with: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 445, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 435, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 631, in __spawn_instance DogtagInstance.spawn_instance(self, cfg_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 185, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 448, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) RuntimeError: CA configuration failed. I guess I'm hitting the authentication bug in Dogtag. It is supposed to be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? We might need a new 10.2.7 build. "Remove unused kra option": ACK "Allow to install the KRA on a promoted server": 1) ipa-kra-install fails with: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", line 220, in run self._run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", line 200, in _run if config.subject_base is None: AttributeError: 'NoneType' object has no attribute 'subject_base' -- Jan Cholasta From pvoborni at redhat.com Thu Oct 15 10:00:27 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Oct 2015 12:00:27 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561F6794.1040201@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> Message-ID: <561F793B.2090000@redhat.com> On 10/15/2015 10:45 AM, Jan Cholasta wrote: > On 23.9.2015 19:47, Simo Sorce wrote: >> 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. > > "Add ipa-custodia service": functional ACK > > 1) freeipa-python is still missing BuildRequires and Requires on > python-jwcrypto: > > On 23.9.2015 08:35, Jan Cholasta wrote: >> 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: >>>>> 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. > > > "Require a DS version that has working DNA plugin": ACK > > > "Implement replica promotion functionality": > > 1) You should handle NotFound for the find_entries() call in > cainstance.find_ca_server(). > > 2) You can remove ReplicaCA and ReplicaDNS classes as they are unused. > > 3) I'm getting this on domain level 0 client: > > # ipa-replica-install > Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROR Major (851968): > Unspecified GSS failure. Minor code may provide more information, Minor > (2529639053): No Kerberos credentials available > > It comes from the "Try out authentication" conn.connect() in > promote_check(), because it is missing the ccache kwarg. > > > "Change DNS installer code to use passed in api": ACK > > > "Allow ipa-replica-conncheck to use default creds": > > 1) ipa-replica-install prompts for admin password twice during > connection check: > > Get credentials to log in to remote master > Check SSH connection to remote master > admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: > Execute check on remote master > admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: > > > "Add function to extract CA certs for install": ACK > > > "topology: manage ca replication agreements": functional ACK > > 1) This 20-replication.update bit does not seem to be related to the patch: > > # add IPA realm managed suffix to master entry > dn: cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > add: objectclass: ipaReplTopoManagedServer > add: ipaReplTopoManagedSuffix: $SUFFIX > > Why is it included? (Petr?) I believe this could be send as a separate patch. It was included during tuning of update and is not related to replica promotion nor managing of CA agreements. > > 2) In update_ca_topology, call CAInstance.__update_topology() instead of > copy & pasting the code. > > > "enable topology plugin on upgrade": ACK > > > "topology plugin configuration workaround": ACK > > > "handle multiple managed suffixes": ACK > > > "prevent operation on tombstones": ACK > > > "Allow to setup the CA when promoting a replica": ACK > > > "Make checks for existing credentials reusable": ACK > > > "Add low level helper to get domain level": ACK > > > "Allow ipa-ca-install to use the new promotion code": > > 1) The --replica option was not removed: > > On 22.9.2015 10:45, Jan Cholasta wrote: >> 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) ipa-ca-install prompts for both admin and DM password: > > # ipa-ca-install -r > Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: > Directory Manager (existing master) password: > > DM password should not be required, right? > > 3) ipa-ca-install fails with: > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 445, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 435, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 631, in __spawn_instance > DogtagInstance.spawn_instance(self, cfg_file) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 185, in spawn_instance > self.handle_setup_error(e) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 448, in handle_setup_error > raise RuntimeError("%s configuration failed." % self.subsystem) > RuntimeError: CA configuration failed. > > I guess I'm hitting the authentication bug in Dogtag. It is supposed to > be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? > We might need a new 10.2.7 build. > > > "Remove unused kra option": ACK > > > "Allow to install the KRA on a promoted server": > > 1) ipa-kra-install fails with: > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line > 171, in execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", > line 220, in run > self._run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", > line 200, in _run > if config.subject_base is None: > AttributeError: 'NoneType' object has no attribute 'subject_base' > > -- Petr Vobornik From dkupka at redhat.com Thu Oct 15 10:33:39 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 15 Oct 2015 12:33:39 +0200 Subject: [Freeipa-devel] [PATCH] admintool: Add error message with path to log on failure. Message-ID: <561F8103.1050708@redhat.com> Currently, when there is unhanded exception without any message, installer ends with error code but without any error message. Adding line stating that some error occurred and where are logs located should help with debugging. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0067-admintool-Add-error-message-with-path-to-log-on-fail.patch Type: text/x-patch Size: 941 bytes Desc: not available URL: From tbabej at redhat.com Thu Oct 15 11:02:55 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Oct 2015 13:02:55 +0200 Subject: [Freeipa-devel] [PATCH] admintool: Add error message with path to log on failure. In-Reply-To: <561F8103.1050708@redhat.com> References: <561F8103.1050708@redhat.com> Message-ID: <561F87DF.5070304@redhat.com> On 10/15/2015 12:33 PM, David Kupka wrote: > Currently, when there is unhanded exception without any message, > installer ends with error code but without any error message. > > Adding line stating that some error occurred and where are logs located > should help with debugging. > > > The default value for the log_file_name is None, so we probably need to handle this correctly in case the AdminTool class instance logs to stderr only. Tomas From dkupka at redhat.com Thu Oct 15 11:24:13 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 15 Oct 2015 13:24:13 +0200 Subject: [Freeipa-devel] [PATCH] admintool: Add error message with path to log on failure. In-Reply-To: <561F87DF.5070304@redhat.com> References: <561F8103.1050708@redhat.com> <561F87DF.5070304@redhat.com> Message-ID: <561F8CDD.1040601@redhat.com> On 15/10/15 13:02, Tomas Babej wrote: > > > On 10/15/2015 12:33 PM, David Kupka wrote: >> Currently, when there is unhanded exception without any message, >> installer ends with error code but without any error message. >> >> Adding line stating that some error occurred and where are logs located >> should help with debugging. >> >> >> > > The default value for the log_file_name is None, so we probably need to > handle this correctly in case the AdminTool class instance logs to > stderr only. > > Tomas > Thanks for good catch, fixed patch attached. I guess the same is true for command_name but it is used quite extensively it the code so it's probably safe to assume that it will be always set. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0067.1-admintool-Add-error-message-with-path-to-log-on-fail.patch Type: text/x-patch Size: 1015 bytes Desc: not available URL: From tbabej at redhat.com Thu Oct 15 11:30:32 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Oct 2015 13:30:32 +0200 Subject: [Freeipa-devel] [PATCH] admintool: Add error message with path to log on failure. In-Reply-To: <561F8CDD.1040601@redhat.com> References: <561F8103.1050708@redhat.com> <561F87DF.5070304@redhat.com> <561F8CDD.1040601@redhat.com> Message-ID: <561F8E58.7000401@redhat.com> On 10/15/2015 01:24 PM, David Kupka wrote: > On 15/10/15 13:02, Tomas Babej wrote: >> >> >> On 10/15/2015 12:33 PM, David Kupka wrote: >>> Currently, when there is unhanded exception without any message, >>> installer ends with error code but without any error message. >>> >>> Adding line stating that some error occurred and where are logs located >>> should help with debugging. >>> >>> >>> >> >> The default value for the log_file_name is None, so we probably need to >> handle this correctly in case the AdminTool class instance logs to >> stderr only. >> >> Tomas >> > > Thanks for good catch, fixed patch attached. > I guess the same is true for command_name but it is used quite > extensively it the code so it's probably safe to assume that it will be > always set. > Yes, such assumption is reasonable. Unlike log_file_name, there is no use case for command_name being set to None intentionally. ACK. Tomas From tbabej at redhat.com Thu Oct 15 11:33:20 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Oct 2015 13:33:20 +0200 Subject: [Freeipa-devel] [PATCH] admintool: Add error message with path to log on failure. In-Reply-To: <561F8E58.7000401@redhat.com> References: <561F8103.1050708@redhat.com> <561F87DF.5070304@redhat.com> <561F8CDD.1040601@redhat.com> <561F8E58.7000401@redhat.com> Message-ID: <561F8F00.2060609@redhat.com> On 10/15/2015 01:30 PM, Tomas Babej wrote: > > > On 10/15/2015 01:24 PM, David Kupka wrote: >> On 15/10/15 13:02, Tomas Babej wrote: >>> >>> >>> On 10/15/2015 12:33 PM, David Kupka wrote: >>>> Currently, when there is unhanded exception without any message, >>>> installer ends with error code but without any error message. >>>> >>>> Adding line stating that some error occurred and where are logs located >>>> should help with debugging. >>>> >>>> >>>> >>> >>> The default value for the log_file_name is None, so we probably need to >>> handle this correctly in case the AdminTool class instance logs to >>> stderr only. >>> >>> Tomas >>> >> >> Thanks for good catch, fixed patch attached. >> I guess the same is true for command_name but it is used quite >> extensively it the code so it's probably safe to assume that it will be >> always set. >> > > Yes, such assumption is reasonable. Unlike log_file_name, there is no > use case for command_name being set to None intentionally. > > ACK. > > Tomas > Pushed to master: 5aa118d14905daa8c124be1cee02cfeaf26be3e4 From pvoborni at redhat.com Thu Oct 15 12:04:53 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Oct 2015 14:04:53 +0200 Subject: [Freeipa-devel] [PATCH] 922 topology: add realm suffix to master entry on update Message-ID: <561F9665.5000303@redhat.com> This patch was extracted from replica promotion patches. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0922-topology-add-realm-suffix-to-master-entry-on-update.patch Type: text/x-patch Size: 1070 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 15 12:09:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Oct 2015 14:09:10 +0200 Subject: [Freeipa-devel] [PATCH] 922 topology: add realm suffix to master entry on update In-Reply-To: <561F9665.5000303@redhat.com> References: <561F9665.5000303@redhat.com> Message-ID: <561F9766.8060005@redhat.com> On 15.10.2015 14:04, Petr Vobornik wrote: > This patch was extracted from replica promotion patches. (reference: ) Thanks, ACK. Pushed to master: ba22999cefb57f344acdc63a553d569ab6249099 -- Jan Cholasta From jcholast at redhat.com Thu Oct 15 12:29:30 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Oct 2015 14:29:30 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561F793B.2090000@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> Message-ID: <561F9C2A.5020907@redhat.com> On 15.10.2015 12:00, Petr Vobornik wrote: > On 10/15/2015 10:45 AM, Jan Cholasta wrote: >> On 23.9.2015 19:47, Simo Sorce wrote: >>> 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. >> >> "Add ipa-custodia service": functional ACK >> >> 1) freeipa-python is still missing BuildRequires and Requires on >> python-jwcrypto: >> >> On 23.9.2015 08:35, Jan Cholasta wrote: >>> 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: >>>>>> 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. >> >> >> "Require a DS version that has working DNA plugin": ACK >> >> >> "Implement replica promotion functionality": >> >> 1) You should handle NotFound for the find_entries() call in >> cainstance.find_ca_server(). >> >> 2) You can remove ReplicaCA and ReplicaDNS classes as they are unused. >> >> 3) I'm getting this on domain level 0 client: >> >> # ipa-replica-install >> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> ipa.ipapython.install.cli.install_tool(Replica): ERROR Major (851968): >> Unspecified GSS failure. Minor code may provide more information, Minor >> (2529639053): No Kerberos credentials available >> >> It comes from the "Try out authentication" conn.connect() in >> promote_check(), because it is missing the ccache kwarg. >> >> >> "Change DNS installer code to use passed in api": ACK >> >> >> "Allow ipa-replica-conncheck to use default creds": >> >> 1) ipa-replica-install prompts for admin password twice during >> connection check: >> >> Get credentials to log in to remote master >> Check SSH connection to remote master >> admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: >> Execute check on remote master >> admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: >> >> >> "Add function to extract CA certs for install": ACK >> >> >> "topology: manage ca replication agreements": functional ACK >> >> 1) This 20-replication.update bit does not seem to be related to the >> patch: >> >> # add IPA realm managed suffix to master entry >> dn: cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX >> add: objectclass: ipaReplTopoManagedServer >> add: ipaReplTopoManagedSuffix: $SUFFIX >> >> Why is it included? (Petr?) > > I believe this could be send as a separate patch. It was included during > tuning of update and is not related to replica promotion nor managing of > CA agreements. (reference: ) > >> >> 2) In update_ca_topology, call CAInstance.__update_topology() instead of >> copy & pasting the code. >> >> >> "enable topology plugin on upgrade": ACK >> >> >> "topology plugin configuration workaround": ACK >> >> >> "handle multiple managed suffixes": ACK >> >> >> "prevent operation on tombstones": ACK >> >> >> "Allow to setup the CA when promoting a replica": ACK >> >> >> "Make checks for existing credentials reusable": ACK >> >> >> "Add low level helper to get domain level": ACK To speed things up, I fixed the issues I found in the patches above, to be able to push them. Pushed to master: 6a0087aea176d1e1154b359fa262066896d663e3 >> >> >> "Allow ipa-ca-install to use the new promotion code": >> >> 1) The --replica option was not removed: >> >> On 22.9.2015 10:45, Jan Cholasta wrote: >>> 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) ipa-ca-install prompts for both admin and DM password: >> >> # ipa-ca-install -r >> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >> Directory Manager (existing master) password: >> >> DM password should not be required, right? >> >> 3) ipa-ca-install fails with: >> >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 445, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 435, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 631, in __spawn_instance >> DogtagInstance.spawn_instance(self, cfg_file) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >> line 185, in spawn_instance >> self.handle_setup_error(e) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >> line 448, in handle_setup_error >> raise RuntimeError("%s configuration failed." % self.subsystem) >> RuntimeError: CA configuration failed. >> >> I guess I'm hitting the authentication bug in Dogtag. It is supposed to >> be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? >> We might need a new 10.2.7 build. >> >> >> "Remove unused kra option": ACK I also pushed this one. Pushed to master: 9e007edbd902a5395797ca0ca9a698033540d755 >> >> >> "Allow to install the KRA on a promoted server": >> >> 1) ipa-kra-install fails with: >> >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >> 171, in execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", >> line 220, in run >> self._run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", >> line 200, in _run >> if config.subject_base is None: >> AttributeError: 'NoneType' object has no attribute 'subject_base' >> >> > > -- Jan Cholasta From mbabinsk at redhat.com Thu Oct 15 14:29:47 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 15 Oct 2015 16:29:47 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels Message-ID: <561FB85B.3070202@redhat.com> https://fedorahosted.org/freeipa/ticket/5175 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0086-disable-ipa-replica-prepare-in-non-zero-IPA-domain-l.patch Type: text/x-patch Size: 2878 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 15 14:50:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Oct 2015 16:50:01 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561E624C.2080601@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> Message-ID: <561FBD19.9030404@redhat.com> On 14.10.2015 16:10, Martin Basti wrote: > > > On 14.10.2015 15:51, Martin Babinsky wrote: >> On 10/13/2015 06:38 PM, Martin Basti wrote: >>> >>> >>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>> The attached patches fix following tickets: >>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>> >>>>> With these patches, an administrator can specify LDIF file that >>>>> contains >>>>> modifications to be applied to dse.ldif right after creation of DS >>>>> instance. >>>>> >>>>> >>>> Hi, >>>> >>>> Functionally the paches work as expected. However I have following >>>> nitpicks: >>>> >>>> in patch 318: >>>> >>>> 1.) there is a typo in ModifyLDIF class docstring: >>>> >>>> + Operations keep the order in whihc were specified per DN. >>>> >>>> in patch 320: >>>> >>>> 1.) you should use 'os.path.join' to construct FS paths: >>>> >>>> >>>> - dse_filename = '%s/%s' % ( >>>> + dse_filename = os.path.join( >>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % self.serverid, >>>> - 'dse.ldif', >>>> + 'dse.ldif' >>>> ) >>>> >>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to >>>> LDIF containing the mod operations to dse.ldif. However, the knob name >>>> sounds like the option accepts the path of dse.ldif itself. I propose >>>> to rename the knob to something more in-line with the supposed >>>> function, like 'dse_mods_file'. >>>> >>> >>> Updated patches + CI test attached >> >> Patches work as expected and CI tests are OK. >> >> However it seems that warning level messages are not logged to >> installer output but only to log file (*waves hand* magic). >> >> Maybe it would be a good idea to raise the message level to "error", >> so that it is immediately obvious to the user that his DSE mods >> contain an error and cannot be parsed. >> >> Also you have a typo in the commit message of patch 320 >> (s/chages/changes/). >> > Updated patches attached. > > > Rebased patches for master branch. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0318.4-Make-offline-LDIF-modify-more-robust.patch Type: text/x-patch Size: 10748 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0319.4-Add-method-to-read-changes-from-LDIF.patch Type: text/x-patch Size: 2951 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0320.4-Add-option-to-specify-LDIF-file-that-contains-DS-con.patch Type: text/x-patch Size: 9726 bytes Desc: not available URL: From simo at redhat.com Thu Oct 15 14:54:07 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Oct 2015 10:54:07 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561F6794.1040201@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> Message-ID: <561FBE0F.5040601@redhat.com> Commenting only on the 2 remaining patches that need to be committed, inline. On 15/10/15 04:45, Jan Cholasta wrote: > On 23.9.2015 19:47, Simo Sorce wrote: > "Allow ipa-ca-install to use the new promotion code": > > 1) The --replica option was not removed: Will do, thanks for spotting. > On 22.9.2015 10:45, Jan Cholasta wrote: >> 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) ipa-ca-install prompts for both admin and DM password: > > # ipa-ca-install -r > Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: > Directory Manager (existing master) password: > > DM password should not be required, right? Unfortunately if you install the CA in a separate step we still need to ask for the DM password because dogtag uses simple binds over ldaps:// and not ldapi://, we do not need that if you pass --setup-ca because we generate a random DM password and replace it with the hash obtained by the existing master only after all components are installed. > 3) ipa-ca-install fails with: > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 445, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 435, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 631, in __spawn_instance > DogtagInstance.spawn_instance(self, cfg_file) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 185, in spawn_instance > self.handle_setup_error(e) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 448, in handle_setup_error > raise RuntimeError("%s configuration failed." % self.subsystem) > RuntimeError: CA configuration failed. > > I guess I'm hitting the authentication bug in Dogtag. It is supposed to > be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? > We might need a new 10.2.7 build. I am not sure which version has it fixed, Endi ? > 1) ipa-kra-install fails with: > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line > 171, in execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", > line 220, in run > self._run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", > line 200, in _run > if config.subject_base is None: > AttributeError: 'NoneType' object has no attribute 'subject_base' I need to find out why this stopped working, will post a patch asap. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Oct 15 15:09:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Oct 2015 17:09:04 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561F9C2A.5020907@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> Message-ID: <561FC190.50200@redhat.com> On 15.10.2015 14:29, Jan Cholasta wrote: > On 15.10.2015 12:00, Petr Vobornik wrote: >> On 10/15/2015 10:45 AM, Jan Cholasta wrote: >>> On 23.9.2015 19:47, Simo Sorce wrote: >>>> 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. >>> >>> "Add ipa-custodia service": functional ACK >>> >>> 1) freeipa-python is still missing BuildRequires and Requires on >>> python-jwcrypto: >>> >>> On 23.9.2015 08:35, Jan Cholasta wrote: >>>> 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: >>>>>>> 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. >>> >>> >>> "Require a DS version that has working DNA plugin": ACK >>> >>> >>> "Implement replica promotion functionality": >>> >>> 1) You should handle NotFound for the find_entries() call in >>> cainstance.find_ca_server(). >>> >>> 2) You can remove ReplicaCA and ReplicaDNS classes as they are unused. >>> >>> 3) I'm getting this on domain level 0 client: >>> >>> # ipa-replica-install >>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR Major (851968): >>> Unspecified GSS failure. Minor code may provide more information, Minor >>> (2529639053): No Kerberos credentials available >>> >>> It comes from the "Try out authentication" conn.connect() in >>> promote_check(), because it is missing the ccache kwarg. >>> >>> >>> "Change DNS installer code to use passed in api": ACK >>> >>> >>> "Allow ipa-replica-conncheck to use default creds": >>> >>> 1) ipa-replica-install prompts for admin password twice during >>> connection check: >>> >>> Get credentials to log in to remote master >>> Check SSH connection to remote master >>> admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: >>> Execute check on remote master >>> admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: >>> >>> >>> "Add function to extract CA certs for install": ACK >>> >>> >>> "topology: manage ca replication agreements": functional ACK >>> >>> 1) This 20-replication.update bit does not seem to be related to the >>> patch: >>> >>> # add IPA realm managed suffix to master entry >>> dn: cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX >>> add: objectclass: ipaReplTopoManagedServer >>> add: ipaReplTopoManagedSuffix: $SUFFIX >>> >>> Why is it included? (Petr?) >> >> I believe this could be send as a separate patch. It was included during >> tuning of update and is not related to replica promotion nor managing of >> CA agreements. > > (reference: > ) > >> >>> >>> 2) In update_ca_topology, call CAInstance.__update_topology() >>> instead of >>> copy & pasting the code. >>> >>> >>> "enable topology plugin on upgrade": ACK >>> >>> >>> "topology plugin configuration workaround": ACK >>> >>> >>> "handle multiple managed suffixes": ACK >>> >>> >>> "prevent operation on tombstones": ACK >>> >>> >>> "Allow to setup the CA when promoting a replica": ACK >>> >>> >>> "Make checks for existing credentials reusable": ACK >>> >>> >>> "Add low level helper to get domain level": ACK > > To speed things up, I fixed the issues I found in the patches above, > to be able to push them. > > Pushed to master: 6a0087aea176d1e1154b359fa262066896d663e3 Upgrade does not work: https://fedorahosted.org/freeipa/ticket/5374 Martin > >>> >>> >>> "Allow ipa-ca-install to use the new promotion code": >>> >>> 1) The --replica option was not removed: >>> >>> On 22.9.2015 10:45, Jan Cholasta wrote: >>>> 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) ipa-ca-install prompts for both admin and DM password: >>> >>> # ipa-ca-install -r >>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>> Directory Manager (existing master) password: >>> >>> DM password should not be required, right? >>> >>> 3) ipa-ca-install fails with: >>> >>> Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 445, in start_creation >>> run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 435, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line >>> 631, in __spawn_instance >>> DogtagInstance.spawn_instance(self, cfg_file) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>> line 185, in spawn_instance >>> self.handle_setup_error(e) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>> line 448, in handle_setup_error >>> raise RuntimeError("%s configuration failed." % self.subsystem) >>> RuntimeError: CA configuration failed. >>> >>> I guess I'm hitting the authentication bug in Dogtag. It is supposed to >>> be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? >>> We might need a new 10.2.7 build. >>> >>> >>> "Remove unused kra option": ACK > > I also pushed this one. > > Pushed to master: 9e007edbd902a5395797ca0ca9a698033540d755 > >>> >>> >>> "Allow to install the KRA on a promoted server": >>> >>> 1) ipa-kra-install fails with: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >>> 171, in execute >>> return_value = self.run() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", >>> >>> line 220, in run >>> self._run() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", >>> >>> line 200, in _run >>> if config.subject_base is None: >>> AttributeError: 'NoneType' object has no attribute 'subject_base' >>> >>> >> >> > > From janorel at gmail.com Thu Oct 15 15:28:48 2015 From: janorel at gmail.com (Jan Orel) Date: Thu, 15 Oct 2015 17:28:48 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <561D3ED1.3030700@redhat.com> References: <5617B56E.7000807@redhat.com> <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> <561BD90A.9080000@redhat.com> <561D3ED1.3030700@redhat.com> Message-ID: > Anything bound to IPA can potentially retrieve a certificate. This code > adds special handling for hosts and probably should cover services as > well now that I think about it. I don't think services could be included > in ACIs when this was originally written. > > The idea was that hosts have no need to be able to query random serial > numbers so it should be limited to viewing its own. Removing the if > hostname: applies this logic to ALL retrieval which is by far overkill > and limits all non-admin entries to only be able to view certs they own > (or can write) which sort of kills the reason for the 'retrieve > certificate' permission. OK, anyway I don't think I am able to refactor right now to include also the services. I am attaching new simple patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-xorel-0001-3-cert-show-verify-write-access-to-userCertificate.patch Type: text/x-patch Size: 1407 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 15 15:39:30 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Oct 2015 17:39:30 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561F9C2A.5020907@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> Message-ID: <561FC8B2.7000500@redhat.com> On 15.10.2015 14:29, Jan Cholasta wrote: > On 15.10.2015 12:00, Petr Vobornik wrote: >> On 10/15/2015 10:45 AM, Jan Cholasta wrote: >>> On 23.9.2015 19:47, Simo Sorce wrote: >>>> 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. >>> >>> "Add ipa-custodia service": functional ACK >>> >>> 1) freeipa-python is still missing BuildRequires and Requires on >>> python-jwcrypto: >>> >>> On 23.9.2015 08:35, Jan Cholasta wrote: >>>> 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: >>>>>>> 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. >>> >>> >>> "Require a DS version that has working DNA plugin": ACK >>> >>> >>> "Implement replica promotion functionality": >>> >>> 1) You should handle NotFound for the find_entries() call in >>> cainstance.find_ca_server(). >>> >>> 2) You can remove ReplicaCA and ReplicaDNS classes as they are unused. >>> >>> 3) I'm getting this on domain level 0 client: >>> >>> # ipa-replica-install >>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> ipa.ipapython.install.cli.install_tool(Replica): ERROR Major (851968): >>> Unspecified GSS failure. Minor code may provide more information, Minor >>> (2529639053): No Kerberos credentials available >>> >>> It comes from the "Try out authentication" conn.connect() in >>> promote_check(), because it is missing the ccache kwarg. >>> >>> >>> "Change DNS installer code to use passed in api": ACK >>> >>> >>> "Allow ipa-replica-conncheck to use default creds": >>> >>> 1) ipa-replica-install prompts for admin password twice during >>> connection check: >>> >>> Get credentials to log in to remote master >>> Check SSH connection to remote master >>> admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: >>> Execute check on remote master >>> admin at vm-137.abc.idm.lab.eng.brq.redhat.com's password: >>> >>> >>> "Add function to extract CA certs for install": ACK >>> >>> >>> "topology: manage ca replication agreements": functional ACK >>> >>> 1) This 20-replication.update bit does not seem to be related to the >>> patch: >>> >>> # add IPA realm managed suffix to master entry >>> dn: cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX >>> add: objectclass: ipaReplTopoManagedServer >>> add: ipaReplTopoManagedSuffix: $SUFFIX >>> >>> Why is it included? (Petr?) >> >> I believe this could be send as a separate patch. It was included during >> tuning of update and is not related to replica promotion nor managing of >> CA agreements. > > (reference: > ) > >> >>> >>> 2) In update_ca_topology, call CAInstance.__update_topology() >>> instead of >>> copy & pasting the code. >>> >>> >>> "enable topology plugin on upgrade": ACK >>> >>> >>> "topology plugin configuration workaround": ACK >>> >>> >>> "handle multiple managed suffixes": ACK >>> >>> >>> "prevent operation on tombstones": ACK >>> >>> >>> "Allow to setup the CA when promoting a replica": ACK >>> >>> >>> "Make checks for existing credentials reusable": ACK >>> >>> >>> "Add low level helper to get domain level": ACK > > To speed things up, I fixed the issues I found in the patches above, > to be able to push them. > > Pushed to master: 6a0087aea176d1e1154b359fa262066896d663e3 > >>> >>> >>> "Allow ipa-ca-install to use the new promotion code": >>> >>> 1) The --replica option was not removed: >>> >>> On 22.9.2015 10:45, Jan Cholasta wrote: >>>> 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) ipa-ca-install prompts for both admin and DM password: >>> >>> # ipa-ca-install -r >>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>> Directory Manager (existing master) password: >>> >>> DM password should not be required, right? >>> >>> 3) ipa-ca-install fails with: >>> >>> Traceback (most recent call last): >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 445, in start_creation >>> run_step(full_msg, method) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 435, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line >>> 631, in __spawn_instance >>> DogtagInstance.spawn_instance(self, cfg_file) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>> line 185, in spawn_instance >>> self.handle_setup_error(e) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>> line 448, in handle_setup_error >>> raise RuntimeError("%s configuration failed." % self.subsystem) >>> RuntimeError: CA configuration failed. >>> >>> I guess I'm hitting the authentication bug in Dogtag. It is supposed to >>> be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? >>> We might need a new 10.2.7 build. Without this patch the ipa-ca-install is broken in current master. Unexpected error - see /var/log/ipareplica-ca-install.log for details: AttributeError: Values instance has no attribute 'promote' >>> >>> >>> "Remove unused kra option": ACK > > I also pushed this one. > > Pushed to master: 9e007edbd902a5395797ca0ca9a698033540d755 > >>> >>> >>> "Allow to install the KRA on a promoted server": >>> >>> 1) ipa-kra-install fails with: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >>> 171, in execute >>> return_value = self.run() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", >>> >>> line 220, in run >>> self._run() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_kra_install.py", >>> >>> line 200, in _run >>> if config.subject_base is None: >>> AttributeError: 'NoneType' object has no attribute 'subject_base' >>> >>> >> >> > > From mbabinsk at redhat.com Thu Oct 15 16:36:26 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 15 Oct 2015 18:36:26 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561FBD19.9030404@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> Message-ID: <561FD60A.7080409@redhat.com> On 10/15/2015 04:50 PM, Martin Basti wrote: > > > On 14.10.2015 16:10, Martin Basti wrote: >> >> >> On 14.10.2015 15:51, Martin Babinsky wrote: >>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>> >>>> >>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>> The attached patches fix following tickets: >>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>> >>>>>> With these patches, an administrator can specify LDIF file that >>>>>> contains >>>>>> modifications to be applied to dse.ldif right after creation of DS >>>>>> instance. >>>>>> >>>>>> >>>>> Hi, >>>>> >>>>> Functionally the paches work as expected. However I have following >>>>> nitpicks: >>>>> >>>>> in patch 318: >>>>> >>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>> >>>>> + Operations keep the order in whihc were specified per DN. >>>>> >>>>> in patch 320: >>>>> >>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>> >>>>> >>>>> - dse_filename = '%s/%s' % ( >>>>> + dse_filename = os.path.join( >>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % self.serverid, >>>>> - 'dse.ldif', >>>>> + 'dse.ldif' >>>>> ) >>>>> >>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to >>>>> LDIF containing the mod operations to dse.ldif. However, the knob name >>>>> sounds like the option accepts the path of dse.ldif itself. I propose >>>>> to rename the knob to something more in-line with the supposed >>>>> function, like 'dse_mods_file'. >>>>> >>>> >>>> Updated patches + CI test attached >>> >>> Patches work as expected and CI tests are OK. >>> >>> However it seems that warning level messages are not logged to >>> installer output but only to log file (*waves hand* magic). >>> >>> Maybe it would be a good idea to raise the message level to "error", >>> so that it is immediately obvious to the user that his DSE mods >>> contain an error and cannot be parsed. >>> >>> Also you have a typo in the commit message of patch 320 >>> (s/chages/changes/). >>> >> Updated patches attached. >> >> >> > Rebased patches for master branch. ACK -- Martin^3 Babinsky From mbasti at redhat.com Thu Oct 15 16:47:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Oct 2015 18:47:02 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561FD60A.7080409@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> Message-ID: <561FD886.9050800@redhat.com> On 15.10.2015 18:36, Martin Babinsky wrote: > On 10/15/2015 04:50 PM, Martin Basti wrote: >> >> >> On 14.10.2015 16:10, Martin Basti wrote: >>> >>> >>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>> The attached patches fix following tickets: >>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>> >>>>>>> With these patches, an administrator can specify LDIF file that >>>>>>> contains >>>>>>> modifications to be applied to dse.ldif right after creation of DS >>>>>>> instance. >>>>>>> >>>>>>> >>>>>> Hi, >>>>>> >>>>>> Functionally the paches work as expected. However I have following >>>>>> nitpicks: >>>>>> >>>>>> in patch 318: >>>>>> >>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>> >>>>>> + Operations keep the order in whihc were specified per DN. >>>>>> >>>>>> in patch 320: >>>>>> >>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>> >>>>>> >>>>>> - dse_filename = '%s/%s' % ( >>>>>> + dse_filename = os.path.join( >>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>> self.serverid, >>>>>> - 'dse.ldif', >>>>>> + 'dse.ldif' >>>>>> ) >>>>>> >>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the path to >>>>>> LDIF containing the mod operations to dse.ldif. However, the knob >>>>>> name >>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>> propose >>>>>> to rename the knob to something more in-line with the supposed >>>>>> function, like 'dse_mods_file'. >>>>>> >>>>> >>>>> Updated patches + CI test attached >>>> >>>> Patches work as expected and CI tests are OK. >>>> >>>> However it seems that warning level messages are not logged to >>>> installer output but only to log file (*waves hand* magic). >>>> >>>> Maybe it would be a good idea to raise the message level to "error", >>>> so that it is immediately obvious to the user that his DSE mods >>>> contain an error and cannot be parsed. >>>> >>>> Also you have a typo in the commit message of patch 320 >>>> (s/chages/changes/). >>>> >>> Updated patches attached. >>> >>> >>> >> Rebased patches for master branch. > ACK > Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 From mbasti at redhat.com Thu Oct 15 17:47:32 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Oct 2015 19:47:32 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561FD886.9050800@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> Message-ID: <561FE6B4.9000102@redhat.com> On 15.10.2015 18:47, Martin Basti wrote: > > > On 15.10.2015 18:36, Martin Babinsky wrote: >> On 10/15/2015 04:50 PM, Martin Basti wrote: >>> >>> >>> On 14.10.2015 16:10, Martin Basti wrote: >>>> >>>> >>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>> The attached patches fix following tickets: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>> >>>>>>>> With these patches, an administrator can specify LDIF file that >>>>>>>> contains >>>>>>>> modifications to be applied to dse.ldif right after creation of DS >>>>>>>> instance. >>>>>>>> >>>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Functionally the paches work as expected. However I have following >>>>>>> nitpicks: >>>>>>> >>>>>>> in patch 318: >>>>>>> >>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>> >>>>>>> + Operations keep the order in whihc were specified per DN. >>>>>>> >>>>>>> in patch 320: >>>>>>> >>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>> >>>>>>> >>>>>>> - dse_filename = '%s/%s' % ( >>>>>>> + dse_filename = os.path.join( >>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>> self.serverid, >>>>>>> - 'dse.ldif', >>>>>>> + 'dse.ldif' >>>>>>> ) >>>>>>> >>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>> path to >>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>> knob name >>>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>>> propose >>>>>>> to rename the knob to something more in-line with the supposed >>>>>>> function, like 'dse_mods_file'. >>>>>>> >>>>>> >>>>>> Updated patches + CI test attached >>>>> >>>>> Patches work as expected and CI tests are OK. >>>>> >>>>> However it seems that warning level messages are not logged to >>>>> installer output but only to log file (*waves hand* magic). >>>>> >>>>> Maybe it would be a good idea to raise the message level to "error", >>>>> so that it is immediately obvious to the user that his DSE mods >>>>> contain an error and cannot be parsed. >>>>> >>>>> Also you have a typo in the commit message of patch 320 >>>>> (s/chages/changes/). >>>>> >>>> Updated patches attached. >>>> >>>> >>>> >>> Rebased patches for master branch. >> ACK >> > Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b > Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 > These tickets are not for ipa-4-2, reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 From simo at redhat.com Thu Oct 15 18:14:46 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Oct 2015 14:14:46 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561FC8B2.7000500@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> Message-ID: <561FED16.5060604@redhat.com> On 15/10/15 11:39, Martin Basti wrote: > Without this patch the ipa-ca-install is broken in current master. > Unexpected error - see /var/log/ipareplica-ca-install.log for details: > AttributeError: Values instance has no attribute 'promote' Should be fixed with the attached patches. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-551-3-Allow-ipa-ca-install-to-use-the-new-promotion-code.patch Type: text/x-patch Size: 7650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-552-1-Allow-to-install-the-KRA-on-a-promoted-server.patch Type: text/x-patch Size: 31863 bytes Desc: not available URL: From janorel at gmail.com Thu Oct 15 15:10:20 2015 From: janorel at gmail.com (Jan Orel) Date: Thu, 15 Oct 2015 17:10:20 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: <561D3ED1.3030700@redhat.com> References: <5617B56E.7000807@redhat.com> <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> <561BD90A.9080000@redhat.com> <561D3ED1.3030700@redhat.com> Message-ID: 2015-10-13 19:26 GMT+02:00 Rob Crittenden : > Jan Orel wrote: >>> The restriction was there so that hosts had limited visibility. This >>> applies that limitation to all users. I think the host check needs to be >>> re-added. >> >> I am confused, correct me if I am wrong, but the "if hostname:" check >> seems always redundat because it would raise exception before >> either here: >> >> 615 if not bind_principal.startswith('host/'): >> 616 raise acierr >> >> or in validate_principal() > > Anything bound to IPA can potentially retrieve a certificate. This code > adds special handling for hosts and probably should cover services as > well now that I think about it. I don't think services could be included > in ACIs when this was originally written. > > The idea was that hosts have no need to be able to query random serial > numbers so it should be limited to viewing its own. Removing the if > hostname: applies this logic to ALL retrieval which is by far overkill > and limits all non-admin entries to only be able to view certs they own > (or can write) which sort of kills the reason for the 'retrieve > certificate' permission. > >> >>> Also, every host is not guaranteed to have a krbPrincipalAux (it can be >>> unenrolled). I assume you used this to cover managed services as well, >>> that's why the broad search base? >> >> Checking it, even host which is not enrolled have objectClass: krbprincipalaux, >> but advise me if different search should be used. > > If a host is added with a password (random or otherwise) it won't have > this objectclass. I'd make the search filter something like > (|(objectclass=ipahost)(objectclass=ipaservice)). > > rob From jcholast at redhat.com Fri Oct 16 04:00:26 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 16 Oct 2015 06:00:26 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <561FE6B4.9000102@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> Message-ID: <5620765A.6020208@redhat.com> On 15.10.2015 19:47, Martin Basti wrote: > > > On 15.10.2015 18:47, Martin Basti wrote: >> >> >> On 15.10.2015 18:36, Martin Babinsky wrote: >>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>> >>>> >>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>> >>>>> >>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>> The attached patches fix following tickets: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>> >>>>>>>>> With these patches, an administrator can specify LDIF file that >>>>>>>>> contains >>>>>>>>> modifications to be applied to dse.ldif right after creation of DS >>>>>>>>> instance. >>>>>>>>> >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Functionally the paches work as expected. However I have following >>>>>>>> nitpicks: >>>>>>>> >>>>>>>> in patch 318: >>>>>>>> >>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>> >>>>>>>> + Operations keep the order in whihc were specified per DN. >>>>>>>> >>>>>>>> in patch 320: >>>>>>>> >>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>> >>>>>>>> >>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>> + dse_filename = os.path.join( >>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>> self.serverid, >>>>>>>> - 'dse.ldif', >>>>>>>> + 'dse.ldif' >>>>>>>> ) >>>>>>>> >>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>> path to >>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>> knob name >>>>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>>>> propose >>>>>>>> to rename the knob to something more in-line with the supposed >>>>>>>> function, like 'dse_mods_file'. >>>>>>>> >>>>>>> >>>>>>> Updated patches + CI test attached >>>>>> >>>>>> Patches work as expected and CI tests are OK. >>>>>> >>>>>> However it seems that warning level messages are not logged to >>>>>> installer output but only to log file (*waves hand* magic). >>>>>> >>>>>> Maybe it would be a good idea to raise the message level to "error", >>>>>> so that it is immediately obvious to the user that his DSE mods >>>>>> contain an error and cannot be parsed. >>>>>> >>>>>> Also you have a typo in the commit message of patch 320 >>>>>> (s/chages/changes/). >>>>>> >>>>> Updated patches attached. >>>>> >>>>> >>>>> >>>> Rebased patches for master branch. >>> ACK >>> >> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >> > These tickets are not for ipa-4-2, > reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 Can we use a better option name? --dirsrv-config-mods sounds weird, as you need to specify a file, not mods... -- Jan Cholasta From mkosek at redhat.com Fri Oct 16 06:42:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Oct 2015 08:42:02 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <5620765A.6020208@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> Message-ID: <56209C3A.2010204@redhat.com> On 10/16/2015 06:00 AM, Jan Cholasta wrote: > On 15.10.2015 19:47, Martin Basti wrote: >> >> >> On 15.10.2015 18:47, Martin Basti wrote: >>> >>> >>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>> >>>>>>>>>> With these patches, an administrator can specify LDIF file that >>>>>>>>>> contains >>>>>>>>>> modifications to be applied to dse.ldif right after creation of DS >>>>>>>>>> instance. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Functionally the paches work as expected. However I have following >>>>>>>>> nitpicks: >>>>>>>>> >>>>>>>>> in patch 318: >>>>>>>>> >>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>> >>>>>>>>> + Operations keep the order in whihc were specified per DN. >>>>>>>>> >>>>>>>>> in patch 320: >>>>>>>>> >>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>> >>>>>>>>> >>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>> + dse_filename = os.path.join( >>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>> self.serverid, >>>>>>>>> - 'dse.ldif', >>>>>>>>> + 'dse.ldif' >>>>>>>>> ) >>>>>>>>> >>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>>> path to >>>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>>> knob name >>>>>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>>>>> propose >>>>>>>>> to rename the knob to something more in-line with the supposed >>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>> >>>>>>>> >>>>>>>> Updated patches + CI test attached >>>>>>> >>>>>>> Patches work as expected and CI tests are OK. >>>>>>> >>>>>>> However it seems that warning level messages are not logged to >>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>> >>>>>>> Maybe it would be a good idea to raise the message level to "error", >>>>>>> so that it is immediately obvious to the user that his DSE mods >>>>>>> contain an error and cannot be parsed. >>>>>>> >>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>> (s/chages/changes/). >>>>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> >>>>>> >>>>> Rebased patches for master branch. >>>> ACK >>>> >>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>> >> These tickets are not for ipa-4-2, >> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 > > Can we use a better option name? --dirsrv-config-mods sounds weird, as you need > to specify a file, not mods... > +1. maybe --dirsrv-config-ldif? Speaking about the option, I saw some unescaped "-"'s in the man page updates: +.TP +\fB\-\-dirsrv-config-mods\fR +The path to LDIF file that will be used to modify configuration of dse.ldif during installation of the directory server instance Martin From jcholast at redhat.com Fri Oct 16 06:47:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 16 Oct 2015 08:47:14 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <56209C3A.2010204@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> <56209C3A.2010204@redhat.com> Message-ID: <56209D72.8010900@redhat.com> On 16.10.2015 08:42, Martin Kosek wrote: > On 10/16/2015 06:00 AM, Jan Cholasta wrote: >> On 15.10.2015 19:47, Martin Basti wrote: >>> >>> >>> On 15.10.2015 18:47, Martin Basti wrote: >>>> >>>> >>>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>>> >>>>>>>>>>> With these patches, an administrator can specify LDIF file that >>>>>>>>>>> contains >>>>>>>>>>> modifications to be applied to dse.ldif right after creation of DS >>>>>>>>>>> instance. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Functionally the paches work as expected. However I have following >>>>>>>>>> nitpicks: >>>>>>>>>> >>>>>>>>>> in patch 318: >>>>>>>>>> >>>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>>> >>>>>>>>>> + Operations keep the order in whihc were specified per DN. >>>>>>>>>> >>>>>>>>>> in patch 320: >>>>>>>>>> >>>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>>> + dse_filename = os.path.join( >>>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>>> self.serverid, >>>>>>>>>> - 'dse.ldif', >>>>>>>>>> + 'dse.ldif' >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>>>> path to >>>>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>>>> knob name >>>>>>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>>>>>> propose >>>>>>>>>> to rename the knob to something more in-line with the supposed >>>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Updated patches + CI test attached >>>>>>>> >>>>>>>> Patches work as expected and CI tests are OK. >>>>>>>> >>>>>>>> However it seems that warning level messages are not logged to >>>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>>> >>>>>>>> Maybe it would be a good idea to raise the message level to "error", >>>>>>>> so that it is immediately obvious to the user that his DSE mods >>>>>>>> contain an error and cannot be parsed. >>>>>>>> >>>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>>> (s/chages/changes/). >>>>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> >>>>>>> >>>>>> Rebased patches for master branch. >>>>> ACK >>>>> >>>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>>> >>> These tickets are not for ipa-4-2, >>> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 >> >> Can we use a better option name? --dirsrv-config-mods sounds weird, as you need >> to specify a file, not mods... >> > > +1. maybe --dirsrv-config-ldif? --dirsrv-config-file is most consistent with other options which accept files (--external-cert-file, --ca-cert-file, --kasp-db-file, etc.) > Speaking about the option, I saw some unescaped > "-"'s in the man page updates: > > +.TP > +\fB\-\-dirsrv-config-mods\fR > +The path to LDIF file that will be used to modify configuration of dse.ldif > during installation of the directory server instance > > Martin > -- Jan Cholasta From mbabinsk at redhat.com Fri Oct 16 08:05:43 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 16 Oct 2015 10:05:43 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <56209D72.8010900@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> <56209C3A.2010204@redhat.com> <56209D72.8010900@redhat.com> Message-ID: <5620AFD7.5000307@redhat.com> On 10/16/2015 08:47 AM, Jan Cholasta wrote: > On 16.10.2015 08:42, Martin Kosek wrote: >> On 10/16/2015 06:00 AM, Jan Cholasta wrote: >>> On 15.10.2015 19:47, Martin Basti wrote: >>>> >>>> >>>> On 15.10.2015 18:47, Martin Basti wrote: >>>>> >>>>> >>>>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>>>> >>>>>>>>>>>> With these patches, an administrator can specify LDIF file that >>>>>>>>>>>> contains >>>>>>>>>>>> modifications to be applied to dse.ldif right after creation >>>>>>>>>>>> of DS >>>>>>>>>>>> instance. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Functionally the paches work as expected. However I have >>>>>>>>>>> following >>>>>>>>>>> nitpicks: >>>>>>>>>>> >>>>>>>>>>> in patch 318: >>>>>>>>>>> >>>>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>>>> >>>>>>>>>>> + Operations keep the order in whihc were specified per DN. >>>>>>>>>>> >>>>>>>>>>> in patch 320: >>>>>>>>>>> >>>>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>>>> + dse_filename = os.path.join( >>>>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>>>> self.serverid, >>>>>>>>>>> - 'dse.ldif', >>>>>>>>>>> + 'dse.ldif' >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>>>>> path to >>>>>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>>>>> knob name >>>>>>>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>>>>>>> propose >>>>>>>>>>> to rename the knob to something more in-line with the supposed >>>>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Updated patches + CI test attached >>>>>>>>> >>>>>>>>> Patches work as expected and CI tests are OK. >>>>>>>>> >>>>>>>>> However it seems that warning level messages are not logged to >>>>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>>>> >>>>>>>>> Maybe it would be a good idea to raise the message level to >>>>>>>>> "error", >>>>>>>>> so that it is immediately obvious to the user that his DSE mods >>>>>>>>> contain an error and cannot be parsed. >>>>>>>>> >>>>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>>>> (s/chages/changes/). >>>>>>>>> >>>>>>>> Updated patches attached. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Rebased patches for master branch. >>>>>> ACK >>>>>> >>>>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>>>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>>>> >>>> These tickets are not for ipa-4-2, >>>> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 >>> >>> Can we use a better option name? --dirsrv-config-mods sounds weird, >>> as you need >>> to specify a file, not mods... >>> >> >> +1. maybe --dirsrv-config-ldif? > > --dirsrv-config-file is most consistent with other options which accept > files (--external-cert-file, --ca-cert-file, --kasp-db-file, etc.) > This, however, may be confusing to user since '--dirsrv-config-file' may evoke a feeling that it consumes *whole new* dse.ldif while in reality it is only a few custom mods to directory server configuration. >> Speaking about the option, I saw some unescaped >> "-"'s in the man page updates: >> >> +.TP >> +\fB\-\-dirsrv-config-mods\fR >> +The path to LDIF file that will be used to modify configuration of >> dse.ldif >> during installation of the directory server instance >> >> Martin >> > > -- Martin^3 Babinsky From pspacek at redhat.com Fri Oct 16 08:23:58 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 16 Oct 2015 10:23:58 +0200 Subject: [Freeipa-devel] [PATCH] 0001 cert-show: Remove check if hostname != CN In-Reply-To: References: <5617B56E.7000807@redhat.com> <20151012010036.GI13048@dhcp-40-8.bne.redhat.com> <561BD90A.9080000@redhat.com> <561D3ED1.3030700@redhat.com> Message-ID: <5620B41E.8080002@redhat.com> On 15.10.2015 17:28, Jan Orel wrote: > diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py > index e459320..55f9484 100644 > --- a/ipalib/plugins/cert.py > +++ b/ipalib/plugins/cert.py > @@ -625,9 +625,12 @@ class cert_show(VirtualCommand): > result['md5_fingerprint'] = unicode(nss.data_to_hex(nss.md5_digest(cert.der_data), 64)[0]) > result['sha1_fingerprint'] = unicode(nss.data_to_hex(nss.sha1_digest(cert.der_data), 64)[0]) > if hostname: > - # If we have a hostname we want to verify that the subject > - # of the certificate matches it, otherwise raise an error > - if hostname != cert.subject.common_name: #pylint: disable=E1101 > + # If we have a hostname we want to verify that we can > + # write to the usercertificate attr of the target > + ldap = self.api.Backend.ldap2 > + entry = ldap.find_entry_by_attr("cn", cert.subject.common_name, > + "ipahost", base_dn=api.env.basedn) > + if not ldap.can_write(entry.dn, 'usercertificate'): > raise acierr > > return dict(result=result) I can't say anything about correctness of the change itself but it would be good to add explanatory error message to acierr, when you are at it. Something like 'Insufficient permissions for write to userCertificate attribute of $DN entry' or so. Thanks! -- Petr^2 Spacek From mbasti at redhat.com Fri Oct 16 08:31:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 16 Oct 2015 10:31:25 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <5620AFD7.5000307@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> <56209C3A.2010204@redhat.com> <56209D72.8010900@redhat.com> <5620AFD7.5000307@redhat.com> Message-ID: <5620B5DD.3080907@redhat.com> On 16.10.2015 10:05, Martin Babinsky wrote: > On 10/16/2015 08:47 AM, Jan Cholasta wrote: >> On 16.10.2015 08:42, Martin Kosek wrote: >>> On 10/16/2015 06:00 AM, Jan Cholasta wrote: >>>> On 15.10.2015 19:47, Martin Basti wrote: >>>>> >>>>> >>>>> On 15.10.2015 18:47, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>>>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>>>>> >>>>>>>>>>>>> With these patches, an administrator can specify LDIF file >>>>>>>>>>>>> that >>>>>>>>>>>>> contains >>>>>>>>>>>>> modifications to be applied to dse.ldif right after creation >>>>>>>>>>>>> of DS >>>>>>>>>>>>> instance. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Functionally the paches work as expected. However I have >>>>>>>>>>>> following >>>>>>>>>>>> nitpicks: >>>>>>>>>>>> >>>>>>>>>>>> in patch 318: >>>>>>>>>>>> >>>>>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>>>>> >>>>>>>>>>>> + Operations keep the order in whihc were specified per DN. >>>>>>>>>>>> >>>>>>>>>>>> in patch 320: >>>>>>>>>>>> >>>>>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>>>>> + dse_filename = os.path.join( >>>>>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>>>>> self.serverid, >>>>>>>>>>>> - 'dse.ldif', >>>>>>>>>>>> + 'dse.ldif' >>>>>>>>>>>> ) >>>>>>>>>>>> >>>>>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>>>>>> path to >>>>>>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>>>>>> knob name >>>>>>>>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>>>>>>>> propose >>>>>>>>>>>> to rename the knob to something more in-line with the supposed >>>>>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Updated patches + CI test attached >>>>>>>>>> >>>>>>>>>> Patches work as expected and CI tests are OK. >>>>>>>>>> >>>>>>>>>> However it seems that warning level messages are not logged to >>>>>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>>>>> >>>>>>>>>> Maybe it would be a good idea to raise the message level to >>>>>>>>>> "error", >>>>>>>>>> so that it is immediately obvious to the user that his DSE mods >>>>>>>>>> contain an error and cannot be parsed. >>>>>>>>>> >>>>>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>>>>> (s/chages/changes/). >>>>>>>>>> >>>>>>>>> Updated patches attached. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Rebased patches for master branch. >>>>>>> ACK >>>>>>> >>>>>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>>>>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>>>>> >>>>> These tickets are not for ipa-4-2, >>>>> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 >>>> >>>> Can we use a better option name? --dirsrv-config-mods sounds weird, >>>> as you need >>>> to specify a file, not mods... >>>> >>> >>> +1. maybe --dirsrv-config-ldif? >> >> --dirsrv-config-file is most consistent with other options which accept >> files (--external-cert-file, --ca-cert-file, --kasp-db-file, etc.) >> > This, however, may be confusing to user since '--dirsrv-config-file' > may evoke a feeling that it consumes *whole new* dse.ldif while in > reality it is only a few custom mods to directory server configuration. I agree, it expects only file containing modifications in LDIF format, 'config-file' suffix may be confusing > >>> Speaking about the option, I saw some unescaped >>> "-"'s in the man page updates: >>> >>> +.TP >>> +\fB\-\-dirsrv-config-mods\fR >>> +The path to LDIF file that will be used to modify configuration of >>> dse.ldif >>> during installation of the directory server instance >>> >>> Martin >>> >> >> > > From mbabinsk at redhat.com Fri Oct 16 10:13:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 16 Oct 2015 12:13:58 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <561E612F.5090205@redhat.com> References: <561BC52D.6030301@redhat.com> <561CB486.2020906@redhat.com> <561CED0B.9090009@redhat.com> <561D0E76.1030709@redhat.com> <561E46FD.1020404@redhat.com> <561E612F.5090205@redhat.com> Message-ID: <5620CDE6.4000901@redhat.com> On 10/14/2015 04:05 PM, Petr Spacek wrote: > On 14.10.2015 14:13, Martin Babinsky wrote: >> On 10/13/2015 04:00 PM, Petr Spacek wrote: >>> On 13.10.2015 13:37, Martin Babinsky wrote: >>>> On 10/13/2015 09:36 AM, Petr Spacek wrote: >>>>> On 12.10.2015 16:35, Martin Babinsky wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5200 >>>>>> --- >>>>>> ipalib/plugins/dns.py | 3 ++- >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>>> index >>>>>> 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 >>>>>> >>>>>> 100644 >>>>>> --- a/ipalib/plugins/dns.py >>>>>> +++ b/ipalib/plugins/dns.py >>>>>> @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>>>> if prefixlen is None: >>>>>> revzone = None >>>>>> >>>>>> - result = api.Command['dnszone_find']()['result'] >>>>>> + result = api.Command['dnszone_find'](sizelimit=0)['result'] >>>>>> + >>>>> >>>>> NACK, this just increases the limit because LDAP server will enforce a >>>>> per-user limit. >>>>> >>>>>> for zone in result: >>>>>> zonename = zone['idnsname'][0] >>>>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>>>> >>>>> Generic solution should use dns.resolver.zone_for_name() to find DNS zone >>>>> matching the reverse name. This should also implicitly cover CNAME/DNAME >>>>> redirections per RFC2317. >>>>> >>>>> Using DNS implicitly means that a zone will always be found (at least the >>>>> root >>>>> zone :-). For this reason I would change final error message >>>>>> reason=_('DNS reverse zone for IP address %(addr)s not found') >>>>> to something like: >>>>> reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not >>>>> managed >>>>> by this server') >>>>> >>>>> >>>>> These changes should fix it without adding other artificial limitation. >>>>> >>>> >>>> Thank you for clarification Petr. >>>> >>>> Attaching the reworked patch. >>>> >>>> -- >>>> Martin^3 Babinsky >>>> >>>> freeipa-mbabinsk-0083.1-perform-more-robust-search-for-reverse-zones-when-ad.patch >>>> >>>> >>>> >>>> From 463903f4ea4f74efeb02dbb705ca0a54fab81366 Mon Sep 17 00:00:00 2001 >>>> From: Martin Babinsky >>>> Date: Mon, 12 Oct 2015 16:24:50 +0200 >>>> Subject: [PATCH 1/3] perform more robust search for reverse zones when adding >>>> DNS record >>>> >>>> Instead of searching for all zones to identify the correct reverse zone, we >>>> will first ask the resolver to return the name of zone that should contain the >>>> desired record and then see if IPA manages this zone. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5200 >>>> --- >>>> ipalib/plugins/dns.py | 21 +++++++++++++++++---- >>>> 1 file changed, 17 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>> index >>>> 84086f4c77d02922f237937d58031cc42d55410e..e3c6ce46168f8b6af607a61af1e3e431cfee32c8 >>>> 100644 >>>> --- a/ipalib/plugins/dns.py >>>> +++ b/ipalib/plugins/dns.py >>>> @@ -531,25 +531,35 @@ def add_forward_record(zone, name, str_address): >>>> pass # the entry already exists and matches >>>> >>>> def get_reverse_zone(ipaddr, prefixlen=None): >>>> + """ >>>> + resolve the reverse zone for IP address and see if it is managed by IPA >>>> + server >>>> + :param ipaddr: host IP address >>>> + :param prefixlen: network prefix length >>>> + :return: tuple containing name of the reverse zone and the name of the >>>> + record >>>> + """ >>>> ip = netaddr.IPAddress(str(ipaddr)) >>>> revdns = DNSName(unicode(ip.reverse_dns)) >>>> + resolved_zone = unicode(dns.resolver.zone_for_name(revdns)) >>>> >>>> if prefixlen is None: >>>> revzone = None >>>> + result = api.Command['dnszone_find'](resolved_zone)['result'] >>>> >>>> - result = api.Command['dnszone_find']()['result'] >>>> for zone in result: >>>> zonename = zone['idnsname'][0] >>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>>> (revzone is None or zonename.is_subdomain(revzone))): >>>> revzone = zonename >>> >>> Oh, wait, this might blow up if there is a disabled DNS zone which is deeper >>> than the one returned from DNS query. >>> >>> Damn, we have opened a Pandora box! >>> >>> ipaserver/install/bindinstance.py has own implementation of get_reverse_zone() >>> + additional menthods find_reverse_zone(). >>> These are using get_reverse_zone_default() from ipalib/util.py which is >>> duplicating code in 'if prefixlen is not None' branch. >>> >>> And of course, are not correct in light of this change. >>> >>> My expectation would be that disabled zones should be ignored... So we should >>> get rid of this mess in the loop and use dnszone_show() which is called at the >>> end. And fix the other places, preferably by deleting duplicate >>> implementations. >>> >>> I would expect that you can store (converted) output of >>> dns.resolver.zone_for_name(revdns) into revzone and delete whole 'if prefixlen >>> is None' branch. >>> >>>> else: >>>> + # if prefixlen is specified, determine the zone name for the network >>>> + # prefix >>>> if ip.version == 4: >>>> pos = 4 - prefixlen / 8 >>>> elif ip.version == 6: >>>> pos = 32 - prefixlen / 4 >>>> - items = ip.reverse_dns.split('.') >>>> - revzone = DNSName(items[pos:]) >>>> + revzone = revdns[pos:] >>> >>> Hmm, and this logic will breaks CNAME/DNAME (RFC2317) handling ... Damn, we >>> need different handling when we intend to create the zone and when we want to >>> manipulate a record in a reverse zone. Grrr. >>> >>> When we want to manipulate a record in existing zone, the whole branch does >>> not make sense and the result of DNS query is what we want and need. >>> >>> On the other hand, we need this when creating *a new zone* from IP address ... >>> >>> Mastin^2, what about zone names with missing period at the end? Is it handled >>> by dnszone_show() internally? >>> >>> We have to discuss all this... >>> >>>> try: >>>> api.Command['dnszone_show'](revzone) >>>> @@ -558,7 +568,10 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>> >>>> if revzone is None: >>>> raise errors.NotFound( >>>> - reason=_('DNS reverse zone for IP address %(addr)s not found') >>>> % dict(addr=ipaddr) >>>> + reason=_( >>>> + 'DNS reverse zone %(resolved_zone)s for IP address ' >>>> + '%(addr)s is not manager by this server') % dict( >>> typo s/manager/managed/ >>> >>>> + addr=ipaddr, resolved_zone=resolved_zone) >>>> ) >>>> >>>> revname = revdns.relativize(revzone) >>> >> >> After lengthy discussion with Petr^2 I we decided to rework get_reverse_zone >> function a bit. Attaching updated patch. > > Well, we should get rid of prefixlen parameter. Wipe it from Earth's surface! :-) > > The assumption here is that this function is always used only for manipulating > *records in existing zones*, so the only way to find appropriate reverse zone > name is to ask DNS. > > Derivation based on prefix length makes sense only for deriving reverse zone > names from IP addresses *with intent to create the zone*. > > In all other cases it does not make sense to use prefix. I'm sorry that I was > not clear. > Upon Thy request I purged the Function that Gets the Name of the Zone Reverse of the crawling evil thee caleth the Prefixlen. The shallow impostor of The Function whose services no Module required nor used was also banished to oblivion and His noisome vapors shall bother the Kingdom of Identity no more. Thou shalt rejoice when Thy review the rewritten Patch attached herein or else I shall be smitten by the mighty NACK thee wieldeth. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0083.3-always-ask-the-resolver-for-the-reverse-zone-when-ma.patch Type: text/x-patch Size: 4568 bytes Desc: not available URL: From jcholast at redhat.com Fri Oct 16 10:36:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 16 Oct 2015 12:36:10 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323] installer: allow to modify dse.ldif during installation In-Reply-To: <5620B5DD.3080907@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> <56209C3A.2010204@redhat.com> <56209D72.8010900@redhat.com> <5620AFD7.5000307@redhat.com> <5620B5DD.3080907@redhat.com> Message-ID: <5620D31A.4090309@redhat.com> On 16.10.2015 10:31, Martin Basti wrote: > > > On 16.10.2015 10:05, Martin Babinsky wrote: >> On 10/16/2015 08:47 AM, Jan Cholasta wrote: >>> On 16.10.2015 08:42, Martin Kosek wrote: >>>> On 10/16/2015 06:00 AM, Jan Cholasta wrote: >>>>> On 15.10.2015 19:47, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 15.10.2015 18:47, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>>>>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>>>>>> >>>>>>>>>>>>>> With these patches, an administrator can specify LDIF file >>>>>>>>>>>>>> that >>>>>>>>>>>>>> contains >>>>>>>>>>>>>> modifications to be applied to dse.ldif right after creation >>>>>>>>>>>>>> of DS >>>>>>>>>>>>>> instance. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Functionally the paches work as expected. However I have >>>>>>>>>>>>> following >>>>>>>>>>>>> nitpicks: >>>>>>>>>>>>> >>>>>>>>>>>>> in patch 318: >>>>>>>>>>>>> >>>>>>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>>>>>> >>>>>>>>>>>>> + Operations keep the order in whihc were specified per DN. >>>>>>>>>>>>> >>>>>>>>>>>>> in patch 320: >>>>>>>>>>>>> >>>>>>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>>>>>> + dse_filename = os.path.join( >>>>>>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>>>>>> self.serverid, >>>>>>>>>>>>> - 'dse.ldif', >>>>>>>>>>>>> + 'dse.ldif' >>>>>>>>>>>>> ) >>>>>>>>>>>>> >>>>>>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>>>>>>> path to >>>>>>>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>>>>>>> knob name >>>>>>>>>>>>> sounds like the option accepts the path of dse.ldif itself. I >>>>>>>>>>>>> propose >>>>>>>>>>>>> to rename the knob to something more in-line with the supposed >>>>>>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Updated patches + CI test attached >>>>>>>>>>> >>>>>>>>>>> Patches work as expected and CI tests are OK. >>>>>>>>>>> >>>>>>>>>>> However it seems that warning level messages are not logged to >>>>>>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>>>>>> >>>>>>>>>>> Maybe it would be a good idea to raise the message level to >>>>>>>>>>> "error", >>>>>>>>>>> so that it is immediately obvious to the user that his DSE mods >>>>>>>>>>> contain an error and cannot be parsed. >>>>>>>>>>> >>>>>>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>>>>>> (s/chages/changes/). >>>>>>>>>>> >>>>>>>>>> Updated patches attached. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Rebased patches for master branch. >>>>>>>> ACK >>>>>>>> >>>>>>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>>>>>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>>>>>> >>>>>> These tickets are not for ipa-4-2, >>>>>> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 >>>>> >>>>> Can we use a better option name? --dirsrv-config-mods sounds weird, >>>>> as you need >>>>> to specify a file, not mods... >>>>> >>>> >>>> +1. maybe --dirsrv-config-ldif? >>> >>> --dirsrv-config-file is most consistent with other options which accept >>> files (--external-cert-file, --ca-cert-file, --kasp-db-file, etc.) >>> >> This, however, may be confusing to user since '--dirsrv-config-file' >> may evoke a feeling that it consumes *whole new* dse.ldif while in >> reality it is only a few custom mods to directory server configuration. > I agree, it expects only file containing modifications in LDIF format, > 'config-file' suffix may be confusing Sorry, but this does not make any sense. Why would anyone think they are supposed to specify a complete dse.ldif? Is it written somewhere that DS config file == dse.ldif? I don't think so. And, if you use --help, you will see exactly what the option does right away. What is actually confusing is inventing a "smart" name instead of making it consistent with everything else. >> >>>> Speaking about the option, I saw some unescaped >>>> "-"'s in the man page updates: >>>> >>>> +.TP >>>> +\fB\-\-dirsrv-config-mods\fR >>>> +The path to LDIF file that will be used to modify configuration of >>>> dse.ldif >>>> during installation of the directory server instance >>>> >>>> Martin >>>> >>> >>> >> >> > -- Jan Cholasta From mbasti at redhat.com Fri Oct 16 10:41:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 16 Oct 2015 12:41:57 +0200 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica Message-ID: <5620D475.2030200@redhat.com> https://fedorahosted.org/freeipa/ticket/5345 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0327-KRA-fix-check-that-CA-is-installed.patch Type: text/x-patch Size: 3452 bytes Desc: not available URL: From mkubik at redhat.com Fri Oct 16 13:43:13 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 16 Oct 2015 15:43:13 +0200 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test In-Reply-To: <560BD9C8.2070205@redhat.com> References: <5603F13E.4060805@redhat.com> <560BD9C8.2070205@redhat.com> Message-ID: <5620FEF1.70808@redhat.com> On 09/30/2015 02:47 PM, Martin Basti wrote: > > > > > > > > > > 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. > > > > > > > > Hi, updated patches and the numbering mess somehow curbed. The patches are rebased on top of current master and ipa-4-2. 0) fixed by 0021 1) docs for tracker extended, added more test cases 2) changed -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0012.4-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.4-ipatests-Add-initial-CAACLTracker-implementation.patch Type: text/x-patch Size: 15040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0014.4-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 5896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0015-2-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-2-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-2-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-ipa42-0012.4-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-ipa42-0013.4-ipatests-Add-initial-CAACLTracker-implementation.patch Type: text/x-patch Size: 15040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0014.4-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 5896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0015-2-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-ipa42-0016-2-ipatests-added-unlock_principal_password-and-change_.patch Type: text/x-patch Size: 2394 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0017-2-ipatests-CA-ACL-and-cert-profile-functional-test.patch Type: text/x-patch Size: 7657 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 16 14:51:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 16 Oct 2015 16:51:56 +0200 Subject: [Freeipa-devel] [PATCH 0328] DNSSEC CI: Wait until DS records are replicated Message-ID: <56210F0C.9060206@redhat.com> Drill command sometimes fail on replica due to long replication time, this patch adding check that waits until record is replicated. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0328-DNSSEC-CI-wait-until-DS-records-is-replicated.patch Type: text/x-patch Size: 1280 bytes Desc: not available URL: From edewata at redhat.com Fri Oct 16 16:41:13 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 16 Oct 2015 11:41:13 -0500 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561FBE0F.5040601@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561FBE0F.5040601@redhat.com> Message-ID: <562128A9.80600@redhat.com> On 10/15/2015 9:54 AM, Simo Sorce wrote: >> 3) ipa-ca-install fails with: >> >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 445, in start_creation >> run_step(full_msg, method) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 435, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 631, in __spawn_instance >> DogtagInstance.spawn_instance(self, cfg_file) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >> line 185, in spawn_instance >> self.handle_setup_error(e) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >> line 448, in handle_setup_error >> raise RuntimeError("%s configuration failed." % self.subsystem) >> RuntimeError: CA configuration failed. >> >> I guess I'm hitting the authentication bug in Dogtag. It is supposed to >> be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? >> We might need a new 10.2.7 build. > > I am not sure which version has it fixed, Endi ? PKI ticket #1580 was fixed in pki-core-10.2.6-10 for F23 and F24. We never released a pki-core-10.2.7. I suppose that is a custom build? -- Endi S. Dewata From mbabinsk at redhat.com Fri Oct 16 17:28:56 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 16 Oct 2015 19:28:56 +0200 Subject: [Freeipa-devel] [PATCH 0087] execute user-del pre-callback also during user preservation Message-ID: <562133D8.6050107@redhat.com> fixes tickets: https://fedorahosted.org/freeipa/ticket/5362 https://fedorahosted.org/freeipa/ticket/5372 Upon discussion with Simo we decided that OTP tokens should be orphaned/deleted also during the user preservation. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0087-execute-user-del-pre-callback-also-during-user-prese.patch Type: text/x-patch Size: 1701 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Oct 19 05:35:40 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 19 Oct 2015 07:35:40 +0200 Subject: [Freeipa-devel] [PATCH 0087] execute user-del pre-callback also during user preservation In-Reply-To: <562133D8.6050107@redhat.com> References: <562133D8.6050107@redhat.com> Message-ID: <5624812C.6000303@redhat.com> On 10/16/2015 07:28 PM, Martin Babinsky wrote: > fixes tickets: > > https://fedorahosted.org/freeipa/ticket/5362 > https://fedorahosted.org/freeipa/ticket/5372 > > Upon discussion with Simo we decided that OTP tokens should be > orphaned/deleted also during the user preservation. > > > self-NACK, the current patch violates what we agreed on with Tomas regarding removal of ID overrides. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Oct 19 08:42:25 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 19 Oct 2015 10:42:25 +0200 Subject: [Freeipa-devel] [PATCH 0087] execute user-del pre-callback also during user preservation In-Reply-To: <5624812C.6000303@redhat.com> References: <562133D8.6050107@redhat.com> <5624812C.6000303@redhat.com> Message-ID: <5624ACF1.8060008@redhat.com> On 10/19/2015 07:35 AM, Martin Babinsky wrote: > On 10/16/2015 07:28 PM, Martin Babinsky wrote: >> fixes tickets: >> >> https://fedorahosted.org/freeipa/ticket/5362 >> https://fedorahosted.org/freeipa/ticket/5372 >> >> Upon discussion with Simo we decided that OTP tokens should be >> orphaned/deleted also during the user preservation. >> >> >> > self-NACK, the current patch violates what we agreed on with Tomas > regarding removal of ID overrides. > Reworked patch attached. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0087.1-execute-user-del-pre-callback-also-during-user-prese.patch Type: text/x-patch Size: 3946 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 19 10:30:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Oct 2015 12:30:21 +0200 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker Message-ID: <5624C63D.5020000@redhat.com> Attribute nsaccountlock has not been processed correctly Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0329-Tests-Fix-user-tracker.patch Type: text/x-patch Size: 4208 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 19 10:47:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Oct 2015 12:47:40 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323, 0330] installer: allow to modify dse.ldif during installation In-Reply-To: <5620D31A.4090309@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> <56209C3A.2010204@redhat.com> <56209D72.8010900@redhat.com> <5620AFD7.5000307@redhat.com> <5620B5DD.3080907@redhat.com> <5620D31A.4090309@redhat.com> Message-ID: <5624CA4C.4090505@redhat.com> On 16.10.2015 12:36, Jan Cholasta wrote: > On 16.10.2015 10:31, Martin Basti wrote: >> >> >> On 16.10.2015 10:05, Martin Babinsky wrote: >>> On 10/16/2015 08:47 AM, Jan Cholasta wrote: >>>> On 16.10.2015 08:42, Martin Kosek wrote: >>>>> On 10/16/2015 06:00 AM, Jan Cholasta wrote: >>>>>> On 15.10.2015 19:47, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 15.10.2015 18:47, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>>>>>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With these patches, an administrator can specify LDIF file >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> contains >>>>>>>>>>>>>>> modifications to be applied to dse.ldif right after >>>>>>>>>>>>>>> creation >>>>>>>>>>>>>>> of DS >>>>>>>>>>>>>>> instance. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Functionally the paches work as expected. However I have >>>>>>>>>>>>>> following >>>>>>>>>>>>>> nitpicks: >>>>>>>>>>>>>> >>>>>>>>>>>>>> in patch 318: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + Operations keep the order in whihc were specified >>>>>>>>>>>>>> per DN. >>>>>>>>>>>>>> >>>>>>>>>>>>>> in patch 320: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>>>>>>> + dse_filename = os.path.join( >>>>>>>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>>>>>>> self.serverid, >>>>>>>>>>>>>> - 'dse.ldif', >>>>>>>>>>>>>> + 'dse.ldif' >>>>>>>>>>>>>> ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>>>>>>>> path to >>>>>>>>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>>>>>>>> knob name >>>>>>>>>>>>>> sounds like the option accepts the path of dse.ldif >>>>>>>>>>>>>> itself. I >>>>>>>>>>>>>> propose >>>>>>>>>>>>>> to rename the knob to something more in-line with the >>>>>>>>>>>>>> supposed >>>>>>>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Updated patches + CI test attached >>>>>>>>>>>> >>>>>>>>>>>> Patches work as expected and CI tests are OK. >>>>>>>>>>>> >>>>>>>>>>>> However it seems that warning level messages are not logged to >>>>>>>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>>>>>>> >>>>>>>>>>>> Maybe it would be a good idea to raise the message level to >>>>>>>>>>>> "error", >>>>>>>>>>>> so that it is immediately obvious to the user that his DSE >>>>>>>>>>>> mods >>>>>>>>>>>> contain an error and cannot be parsed. >>>>>>>>>>>> >>>>>>>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>>>>>>> (s/chages/changes/). >>>>>>>>>>>> >>>>>>>>>>> Updated patches attached. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Rebased patches for master branch. >>>>>>>>> ACK >>>>>>>>> >>>>>>>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>>>>>>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>>>>>>> >>>>>>> These tickets are not for ipa-4-2, >>>>>>> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 >>>>>> >>>>>> Can we use a better option name? --dirsrv-config-mods sounds weird, >>>>>> as you need >>>>>> to specify a file, not mods... >>>>>> >>>>> >>>>> +1. maybe --dirsrv-config-ldif? >>>> >>>> --dirsrv-config-file is most consistent with other options which >>>> accept >>>> files (--external-cert-file, --ca-cert-file, --kasp-db-file, etc.) >>>> >>> This, however, may be confusing to user since '--dirsrv-config-file' >>> may evoke a feeling that it consumes *whole new* dse.ldif while in >>> reality it is only a few custom mods to directory server configuration. >> I agree, it expects only file containing modifications in LDIF format, >> 'config-file' suffix may be confusing > > Sorry, but this does not make any sense. Why would anyone think they > are supposed to specify a complete dse.ldif? Is it written somewhere > that DS config file == dse.ldif? I don't think so. And, if you use > --help, you will see exactly what the option does right away. > > What is actually confusing is inventing a "smart" name instead of > making it consistent with everything else. Patch attached. Martin^2 > >>> >>>>> Speaking about the option, I saw some unescaped >>>>> "-"'s in the man page updates: >>>>> >>>>> +.TP >>>>> +\fB\-\-dirsrv-config-mods\fR >>>>> +The path to LDIF file that will be used to modify configuration of >>>>> dse.ldif >>>>> during installation of the directory server instance >>>>> >>>>> Martin >>>>> >>>> >>>> >>> >>> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0330-Rename-option-dirsrv-config-mods-to-dirsrv-config-fi.patch Type: text/x-patch Size: 6572 bytes Desc: not available URL: From tbabej at redhat.com Mon Oct 19 11:21:54 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 19 Oct 2015 13:21:54 +0200 Subject: [Freeipa-devel] [PATCH 0087] execute user-del pre-callback also during user preservation In-Reply-To: <5624ACF1.8060008@redhat.com> References: <562133D8.6050107@redhat.com> <5624812C.6000303@redhat.com> <5624ACF1.8060008@redhat.com> Message-ID: <5624D252.3060709@redhat.com> On 10/19/2015 10:42 AM, Martin Babinsky wrote: > On 10/19/2015 07:35 AM, Martin Babinsky wrote: >> On 10/16/2015 07:28 PM, Martin Babinsky wrote: >>> fixes tickets: >>> >>> https://fedorahosted.org/freeipa/ticket/5362 >>> https://fedorahosted.org/freeipa/ticket/5372 >>> >>> Upon discussion with Simo we decided that OTP tokens should be >>> orphaned/deleted also during the user preservation. >>> >>> >>> >> self-NACK, the current patch violates what we agreed on with Tomas >> regarding removal of ID overrides. >> > Reworked patch attached. > ACK, works as expected. From mbasti at redhat.com Mon Oct 19 11:38:06 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Oct 2015 13:38:06 +0200 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test In-Reply-To: <5620FEF1.70808@redhat.com> References: <5603F13E.4060805@redhat.com> <560BD9C8.2070205@redhat.com> <5620FEF1.70808@redhat.com> Message-ID: <5624D61E.20106@redhat.com> On 16.10.2015 15:43, Milan Kub?k wrote: > On 09/30/2015 02:47 PM, Martin Basti wrote: >> >> >> >> >> >> >> >> >> >> 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. >> >> >> >> >> >> >> >> > Hi, > > updated patches and the numbering mess somehow curbed. The patches are > rebased on top of current master and ipa-4-2. > > 0) fixed by 0021 > > 1) docs for tracker extended, added more test cases > > 2) changed > > > -- > Milan Kubik I have a few comments: 1) +# TODO: rewrite these into Tracker instances + at pytest.fixture(scope='class') +def smime_user(request): + api.Command.user_add(uid=u'alice', givenname=u'Alice', sn=u'SMIME', + userpassword=u'Change123') + + unlock_principal_password('alice', 'Change123', 'Secret123') + + def fin(): + api.Command.user_del(u'alice') + request.addfinalizer(fin) + + return u'alice' I do not like hardcoded password value, as this password is used in many places in the test, I sugest to use a module variable 2) +class TestSignWithChangedProfile(XMLRPC_test): + """ Test to verify that the updated profile is used.""" + pass # import invalid profile, try to sign, expect fail IMO something is missing here, a test maybe? 3) # noqa Please remove "# noqa" commets from commits -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Mon Oct 19 11:53:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 19 Oct 2015 13:53:05 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <561FB85B.3070202@redhat.com> References: <561FB85B.3070202@redhat.com> Message-ID: <5624D9A1.5000406@redhat.com> On 10/15/2015 04:29 PM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5175 > > > Updated patch attached -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0086.1-disable-ipa-replica-prepare-in-non-zero-IPA-domain-l.patch Type: text/x-patch Size: 2878 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Oct 19 12:12:30 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 19 Oct 2015 14:12:30 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323, 0330] installer: allow to modify dse.ldif during installation In-Reply-To: <5624CA4C.4090505@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> <56209C3A.2010204@redhat.com> <56209D72.8010900@redhat.com> <5620AFD7.5000307@redhat.com> <5620B5DD.3080907@redhat.com> <5620D31A.4090309@redhat.com> <5624CA4C.4090505@redhat.com> Message-ID: <5624DE2E.5010501@redhat.com> On 10/19/2015 12:47 PM, Martin Basti wrote: > > > On 16.10.2015 12:36, Jan Cholasta wrote: >> On 16.10.2015 10:31, Martin Basti wrote: >>> >>> >>> On 16.10.2015 10:05, Martin Babinsky wrote: >>>> On 10/16/2015 08:47 AM, Jan Cholasta wrote: >>>>> On 16.10.2015 08:42, Martin Kosek wrote: >>>>>> On 10/16/2015 06:00 AM, Jan Cholasta wrote: >>>>>>> On 15.10.2015 19:47, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 15.10.2015 18:47, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>>>>>>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>>>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> With these patches, an administrator can specify LDIF file >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> contains >>>>>>>>>>>>>>>> modifications to be applied to dse.ldif right after >>>>>>>>>>>>>>>> creation >>>>>>>>>>>>>>>> of DS >>>>>>>>>>>>>>>> instance. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Functionally the paches work as expected. However I have >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> nitpicks: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in patch 318: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + Operations keep the order in whihc were specified >>>>>>>>>>>>>>> per DN. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in patch 320: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>>>>>>>> + dse_filename = os.path.join( >>>>>>>>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>>>>>>>> self.serverid, >>>>>>>>>>>>>>> - 'dse.ldif', >>>>>>>>>>>>>>> + 'dse.ldif' >>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer holds the >>>>>>>>>>>>>>> path to >>>>>>>>>>>>>>> LDIF containing the mod operations to dse.ldif. However, the >>>>>>>>>>>>>>> knob name >>>>>>>>>>>>>>> sounds like the option accepts the path of dse.ldif >>>>>>>>>>>>>>> itself. I >>>>>>>>>>>>>>> propose >>>>>>>>>>>>>>> to rename the knob to something more in-line with the >>>>>>>>>>>>>>> supposed >>>>>>>>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Updated patches + CI test attached >>>>>>>>>>>>> >>>>>>>>>>>>> Patches work as expected and CI tests are OK. >>>>>>>>>>>>> >>>>>>>>>>>>> However it seems that warning level messages are not logged to >>>>>>>>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe it would be a good idea to raise the message level to >>>>>>>>>>>>> "error", >>>>>>>>>>>>> so that it is immediately obvious to the user that his DSE >>>>>>>>>>>>> mods >>>>>>>>>>>>> contain an error and cannot be parsed. >>>>>>>>>>>>> >>>>>>>>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>>>>>>>> (s/chages/changes/). >>>>>>>>>>>>> >>>>>>>>>>>> Updated patches attached. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Rebased patches for master branch. >>>>>>>>>> ACK >>>>>>>>>> >>>>>>>>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>>>>>>>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>>>>>>>> >>>>>>>> These tickets are not for ipa-4-2, >>>>>>>> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 >>>>>>> >>>>>>> Can we use a better option name? --dirsrv-config-mods sounds weird, >>>>>>> as you need >>>>>>> to specify a file, not mods... >>>>>>> >>>>>> >>>>>> +1. maybe --dirsrv-config-ldif? >>>>> >>>>> --dirsrv-config-file is most consistent with other options which >>>>> accept >>>>> files (--external-cert-file, --ca-cert-file, --kasp-db-file, etc.) >>>>> >>>> This, however, may be confusing to user since '--dirsrv-config-file' >>>> may evoke a feeling that it consumes *whole new* dse.ldif while in >>>> reality it is only a few custom mods to directory server configuration. >>> I agree, it expects only file containing modifications in LDIF format, >>> 'config-file' suffix may be confusing >> >> Sorry, but this does not make any sense. Why would anyone think they >> are supposed to specify a complete dse.ldif? Is it written somewhere >> that DS config file == dse.ldif? I don't think so. And, if you use >> --help, you will see exactly what the option does right away. >> >> What is actually confusing is inventing a "smart" name instead of >> making it consistent with everything else. > > Patch attached. > Martin^2 > ACK >> >>>> >>>>>> Speaking about the option, I saw some unescaped >>>>>> "-"'s in the man page updates: >>>>>> >>>>>> +.TP >>>>>> +\fB\-\-dirsrv-config-mods\fR >>>>>> +The path to LDIF file that will be used to modify configuration of >>>>>> dse.ldif >>>>>> during installation of the directory server instance >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > -- Martin^3 Babinsky From mbasti at redhat.com Mon Oct 19 12:16:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Oct 2015 14:16:16 +0200 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker In-Reply-To: <5624C63D.5020000@redhat.com> References: <5624C63D.5020000@redhat.com> Message-ID: <5624DF10.4060000@redhat.com> On 19.10.2015 12:30, Martin Basti wrote: > Attribute nsaccountlock has not been processed correctly > > Patch attached. > > Self-NACK, more fixes required -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 19 12:19:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Oct 2015 14:19:11 +0200 Subject: [Freeipa-devel] [PATCHES 0318 - 0320, 0323, 0330] installer: allow to modify dse.ldif during installation In-Reply-To: <5624DE2E.5010501@redhat.com> References: <56169297.2010006@redhat.com> <561B8BD2.2050301@redhat.com> <561D336F.3060409@redhat.com> <561E5DDC.2090609@redhat.com> <561E624C.2080601@redhat.com> <561FBD19.9030404@redhat.com> <561FD60A.7080409@redhat.com> <561FD886.9050800@redhat.com> <561FE6B4.9000102@redhat.com> <5620765A.6020208@redhat.com> <56209C3A.2010204@redhat.com> <56209D72.8010900@redhat.com> <5620AFD7.5000307@redhat.com> <5620B5DD.3080907@redhat.com> <5620D31A.4090309@redhat.com> <5624CA4C.4090505@redhat.com> <5624DE2E.5010501@redhat.com> Message-ID: <5624DFBF.7000809@redhat.com> On 19.10.2015 14:12, Martin Babinsky wrote: > On 10/19/2015 12:47 PM, Martin Basti wrote: >> >> >> On 16.10.2015 12:36, Jan Cholasta wrote: >>> On 16.10.2015 10:31, Martin Basti wrote: >>>> >>>> >>>> On 16.10.2015 10:05, Martin Babinsky wrote: >>>>> On 10/16/2015 08:47 AM, Jan Cholasta wrote: >>>>>> On 16.10.2015 08:42, Martin Kosek wrote: >>>>>>> On 10/16/2015 06:00 AM, Jan Cholasta wrote: >>>>>>>> On 15.10.2015 19:47, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 15.10.2015 18:47, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 15.10.2015 18:36, Martin Babinsky wrote: >>>>>>>>>>> On 10/15/2015 04:50 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 14.10.2015 16:10, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 14.10.2015 15:51, Martin Babinsky wrote: >>>>>>>>>>>>>> On 10/13/2015 06:38 PM, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 12.10.2015 12:30, Martin Babinsky wrote: >>>>>>>>>>>>>>>> On 10/08/2015 05:58 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>> The attached patches fix following tickets: >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4949 >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4048 >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/1930 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> With these patches, an administrator can specify LDIF >>>>>>>>>>>>>>>>> file >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> contains >>>>>>>>>>>>>>>>> modifications to be applied to dse.ldif right after >>>>>>>>>>>>>>>>> creation >>>>>>>>>>>>>>>>> of DS >>>>>>>>>>>>>>>>> instance. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Functionally the paches work as expected. However I have >>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>> nitpicks: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in patch 318: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1.) there is a typo in ModifyLDIF class docstring: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + Operations keep the order in whihc were specified >>>>>>>>>>>>>>>> per DN. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in patch 320: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1.) you should use 'os.path.join' to construct FS paths: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - dse_filename = '%s/%s' % ( >>>>>>>>>>>>>>>> + dse_filename = os.path.join( >>>>>>>>>>>>>>>> paths.ETC_DIRSRV_SLAPD_INSTANCE_TEMPLATE % >>>>>>>>>>>>>>>> self.serverid, >>>>>>>>>>>>>>>> - 'dse.ldif', >>>>>>>>>>>>>>>> + 'dse.ldif' >>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2.) IIUC the 'config_ldif_file' knob in BaseServer >>>>>>>>>>>>>>>> holds the >>>>>>>>>>>>>>>> path to >>>>>>>>>>>>>>>> LDIF containing the mod operations to dse.ldif. >>>>>>>>>>>>>>>> However, the >>>>>>>>>>>>>>>> knob name >>>>>>>>>>>>>>>> sounds like the option accepts the path of dse.ldif >>>>>>>>>>>>>>>> itself. I >>>>>>>>>>>>>>>> propose >>>>>>>>>>>>>>>> to rename the knob to something more in-line with the >>>>>>>>>>>>>>>> supposed >>>>>>>>>>>>>>>> function, like 'dse_mods_file'. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Updated patches + CI test attached >>>>>>>>>>>>>> >>>>>>>>>>>>>> Patches work as expected and CI tests are OK. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However it seems that warning level messages are not >>>>>>>>>>>>>> logged to >>>>>>>>>>>>>> installer output but only to log file (*waves hand* magic). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe it would be a good idea to raise the message level to >>>>>>>>>>>>>> "error", >>>>>>>>>>>>>> so that it is immediately obvious to the user that his DSE >>>>>>>>>>>>>> mods >>>>>>>>>>>>>> contain an error and cannot be parsed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also you have a typo in the commit message of patch 320 >>>>>>>>>>>>>> (s/chages/changes/). >>>>>>>>>>>>>> >>>>>>>>>>>>> Updated patches attached. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Rebased patches for master branch. >>>>>>>>>>> ACK >>>>>>>>>>> >>>>>>>>>> Pushed to master: 5233165ce7062bb7aa649bf95a029103c375207b >>>>>>>>>> Pushed to ipa-4-2: 94412b81c1c09b56ee2900942a1b804f21c264c5 >>>>>>>>>> >>>>>>>>> These tickets are not for ipa-4-2, >>>>>>>>> reverted a17936a1aad139236f18f0e5ad0b066f7747ca60 >>>>>>>> >>>>>>>> Can we use a better option name? --dirsrv-config-mods sounds >>>>>>>> weird, >>>>>>>> as you need >>>>>>>> to specify a file, not mods... >>>>>>>> >>>>>>> >>>>>>> +1. maybe --dirsrv-config-ldif? >>>>>> >>>>>> --dirsrv-config-file is most consistent with other options which >>>>>> accept >>>>>> files (--external-cert-file, --ca-cert-file, --kasp-db-file, etc.) >>>>>> >>>>> This, however, may be confusing to user since '--dirsrv-config-file' >>>>> may evoke a feeling that it consumes *whole new* dse.ldif while in >>>>> reality it is only a few custom mods to directory server >>>>> configuration. >>>> I agree, it expects only file containing modifications in LDIF format, >>>> 'config-file' suffix may be confusing >>> >>> Sorry, but this does not make any sense. Why would anyone think they >>> are supposed to specify a complete dse.ldif? Is it written somewhere >>> that DS config file == dse.ldif? I don't think so. And, if you use >>> --help, you will see exactly what the option does right away. >>> >>> What is actually confusing is inventing a "smart" name instead of >>> making it consistent with everything else. >> >> Patch attached. >> Martin^2 >> > ACK Pushed to master: f4c8c93e7092b341c3ed2e04553dd5afbcc44dc5 >>> >>>>> >>>>>>> Speaking about the option, I saw some unescaped >>>>>>> "-"'s in the man page updates: >>>>>>> >>>>>>> +.TP >>>>>>> +\fB\-\-dirsrv-config-mods\fR >>>>>>> +The path to LDIF file that will be used to modify configuration of >>>>>>> dse.ldif >>>>>>> during installation of the directory server instance >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From mbasti at redhat.com Mon Oct 19 12:47:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Oct 2015 14:47:40 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <561FB85B.3070202@redhat.com> References: <561FB85B.3070202@redhat.com> Message-ID: <5624E66C.7090809@redhat.com> On 15.10.2015 16:29, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5175 > > > NACK with domain level 0 ipa-replica-prepare ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in execute self.ask_for_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", line 215, in ask_for_options bind_pw=self.dirman_password) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 61, in connect self.id, threading.currentThread().getName() ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: Exception: connect: 'context.ldap2_140616703529424' already exists in thread 'MainThread' ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: connect: 'context.ldap2_140616703529424' already exists in thread 'MainThread' ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The ipa-replica-prepare command failed. without your patch it works Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Mon Oct 19 14:51:21 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 19 Oct 2015 16:51:21 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <5624E66C.7090809@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> Message-ID: <56250369.3090400@redhat.com> On 10/19/2015 02:47 PM, Martin Basti wrote: > > > On 15.10.2015 16:29, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5175 >> >> >> > NACK > > with domain level 0 > > ipa-replica-prepare > > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in > execute > self.ask_for_options() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", > line 215, in ask_for_options > bind_pw=self.dirman_password) > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 61, > in connect > self.id, threading.currentThread().getName() > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The > ipa-replica-prepare command failed, exception: Exception: connect: > 'context.ldap2_140616703529424' already exists in thread 'MainThread' > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: > connect: 'context.ldap2_140616703529424' already exists in thread > 'MainThread' > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The > ipa-replica-prepare command failed. > > without your patch it works > > Martin^2 The function was leaking opened backend connection due to incorrect disconnect logic. Updated patch should fix this. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0086.2-disable-ipa-replica-prepare-in-non-zero-IPA-domain-l.patch Type: text/x-patch Size: 2926 bytes Desc: not available URL: From redhatrises at gmail.com Tue Oct 20 03:17:23 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 19 Oct 2015 21:17:23 -0600 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: References: <561B5786.8070207@redhat.com> <561CA554.505@redhat.com> <561CA707.3050800@redhat.com> Message-ID: Bump for re-review. On Tue, Oct 13, 2015 at 7:15 AM, Gabe Alford wrote: > No worries Petr. All a part of the review process. > > I have attached an updated patch that prints only a warning message. > > thanks, > > Gabe > > On Tue, Oct 13, 2015 at 12:39 AM, Petr Spacek wrote: > >> Hello Gabe, >> >> I would like to apologize for the confusion regarding this patch and the >> repeated reworking. >> >> Unfortunately Honza's position is not mentioned in the ticket so you >> could not >> know what to do, but Honza is our "installer architect" so he has final >> say. >> >> Petr^2 Spacek >> >> On 13.10.2015 08:31, Jan Cholasta wrote: >> > Hi, >> > >> > I don't think this is the correct approach. We are aiming to have >> idempotent >> > installers, which means that running uninstall on a system without IPA >> > installed should be a no-op. This is the current behavior, so your >> patch is >> > actually moving us back. >> > >> > The proper fix would be to *remove* the check from install (as opposed >> to >> > adding it to uninstall), but this requires the install code to be >> idempotent, >> > and we're not there yet. >> > >> > I'm OK with making this a warning, but don't make it a fatal error >> and/or >> > require --force. >> > >> > Honza >> > >> > On 12.10.2015 17:12, Gabe Alford wrote: >> >> Thanks, Petr. Updated patch attached. >> >> >> >> Gabe >> >> >> >> On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek > >> > wrote: >> >> >> >> Hello Gabe, >> >> >> >> thank you for your patch! >> >> >> >> Please note that there might be a case where detection >> >> is_ipa_configured() is >> >> broken but the user still needs to run the uninstall process to >> >> clean it up. >> >> >> >> Could you amend the patch to respect --force option? In that case >> the >> >> detection should be skipped. >> >> >> >> Thank you for your time! >> >> >> >> Petr^2 Spacek >> >> >> >> On 9.10.2015 19:17, Gabe Alford wrote: >> >> > diff --git a/ipaserver/install/server/install.py >> >> b/ipaserver/install/server/install.py >> >> > index >> >> >> >> >> 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 >> >> >> >> 100644 >> >> > --- a/ipaserver/install/server/install.py >> >> > +++ b/ipaserver/install/server/install.py >> >> > @@ -954,6 +954,12 @@ def uninstall_check(installer): >> >> > >> >> > installer._installation_cleanup = False >> >> > >> >> > + if not is_ipa_configured(): >> >> > + print("IPA server is not configured on this system.\n" >> + >> >> > + "If you want to install the IPA server, please >> >> install " + >> >> > + "it using 'ipa-server-install'.") >> >> > + sys.exit(1) >> >> > + >> >> > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) >> >> > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Oct 20 07:19:14 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 20 Oct 2015 09:19:14 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <561D39B6.4090801@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561D377B.5040806@redhat.com> <561D39B6.4090801@redhat.com> Message-ID: <5625EAF2.4000903@redhat.com> On 10/13/2015 07:04 PM, Martin Babinsky wrote: > On 10/13/2015 06:55 PM, Martin Babinsky wrote: >> mbabinsk - hide segment direction from topology commands > > Ooops forgot to regenerate API.txt. Attaching updated patch. > > > Ping for review. -- Martin^3 Babinsky From ofayans at redhat.com Tue Oct 20 07:57:18 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 20 Oct 2015 09:57:18 +0200 Subject: [Freeipa-devel] Host does not have corresponding DNS A/AAAA record Message-ID: <5625F3DE.4060708@redhat.com> Hi, I keep hitting a strange issue: when I create a dnsrecord manually and then try to create the host, it complains that the host does not have corresponding DNS A/AAAA record. ofayans at f22master:~]$ ipa dnsrecord-add Record name: fortest Zone name: pesen.net. Please choose a type of DNS resource record to be added The most common types for this type of zone are: A, AAAA DNS resource record type: A A IP Address: 192.168.122.253 Record name: fortest A record: 192.168.122.253 ofayans at f22master:~]$ ipa host-add Host name: fortest.pesen.net ipa: ERROR: Host does not have corresponding DNS A/AAAA record ofayans at f22master:~]$ ping fortest PING fortest.pesen.net (192.168.122.253) 56(84) bytes of data. When I then use --force to create the host anyway and then try to add a service to this host, I get the same error: ofayans at f22master:~]$ ipa service-add Principal: fortest/fortest.pesen.net ipa: ERROR: The host 'fortest.pesen.net' does not exist to add a service to. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mkubik at redhat.com Tue Oct 20 08:00:19 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 20 Oct 2015 10:00:19 +0200 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test In-Reply-To: <5624D61E.20106@redhat.com> References: <5603F13E.4060805@redhat.com> <560BD9C8.2070205@redhat.com> <5620FEF1.70808@redhat.com> <5624D61E.20106@redhat.com> Message-ID: <5625F493.9020109@redhat.com> On 10/19/2015 01:38 PM, Martin Basti wrote: > > > On 16.10.2015 15:43, Milan Kub?k wrote: >> On 09/30/2015 02:47 PM, Martin Basti wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> >>> >>> >> Hi, >> >> updated patches and the numbering mess somehow curbed. The patches >> are rebased on top of current master and ipa-4-2. >> >> 0) fixed by 0021 >> >> 1) docs for tracker extended, added more test cases >> >> 2) changed >> >> >> -- >> Milan Kubik > I have a few comments: > > 1) > +# TODO: rewrite these into Tracker instances > + at pytest.fixture(scope='class') > +def smime_user(request): > + api.Command.user_add(uid=u'alice', givenname=u'Alice', sn=u'SMIME', > + userpassword=u'Change123') > + > + unlock_principal_password('alice', 'Change123', 'Secret123') > + > + def fin(): > + api.Command.user_del(u'alice') > + request.addfinalizer(fin) > + > + return u'alice' > > I do not like hardcoded password value, as this password is used in > many places in the test, I sugest to use a module variable Done > > 2) > +class TestSignWithChangedProfile(XMLRPC_test): > + """ Test to verify that the updated profile is used.""" > + pass # import invalid profile, try to sign, expect fail > > IMO something is missing here, a test maybe? > Done by using profile with constraint that CSR cannot meet. > 3) > # noqa > Please remove "# noqa" commets from commits Done. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0014.5-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 5880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0017-3-ipatests-CA-ACL-and-cert-profile-functional-test.patch Type: text/x-patch Size: 16600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0014.5-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 5880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0017-3-ipatests-CA-ACL-and-cert-profile-functional-test.patch Type: text/x-patch Size: 16596 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 20 08:10:59 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Oct 2015 10:10:59 +0200 Subject: [Freeipa-devel] Host does not have corresponding DNS A/AAAA record In-Reply-To: <5625F3DE.4060708@redhat.com> References: <5625F3DE.4060708@redhat.com> Message-ID: <5625F713.5010703@redhat.com> On 10/20/2015 09:57 AM, Oleg Fayans wrote: > Hi, > > I keep hitting a strange issue: when I create a dnsrecord manually and > then try to create the host, it complains that the host does not have > corresponding DNS A/AAAA record. > > ofayans at f22master:~]$ ipa dnsrecord-add > Record name: fortest > Zone name: pesen.net. > Please choose a type of DNS resource record to be added > The most common types for this type of zone are: A, AAAA > > DNS resource record type: A > A IP Address: 192.168.122.253 > Record name: fortest > A record: 192.168.122.253 > ofayans at f22master:~]$ ipa host-add > Host name: fortest.pesen.net > ipa: ERROR: Host does not have corresponding DNS A/AAAA record > ofayans at f22master:~]$ ping fortest > PING fortest.pesen.net (192.168.122.253) 56(84) bytes of data. The check uses DNS resolution to get the info. Does it work well? Other option is to add host with --ip-address option so you can skip the dnsrecord-add call. > > When I then use --force to create the host anyway and then try to add a > service to this host, I get the same error: > > ofayans at f22master:~]$ ipa service-add > Principal: fortest/fortest.pesen.net > ipa: ERROR: The host 'fortest.pesen.net' does not exist to add a service > to. > This error tells that the host entry does not exist. -- Petr Vobornik From ofayans at redhat.com Tue Oct 20 08:12:00 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 20 Oct 2015 10:12:00 +0200 Subject: [Freeipa-devel] freshly added service is disabled Message-ID: <5625F750.1070501@redhat.com> Hi all, While running the caless tests I've encountered a strange behavior of the service module: when I add a new service and then try to disable it, it says, it has been already disabled: ofayans at f22master:~]$ ipa service-add --force Principal: totest/trololo.pesen.net -------------------------------------------------- Added service "totest/trololo.pesen.net at PESEN.NET" -------------------------------------------------- Principal: totest/trololo.pesen.net at PESEN.NET Managed by: trololo.pesen.net ofayans at f22master:~]$ ipa service-disable Principal: totest/trololo.pesen.net at PESEN.NET ipa: ERROR: This entry is already disabled ipa help service shows there is no service-enable subcommand. So I have 2 questions: 1. How do I enable previously disabled service? 2. Why is a freshly-created service disabled by default? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ofayans at redhat.com Tue Oct 20 08:17:57 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 20 Oct 2015 10:17:57 +0200 Subject: [Freeipa-devel] Host does not have corresponding DNS A/AAAA record In-Reply-To: <5625F713.5010703@redhat.com> References: <5625F3DE.4060708@redhat.com> <5625F713.5010703@redhat.com> Message-ID: <5625F8B5.702@redhat.com> On 10/20/2015 10:10 AM, Petr Vobornik wrote: > On 10/20/2015 09:57 AM, Oleg Fayans wrote: >> Hi, >> >> I keep hitting a strange issue: when I create a dnsrecord manually and >> then try to create the host, it complains that the host does not have >> corresponding DNS A/AAAA record. >> >> ofayans at f22master:~]$ ipa dnsrecord-add >> Record name: fortest >> Zone name: pesen.net. >> Please choose a type of DNS resource record to be added >> The most common types for this type of zone are: A, AAAA >> >> DNS resource record type: A >> A IP Address: 192.168.122.253 >> Record name: fortest >> A record: 192.168.122.253 >> ofayans at f22master:~]$ ipa host-add >> Host name: fortest.pesen.net >> ipa: ERROR: Host does not have corresponding DNS A/AAAA record >> ofayans at f22master:~]$ ping fortest >> PING fortest.pesen.net (192.168.122.253) 56(84) bytes of data. > > The check uses DNS resolution to get the info. Does it work well? It works, I added an output of ping command to show that > > Other option is to add host with --ip-address option so you can skip the > dnsrecord-add call. I know, but there must be a way to fix the host if an admin forgot to add this option. So, ideally, I should be able to create a host, then add a dnsrecord, then add a service. Now, obviously it's not the case: root at f22master:/home/ofayans]$ ping trololo.pesen.net PING trololo.pesen.net (192.168.122.200) 56(84) bytes of data. ^C --- trololo.pesen.net ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms root at f22master:/home/ofayans]$ ipa service-add someservice/trololo.pesen.net ipa: ERROR: Host does not have corresponding DNS A/AAAA record root at f22master:/home/ofayans]$ ipa dnsrecord-show Record name: trololo Zone name: pesen.net. Record name: trololo A record: 192.168.122.200 > > >> >> When I then use --force to create the host anyway and then try to add a >> service to this host, I get the same error: >> >> ofayans at f22master:~]$ ipa service-add >> Principal: fortest/fortest.pesen.net >> ipa: ERROR: The host 'fortest.pesen.net' does not exist to add a service >> to. >> > > This error tells that the host entry does not exist. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pvoborni at redhat.com Tue Oct 20 08:19:32 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Oct 2015 10:19:32 +0200 Subject: [Freeipa-devel] freshly added service is disabled In-Reply-To: <5625F750.1070501@redhat.com> References: <5625F750.1070501@redhat.com> Message-ID: <5625F914.90802@redhat.com> On 10/20/2015 10:12 AM, Oleg Fayans wrote: > Hi all, > > While running the caless tests I've encountered a strange behavior of > the service module: > when I add a new service and then try to disable it, it says, it has > been already disabled: > > ofayans at f22master:~]$ ipa service-add --force > Principal: totest/trololo.pesen.net > -------------------------------------------------- > Added service "totest/trololo.pesen.net at PESEN.NET" > -------------------------------------------------- > Principal: totest/trololo.pesen.net at PESEN.NET > Managed by: trololo.pesen.net > ofayans at f22master:~]$ ipa service-disable > Principal: totest/trololo.pesen.net at PESEN.NET > ipa: ERROR: This entry is already disabled > > ipa help service shows there is no service-enable subcommand. So I have > 2 questions: > 1. How do I enable previously disabled service? > 2. Why is a freshly-created service disabled by default? > Service disable revokes existing certificate, removes it from the service entry and also removes Kerberos principal key. When you create a new service, it does not contain principal key nor a certificate therefore there is no work to do in disable command and therefore the message. -- Petr Vobornik From mbasti at redhat.com Tue Oct 20 08:26:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 10:26:18 +0200 Subject: [Freeipa-devel] Host does not have corresponding DNS A/AAAA record In-Reply-To: <5625F8B5.702@redhat.com> References: <5625F3DE.4060708@redhat.com> <5625F713.5010703@redhat.com> <5625F8B5.702@redhat.com> Message-ID: <5625FAAA.5080303@redhat.com> On 20.10.2015 10:17, Oleg Fayans wrote: > > > On 10/20/2015 10:10 AM, Petr Vobornik wrote: >> On 10/20/2015 09:57 AM, Oleg Fayans wrote: >>> Hi, >>> >>> I keep hitting a strange issue: when I create a dnsrecord manually and >>> then try to create the host, it complains that the host does not have >>> corresponding DNS A/AAAA record. >>> >>> ofayans at f22master:~]$ ipa dnsrecord-add >>> Record name: fortest >>> Zone name: pesen.net. >>> Please choose a type of DNS resource record to be added >>> The most common types for this type of zone are: A, AAAA >>> >>> DNS resource record type: A >>> A IP Address: 192.168.122.253 >>> Record name: fortest >>> A record: 192.168.122.253 >>> ofayans at f22master:~]$ ipa host-add >>> Host name: fortest.pesen.net >>> ipa: ERROR: Host does not have corresponding DNS A/AAAA record >>> ofayans at f22master:~]$ ping fortest >>> PING fortest.pesen.net (192.168.122.253) 56(84) bytes of data. >> >> The check uses DNS resolution to get the info. Does it work well? > It works, I added an output of ping command to show that dnsrecord-add and host-add works for me, A records is resolvable. Do you have configured /etc/resolv.conf properly on host? (or network manager DNS configuration)? >> >> Other option is to add host with --ip-address option so you can skip the >> dnsrecord-add call. > > I know, but there must be a way to fix the host if an admin forgot to > add this option. So, ideally, I should be able to create a host, then > add a dnsrecord, then add a service. Now, obviously it's not the case: > > root at f22master:/home/ofayans]$ ping trololo.pesen.net > PING trololo.pesen.net (192.168.122.200) 56(84) bytes of data. > ^C > --- trololo.pesen.net ping statistics --- > 1 packets transmitted, 0 received, 100% packet loss, time 0ms > > root at f22master:/home/ofayans]$ ipa service-add > someservice/trololo.pesen.net > ipa: ERROR: Host does not have corresponding DNS A/AAAA record > root at f22master:/home/ofayans]$ ipa dnsrecord-show > Record name: trololo > Zone name: pesen.net. > Record name: trololo > A record: 192.168.122.200 > > >> >> >>> >>> When I then use --force to create the host anyway and then try to add a >>> service to this host, I get the same error: >>> >>> ofayans at f22master:~]$ ipa service-add >>> Principal: fortest/fortest.pesen.net >>> ipa: ERROR: The host 'fortest.pesen.net' does not exist to add a >>> service >>> to. >>> >> >> This error tells that the host entry does not exist. > From ofayans at redhat.com Tue Oct 20 08:49:30 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 20 Oct 2015 10:49:30 +0200 Subject: [Freeipa-devel] Host does not have corresponding DNS A/AAAA record In-Reply-To: <5625FAAA.5080303@redhat.com> References: <5625F3DE.4060708@redhat.com> <5625F713.5010703@redhat.com> <5625F8B5.702@redhat.com> <5625FAAA.5080303@redhat.com> Message-ID: <5626001A.4050703@redhat.com> Hi Martin, On 10/20/2015 10:26 AM, Martin Basti wrote: > > > On 20.10.2015 10:17, Oleg Fayans wrote: >> >> >> On 10/20/2015 10:10 AM, Petr Vobornik wrote: >>> On 10/20/2015 09:57 AM, Oleg Fayans wrote: >>>> Hi, >>>> >>>> I keep hitting a strange issue: when I create a dnsrecord manually and >>>> then try to create the host, it complains that the host does not have >>>> corresponding DNS A/AAAA record. >>>> >>>> ofayans at f22master:~]$ ipa dnsrecord-add >>>> Record name: fortest >>>> Zone name: pesen.net. >>>> Please choose a type of DNS resource record to be added >>>> The most common types for this type of zone are: A, AAAA >>>> >>>> DNS resource record type: A >>>> A IP Address: 192.168.122.253 >>>> Record name: fortest >>>> A record: 192.168.122.253 >>>> ofayans at f22master:~]$ ipa host-add >>>> Host name: fortest.pesen.net >>>> ipa: ERROR: Host does not have corresponding DNS A/AAAA record >>>> ofayans at f22master:~]$ ping fortest >>>> PING fortest.pesen.net (192.168.122.253) 56(84) bytes of data. >>> >>> The check uses DNS resolution to get the info. Does it work well? >> It works, I added an output of ping command to show that > dnsrecord-add and host-add works for me, A records is resolvable. > > Do you have configured /etc/resolv.conf properly on host? (or network > manager DNS configuration)? Yes, I did. In fact, I just upgraded the server to the latest version from upstream, and the issue is gone. > >>> >>> Other option is to add host with --ip-address option so you can skip the >>> dnsrecord-add call. >> >> I know, but there must be a way to fix the host if an admin forgot to >> add this option. So, ideally, I should be able to create a host, then >> add a dnsrecord, then add a service. Now, obviously it's not the case: >> >> root at f22master:/home/ofayans]$ ping trololo.pesen.net >> PING trololo.pesen.net (192.168.122.200) 56(84) bytes of data. >> ^C >> --- trololo.pesen.net ping statistics --- >> 1 packets transmitted, 0 received, 100% packet loss, time 0ms >> >> root at f22master:/home/ofayans]$ ipa service-add >> someservice/trololo.pesen.net >> ipa: ERROR: Host does not have corresponding DNS A/AAAA record >> root at f22master:/home/ofayans]$ ipa dnsrecord-show >> Record name: trololo >> Zone name: pesen.net. >> Record name: trololo >> A record: 192.168.122.200 >> >> >>> >>> >>>> >>>> When I then use --force to create the host anyway and then try to add a >>>> service to this host, I get the same error: >>>> >>>> ofayans at f22master:~]$ ipa service-add >>>> Principal: fortest/fortest.pesen.net >>>> ipa: ERROR: The host 'fortest.pesen.net' does not exist to add a >>>> service >>>> to. >>>> >>> >>> This error tells that the host entry does not exist. >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Tue Oct 20 10:32:50 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 20 Oct 2015 12:32:50 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561FED16.5060604@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> Message-ID: <56261852.8090603@redhat.com> On 10/15/2015 08:14 PM, Simo Sorce wrote: > On 15/10/15 11:39, Martin Basti wrote: >> Without this patch the ipa-ca-install is broken in current master. >> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >> AttributeError: Values instance has no attribute 'promote' > > Should be fixed with the attached patches. > > > NACK, in patch 551 you add a test for non-existent CLI option into main method: @@ -198,10 +251,20 @@ def main(): if os.geteuid() != 0: sys.exit("\nYou must be root to run this script.\n") - if filename is not None: - install_replica(safe_options, options, filename) - else: - install_master(safe_options, options) + try: + if options.replica or filename is not None: + install_replica(safe_options, options, filename) + else: + install_master(safe_options, options) + + finally: + # Clean up if we created custom credentials + created_ccache_file = getattr(options, 'created_ccache_file', None) + if created_ccache_file is not None: + try: + os.unlink(created_ccache_file) + except OSError: + pass I guess you wanted to add '--replica' option to the CA installer but since it was not added to option parser the installer explodes. # ipa-ca-install Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: AttributeError: Values instance has no attribute 'replica' -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Oct 20 10:49:40 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 20 Oct 2015 12:49:40 +0200 Subject: [Freeipa-devel] [PATCH 0088] fix dsinstance.py:get_domain_level function Message-ID: <56261C44.2020709@redhat.com> During review of Simo's patches I have found some inconsistencies between 'get_domain_level' function definition and its usage. This little patch fixes them. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0088-fix-dsinstance.py-get_domain_level-function.patch Type: text/x-patch Size: 1245 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 20 11:05:29 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Oct 2015 13:05:29 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <5625EAF2.4000903@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561D377B.5040806@redhat.com> <561D39B6.4090801@redhat.com> <5625EAF2.4000903@redhat.com> Message-ID: <56261FF9.1090106@redhat.com> On 10/20/2015 09:19 AM, Martin Babinsky wrote: > On 10/13/2015 07:04 PM, Martin Babinsky wrote: >> On 10/13/2015 06:55 PM, Martin Babinsky wrote: >>> mbabinsk - hide segment direction from topology commands >> >> Ooops forgot to regenerate API.txt. Attaching updated patch. >> >> >> > Ping for review. > commit message is wrong, it doesn't do anything with Web UI. Also there is only one patch, not 1/2, otherwise ACK. -- Petr Vobornik From mbabinsk at redhat.com Tue Oct 20 11:25:47 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 20 Oct 2015 13:25:47 +0200 Subject: [Freeipa-devel] [0089] fix class teardown in user plugin tests Message-ID: <562624BB.8090108@redhat.com> fixes https://fedorahosted.org/freeipa/ticket/5368 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0089-fix-class-teardown-in-user-plugin-tests.patch Type: text/x-patch Size: 2203 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Oct 20 11:32:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 20 Oct 2015 13:32:33 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <56261FF9.1090106@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561D377B.5040806@redhat.com> <561D39B6.4090801@redhat.com> <5625EAF2.4000903@redhat.com> <56261FF9.1090106@redhat.com> Message-ID: <56262651.7010605@redhat.com> On 10/20/2015 01:05 PM, Petr Vobornik wrote: > On 10/20/2015 09:19 AM, Martin Babinsky wrote: >> On 10/13/2015 07:04 PM, Martin Babinsky wrote: >>> On 10/13/2015 06:55 PM, Martin Babinsky wrote: >>>> mbabinsk - hide segment direction from topology commands >>> >>> Ooops forgot to regenerate API.txt. Attaching updated patch. >>> >>> >>> >> Ping for review. >> > > commit message is wrong, it doesn't do anything with Web UI. Also there > is only one patch, not 1/2, otherwise ACK. > Yes the commit message was confusing. I have rewritten it completely. Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0084.3-do-not-ask-for-segment-direction-when-running-topolo.patch Type: text/x-patch Size: 2998 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 20 12:19:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 14:19:33 +0200 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test In-Reply-To: <5625F493.9020109@redhat.com> References: <5603F13E.4060805@redhat.com> <560BD9C8.2070205@redhat.com> <5620FEF1.70808@redhat.com> <5624D61E.20106@redhat.com> <5625F493.9020109@redhat.com> Message-ID: <56263155.4000608@redhat.com> On 20.10.2015 10:00, Milan Kub?k wrote: > On 10/19/2015 01:38 PM, Martin Basti wrote: >> >> >> On 16.10.2015 15:43, Milan Kub?k wrote: >>> On 09/30/2015 02:47 PM, Martin Basti wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> Hi, >>> >>> updated patches and the numbering mess somehow curbed. The patches >>> are rebased on top of current master and ipa-4-2. >>> >>> 0) fixed by 0021 >>> >>> 1) docs for tracker extended, added more test cases >>> >>> 2) changed >>> >>> >>> -- >>> Milan Kubik >> I have a few comments: >> >> 1) >> +# TODO: rewrite these into Tracker instances >> + at pytest.fixture(scope='class') >> +def smime_user(request): >> + api.Command.user_add(uid=u'alice', givenname=u'Alice', sn=u'SMIME', >> + userpassword=u'Change123') >> + >> + unlock_principal_password('alice', 'Change123', 'Secret123') >> + >> + def fin(): >> + api.Command.user_del(u'alice') >> + request.addfinalizer(fin) >> + >> + return u'alice' >> >> I do not like hardcoded password value, as this password is used in >> many places in the test, I sugest to use a module variable > Done >> >> 2) >> +class TestSignWithChangedProfile(XMLRPC_test): >> + """ Test to verify that the updated profile is used.""" >> + pass # import invalid profile, try to sign, expect fail >> >> IMO something is missing here, a test maybe? >> > Done by using profile with constraint that CSR cannot meet. >> 3) >> # noqa >> Please remove "# noqa" commets from commits > > Done. > > -- > Milan Kubik NACK 1) I still see many hardcoded passwords in the code with change_principal(smime_user, "Secret123"): 2) Also the 'alice' username can be extracted to module variable instead hardcoding 3) File alice.conf.tmpl can be generalized to be used for more users, replace alice in template to {username} and in code replace this variable with alice, also do not forgot rename template to something more general -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Oct 20 13:33:19 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Oct 2015 15:33:19 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <56262651.7010605@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561D377B.5040806@redhat.com> <561D39B6.4090801@redhat.com> <5625EAF2.4000903@redhat.com> <56261FF9.1090106@redhat.com> <56262651.7010605@redhat.com> Message-ID: <5626429F.9060902@redhat.com> On 10/20/2015 01:32 PM, Martin Babinsky wrote: > On 10/20/2015 01:05 PM, Petr Vobornik wrote: >> On 10/20/2015 09:19 AM, Martin Babinsky wrote: >>> On 10/13/2015 07:04 PM, Martin Babinsky wrote: >>>> On 10/13/2015 06:55 PM, Martin Babinsky wrote: >>>>> mbabinsk - hide segment direction from topology commands >>>> >>>> Ooops forgot to regenerate API.txt. Attaching updated patch. >>>> >>>> >>>> >>> Ping for review. >>> >> >> commit message is wrong, it doesn't do anything with Web UI. Also there >> is only one patch, not 1/2, otherwise ACK. >> > Yes the commit message was confusing. I have rewritten it completely. > Attaching updated patch. > ACK Pushed to master: e0d9a1b47ce6144d57345744d895b63e5b0ea413 -- Petr Vobornik From mbasti at redhat.com Tue Oct 20 13:53:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 15:53:23 +0200 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker In-Reply-To: <5624DF10.4060000@redhat.com> References: <5624C63D.5020000@redhat.com> <5624DF10.4060000@redhat.com> Message-ID: <56264753.1000405@redhat.com> On 19.10.2015 14:16, Martin Basti wrote: > > > On 19.10.2015 12:30, Martin Basti wrote: >> Attribute nsaccountlock has not been processed correctly >> >> Patch attached. >> >> > > Self-NACK, more fixes required > > > Updated patch attached, but it still needs to improve because tests in my patch 331 are still failing. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0329.2-Tests-Fix-user-tracker.patch Type: text/x-patch Size: 5053 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 20 13:57:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 15:57:41 +0200 Subject: [Freeipa-devel] [PATCH 0331] User plugin: allow multiple managers per user - CLI part Message-ID: <56264855.50606@redhat.com> https://fedorahosted.org/freeipa/ticket/5344 Patch attached. Test are failing, a fix in UserTracker has to be done (partially in my patch 329) -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0331-Allow-multiple-managers-per-user-CLI-part.patch Type: text/x-patch Size: 9135 bytes Desc: not available URL: From ofayans at redhat.com Tue Oct 20 14:03:06 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 20 Oct 2015 16:03:06 +0200 Subject: [Freeipa-devel] [PATCH 0084] hide topology segment direction in topology command CLI and webui interface In-Reply-To: <5626429F.9060902@redhat.com> References: <561BD870.8040107@redhat.com> <561CBA7C.1090003@redhat.com> <561CBDB6.7000202@redhat.com> <561D377B.5040806@redhat.com> <561D39B6.4090801@redhat.com> <5625EAF2.4000903@redhat.com> <56261FF9.1090106@redhat.com> <56262651.7010605@redhat.com> <5626429F.9060902@redhat.com> Message-ID: <5626499A.2040700@redhat.com> Verified. works as expected On 10/20/2015 03:33 PM, Petr Vobornik wrote: > On 10/20/2015 01:32 PM, Martin Babinsky wrote: >> On 10/20/2015 01:05 PM, Petr Vobornik wrote: >>> On 10/20/2015 09:19 AM, Martin Babinsky wrote: >>>> On 10/13/2015 07:04 PM, Martin Babinsky wrote: >>>>> On 10/13/2015 06:55 PM, Martin Babinsky wrote: >>>>>> mbabinsk - hide segment direction from topology commands >>>>> >>>>> Ooops forgot to regenerate API.txt. Attaching updated patch. >>>>> >>>>> >>>>> >>>> Ping for review. >>>> >>> >>> commit message is wrong, it doesn't do anything with Web UI. Also there >>> is only one patch, not 1/2, otherwise ACK. >>> >> Yes the commit message was confusing. I have rewritten it completely. >> Attaching updated patch. >> > > ACK > > Pushed to master: e0d9a1b47ce6144d57345744d895b63e5b0ea413 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Tue Oct 20 14:07:34 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 16:07:34 +0200 Subject: [Freeipa-devel] [PATCH 0331] User plugin: allow multiple managers per user - CLI part In-Reply-To: <56264855.50606@redhat.com> References: <56264855.50606@redhat.com> Message-ID: <56264AA6.5010003@redhat.com> On 20.10.2015 15:57, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5344 > > Patch attached. > > Test are failing, a fix in UserTracker has to be done (partially in my > patch 329) > > SelfNACK, I forgot to add stageuser tests -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Oct 20 14:27:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 20 Oct 2015 16:27:39 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <56250369.3090400@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> <56250369.3090400@redhat.com> Message-ID: <56264F5B.6080109@redhat.com> On 10/19/2015 04:51 PM, Martin Babinsky wrote: > On 10/19/2015 02:47 PM, Martin Basti wrote: >> >> >> On 15.10.2015 16:29, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5175 >>> >>> >>> >> NACK >> >> with domain level 0 >> >> ipa-replica-prepare >> >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in >> execute >> self.ask_for_options() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", >> >> line 215, in ask_for_options >> bind_pw=self.dirman_password) >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 61, >> in connect >> self.id, threading.currentThread().getName() >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The >> ipa-replica-prepare command failed, exception: Exception: connect: >> 'context.ldap2_140616703529424' already exists in thread 'MainThread' >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: >> connect: 'context.ldap2_140616703529424' already exists in thread >> 'MainThread' >> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The >> ipa-replica-prepare command failed. >> >> without your patch it works >> >> Martin^2 > > The function was leaking opened backend connection due to incorrect > disconnect logic. Updated patch should fix this. > > > Reworked patch attached which used existing function in dsinstance.py to check domain level. However, note that it may require my patch 0088 to function correctly. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0086.3-disable-ipa-replica-prepare-in-non-zero-IPA-domain-l.patch Type: text/x-patch Size: 2516 bytes Desc: not available URL: From simo at redhat.com Tue Oct 20 14:49:30 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Oct 2015 10:49:30 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56261852.8090603@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> Message-ID: <5626547A.9080804@redhat.com> On 20/10/15 06:32, Martin Babinsky wrote: > On 10/15/2015 08:14 PM, Simo Sorce wrote: >> On 15/10/15 11:39, Martin Basti wrote: >>> Without this patch the ipa-ca-install is broken in current master. >>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>> AttributeError: Values instance has no attribute 'promote' >> >> Should be fixed with the attached patches. >> >> >> > NACK, in patch 551 you add a test for non-existent CLI option into main > method: > > @@ -198,10 +251,20 @@ def main(): > if os.geteuid() != 0: > sys.exit("\nYou must be root to run this script.\n") > > - if filename is not None: > - install_replica(safe_options, options, filename) > - else: > - install_master(safe_options, options) > + try: > + if options.replica or filename is not None: > + install_replica(safe_options, options, filename) > + else: > + install_master(safe_options, options) > + > + finally: > + # Clean up if we created custom credentials > + created_ccache_file = getattr(options, 'created_ccache_file', > None) > + if created_ccache_file is not None: > + try: > + os.unlink(created_ccache_file) > + except OSError: > + pass > > I guess you wanted to add '--replica' option to the CA installer but > since it was not added to option parser the installer explodes. > > # ipa-ca-install > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Unexpected error - see /var/log/ipareplica-ca-install.log for details: > AttributeError: Values instance has no attribute 'replica' Argh! Sorry, this use was exactly one of the reason I had to introduce the --replica switch, I will have to rework a bunch of code to detect if we are a replica or a master, I will hopefully have a revised patch in a few hours. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Tue Oct 20 15:35:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 17:35:26 +0200 Subject: [Freeipa-devel] [PATCH 0088] fix dsinstance.py:get_domain_level function In-Reply-To: <56261C44.2020709@redhat.com> References: <56261C44.2020709@redhat.com> Message-ID: <56265F3E.5060709@redhat.com> On 20.10.2015 12:49, Martin Babinsky wrote: > During review of Simo's patches I have found some inconsistencies > between 'get_domain_level' function definition and its usage. > > This little patch fixes them. > > > ACK Pushed to master: 98bf90e4cecb38fc72a0b598a6e6a50fee284f31 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Oct 20 15:47:21 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 20 Oct 2015 17:47:21 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <56264F5B.6080109@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> <56250369.3090400@redhat.com> <56264F5B.6080109@redhat.com> Message-ID: <56266209.8060705@redhat.com> On 10/20/2015 04:27 PM, Martin Babinsky wrote: > On 10/19/2015 04:51 PM, Martin Babinsky wrote: >> On 10/19/2015 02:47 PM, Martin Basti wrote: >>> >>> >>> On 15.10.2015 16:29, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5175 >>>> >>>> >>>> >>> NACK >>> >>> with domain level 0 >>> >>> ipa-replica-prepare >>> >>> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File >>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 169, in >>> execute >>> self.ask_for_options() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py", >>> >>> >>> line 215, in ask_for_options >>> bind_pw=self.dirman_password) >>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 61, >>> in connect >>> self.id, threading.currentThread().getName() >>> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The >>> ipa-replica-prepare command failed, exception: Exception: connect: >>> 'context.ldap2_140616703529424' already exists in thread 'MainThread' >>> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: >>> connect: 'context.ldap2_140616703529424' already exists in thread >>> 'MainThread' >>> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The >>> ipa-replica-prepare command failed. >>> >>> without your patch it works >>> >>> Martin^2 >> >> The function was leaking opened backend connection due to incorrect >> disconnect logic. Updated patch should fix this. >> >> >> > Reworked patch attached which used existing function in dsinstance.py to > check domain level. > > However, note that it may require my patch 0088 to function correctly. > > > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0086.4-disable-ipa-replica-prepare-in-non-zero-IPA-domain-l.patch Type: text/x-patch Size: 2661 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 20 16:21:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 18:21:12 +0200 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker In-Reply-To: <56264753.1000405@redhat.com> References: <5624C63D.5020000@redhat.com> <5624DF10.4060000@redhat.com> <56264753.1000405@redhat.com> Message-ID: <562669F8.3060502@redhat.com> On 20.10.2015 15:53, Martin Basti wrote: > > > On 19.10.2015 14:16, Martin Basti wrote: >> >> >> On 19.10.2015 12:30, Martin Basti wrote: >>> Attribute nsaccountlock has not been processed correctly >>> >>> Patch attached. >>> >>> >> >> Self-NACK, more fixes required >> >> >> > Updated patch attached, but it still needs to improve because tests in > my patch 331 are still failing. > Eternal self-NACK for this patch I'm not able to fix UserTracker, I need help from somebody with higher view of how this tracker is supposed to work. Follow my patch 0331 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Oct 20 16:30:15 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 20 Oct 2015 18:30:15 +0200 Subject: [Freeipa-devel] [PATCHES] 737-742 More Python3 porting Message-ID: <56266C17.6040307@redhat.com> Yet another batch of py3 patches. We're getting closer: if this was merged, my WIP branch that passes ipapython & ipalib tests under py3 would currently be down to: 8 files changed, 73 insertions(+), 23 deletions(-) -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0737-Handle-binascii.Error-from-base64.b64decode.patch Type: text/x-patch Size: 6908 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0738-ipatest.util-Port-to-Python-3.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0739-ipalib.messages-Add-message-property-to-PublicMessag.patch Type: text/x-patch Size: 862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0740-Fix-more-bytes-unicode-issues.patch Type: text/x-patch Size: 22048 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0741-Work-around-ipalib.text-i18n-str-unicode-handling.patch Type: text/x-patch Size: 2354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0742-Fix-left-over-Python-3-syntax-errors.patch Type: text/x-patch Size: 1106 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 20 16:46:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Oct 2015 18:46:07 +0200 Subject: [Freeipa-devel] [PATCH 0331] User plugin: allow multiple managers per user - CLI part In-Reply-To: <56264AA6.5010003@redhat.com> References: <56264855.50606@redhat.com> <56264AA6.5010003@redhat.com> Message-ID: <56266FCF.80909@redhat.com> On 20.10.2015 16:07, Martin Basti wrote: > > > On 20.10.2015 15:57, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5344 >> >> Patch attached. >> >> Test are failing, a fix in UserTracker has to be done (partially in >> my patch 329) >> >> > SelfNACK, I forgot to add stageuser tests > > Updated patch attached. I extracted tests to the separate patch, tests do not work, I had issues with user and stageuser trackers. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0331.2-Allow-multiple-managers-per-user-CLI-part.patch Type: text/x-patch Size: 7437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0000-WIP-tests-multiple-managers-per-user.patch Type: text/x-patch Size: 4585 bytes Desc: not available URL: From simo at redhat.com Tue Oct 20 17:24:16 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Oct 2015 13:24:16 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <56261852.8090603@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> Message-ID: <562678C0.9010407@redhat.com> On 20/10/15 06:32, Martin Babinsky wrote: > On 10/15/2015 08:14 PM, Simo Sorce wrote: >> On 15/10/15 11:39, Martin Basti wrote: >>> Without this patch the ipa-ca-install is broken in current master. >>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>> AttributeError: Values instance has no attribute 'promote' >> >> Should be fixed with the attached patches. >> >> >> > NACK, in patch 551 you add a test for non-existent CLI option into main > method: > > @@ -198,10 +251,20 @@ def main(): > if os.geteuid() != 0: > sys.exit("\nYou must be root to run this script.\n") > > - if filename is not None: > - install_replica(safe_options, options, filename) > - else: > - install_master(safe_options, options) > + try: > + if options.replica or filename is not None: > + install_replica(safe_options, options, filename) > + else: > + install_master(safe_options, options) > + > + finally: > + # Clean up if we created custom credentials > + created_ccache_file = getattr(options, 'created_ccache_file', > None) > + if created_ccache_file is not None: > + try: > + os.unlink(created_ccache_file) > + except OSError: > + pass > > I guess you wanted to add '--replica' option to the CA installer but > since it was not added to option parser the installer explodes. > > # ipa-ca-install > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Unexpected error - see /var/log/ipareplica-ca-install.log for details: > AttributeError: Values instance has no attribute 'replica' > The attached patch should address this problem now. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-551-4-Allow-ipa-ca-install-to-use-the-new-promotion-code.patch Type: text/x-patch Size: 9195 bytes Desc: not available URL: From ldoudova at redhat.com Wed Oct 21 04:53:50 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 21 Oct 2015 06:53:50 +0200 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker In-Reply-To: <562669F8.3060502@redhat.com> References: <5624C63D.5020000@redhat.com> <5624DF10.4060000@redhat.com> <56264753.1000405@redhat.com> <562669F8.3060502@redhat.com> Message-ID: <56271A5E.3010608@redhat.com> On 10/20/2015 06:21 PM, Martin Basti wrote: > > > On 20.10.2015 15:53, Martin Basti wrote: >> >> >> On 19.10.2015 14:16, Martin Basti wrote: >>> >>> >>> On 19.10.2015 12:30, Martin Basti wrote: >>>> Attribute nsaccountlock has not been processed correctly >>>> >>>> Patch attached. >>>> >>>> >>> >>> Self-NACK, more fixes required >>> >>> >>> >> Updated patch attached, but it still needs to improve because tests >> in my patch 331 are still failing. >> > > Eternal self-NACK for this patch > > I'm not able to fix UserTracker, I need help from somebody with higher > view of how this tracker is supposed to work. > Follow my patch 0331 Hi, I'll take a look at it today. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 21 08:46:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 Oct 2015 10:46:04 +0200 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: References: <561B5786.8070207@redhat.com> <561CA554.505@redhat.com> <561CA707.3050800@redhat.com> Message-ID: <562750CC.3030100@redhat.com> On 20.10.2015 05:17, Gabe Alford wrote: > Bump for re-review. Hello, thank your for your patch, the patch LGTM, but please use print() as function to be python2/3 compatible Martin^2 > > On Tue, Oct 13, 2015 at 7:15 AM, Gabe Alford > wrote: > > No worries Petr. All a part of the review process. > > I have attached an updated patch that prints only a warning message. > > thanks, > > Gabe > > On Tue, Oct 13, 2015 at 12:39 AM, Petr Spacek > wrote: > > Hello Gabe, > > I would like to apologize for the confusion regarding this > patch and the > repeated reworking. > > Unfortunately Honza's position is not mentioned in the ticket > so you could not > know what to do, but Honza is our "installer architect" so he > has final say. > > Petr^2 Spacek > > On 13.10.2015 08:31, Jan Cholasta wrote: > > Hi, > > > > I don't think this is the correct approach. We are aiming to > have idempotent > > installers, which means that running uninstall on a system > without IPA > > installed should be a no-op. This is the current behavior, > so your patch is > > actually moving us back. > > > > The proper fix would be to *remove* the check from install > (as opposed to > > adding it to uninstall), but this requires the install code > to be idempotent, > > and we're not there yet. > > > > I'm OK with making this a warning, but don't make it a fatal > error and/or > > require --force. > > > > Honza > > > > On 12.10.2015 17:12, Gabe Alford wrote: > >> Thanks, Petr. Updated patch attached. > >> > >> Gabe > >> > >> On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek > > >> >> wrote: > >> > >> Hello Gabe, > >> > >> thank you for your patch! > >> > >> Please note that there might be a case where detection > >> is_ipa_configured() is > >> broken but the user still needs to run the uninstall > process to > >> clean it up. > >> > >> Could you amend the patch to respect --force option? In > that case the > >> detection should be skipped. > >> > >> Thank you for your time! > >> > >> Petr^2 Spacek > >> > >> On 9.10.2015 19:17, Gabe Alford wrote: > >> > diff --git a/ipaserver/install/server/install.py > >> b/ipaserver/install/server/install.py > >> > index > >> > >> > 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 > >> > >> 100644 > >> > --- a/ipaserver/install/server/install.py > >> > +++ b/ipaserver/install/server/install.py > >> > @@ -954,6 +954,12 @@ def uninstall_check(installer): > >> > > >> > installer._installation_cleanup = False > >> > > >> > + if not is_ipa_configured(): > >> > + print("IPA server is not configured on this > system.\n" + > >> > + "If you want to install the IPA > server, please > >> install " + > >> > + "it using 'ipa-server-install'.") > >> > + sys.exit(1) > >> > + > >> > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) > >> > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 21 09:14:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 Oct 2015 11:14:46 +0200 Subject: [Freeipa-devel] [PATCH 0332] fix user post_callback Message-ID: <56275786.8090504@redhat.com> https://fedorahosted.org/freeipa/ticket/5387 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0332-baseuser-add-fix-post_callback.patch Type: text/x-patch Size: 3003 bytes Desc: not available URL: From tbabej at redhat.com Wed Oct 21 10:41:52 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 21 Oct 2015 12:41:52 +0200 Subject: [Freeipa-devel] [PATCH 0087] execute user-del pre-callback also during user preservation In-Reply-To: <5624D252.3060709@redhat.com> References: <562133D8.6050107@redhat.com> <5624812C.6000303@redhat.com> <5624ACF1.8060008@redhat.com> <5624D252.3060709@redhat.com> Message-ID: <56276BF0.9040500@redhat.com> On 10/19/2015 01:21 PM, Tomas Babej wrote: > > > On 10/19/2015 10:42 AM, Martin Babinsky wrote: >> On 10/19/2015 07:35 AM, Martin Babinsky wrote: >>> On 10/16/2015 07:28 PM, Martin Babinsky wrote: >>>> fixes tickets: >>>> >>>> https://fedorahosted.org/freeipa/ticket/5362 >>>> https://fedorahosted.org/freeipa/ticket/5372 >>>> >>>> Upon discussion with Simo we decided that OTP tokens should be >>>> orphaned/deleted also during the user preservation. >>>> >>>> >>>> >>> self-NACK, the current patch violates what we agreed on with Tomas >>> regarding removal of ID overrides. >>> >> Reworked patch attached. >> > > ACK, works as expected. > Pushed to: master: 6a401fbf31bd35220b47ad2a8552d1f93928a2eb ipa-4-2: a85a8f3a4ee1f90fe6f0fb8ea4518ee616c6b42e From mbabinsk at redhat.com Wed Oct 21 15:46:32 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 21 Oct 2015 17:46:32 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <562678C0.9010407@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> <562678C0.9010407@redhat.com> Message-ID: <5627B358.7010203@redhat.com> On 10/20/2015 07:24 PM, Simo Sorce wrote: > On 20/10/15 06:32, Martin Babinsky wrote: >> On 10/15/2015 08:14 PM, Simo Sorce wrote: >>> On 15/10/15 11:39, Martin Basti wrote: >>>> Without this patch the ipa-ca-install is broken in current master. >>>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>>> AttributeError: Values instance has no attribute 'promote' >>> >>> Should be fixed with the attached patches. >>> >>> >>> >> NACK, in patch 551 you add a test for non-existent CLI option into main >> method: >> >> @@ -198,10 +251,20 @@ def main(): >> if os.geteuid() != 0: >> sys.exit("\nYou must be root to run this script.\n") >> >> - if filename is not None: >> - install_replica(safe_options, options, filename) >> - else: >> - install_master(safe_options, options) >> + try: >> + if options.replica or filename is not None: >> + install_replica(safe_options, options, filename) >> + else: >> + install_master(safe_options, options) >> + >> + finally: >> + # Clean up if we created custom credentials >> + created_ccache_file = getattr(options, 'created_ccache_file', >> None) >> + if created_ccache_file is not None: >> + try: >> + os.unlink(created_ccache_file) >> + except OSError: >> + pass >> >> I guess you wanted to add '--replica' option to the CA installer but >> since it was not added to option parser the installer explodes. >> >> # ipa-ca-install >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >> AttributeError: Values instance has no attribute 'replica' >> > > The attached patch should address this problem now. > > Simo. > Thanks, the patch enables CA install on promoted replica. I have one minor nitpick though: When running ipa-ca-install on domain level 0 replica w/o replica file, the installer issues the following error: # ipa-ca-install Replica file None does not exist I guess you should separately handle the case when no replica file is specified and issue a corresponding error message like "A replica file is required". -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Oct 21 15:55:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 21 Oct 2015 17:55:34 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <561CB013.2080406@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> Message-ID: <5627B576.9060003@redhat.com> On 10/13/2015 09:17 AM, Petr Spacek wrote: > On 12.10.2015 13:38, Martin Babinsky wrote: >> >> each service possessing Kerberos keytab wiil now remove it and destroy any >> associated credentials cache during its uninstall >> >> https://fedorahosted.org/freeipa/ticket/5243 > > BTW some time ago Simo proposed that we should remove caches and old keytabs > during *install* so problems caused by failing uninstallation will be fixed on > repeated install. This is yet another step towards idempotent installer. > > To me this makes more sense than doing so on uninstall. Does it make sense to > you, too? > Attaching updated patch that does cleanup also before each instance creation. It is a bit ugly I admit, but I couldn't think of a better way to do it and didn't want to poke into service/instance code more than neccesary. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0082.1-remove-Kerberos-authenticators-when-installing-unins.patch Type: text/x-patch Size: 8374 bytes Desc: not available URL: From tjaalton at ubuntu.com Wed Oct 21 16:05:21 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 21 Oct 2015 19:05:21 +0300 Subject: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions In-Reply-To: <56152B84.2020503@redhat.com> References: <561419BC.5080707@ubuntu.com> <20151007105110.GA27006@redhat.com> <56152B84.2020503@redhat.com> Message-ID: <5627B7C1.2060303@ubuntu.com> On 07.10.2015 17:26, Martin Basti wrote: > thanks comments inline Hey, I hope these versions address the issues in the first batch.. -- t -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0006-2-ipaplatform-Add-HTTPD_USER-to-constants-and-use-it.patch Type: text/x-patch Size: 5399 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0008-2-httpinstance-Use-full-path-via-HTTPD_IPA_REWRITE_CONF.patch Type: text/x-patch Size: 1005 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0009-2-ipaplatform-Add-SECURE_NFS_VAR-to-constants.patch Type: text/x-patch Size: 1459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0010-2-ipaplatform-Add-NTPD_OPTS_VAR-and-NTPD_OPTS_QUOTE-to.patch Type: text/x-patch Size: 2727 bytes Desc: not available URL: From simo at redhat.com Wed Oct 21 19:24:42 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 21 Oct 2015 15:24:42 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5627B358.7010203@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> <562678C0.9010407@redhat.com> <5627B358.7010203@redhat.com> Message-ID: <5627E67A.4010809@redhat.com> On 21/10/15 11:46, Martin Babinsky wrote: > On 10/20/2015 07:24 PM, Simo Sorce wrote: >> On 20/10/15 06:32, Martin Babinsky wrote: >>> On 10/15/2015 08:14 PM, Simo Sorce wrote: >>>> On 15/10/15 11:39, Martin Basti wrote: >>>>> Without this patch the ipa-ca-install is broken in current master. >>>>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>>>> AttributeError: Values instance has no attribute 'promote' >>>> >>>> Should be fixed with the attached patches. >>>> >>>> >>>> >>> NACK, in patch 551 you add a test for non-existent CLI option into main >>> method: >>> >>> @@ -198,10 +251,20 @@ def main(): >>> if os.geteuid() != 0: >>> sys.exit("\nYou must be root to run this script.\n") >>> >>> - if filename is not None: >>> - install_replica(safe_options, options, filename) >>> - else: >>> - install_master(safe_options, options) >>> + try: >>> + if options.replica or filename is not None: >>> + install_replica(safe_options, options, filename) >>> + else: >>> + install_master(safe_options, options) >>> + >>> + finally: >>> + # Clean up if we created custom credentials >>> + created_ccache_file = getattr(options, 'created_ccache_file', >>> None) >>> + if created_ccache_file is not None: >>> + try: >>> + os.unlink(created_ccache_file) >>> + except OSError: >>> + pass >>> >>> I guess you wanted to add '--replica' option to the CA installer but >>> since it was not added to option parser the installer explodes. >>> >>> # ipa-ca-install >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>> AttributeError: Values instance has no attribute 'replica' >>> >> >> The attached patch should address this problem now. >> >> Simo. >> > > Thanks, the patch enables CA install on promoted replica. > > I have one minor nitpick though: > > When running ipa-ca-install on domain level 0 replica w/o replica file, > the installer issues the following error: > > # ipa-ca-install > Replica file None does not exist > > I guess you should separately handle the case when no replica file is > specified and issue a corresponding error message like "A replica file > is required". Done. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-551-5-Allow-ipa-ca-install-to-use-the-new-promotion-code.patch Type: text/x-patch Size: 9277 bytes Desc: not available URL: From simo at redhat.com Wed Oct 21 19:27:06 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 21 Oct 2015 15:27:06 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5627E67A.4010809@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> <562678C0.9010407@redhat.com> <5627B358.7010203@redhat.com> <5627E67A.4010809@redhat.com> Message-ID: <5627E70A.6040308@redhat.com> On 21/10/15 15:24, Simo Sorce wrote: > On 21/10/15 11:46, Martin Babinsky wrote: >> On 10/20/2015 07:24 PM, Simo Sorce wrote: >>> On 20/10/15 06:32, Martin Babinsky wrote: >>>> On 10/15/2015 08:14 PM, Simo Sorce wrote: >>>>> On 15/10/15 11:39, Martin Basti wrote: >>>>>> Without this patch the ipa-ca-install is broken in current master. >>>>>> Unexpected error - see /var/log/ipareplica-ca-install.log for >>>>>> details: >>>>>> AttributeError: Values instance has no attribute 'promote' >>>>> >>>>> Should be fixed with the attached patches. >>>>> >>>>> >>>>> >>>> NACK, in patch 551 you add a test for non-existent CLI option into main >>>> method: >>>> >>>> @@ -198,10 +251,20 @@ def main(): >>>> if os.geteuid() != 0: >>>> sys.exit("\nYou must be root to run this script.\n") >>>> >>>> - if filename is not None: >>>> - install_replica(safe_options, options, filename) >>>> - else: >>>> - install_master(safe_options, options) >>>> + try: >>>> + if options.replica or filename is not None: >>>> + install_replica(safe_options, options, filename) >>>> + else: >>>> + install_master(safe_options, options) >>>> + >>>> + finally: >>>> + # Clean up if we created custom credentials >>>> + created_ccache_file = getattr(options, 'created_ccache_file', >>>> None) >>>> + if created_ccache_file is not None: >>>> + try: >>>> + os.unlink(created_ccache_file) >>>> + except OSError: >>>> + pass >>>> >>>> I guess you wanted to add '--replica' option to the CA installer but >>>> since it was not added to option parser the installer explodes. >>>> >>>> # ipa-ca-install >>>> >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>>> AttributeError: Values instance has no attribute 'replica' >>>> >>> >>> The attached patch should address this problem now. >>> >>> Simo. >>> >> >> Thanks, the patch enables CA install on promoted replica. >> >> I have one minor nitpick though: >> >> When running ipa-ca-install on domain level 0 replica w/o replica file, >> the installer issues the following error: >> >> # ipa-ca-install >> Replica file None does not exist >> >> I guess you should separately handle the case when no replica file is >> specified and issue a corresponding error message like "A replica file >> is required". > > Done. > Simo. Scratch this, it contains a typo, see attached. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-551-6-Allow-ipa-ca-install-to-use-the-new-promotion-code.patch Type: text/x-patch Size: 9277 bytes Desc: not available URL: From redhatrises at gmail.com Wed Oct 21 23:28:24 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 21 Oct 2015 17:28:24 -0600 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: <562750CC.3030100@redhat.com> References: <561B5786.8070207@redhat.com> <561CA554.505@redhat.com> <561CA707.3050800@redhat.com> <562750CC.3030100@redhat.com> Message-ID: Thanks Martin^2. Updated patched attached. On Wed, Oct 21, 2015 at 2:46 AM, Martin Basti wrote: > > > On 20.10.2015 05:17, Gabe Alford wrote: > > Bump for re-review. > > > Hello, > > thank your for your patch, the patch LGTM, but please use print() as > function to be python2/3 compatible > > Martin^2 > > > On Tue, Oct 13, 2015 at 7:15 AM, Gabe Alford > wrote: > >> No worries Petr. All a part of the review process. >> >> I have attached an updated patch that prints only a warning message. >> >> thanks, >> >> Gabe >> >> On Tue, Oct 13, 2015 at 12:39 AM, Petr Spacek < >> pspacek at redhat.com> wrote: >> >>> Hello Gabe, >>> >>> I would like to apologize for the confusion regarding this patch and the >>> repeated reworking. >>> >>> Unfortunately Honza's position is not mentioned in the ticket so you >>> could not >>> know what to do, but Honza is our "installer architect" so he has final >>> say. >>> >>> Petr^2 Spacek >>> >>> On 13.10.2015 08:31, Jan Cholasta wrote: >>> > Hi, >>> > >>> > I don't think this is the correct approach. We are aiming to have >>> idempotent >>> > installers, which means that running uninstall on a system without IPA >>> > installed should be a no-op. This is the current behavior, so your >>> patch is >>> > actually moving us back. >>> > >>> > The proper fix would be to *remove* the check from install (as opposed >>> to >>> > adding it to uninstall), but this requires the install code to be >>> idempotent, >>> > and we're not there yet. >>> > >>> > I'm OK with making this a warning, but don't make it a fatal error >>> and/or >>> > require --force. >>> > >>> > Honza >>> > >>> > On 12.10.2015 17:12, Gabe Alford wrote: >>> >> Thanks, Petr. Updated patch attached. >>> >> >>> >> Gabe >>> >> >>> >> On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek >> >> pspacek at redhat.com>> wrote: >>> >> >>> >> Hello Gabe, >>> >> >>> >> thank you for your patch! >>> >> >>> >> Please note that there might be a case where detection >>> >> is_ipa_configured() is >>> >> broken but the user still needs to run the uninstall process to >>> >> clean it up. >>> >> >>> >> Could you amend the patch to respect --force option? In that case >>> the >>> >> detection should be skipped. >>> >> >>> >> Thank you for your time! >>> >> >>> >> Petr^2 Spacek >>> >> >>> >> On 9.10.2015 19:17, Gabe Alford wrote: >>> >> > diff --git a/ipaserver/install/server/install.py >>> >> b/ipaserver/install/server/install.py >>> >> > index >>> >> >>> >> >>> 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 >>> >> >>> >> 100644 >>> >> > --- a/ipaserver/install/server/install.py >>> >> > +++ b/ipaserver/install/server/install.py >>> >> > @@ -954,6 +954,12 @@ def uninstall_check(installer): >>> >> > >>> >> > installer._installation_cleanup = False >>> >> > >>> >> > + if not is_ipa_configured(): >>> >> > + print("IPA server is not configured on this >>> system.\n" + >>> >> > + "If you want to install the IPA server, please >>> >> install " + >>> >> > + "it using 'ipa-server-install'.") >>> >> > + sys.exit(1) >>> >> > + >>> >> > fstore = sysrestore.FileStore(SYSRESTORE_DIR_PATH) >>> >> > sstore = sysrestore.StateFile(SYSRESTORE_DIR_PATH) >>> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0057-4-Warn-if-no-installation-found-when-running-ipa-serve.patch Type: text/x-patch Size: 1091 bytes Desc: not available URL: From pspacek at redhat.com Thu Oct 22 07:32:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 09:32:09 +0200 Subject: [Freeipa-devel] terminology: "main/primary/? DNS domain" for FreeIPA In-Reply-To: <5616BC36.8050709@redhat.com> References: <561670D9.7080801@redhat.com> <5616BC36.8050709@redhat.com> Message-ID: <562890F9.9000903@redhat.com> On 8.10.2015 20:55, Simo Sorce wrote: > On 08/10/15 09:34, Petr Spacek wrote: >> Hello list, >> >> I'm in process of reviewing and fixing some of our docs and it seems that we >> do not have established term for The Domain user specified during >> ipa-server-install. >> >> Term "DNS domain" is not specific enough because FreeIPA can manage multiple >> DNS domains but only one of them contains SRV records. Term "IdM domain" >> sounds too vague for the same reasons. > > We should make it easy to publish SRV records on any domain, if a client is in > a different DNS domain it should still be able to discover the IPA servers. That should be unnecessary once we fix https://fedorahosted.org/freeipa/ticket/5270 ipa-client-install should use _kerberos record for IPA domain auto-detection (FreeIPA by default adds _kerberos TXT record to all DNS domains managed by FreeIPA-integrated DNS.) -- Petr^2 Spacek From mbabinsk at redhat.com Thu Oct 22 08:44:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Oct 2015 10:44:33 +0200 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output Message-ID: <5628A1F1.8050602@redhat.com> https://fedorahosted.org/freeipa/ticket/5181 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0090-show-optionally-configured-components-in-server-find.patch Type: text/x-patch Size: 2549 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 22 11:06:28 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 22 Oct 2015 13:06:28 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <562128A9.80600@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561FBE0F.5040601@redhat.com> <562128A9.80600@redhat.com> Message-ID: <5628C334.20100@redhat.com> On 10/16/2015 06:41 PM, Endi Sukma Dewata wrote: > On 10/15/2015 9:54 AM, Simo Sorce wrote: >>> 3) ipa-ca-install fails with: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 445, in start_creation >>> run_step(full_msg, method) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 435, in run_step >>> method() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >>> 631, in __spawn_instance >>> DogtagInstance.spawn_instance(self, cfg_file) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>> line 185, in spawn_instance >>> self.handle_setup_error(e) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>> line 448, in handle_setup_error >>> raise RuntimeError("%s configuration failed." % self.subsystem) >>> RuntimeError: CA configuration failed. >>> >>> I guess I'm hitting the authentication bug in Dogtag. It is supposed to >>> be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? >>> We might need a new 10.2.7 build. >> >> I am not sure which version has it fixed, Endi ? > > PKI ticket #1580 was fixed in pki-core-10.2.6-10 for F23 and F24. We > never released a pki-core-10.2.7. I suppose that is a custom build? > Yes it is a custom build[4]. It was advertised that #1414[1] will be in PKI 10.2.7 but it was laterincluded into 10.2.6-5. I don't know what's a plan for 10.2.7. Required patch for the discussed issue #1580[2] is included in 10.2.6-10 So I propose to change requires - patch attached, remove 10.2.7 custom build from mkosek/freeipa-master repo and add new build(for f22) based on pki-core-10.2.6-10.fc23 from koji[3] [1] https://fedorahosted.org/pki/ticket/1414 [2] https://fedorahosted.org/pki/ticket/1580 [3] http://koji.fedoraproject.org/koji/buildinfo?buildID=689985 [4] https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/121544/ -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0923-change-pki-core-required-version-for-replica-promoti.patch Type: text/x-patch Size: 1132 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 22 11:18:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 13:18:56 +0200 Subject: [Freeipa-devel] [0089] fix class teardown in user plugin tests In-Reply-To: <562624BB.8090108@redhat.com> References: <562624BB.8090108@redhat.com> Message-ID: <5628C620.20400@redhat.com> On 20.10.2015 13:25, Martin Babinsky wrote: > fixes https://fedorahosted.org/freeipa/ticket/5368 > > > Pushed to: master: af1f6721e1941af2012d38e1e8f628eef7ec014f ipa-4-2: 1573d3a81ecd55547bbc1f9b59fd84b0095e3565 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 22 11:22:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 13:22:58 +0200 Subject: [Freeipa-devel] [0089] fix class teardown in user plugin tests In-Reply-To: <5628C620.20400@redhat.com> References: <562624BB.8090108@redhat.com> <5628C620.20400@redhat.com> Message-ID: <5628C712.4060701@redhat.com> On 22.10.2015 13:18, Martin Basti wrote: > > > On 20.10.2015 13:25, Martin Babinsky wrote: >> fixes https://fedorahosted.org/freeipa/ticket/5368 >> >> >> > Pushed to: > master: af1f6721e1941af2012d38e1e8f628eef7ec014f > ipa-4-2: 1573d3a81ecd55547bbc1f9b59fd84b0095e3565 > > > I forgot to write ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Oct 22 11:30:22 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Oct 2015 13:30:22 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5627E70A.6040308@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> <562678C0.9010407@redhat.com> <5627B358.7010203@redhat.com> <5627E67A.4010809@redhat.com> <5627E70A.6040308@redhat.com> Message-ID: <5628C8CE.1000501@redhat.com> On 10/21/2015 09:27 PM, Simo Sorce wrote: > On 21/10/15 15:24, Simo Sorce wrote: >> On 21/10/15 11:46, Martin Babinsky wrote: >>> On 10/20/2015 07:24 PM, Simo Sorce wrote: >>>> On 20/10/15 06:32, Martin Babinsky wrote: >>>>> On 10/15/2015 08:14 PM, Simo Sorce wrote: >>>>>> On 15/10/15 11:39, Martin Basti wrote: >>>>>>> Without this patch the ipa-ca-install is broken in current master. >>>>>>> Unexpected error - see /var/log/ipareplica-ca-install.log for >>>>>>> details: >>>>>>> AttributeError: Values instance has no attribute 'promote' >>>>>> >>>>>> Should be fixed with the attached patches. >>>>>> >>>>>> >>>>>> >>>>> NACK, in patch 551 you add a test for non-existent CLI option into >>>>> main >>>>> method: >>>>> >>>>> @@ -198,10 +251,20 @@ def main(): >>>>> if os.geteuid() != 0: >>>>> sys.exit("\nYou must be root to run this script.\n") >>>>> >>>>> - if filename is not None: >>>>> - install_replica(safe_options, options, filename) >>>>> - else: >>>>> - install_master(safe_options, options) >>>>> + try: >>>>> + if options.replica or filename is not None: >>>>> + install_replica(safe_options, options, filename) >>>>> + else: >>>>> + install_master(safe_options, options) >>>>> + >>>>> + finally: >>>>> + # Clean up if we created custom credentials >>>>> + created_ccache_file = getattr(options, 'created_ccache_file', >>>>> None) >>>>> + if created_ccache_file is not None: >>>>> + try: >>>>> + os.unlink(created_ccache_file) >>>>> + except OSError: >>>>> + pass >>>>> >>>>> I guess you wanted to add '--replica' option to the CA installer but >>>>> since it was not added to option parser the installer explodes. >>>>> >>>>> # ipa-ca-install >>>>> >>>>> Your system may be partly configured. >>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>> >>>>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>>>> AttributeError: Values instance has no attribute 'replica' >>>>> >>>> >>>> The attached patch should address this problem now. >>>> >>>> Simo. >>>> >>> >>> Thanks, the patch enables CA install on promoted replica. >>> >>> I have one minor nitpick though: >>> >>> When running ipa-ca-install on domain level 0 replica w/o replica file, >>> the installer issues the following error: >>> >>> # ipa-ca-install >>> Replica file None does not exist >>> >>> I guess you should separately handle the case when no replica file is >>> specified and issue a corresponding error message like "A replica file >>> is required". >> >> Done. >> Simo. > > Scratch this, it contains a typo, see attached. > > Simo. > > > Thanks, ACK for patch 551-6. I will continue the review of patch 552 when we'll have a dogtag build with fix for https://fedorahosted.org/pki/ticket/1580 in copr repo. -- Martin^3 Babinsky From mbasti at redhat.com Thu Oct 22 11:42:34 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 13:42:34 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5628C8CE.1000501@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> <562678C0.9010407@redhat.com> <5627B358.7010203@redhat.com> <5627E67A.4010809@redhat.com> <5627E70A.6040308@redhat.com> <5628C8CE.1000501@redhat.com> Message-ID: <5628CBAA.9010709@redhat.com> On 22.10.2015 13:30, Martin Babinsky wrote: > On 10/21/2015 09:27 PM, Simo Sorce wrote: >> On 21/10/15 15:24, Simo Sorce wrote: >>> On 21/10/15 11:46, Martin Babinsky wrote: >>>> On 10/20/2015 07:24 PM, Simo Sorce wrote: >>>>> On 20/10/15 06:32, Martin Babinsky wrote: >>>>>> On 10/15/2015 08:14 PM, Simo Sorce wrote: >>>>>>> On 15/10/15 11:39, Martin Basti wrote: >>>>>>>> Without this patch the ipa-ca-install is broken in current master. >>>>>>>> Unexpected error - see /var/log/ipareplica-ca-install.log for >>>>>>>> details: >>>>>>>> AttributeError: Values instance has no attribute 'promote' >>>>>>> >>>>>>> Should be fixed with the attached patches. >>>>>>> >>>>>>> >>>>>>> >>>>>> NACK, in patch 551 you add a test for non-existent CLI option into >>>>>> main >>>>>> method: >>>>>> >>>>>> @@ -198,10 +251,20 @@ def main(): >>>>>> if os.geteuid() != 0: >>>>>> sys.exit("\nYou must be root to run this script.\n") >>>>>> >>>>>> - if filename is not None: >>>>>> - install_replica(safe_options, options, filename) >>>>>> - else: >>>>>> - install_master(safe_options, options) >>>>>> + try: >>>>>> + if options.replica or filename is not None: >>>>>> + install_replica(safe_options, options, filename) >>>>>> + else: >>>>>> + install_master(safe_options, options) >>>>>> + >>>>>> + finally: >>>>>> + # Clean up if we created custom credentials >>>>>> + created_ccache_file = getattr(options, >>>>>> 'created_ccache_file', >>>>>> None) >>>>>> + if created_ccache_file is not None: >>>>>> + try: >>>>>> + os.unlink(created_ccache_file) >>>>>> + except OSError: >>>>>> + pass >>>>>> >>>>>> I guess you wanted to add '--replica' option to the CA installer but >>>>>> since it was not added to option parser the installer explodes. >>>>>> >>>>>> # ipa-ca-install >>>>>> >>>>>> Your system may be partly configured. >>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>>> >>>>>> Unexpected error - see /var/log/ipareplica-ca-install.log for >>>>>> details: >>>>>> AttributeError: Values instance has no attribute 'replica' >>>>>> >>>>> >>>>> The attached patch should address this problem now. >>>>> >>>>> Simo. >>>>> >>>> >>>> Thanks, the patch enables CA install on promoted replica. >>>> >>>> I have one minor nitpick though: >>>> >>>> When running ipa-ca-install on domain level 0 replica w/o replica >>>> file, >>>> the installer issues the following error: >>>> >>>> # ipa-ca-install >>>> Replica file None does not exist >>>> >>>> I guess you should separately handle the case when no replica file is >>>> specified and issue a corresponding error message like "A replica file >>>> is required". >>> >>> Done. >>> Simo. >> >> Scratch this, it contains a typo, see attached. >> >> Simo. >> >> >> > Thanks, ACK for patch 551-6. > > I will continue the review of patch 552 when we'll have a dogtag build > with fix for https://fedorahosted.org/pki/ticket/1580 in copr repo. > Pushed to master: 958996b9cc55b6e9ecdc23981e79599ec6826b4c From pvoborni at redhat.com Thu Oct 22 12:01:22 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 22 Oct 2015 14:01:22 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5628C8CE.1000501@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> <562678C0.9010407@redhat.com> <5627B358.7010203@redhat.com> <5627E67A.4010809@redhat.com> <5627E70A.6040308@redhat.com> <5628C8CE.1000501@redhat.com> Message-ID: <5628D012.80406@redhat.com> On 10/22/2015 01:30 PM, Martin Babinsky wrote: > On 10/21/2015 09:27 PM, Simo Sorce wrote: snip >> >> > Thanks, ACK for patch 551-6. > > I will continue the review of patch 552 when we'll have a dogtag build > with fix for https://fedorahosted.org/pki/ticket/1580 in copr repo. > Martin, could you try it with a plan outlined in http://www.redhat.com/archives/freeipa-devel/2015-October/msg00342.html with a copr build: https://copr.fedoraproject.org/coprs/pvoborni/freeipa-test/build/129440/ -- Petr Vobornik From mbabinsk at redhat.com Thu Oct 22 12:03:30 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Oct 2015 14:03:30 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5628D012.80406@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <56261852.8090603@redhat.com> <562678C0.9010407@redhat.com> <5627B358.7010203@redhat.com> <5627E67A.4010809@redhat.com> <5627E70A.6040308@redhat.com> <5628C8CE.1000501@redhat.com> <5628D012.80406@redhat.com> Message-ID: <5628D092.2000609@redhat.com> On 10/22/2015 02:01 PM, Petr Vobornik wrote: > On 10/22/2015 01:30 PM, Martin Babinsky wrote: >> On 10/21/2015 09:27 PM, Simo Sorce wrote: > > snip > >>> >>> >> Thanks, ACK for patch 551-6. >> >> I will continue the review of patch 552 when we'll have a dogtag build >> with fix for https://fedorahosted.org/pki/ticket/1580 in copr repo. >> > > Martin, could you try it with a plan outlined in > http://www.redhat.com/archives/freeipa-devel/2015-October/msg00342.html > > with a copr build: > > https://copr.fedoraproject.org/coprs/pvoborni/freeipa-test/build/129440/ I'm on it. -- Martin^3 Babinsky From mbasti at redhat.com Thu Oct 22 12:10:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 14:10:13 +0200 Subject: [Freeipa-devel] [PATCH 0057] Warn in no installation found when running ipa-server-install --uninstall In-Reply-To: References: <561B5786.8070207@redhat.com> <561CA554.505@redhat.com> <561CA707.3050800@redhat.com> <562750CC.3030100@redhat.com> Message-ID: <5628D225.1030705@redhat.com> On 22.10.2015 01:28, Gabe Alford wrote: > Thanks Martin^2. Updated patched attached. > > On Wed, Oct 21, 2015 at 2:46 AM, Martin Basti > wrote: > > > > On 20.10.2015 05:17, Gabe Alford wrote: >> Bump for re-review. > > Hello, > > thank your for your patch, the patch LGTM, but please use print() > as function to be python2/3 compatible > > Martin^2 > >> >> On Tue, Oct 13, 2015 at 7:15 AM, Gabe Alford >> > wrote: >> >> No worries Petr. All a part of the review process. >> >> I have attached an updated patch that prints only a warning >> message. >> >> thanks, >> >> Gabe >> >> On Tue, Oct 13, 2015 at 12:39 AM, Petr Spacek >> > wrote: >> >> Hello Gabe, >> >> I would like to apologize for the confusion regarding >> this patch and the >> repeated reworking. >> >> Unfortunately Honza's position is not mentioned in the >> ticket so you could not >> know what to do, but Honza is our "installer architect" >> so he has final say. >> >> Petr^2 Spacek >> >> On 13.10.2015 08:31, Jan Cholasta wrote: >> > Hi, >> > >> > I don't think this is the correct approach. We are >> aiming to have idempotent >> > installers, which means that running uninstall on a >> system without IPA >> > installed should be a no-op. This is the current >> behavior, so your patch is >> > actually moving us back. >> > >> > The proper fix would be to *remove* the check from >> install (as opposed to >> > adding it to uninstall), but this requires the install >> code to be idempotent, >> > and we're not there yet. >> > >> > I'm OK with making this a warning, but don't make it a >> fatal error and/or >> > require --force. >> > >> > Honza >> > >> > On 12.10.2015 17:12, Gabe Alford wrote: >> >> Thanks, Petr. Updated patch attached. >> >> >> >> Gabe >> >> >> >> On Mon, Oct 12, 2015 at 12:47 AM, Petr Spacek >> >> >> > >> wrote: >> >> >> >> Hello Gabe, >> >> >> >> thank you for your patch! >> >> >> >> Please note that there might be a case where detection >> >> is_ipa_configured() is >> >> broken but the user still needs to run the >> uninstall process to >> >> clean it up. >> >> >> >> Could you amend the patch to respect --force >> option? In that case the >> >> detection should be skipped. >> >> >> >> Thank you for your time! >> >> >> >> Petr^2 Spacek >> >> >> >> On 9.10.2015 19:17, Gabe Alford wrote: >> >> > diff --git a/ipaserver/install/server/install.py >> >> b/ipaserver/install/server/install.py >> >> > index >> >> >> >> >> 13a59a0e6149dc22ded4a895db02516e9360e02b..ca93e7a6fd7276d9c0d82eb6f94575730759d858 >> >> >> >> 100644 >> >> > --- a/ipaserver/install/server/install.py >> >> > +++ b/ipaserver/install/server/install.py >> >> > @@ -954,6 +954,12 @@ def >> uninstall_check(installer): >> >> > >> >> > installer._installation_cleanup = False >> >> > >> >> > + if not is_ipa_configured(): >> >> > + print("IPA server is not configured on >> this system.\n" + >> >> > + "If you want to install the IPA >> server, please >> >> install " + >> >> > + "it using 'ipa-server-install'.") >> >> > + sys.exit(1) >> >> > + >> >> > fstore = >> sysrestore.FileStore(SYSRESTORE_DIR_PATH) >> >> > sstore = >> sysrestore.StateFile(SYSRESTORE_DIR_PATH) >> >> >> >> >> > > ACK Pushed to: master: a0b8415236addf0ff32b9e05b2491d626d483171 ipa-4-2: 85dc0c2e3a396ff7d8d429a414b717cc01231b26 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu Oct 22 12:13:03 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 22 Oct 2015 14:13:03 +0200 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests Message-ID: <5628D2CF.2000107@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0011-replica-promotion-changes-in-tests.patch Type: text/x-patch Size: 5499 bytes Desc: not available URL: From pspacek at redhat.com Thu Oct 22 12:15:55 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 14:15:55 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <56266209.8060705@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> <56250369.3090400@redhat.com> <56264F5B.6080109@redhat.com> <56266209.8060705@redhat.com> Message-ID: <5628D37B.80908@redhat.com> On 20.10.2015 17:47, Martin Babinsky wrote: > + def check_domainlevel(self, api): > + domain_level = dsinstance.get_domain_level(api) > + if domain_level > MIN_DOMAIN_LEVEL: > + raise RuntimeError( > + UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE.format( > + command_name=self.command_name, > + min_domain_level=MIN_DOMAIN_LEVEL, > + curr_domain_level=domain_level) > + ) NACK. This is very very weird function because it compares two values which are not passed as parameters, and also the parameter "api" seems to be unused. At very least a explanatory doc string is needed, but a new name might be even better. Check domain level of what against what? It would be great if function name could answer this question. -- Petr^2 Spacek From tbabej at redhat.com Thu Oct 22 12:24:31 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 22 Oct 2015 14:24:31 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <5628D37B.80908@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> <56250369.3090400@redhat.com> <56264F5B.6080109@redhat.com> <56266209.8060705@redhat.com> <5628D37B.80908@redhat.com> Message-ID: <5628D57F.1010607@redhat.com> On 10/22/2015 02:15 PM, Petr Spacek wrote: > On 20.10.2015 17:47, Martin Babinsky wrote: >> + def check_domainlevel(self, api): >> + domain_level = dsinstance.get_domain_level(api) >> + if domain_level > MIN_DOMAIN_LEVEL: >> + raise RuntimeError( >> + UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE.format( >> + command_name=self.command_name, >> + min_domain_level=MIN_DOMAIN_LEVEL, >> + curr_domain_level=domain_level) >> + ) > > NACK. > > This is very very weird function because it compares two values which are not > passed as parameters, and also the parameter "api" seems to be unused. > > At very least a explanatory doc string is needed, but a new name might be even > better. > > Check domain level of what against what? It would be great if function name > could answer this question. > Also note we have a dedicated exception InvalidDomainLevelError which should be used in such situations. Additionally, I'm not sure if putting this huge blob of text (with instructions) into the exception is the best way forward, imho we can either document it somewhere else ('ipa help something?' wiki?) and reference it here. Alternatively, we can just use a logger to log these instructions instead of passing them in the exception itself. HTH, Tomas From pspacek at redhat.com Thu Oct 22 12:29:45 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 14:29:45 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <5628D57F.1010607@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> <56250369.3090400@redhat.com> <56264F5B.6080109@redhat.com> <56266209.8060705@redhat.com> <5628D37B.80908@redhat.com> <5628D57F.1010607@redhat.com> Message-ID: <5628D6B9.5090703@redhat.com> On 22.10.2015 14:24, Tomas Babej wrote: > > > On 10/22/2015 02:15 PM, Petr Spacek wrote: >> On 20.10.2015 17:47, Martin Babinsky wrote: >>> + def check_domainlevel(self, api): >>> + domain_level = dsinstance.get_domain_level(api) >>> + if domain_level > MIN_DOMAIN_LEVEL: >>> + raise RuntimeError( >>> + UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE.format( >>> + command_name=self.command_name, >>> + min_domain_level=MIN_DOMAIN_LEVEL, >>> + curr_domain_level=domain_level) >>> + ) >> >> NACK. >> >> This is very very weird function because it compares two values which are not >> passed as parameters, and also the parameter "api" seems to be unused. >> >> At very least a explanatory doc string is needed, but a new name might be even >> better. >> >> Check domain level of what against what? It would be great if function name >> could answer this question. >> > > Also note we have a dedicated exception InvalidDomainLevelError which > should be used in such situations. > > Additionally, I'm not sure if putting this huge blob of text (with > instructions) into the exception is the best way forward, imho we can > either document it somewhere else ('ipa help something?' wiki?) and > reference it here. > > Alternatively, we can just use a logger to log these instructions > instead of passing them in the exception itself. One more point: + if domain_level > MIN_DOMAIN_LEVEL: + raise RuntimeError( + UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE.format( It is kind of weird that error happens if domain level is greater than some minimal value. Better naming is badly needed. -- Petr^2 Spacek From mbasti at redhat.com Thu Oct 22 12:35:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 14:35:01 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <5628D6B9.5090703@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> <56250369.3090400@redhat.com> <56264F5B.6080109@redhat.com> <56266209.8060705@redhat.com> <5628D37B.80908@redhat.com> <5628D57F.1010607@redhat.com> <5628D6B9.5090703@redhat.com> Message-ID: <5628D7F5.8020602@redhat.com> On 22.10.2015 14:29, Petr Spacek wrote: > On 22.10.2015 14:24, Tomas Babej wrote: >> >> On 10/22/2015 02:15 PM, Petr Spacek wrote: >>> On 20.10.2015 17:47, Martin Babinsky wrote: >>>> + def check_domainlevel(self, api): >>>> + domain_level = dsinstance.get_domain_level(api) >>>> + if domain_level > MIN_DOMAIN_LEVEL: >>>> + raise RuntimeError( >>>> + UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE.format( >>>> + command_name=self.command_name, >>>> + min_domain_level=MIN_DOMAIN_LEVEL, >>>> + curr_domain_level=domain_level) >>>> + ) >>> NACK. >>> >>> This is very very weird function because it compares two values which are not >>> passed as parameters, and also the parameter "api" seems to be unused. >>> >>> At very least a explanatory doc string is needed, but a new name might be even >>> better. >>> >>> Check domain level of what against what? It would be great if function name >>> could answer this question. >>> >> Also note we have a dedicated exception InvalidDomainLevelError which >> should be used in such situations. >> >> Additionally, I'm not sure if putting this huge blob of text (with >> instructions) into the exception is the best way forward, imho we can >> either document it somewhere else ('ipa help something?' wiki?) and >> reference it here. >> >> Alternatively, we can just use a logger to log these instructions >> instead of passing them in the exception itself. > One more point: > > + if domain_level > MIN_DOMAIN_LEVEL: > + raise RuntimeError( > + UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE.format( > > It is kind of weird that error happens if domain level is greater than some > minimal value. Better naming is badly needed. > I acked and pushed this patch 2 days ago, and probably my email has been lost forever, so I did bad review, please sent fix as new patch :( Original patch pushed d81260ef60b64c312e3a164e90ac4faad75c5d82 From mbasti at redhat.com Thu Oct 22 13:23:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 15:23:38 +0200 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <5628D2CF.2000107@redhat.com> References: <5628D2CF.2000107@redhat.com> Message-ID: <5628E35A.30308@redhat.com> On 22.10.2015 14:13, Oleg Fayans wrote: > > > Hello, thank you for the patch. 1) please remove the added empty lines, they are unrelated to this ticket 2) -def install_master(host, setup_dns=True, setup_kra=False): +def install_master(host, setup_dns=True, setup_kra=False, domainlevel=1): I suggest to use default domainlevel=None, which will use the default domain level (specified in build) 3) + domain_level = domainlevel(master) I do not think that this meets expectations. We have to test, both domain level 0 and 1 for IPA 4.3, respectively new IPA must support all older domain levels, domain level is independent on IPA version, only admin can raise it up. So you have to find out way how to pass the domain level for which test will be running, we were talking about using config files, but feel free to find something new and better 4) Did you resolve the pytest fixtures which specifies which tests can be run under which domain level? 5) + '--ip-address', client.ip, why this change to client install? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Oct 22 14:06:20 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 22 Oct 2015 16:06:20 +0200 Subject: [Freeipa-devel] [PATCHES] 737-742 More Python3 porting In-Reply-To: <56266C17.6040307@redhat.com> References: <56266C17.6040307@redhat.com> Message-ID: <5628ED5C.7070401@redhat.com> On 10/20/2015 06:30 PM, Petr Viktorin wrote: > Yet another batch of py3 patches. > > We're getting closer: if this was merged, my WIP branch that passes > ipapython & ipalib tests under py3 would currently be down to: > 8 files changed, 73 insertions(+), 23 deletions(-) ACK. This looks good to me, and works fine in my testing. From mbasti at redhat.com Thu Oct 22 14:13:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 16:13:21 +0200 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628A1F1.8050602@redhat.com> References: <5628A1F1.8050602@redhat.com> Message-ID: <5628EF01.3080809@redhat.com> On 22.10.2015 10:44, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5181 > > > Thank you for the patch. 1) +OPTIONAL_SERVICES = { + 'DNS', + 'CA', + 'KRA', + 'ADTRUST', + 'EXTID', + 'DNSKeyExporter', + 'DNSSEC', + 'DNSKeySync', +} This did not scale well, maybe we should improve it to use some general solution for whole IPA to distinct mandratory and optionl service, but I do not know how (or if it is possible) 2) + search_filter=('(&(objectclass=ipaConfigObject)' + '(ipaConfigString=enabledService))') Common user cannot read ipaConfigString, so this will work only for admins, I do not see any limitations of access in code for other users. 3) + opt_components = [ + r['cn'][0] for r in result if r['cn'][0] in OPTIONAL_SERVICES + ] Probably instead of indexing, you may use result.single_value['cn'] Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Oct 22 14:35:33 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 16:35:33 +0200 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628EF01.3080809@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> Message-ID: <5628F435.7070403@redhat.com> On 22.10.2015 16:13, Martin Basti wrote: > On 22.10.2015 10:44, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5181 >> >> >> > > Thank you for the patch. > > 1) > +OPTIONAL_SERVICES = { > + 'DNS', > + 'CA', > + 'KRA', > + 'ADTRUST', > + 'EXTID', > + 'DNSKeyExporter', > + 'DNSSEC', > + 'DNSKeySync', > +} > > This did not scale well, maybe we should improve it to use some general > solution for whole IPA to distinct mandratory and optionl service, but I do > not know how (or if it is possible) Personally I would not create 'generic' solution until necessary. We have too much 'generic' code which was never tested outside the single use-case we have. Let's generalize it when needed. > 2) > + search_filter=('(&(objectclass=ipaConfigObject)' > + '(ipaConfigString=enabledService))') > > Common user cannot read ipaConfigString, so this will work only for admins, I > do not see any limitations of access in code for other users. I think that this is okay. The user will see exactly what LDAP ACI allows him to see, i.e. nothing. We do the same with DNS, for example. 4) Could you extend ipa server-find with an option to search for servers with a particular optional service? I think that it would be handy to do something like $ ipa server-find --service=CA to see list of CA servers. Thank you! -- Petr^2 Spacek From pspacek at redhat.com Thu Oct 22 14:45:54 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 16:45:54 +0200 Subject: [Freeipa-devel] [PATCHES 0324 - 0325] DNSSEC: warn user if DNSSEC key master is not installed on any replica In-Reply-To: <561D3636.3030801@redhat.com> References: <561D3636.3030801@redhat.com> Message-ID: <5628F6A2.6050102@redhat.com> On 13.10.2015 18:49, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5290 > > Patches attached. ACK, thank you! -- Petr^2 Spacek From mbasti at redhat.com Thu Oct 22 14:51:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 16:51:01 +0200 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628F435.7070403@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <5628F435.7070403@redhat.com> Message-ID: <5628F7D5.4050203@redhat.com> On 22.10.2015 16:35, Petr Spacek wrote: > On 22.10.2015 16:13, Martin Basti wrote: >> On 22.10.2015 10:44, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5181 >>> >>> >>> >> Thank you for the patch. >> >> 1) >> +OPTIONAL_SERVICES = { >> + 'DNS', >> + 'CA', >> + 'KRA', >> + 'ADTRUST', >> + 'EXTID', >> + 'DNSKeyExporter', >> + 'DNSSEC', >> + 'DNSKeySync', >> +} >> >> This did not scale well, maybe we should improve it to use some general >> solution for whole IPA to distinct mandratory and optionl service, but I do >> not know how (or if it is possible) > Personally I would not create 'generic' solution until necessary. We have too > much 'generic' code which was never tested outside the single use-case we > have. Let's generalize it when needed. > > >> 2) >> + search_filter=('(&(objectclass=ipaConfigObject)' >> + '(ipaConfigString=enabledService))') >> >> Common user cannot read ipaConfigString, so this will work only for admins, I >> do not see any limitations of access in code for other users. > I think that this is okay. The user will see exactly what LDAP ACI allows him > to see, i.e. nothing. We do the same with DNS, for example. I disagree: [root at vm-065 ~]# kinit commonuser [root at vm-065 ~]# ldapsearch -Y GSSAPI -b 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' ... # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # ... # CA, vm-065.example.com, masters, ipa, etc, example.com dn: cn=CA,cn=vm-065.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com objectClass: top objectClass: nsContainer objectClass: ipaReplTopoManagedServer objectClass: ipaConfigObject objectClass: ipaSupportedDomainLevelConfig cn: CA [root at vm-065 ~]# ldapsearch -Y GSSAPI -b 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(ipaConfigString=enabledService)' ... # LDAPv3 # base with scope subtree # filter: (ipaConfigString=enabledService) # requesting: ALL # # search result search: 4 result: 0 Success So as I said, a common user has no access to ipaConfigString attribute > > > 4) Could you extend ipa server-find with an option to search for servers with > a particular optional service? I think that it would be handy to do something like > $ ipa server-find --service=CA > to see list of CA servers. > > Thank you! > From pspacek at redhat.com Thu Oct 22 14:56:46 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 16:56:46 +0200 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628F7D5.4050203@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <5628F435.7070403@redhat.com> <5628F7D5.4050203@redhat.com> Message-ID: <5628F92E.8070700@redhat.com> On 22.10.2015 16:51, Martin Basti wrote: > > > On 22.10.2015 16:35, Petr Spacek wrote: >> On 22.10.2015 16:13, Martin Basti wrote: >>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5181 >>>> >>>> >>>> >>> Thank you for the patch. >>> >>> 1) >>> +OPTIONAL_SERVICES = { >>> + 'DNS', >>> + 'CA', >>> + 'KRA', >>> + 'ADTRUST', >>> + 'EXTID', >>> + 'DNSKeyExporter', >>> + 'DNSSEC', >>> + 'DNSKeySync', >>> +} >>> >>> This did not scale well, maybe we should improve it to use some general >>> solution for whole IPA to distinct mandratory and optionl service, but I do >>> not know how (or if it is possible) >> Personally I would not create 'generic' solution until necessary. We have too >> much 'generic' code which was never tested outside the single use-case we >> have. Let's generalize it when needed. >> >> >>> 2) >>> + search_filter=('(&(objectclass=ipaConfigObject)' >>> + '(ipaConfigString=enabledService))') >>> >>> Common user cannot read ipaConfigString, so this will work only for admins, I >>> do not see any limitations of access in code for other users. >> I think that this is okay. The user will see exactly what LDAP ACI allows him >> to see, i.e. nothing. We do the same with DNS, for example. > I disagree: > > [root at vm-065 ~]# kinit commonuser > > [root at vm-065 ~]# ldapsearch -Y GSSAPI -b > 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' > ... > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > ... > # CA, vm-065.example.com, masters, ipa, etc, example.com > dn: cn=CA,cn=vm-065.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > objectClass: top > objectClass: nsContainer > objectClass: ipaReplTopoManagedServer > objectClass: ipaConfigObject > objectClass: ipaSupportedDomainLevelConfig > cn: CA > > > [root at vm-065 ~]# ldapsearch -Y GSSAPI -b > 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(ipaConfigString=enabledService)' > ... > # LDAPv3 > # base with scope subtree > # filter: (ipaConfigString=enabledService) > # requesting: ALL > # > > # search result > search: 4 > result: 0 Success > > So as I said, a common user has no access to ipaConfigString attribute I agree with you - and I believe that current behavior is not a problem. $ ipa server-show will display the same information about enabled services as LDAP search - i.e. no information :-) In other words, ordinary user cannot see if the component is enabled or not, and because the user cannot judge this we will not show the information to him. I'm fine with that. Petr^2 Spacek >> 4) Could you extend ipa server-find with an option to search for servers with >> a particular optional service? I think that it would be handy to do >> something like >> $ ipa server-find --service=CA >> to see list of CA servers. >> >> Thank you! From pspacek at redhat.com Thu Oct 22 14:59:44 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 16:59:44 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <5620CDE6.4000901@redhat.com> References: <561BC52D.6030301@redhat.com> <561CB486.2020906@redhat.com> <561CED0B.9090009@redhat.com> <561D0E76.1030709@redhat.com> <561E46FD.1020404@redhat.com> <561E612F.5090205@redhat.com> <5620CDE6.4000901@redhat.com> Message-ID: <5628F9E0.4060009@redhat.com> On 16.10.2015 12:13, Martin Babinsky wrote: > On 10/14/2015 04:05 PM, Petr Spacek wrote: >> On 14.10.2015 14:13, Martin Babinsky wrote: >>> On 10/13/2015 04:00 PM, Petr Spacek wrote: >>>> On 13.10.2015 13:37, Martin Babinsky wrote: >>>>> On 10/13/2015 09:36 AM, Petr Spacek wrote: >>>>>> On 12.10.2015 16:35, Martin Babinsky wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5200 >>>>>>> --- >>>>>>> ipalib/plugins/dns.py | 3 ++- >>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>>>> index >>>>>>> 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 >>>>>>> >>>>>>> >>>>>>> 100644 >>>>>>> --- a/ipalib/plugins/dns.py >>>>>>> +++ b/ipalib/plugins/dns.py >>>>>>> @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>>>>> if prefixlen is None: >>>>>>> revzone = None >>>>>>> >>>>>>> - result = api.Command['dnszone_find']()['result'] >>>>>>> + result = api.Command['dnszone_find'](sizelimit=0)['result'] >>>>>>> + >>>>>> >>>>>> NACK, this just increases the limit because LDAP server will enforce a >>>>>> per-user limit. >>>>>> >>>>>>> for zone in result: >>>>>>> zonename = zone['idnsname'][0] >>>>>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>>>>> >>>>>> Generic solution should use dns.resolver.zone_for_name() to find DNS zone >>>>>> matching the reverse name. This should also implicitly cover CNAME/DNAME >>>>>> redirections per RFC2317. >>>>>> >>>>>> Using DNS implicitly means that a zone will always be found (at least the >>>>>> root >>>>>> zone :-). For this reason I would change final error message >>>>>>> reason=_('DNS reverse zone for IP address %(addr)s not found') >>>>>> to something like: >>>>>> reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not >>>>>> managed >>>>>> by this server') >>>>>> >>>>>> >>>>>> These changes should fix it without adding other artificial limitation. >>>>>> >>>>> >>>>> Thank you for clarification Petr. >>>>> >>>>> Attaching the reworked patch. >>>>> >>>>> -- >>>>> Martin^3 Babinsky >>>>> >>>>> freeipa-mbabinsk-0083.1-perform-more-robust-search-for-reverse-zones-when-ad.patch >>>>> >>>>> >>>>> >>>>> >>>>> From 463903f4ea4f74efeb02dbb705ca0a54fab81366 Mon Sep 17 00:00:00 2001 >>>>> From: Martin Babinsky >>>>> Date: Mon, 12 Oct 2015 16:24:50 +0200 >>>>> Subject: [PATCH 1/3] perform more robust search for reverse zones when >>>>> adding >>>>> DNS record >>>>> >>>>> Instead of searching for all zones to identify the correct reverse zone, we >>>>> will first ask the resolver to return the name of zone that should >>>>> contain the >>>>> desired record and then see if IPA manages this zone. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5200 >>>>> --- >>>>> ipalib/plugins/dns.py | 21 +++++++++++++++++---- >>>>> 1 file changed, 17 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>> index >>>>> 84086f4c77d02922f237937d58031cc42d55410e..e3c6ce46168f8b6af607a61af1e3e431cfee32c8 >>>>> >>>>> 100644 >>>>> --- a/ipalib/plugins/dns.py >>>>> +++ b/ipalib/plugins/dns.py >>>>> @@ -531,25 +531,35 @@ def add_forward_record(zone, name, str_address): >>>>> pass # the entry already exists and matches >>>>> >>>>> def get_reverse_zone(ipaddr, prefixlen=None): >>>>> + """ >>>>> + resolve the reverse zone for IP address and see if it is managed by IPA >>>>> + server >>>>> + :param ipaddr: host IP address >>>>> + :param prefixlen: network prefix length >>>>> + :return: tuple containing name of the reverse zone and the name of the >>>>> + record >>>>> + """ >>>>> ip = netaddr.IPAddress(str(ipaddr)) >>>>> revdns = DNSName(unicode(ip.reverse_dns)) >>>>> + resolved_zone = unicode(dns.resolver.zone_for_name(revdns)) >>>>> >>>>> if prefixlen is None: >>>>> revzone = None >>>>> + result = api.Command['dnszone_find'](resolved_zone)['result'] >>>>> >>>>> - result = api.Command['dnszone_find']()['result'] >>>>> for zone in result: >>>>> zonename = zone['idnsname'][0] >>>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>>>> (revzone is None or zonename.is_subdomain(revzone))): >>>>> revzone = zonename >>>> >>>> Oh, wait, this might blow up if there is a disabled DNS zone which is deeper >>>> than the one returned from DNS query. >>>> >>>> Damn, we have opened a Pandora box! >>>> >>>> ipaserver/install/bindinstance.py has own implementation of >>>> get_reverse_zone() >>>> + additional menthods find_reverse_zone(). >>>> These are using get_reverse_zone_default() from ipalib/util.py which is >>>> duplicating code in 'if prefixlen is not None' branch. >>>> >>>> And of course, are not correct in light of this change. >>>> >>>> My expectation would be that disabled zones should be ignored... So we should >>>> get rid of this mess in the loop and use dnszone_show() which is called at >>>> the >>>> end. And fix the other places, preferably by deleting duplicate >>>> implementations. >>>> >>>> I would expect that you can store (converted) output of >>>> dns.resolver.zone_for_name(revdns) into revzone and delete whole 'if >>>> prefixlen >>>> is None' branch. >>>> >>>>> else: >>>>> + # if prefixlen is specified, determine the zone name for the >>>>> network >>>>> + # prefix >>>>> if ip.version == 4: >>>>> pos = 4 - prefixlen / 8 >>>>> elif ip.version == 6: >>>>> pos = 32 - prefixlen / 4 >>>>> - items = ip.reverse_dns.split('.') >>>>> - revzone = DNSName(items[pos:]) >>>>> + revzone = revdns[pos:] >>>> >>>> Hmm, and this logic will breaks CNAME/DNAME (RFC2317) handling ... Damn, we >>>> need different handling when we intend to create the zone and when we want to >>>> manipulate a record in a reverse zone. Grrr. >>>> >>>> When we want to manipulate a record in existing zone, the whole branch does >>>> not make sense and the result of DNS query is what we want and need. >>>> >>>> On the other hand, we need this when creating *a new zone* from IP address >>>> ... >>>> >>>> Mastin^2, what about zone names with missing period at the end? Is it handled >>>> by dnszone_show() internally? >>>> >>>> We have to discuss all this... >>>> >>>>> try: >>>>> api.Command['dnszone_show'](revzone) >>>>> @@ -558,7 +568,10 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>>> >>>>> if revzone is None: >>>>> raise errors.NotFound( >>>>> - reason=_('DNS reverse zone for IP address %(addr)s not found') >>>>> % dict(addr=ipaddr) >>>>> + reason=_( >>>>> + 'DNS reverse zone %(resolved_zone)s for IP address ' >>>>> + '%(addr)s is not manager by this server') % dict( >>>> typo s/manager/managed/ >>>> >>>>> + addr=ipaddr, resolved_zone=resolved_zone) >>>>> ) >>>>> >>>>> revname = revdns.relativize(revzone) >>>> >>> >>> After lengthy discussion with Petr^2 I we decided to rework get_reverse_zone >>> function a bit. Attaching updated patch. >> >> Well, we should get rid of prefixlen parameter. Wipe it from Earth's >> surface! :-) >> >> The assumption here is that this function is always used only for manipulating >> *records in existing zones*, so the only way to find appropriate reverse zone >> name is to ask DNS. >> >> Derivation based on prefix length makes sense only for deriving reverse zone >> names from IP addresses *with intent to create the zone*. >> >> In all other cases it does not make sense to use prefix. I'm sorry that I was >> not clear. >> > Upon Thy request I purged the Function that Gets the Name of the Zone Reverse > of the crawling evil thee caleth the Prefixlen. > > The shallow impostor of The Function whose services no Module required nor > used was also banished to oblivion and His noisome vapors shall bother the > Kingdom of Identity no more. > > Thou shalt rejoice when Thy review the rewritten Patch attached herein or else > I shall be smitten by the mighty NACK thee wieldeth. Mighty ACK! :-D Thank you for your patience with me. -- Petr^2 Spacek From mbasti at redhat.com Thu Oct 22 15:02:06 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 17:02:06 +0200 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628F92E.8070700@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <5628F435.7070403@redhat.com> <5628F7D5.4050203@redhat.com> <5628F92E.8070700@redhat.com> Message-ID: <5628FA6E.9050605@redhat.com> On 22.10.2015 16:56, Petr Spacek wrote: > On 22.10.2015 16:51, Martin Basti wrote: >> >> On 22.10.2015 16:35, Petr Spacek wrote: >>> On 22.10.2015 16:13, Martin Basti wrote: >>>> On 22.10.2015 10:44, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5181 >>>>> >>>>> >>>>> >>>> Thank you for the patch. >>>> >>>> 1) >>>> +OPTIONAL_SERVICES = { >>>> + 'DNS', >>>> + 'CA', >>>> + 'KRA', >>>> + 'ADTRUST', >>>> + 'EXTID', >>>> + 'DNSKeyExporter', >>>> + 'DNSSEC', >>>> + 'DNSKeySync', >>>> +} >>>> >>>> This did not scale well, maybe we should improve it to use some general >>>> solution for whole IPA to distinct mandratory and optionl service, but I do >>>> not know how (or if it is possible) >>> Personally I would not create 'generic' solution until necessary. We have too >>> much 'generic' code which was never tested outside the single use-case we >>> have. Let's generalize it when needed. >>> >>> >>>> 2) >>>> + search_filter=('(&(objectclass=ipaConfigObject)' >>>> + '(ipaConfigString=enabledService))') >>>> >>>> Common user cannot read ipaConfigString, so this will work only for admins, I >>>> do not see any limitations of access in code for other users. >>> I think that this is okay. The user will see exactly what LDAP ACI allows him >>> to see, i.e. nothing. We do the same with DNS, for example. >> I disagree: >> >> [root at vm-065 ~]# kinit commonuser >> >> [root at vm-065 ~]# ldapsearch -Y GSSAPI -b >> 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' >> ... >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> ... >> # CA, vm-065.example.com, masters, ipa, etc, example.com >> dn: cn=CA,cn=vm-065.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> objectClass: top >> objectClass: nsContainer >> objectClass: ipaReplTopoManagedServer >> objectClass: ipaConfigObject >> objectClass: ipaSupportedDomainLevelConfig >> cn: CA >> >> >> [root at vm-065 ~]# ldapsearch -Y GSSAPI -b >> 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(ipaConfigString=enabledService)' >> ... >> # LDAPv3 >> # base with scope subtree >> # filter: (ipaConfigString=enabledService) >> # requesting: ALL >> # >> >> # search result >> search: 4 >> result: 0 Success >> >> So as I said, a common user has no access to ipaConfigString attribute > I agree with you - and I believe that current behavior is not a problem. > > $ ipa server-show will display the same information about enabled services as > LDAP search - i.e. no information :-) > > In other words, ordinary user cannot see if the component is enabled or not, > and because the user cannot judge this we will not show the information to > him. I'm fine with that. > > Petr^2 Spacek > Okay, I missed your point, I understand now and I'm agree that only admin or more privileged users are able to see services. >>> 4) Could you extend ipa server-find with an option to search for servers with >>> a particular optional service? I think that it would be handy to do >>> something like >>> $ ipa server-find --service=CA >>> to see list of CA servers. >>> >>> Thank you! From mbasti at redhat.com Thu Oct 22 15:29:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 17:29:01 +0200 Subject: [Freeipa-devel] Freeipa domain levels naming Message-ID: <562900BD.2000104@redhat.com> Hello all, in current master branch we have mixed usage of literals 0, 1 and constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. I suggest to use names for domain levels: COMPAT_DOMAIN_LEVEL = 0 PROMOTION_DOMAIN_LEVEL = 1 UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) Benefits: * ability to grep it in code * better readability in code Martin^2 From pspacek at redhat.com Thu Oct 22 15:32:06 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 17:32:06 +0200 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <5627B576.9060003@redhat.com> References: <561B9B9F.90002@redhat.com> <561CB013.2080406@redhat.com> <5627B576.9060003@redhat.com> Message-ID: <56290176.5030303@redhat.com> On 21.10.2015 17:55, Martin Babinsky wrote: > On 10/13/2015 09:17 AM, Petr Spacek wrote: >> On 12.10.2015 13:38, Martin Babinsky wrote: >>> >>> each service possessing Kerberos keytab wiil now remove it and destroy any >>> associated credentials cache during its uninstall >>> >>> https://fedorahosted.org/freeipa/ticket/5243 >> >> BTW some time ago Simo proposed that we should remove caches and old keytabs >> during *install* so problems caused by failing uninstallation will be fixed on >> repeated install. This is yet another step towards idempotent installer. >> >> To me this makes more sense than doing so on uninstall. Does it make sense to >> you, too? >> > > Attaching updated patch that does cleanup also before each instance creation. > It is a bit ugly I admit, but I couldn't think of a better way to do it and > didn't want to poke into service/instance code more than neccesary. NACK, but we are almost there! * kdestroy -A is too aggressive and wipes root's keyring after each run of ipa-*-install utils. * There are some scattered leftovers of ipautil.run['kdestroy'...] in the tree. Please get rid of them. Thank you! -- Petr^2 Spacek From pspacek at redhat.com Thu Oct 22 15:36:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 17:36:59 +0200 Subject: [Freeipa-devel] [PATCH 0328] DNSSEC CI: Wait until DS records are replicated In-Reply-To: <56210F0C.9060206@redhat.com> References: <56210F0C.9060206@redhat.com> Message-ID: <5629029B.5030105@redhat.com> On 16.10.2015 16:51, Martin Basti wrote: > Drill command sometimes fail on replica due to long replication time, this > patch adding check that waits until record is replicated. > > Patch attached. ACK -- Petr^2 Spacek From mbasti at redhat.com Thu Oct 22 15:38:11 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 17:38:11 +0200 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <5628E35A.30308@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> Message-ID: <562902E3.8020707@redhat.com> On 22.10.2015 15:23, Martin Basti wrote: > > On 22.10.2015 14:13, Oleg Fayans wrote: >> >> >> > > Hello, > > thank you for the patch. > > 1) > please remove the added empty lines, they are unrelated to this ticket > > 2) > -def install_master(host, setup_dns=True, setup_kra=False): > +def install_master(host, setup_dns=True, setup_kra=False, domainlevel=1): > > I suggest to use default domainlevel=None, which will use the default > domain level (specified in build) > > 3) > + domain_level = domainlevel(master) > I do not think that this meets expectations. > > We have to test, both domain level 0 and 1 for IPA 4.3, respectively > new IPA must support all older domain levels, domain level is > independent on IPA version, only admin can raise it up. > > So you have to find out way how to pass the domain level for which > test will be running, we were talking about using config files, but > feel free to find something new and better > > 4) > Did you resolve the pytest fixtures which specifies which tests can be > run under which domain level? > > 5) > + '--ip-address', client.ip, > > why this change to client install? > > Martin^2 > > 6) ************* Module ipatests.test_integration.tasks ipatests/test_integration/tasks.py:85: [E1123(unexpected-keyword-arg), allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function call) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Oct 22 15:41:13 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 17:41:13 +0200 Subject: [Freeipa-devel] Freeipa domain levels naming In-Reply-To: <562900BD.2000104@redhat.com> References: <562900BD.2000104@redhat.com> Message-ID: <56290399.40704@redhat.com> On 22.10.2015 17:29, Martin Basti wrote: > Hello all, > > in current master branch we have mixed usage of literals 0, 1 and constants > MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. > > I suggest to use names for domain levels: > > COMPAT_DOMAIN_LEVEL = 0 > PROMOTION_DOMAIN_LEVEL = 1 > UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 > > MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) > MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) > > Benefits: > * ability to grep it in code > * better readability in code I very much agree. If you want to see the reason with naked eye, see [PATCH 0086] disable ipa-replica prepare in non-zero domain levels Without additional constants we will end up with checks like: + domain_level = dsinstance.get_domain_level(api) + if domain_level > MIN_DOMAIN_LEVEL: + raise RuntimeError( Fail if domain_level is higher than MIN_DOMAIN_LEVEL? What? Even worse, bad things will happen in future when we decide to drop support for domain level 0 etc. Of course, using literals 0, 1, etc. is an option, but I do not like it very much. Again, when we drop support for a particular level we need a way to clean up the code, so named constant seems like a way to go. -- Petr^2 Spacek From mbasti at redhat.com Thu Oct 22 15:42:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 17:42:10 +0200 Subject: [Freeipa-devel] [PATCH 0333] DNSSEC installer: store status of services only for first time Message-ID: <562903D2.20700@redhat.com> After reinstall the wrong status has been saved, we do care only about service status before first installation. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0333-DNSSEC-store-status-of-services-only-before-first-in.patch Type: text/x-patch Size: 2387 bytes Desc: not available URL: From pspacek at redhat.com Thu Oct 22 15:48:42 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 17:48:42 +0200 Subject: [Freeipa-devel] [PATCH 0333] DNSSEC installer: store status of services only for first time In-Reply-To: <562903D2.20700@redhat.com> References: <562903D2.20700@redhat.com> Message-ID: <5629055A.9090608@redhat.com> On 22.10.2015 17:42, Martin Basti wrote: > After reinstall the wrong status has been saved, we do care only about service > status before first installation. > > Patch attached. ACK -- Petr^2 Spacek From simo at redhat.com Thu Oct 22 15:49:41 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Oct 2015 11:49:41 -0400 Subject: [Freeipa-devel] Freeipa domain levels naming In-Reply-To: <562900BD.2000104@redhat.com> References: <562900BD.2000104@redhat.com> Message-ID: <56290595.9090602@redhat.com> On 22/10/15 11:29, Martin Basti wrote: > Hello all, > > in current master branch we have mixed usage of literals 0, 1 and > constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. > > I suggest to use names for domain levels: > > COMPAT_DOMAIN_LEVEL = 0 > PROMOTION_DOMAIN_LEVEL = 1 > UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 > > MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) > MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) > > Benefits: > * ability to grep it in code Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 > * better readability in code Sure, but random names are not appropriate imo > Martin^2 > > > -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Thu Oct 22 15:51:10 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Oct 2015 17:51:10 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <561FED16.5060604@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> Message-ID: <562905EE.5000801@redhat.com> On 10/15/2015 08:14 PM, Simo Sorce wrote: > On 15/10/15 11:39, Martin Basti wrote: >> Without this patch the ipa-ca-install is broken in current master. >> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >> AttributeError: Values instance has no attribute 'promote' > > Should be fixed with the attached patches. > > > Patch 552-1 ACK. BTW our combined reviewer/patch splitter skills broke master build today (see https://fedorahosted.org/freeipa/ticket/5393) so this patch should probably be pushed ASAP. -- Martin^3 Babinsky From pvoborni at redhat.com Thu Oct 22 15:53:53 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 22 Oct 2015 17:53:53 +0200 Subject: [Freeipa-devel] Freeipa domain levels naming In-Reply-To: <56290595.9090602@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> Message-ID: <56290691.3070003@redhat.com> On 10/22/2015 05:49 PM, Simo Sorce wrote: > On 22/10/15 11:29, Martin Basti wrote: >> Hello all, >> >> in current master branch we have mixed usage of literals 0, 1 and >> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >> >> I suggest to use names for domain levels: >> >> COMPAT_DOMAIN_LEVEL = 0 >> PROMOTION_DOMAIN_LEVEL = 1 >> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >> >> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >> >> Benefits: >> * ability to grep it in code > > Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 +1 > >> * better readability in code > > Sure, but random names are not appropriate imo > >> Martin^2 >> -- Petr Vobornik From mbasti at redhat.com Thu Oct 22 15:54:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 17:54:29 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <562905EE.5000801@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <562905EE.5000801@redhat.com> Message-ID: <562906B5.3040805@redhat.com> On 22.10.2015 17:51, Martin Babinsky wrote: > On 10/15/2015 08:14 PM, Simo Sorce wrote: >> On 15/10/15 11:39, Martin Basti wrote: >>> Without this patch the ipa-ca-install is broken in current master. >>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>> AttributeError: Values instance has no attribute 'promote' >> >> Should be fixed with the attached patches. >> >> >> > > Patch 552-1 ACK. > > BTW our combined reviewer/patch splitter skills broke master build > today (see https://fedorahosted.org/freeipa/ticket/5393) so this patch > should probably be pushed ASAP. > Pushed to master: bc39cc9f813c35ba603b45c7dc5e9c5ba2be5743 From simo at redhat.com Thu Oct 22 16:13:25 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Oct 2015 12:13:25 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <562906B5.3040805@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561F793B.2090000@redhat.com> <561F9C2A.5020907@redhat.com> <561FC8B2.7000500@redhat.com> <561FED16.5060604@redhat.com> <562905EE.5000801@redhat.com> <562906B5.3040805@redhat.com> Message-ID: <56290B25.5000002@redhat.com> On 22/10/15 11:54, Martin Basti wrote: > > > On 22.10.2015 17:51, Martin Babinsky wrote: >> On 10/15/2015 08:14 PM, Simo Sorce wrote: >>> On 15/10/15 11:39, Martin Basti wrote: >>>> Without this patch the ipa-ca-install is broken in current master. >>>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>>> AttributeError: Values instance has no attribute 'promote' >>> >>> Should be fixed with the attached patches. >>> >>> >>> >> >> Patch 552-1 ACK. >> >> BTW our combined reviewer/patch splitter skills broke master build >> today (see https://fedorahosted.org/freeipa/ticket/5393) so this patch >> should probably be pushed ASAP. >> > Pushed to master: bc39cc9f813c35ba603b45c7dc5e9c5ba2be5743 > Thanks a lot to all involved in this review and in helping me produce and test this work. It was a sizeable amount of work and I am happy we were able to get it in relatively smoothly. Thanks all. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Oct 22 16:22:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 18:22:54 +0200 Subject: [Freeipa-devel] [PATCHES] from Debian In-Reply-To: <56127650.9010600@ubuntu.com> References: <56127650.9010600@ubuntu.com> Message-ID: <56290D5E.8070001@redhat.com> On 05.10.2015 15:08, Timo Aaltonen wrote: > Hi > > Here are a few prep patches to get off the list before getting to > discuss how to add Debian platform support.. > > ACK for patches 2, 3, 4 Pushed to master: ccae42bedae09d7380e38a67cc33f776ff9a953a -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 22 16:25:32 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 18:25:32 +0200 Subject: [Freeipa-devel] [PATCH 0328] DNSSEC CI: Wait until DS records are replicated In-Reply-To: <5629029B.5030105@redhat.com> References: <56210F0C.9060206@redhat.com> <5629029B.5030105@redhat.com> Message-ID: <56290DFC.3020109@redhat.com> On 22.10.2015 17:36, Petr Spacek wrote: > On 16.10.2015 16:51, Martin Basti wrote: >> Drill command sometimes fail on replica due to long replication time, this >> patch adding check that waits until record is replicated. >> >> Patch attached. > ACK > Pushed to: master: f2032ca2cab3048021956707ec4ff74be69108d4 ipa-4-2: edaf4665e04df2614b59e4319a62030566d1b52d From mbasti at redhat.com Thu Oct 22 16:27:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 18:27:57 +0200 Subject: [Freeipa-devel] [PATCH 0333] DNSSEC installer: store status of services only for first time In-Reply-To: <5629055A.9090608@redhat.com> References: <562903D2.20700@redhat.com> <5629055A.9090608@redhat.com> Message-ID: <56290E8D.4020203@redhat.com> On 22.10.2015 17:48, Petr Spacek wrote: > On 22.10.2015 17:42, Martin Basti wrote: >> After reinstall the wrong status has been saved, we do care only about service >> status before first installation. >> >> Patch attached. > ACK > Pushed to master: 2b01f71bef71229e5b10fa839a1844a6342b36bd From mbasti at redhat.com Thu Oct 22 16:32:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 18:32:07 +0200 Subject: [Freeipa-devel] [PATCHES 0324 - 0325] DNSSEC: warn user if DNSSEC key master is not installed on any replica In-Reply-To: <5628F6A2.6050102@redhat.com> References: <561D3636.3030801@redhat.com> <5628F6A2.6050102@redhat.com> Message-ID: <56290F87.7030907@redhat.com> On 22.10.2015 16:45, Petr Spacek wrote: > On 13.10.2015 18:49, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5290 >> >> Patches attached. > ACK, thank you! > Pushed to: master: 92a4b18fc282ab7b40899c4885617fc080e9e955 ipa-4-2: 1c173749872193b8c9234137a77f3c5400f33d2a From mbasti at redhat.com Thu Oct 22 16:35:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 18:35:25 +0200 Subject: [Freeipa-devel] [PATCHES] 737-742 More Python3 porting In-Reply-To: <5628ED5C.7070401@redhat.com> References: <56266C17.6040307@redhat.com> <5628ED5C.7070401@redhat.com> Message-ID: <5629104D.8020800@redhat.com> On 22.10.2015 16:06, Tomas Babej wrote: > On 10/20/2015 06:30 PM, Petr Viktorin wrote: >> Yet another batch of py3 patches. >> >> We're getting closer: if this was merged, my WIP branch that passes >> ipapython & ipalib tests under py3 would currently be down to: >> 8 files changed, 73 insertions(+), 23 deletions(-) > ACK. This looks good to me, and works fine in my testing. > > > Pushed to master: 6417931a9fd319166d1827d886843a4abb5c4820 From mbasti at redhat.com Thu Oct 22 16:36:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Oct 2015 18:36:46 +0200 Subject: [Freeipa-devel] [PATCH 0083] perform an unlimited search for reverse zones when adding DNS records In-Reply-To: <5628F9E0.4060009@redhat.com> References: <561BC52D.6030301@redhat.com> <561CB486.2020906@redhat.com> <561CED0B.9090009@redhat.com> <561D0E76.1030709@redhat.com> <561E46FD.1020404@redhat.com> <561E612F.5090205@redhat.com> <5620CDE6.4000901@redhat.com> <5628F9E0.4060009@redhat.com> Message-ID: <5629109E.9030105@redhat.com> On 22.10.2015 16:59, Petr Spacek wrote: > On 16.10.2015 12:13, Martin Babinsky wrote: >> On 10/14/2015 04:05 PM, Petr Spacek wrote: >>> On 14.10.2015 14:13, Martin Babinsky wrote: >>>> On 10/13/2015 04:00 PM, Petr Spacek wrote: >>>>> On 13.10.2015 13:37, Martin Babinsky wrote: >>>>>> On 10/13/2015 09:36 AM, Petr Spacek wrote: >>>>>>> On 12.10.2015 16:35, Martin Babinsky wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/5200 >>>>>>>> --- >>>>>>>> ipalib/plugins/dns.py | 3 ++- >>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>>>> >>>>>>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>>>>> index >>>>>>>> 84086f4c77d02922f237937d58031cc42d55410e..c36345faecfb9db7abced1c6bd72ddcf93473a74 >>>>>>>> >>>>>>>> >>>>>>>> 100644 >>>>>>>> --- a/ipalib/plugins/dns.py >>>>>>>> +++ b/ipalib/plugins/dns.py >>>>>>>> @@ -537,7 +537,8 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>>>>>> if prefixlen is None: >>>>>>>> revzone = None >>>>>>>> >>>>>>>> - result = api.Command['dnszone_find']()['result'] >>>>>>>> + result = api.Command['dnszone_find'](sizelimit=0)['result'] >>>>>>>> + >>>>>>> NACK, this just increases the limit because LDAP server will enforce a >>>>>>> per-user limit. >>>>>>> >>>>>>>> for zone in result: >>>>>>>> zonename = zone['idnsname'][0] >>>>>>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>>>>>> Generic solution should use dns.resolver.zone_for_name() to find DNS zone >>>>>>> matching the reverse name. This should also implicitly cover CNAME/DNAME >>>>>>> redirections per RFC2317. >>>>>>> >>>>>>> Using DNS implicitly means that a zone will always be found (at least the >>>>>>> root >>>>>>> zone :-). For this reason I would change final error message >>>>>>>> reason=_('DNS reverse zone for IP address %(addr)s not found') >>>>>>> to something like: >>>>>>> reason=_('DNS reverse zone %(zone)s for IP address %(addr)s is not >>>>>>> managed >>>>>>> by this server') >>>>>>> >>>>>>> >>>>>>> These changes should fix it without adding other artificial limitation. >>>>>>> >>>>>> Thank you for clarification Petr. >>>>>> >>>>>> Attaching the reworked patch. >>>>>> >>>>>> -- >>>>>> Martin^3 Babinsky >>>>>> >>>>>> freeipa-mbabinsk-0083.1-perform-more-robust-search-for-reverse-zones-when-ad.patch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From 463903f4ea4f74efeb02dbb705ca0a54fab81366 Mon Sep 17 00:00:00 2001 >>>>>> From: Martin Babinsky >>>>>> Date: Mon, 12 Oct 2015 16:24:50 +0200 >>>>>> Subject: [PATCH 1/3] perform more robust search for reverse zones when >>>>>> adding >>>>>> DNS record >>>>>> >>>>>> Instead of searching for all zones to identify the correct reverse zone, we >>>>>> will first ask the resolver to return the name of zone that should >>>>>> contain the >>>>>> desired record and then see if IPA manages this zone. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5200 >>>>>> --- >>>>>> ipalib/plugins/dns.py | 21 +++++++++++++++++---- >>>>>> 1 file changed, 17 insertions(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>>> index >>>>>> 84086f4c77d02922f237937d58031cc42d55410e..e3c6ce46168f8b6af607a61af1e3e431cfee32c8 >>>>>> >>>>>> 100644 >>>>>> --- a/ipalib/plugins/dns.py >>>>>> +++ b/ipalib/plugins/dns.py >>>>>> @@ -531,25 +531,35 @@ def add_forward_record(zone, name, str_address): >>>>>> pass # the entry already exists and matches >>>>>> >>>>>> def get_reverse_zone(ipaddr, prefixlen=None): >>>>>> + """ >>>>>> + resolve the reverse zone for IP address and see if it is managed by IPA >>>>>> + server >>>>>> + :param ipaddr: host IP address >>>>>> + :param prefixlen: network prefix length >>>>>> + :return: tuple containing name of the reverse zone and the name of the >>>>>> + record >>>>>> + """ >>>>>> ip = netaddr.IPAddress(str(ipaddr)) >>>>>> revdns = DNSName(unicode(ip.reverse_dns)) >>>>>> + resolved_zone = unicode(dns.resolver.zone_for_name(revdns)) >>>>>> >>>>>> if prefixlen is None: >>>>>> revzone = None >>>>>> + result = api.Command['dnszone_find'](resolved_zone)['result'] >>>>>> >>>>>> - result = api.Command['dnszone_find']()['result'] >>>>>> for zone in result: >>>>>> zonename = zone['idnsname'][0] >>>>>> if (revdns.is_subdomain(zonename.make_absolute()) and >>>>>> (revzone is None or zonename.is_subdomain(revzone))): >>>>>> revzone = zonename >>>>> Oh, wait, this might blow up if there is a disabled DNS zone which is deeper >>>>> than the one returned from DNS query. >>>>> >>>>> Damn, we have opened a Pandora box! >>>>> >>>>> ipaserver/install/bindinstance.py has own implementation of >>>>> get_reverse_zone() >>>>> + additional menthods find_reverse_zone(). >>>>> These are using get_reverse_zone_default() from ipalib/util.py which is >>>>> duplicating code in 'if prefixlen is not None' branch. >>>>> >>>>> And of course, are not correct in light of this change. >>>>> >>>>> My expectation would be that disabled zones should be ignored... So we should >>>>> get rid of this mess in the loop and use dnszone_show() which is called at >>>>> the >>>>> end. And fix the other places, preferably by deleting duplicate >>>>> implementations. >>>>> >>>>> I would expect that you can store (converted) output of >>>>> dns.resolver.zone_for_name(revdns) into revzone and delete whole 'if >>>>> prefixlen >>>>> is None' branch. >>>>> >>>>>> else: >>>>>> + # if prefixlen is specified, determine the zone name for the >>>>>> network >>>>>> + # prefix >>>>>> if ip.version == 4: >>>>>> pos = 4 - prefixlen / 8 >>>>>> elif ip.version == 6: >>>>>> pos = 32 - prefixlen / 4 >>>>>> - items = ip.reverse_dns.split('.') >>>>>> - revzone = DNSName(items[pos:]) >>>>>> + revzone = revdns[pos:] >>>>> Hmm, and this logic will breaks CNAME/DNAME (RFC2317) handling ... Damn, we >>>>> need different handling when we intend to create the zone and when we want to >>>>> manipulate a record in a reverse zone. Grrr. >>>>> >>>>> When we want to manipulate a record in existing zone, the whole branch does >>>>> not make sense and the result of DNS query is what we want and need. >>>>> >>>>> On the other hand, we need this when creating *a new zone* from IP address >>>>> ... >>>>> >>>>> Mastin^2, what about zone names with missing period at the end? Is it handled >>>>> by dnszone_show() internally? >>>>> >>>>> We have to discuss all this... >>>>> >>>>>> try: >>>>>> api.Command['dnszone_show'](revzone) >>>>>> @@ -558,7 +568,10 @@ def get_reverse_zone(ipaddr, prefixlen=None): >>>>>> >>>>>> if revzone is None: >>>>>> raise errors.NotFound( >>>>>> - reason=_('DNS reverse zone for IP address %(addr)s not found') >>>>>> % dict(addr=ipaddr) >>>>>> + reason=_( >>>>>> + 'DNS reverse zone %(resolved_zone)s for IP address ' >>>>>> + '%(addr)s is not manager by this server') % dict( >>>>> typo s/manager/managed/ >>>>> >>>>>> + addr=ipaddr, resolved_zone=resolved_zone) >>>>>> ) >>>>>> >>>>>> revname = revdns.relativize(revzone) >>>> After lengthy discussion with Petr^2 I we decided to rework get_reverse_zone >>>> function a bit. Attaching updated patch. >>> Well, we should get rid of prefixlen parameter. Wipe it from Earth's >>> surface! :-) >>> >>> The assumption here is that this function is always used only for manipulating >>> *records in existing zones*, so the only way to find appropriate reverse zone >>> name is to ask DNS. >>> >>> Derivation based on prefix length makes sense only for deriving reverse zone >>> names from IP addresses *with intent to create the zone*. >>> >>> In all other cases it does not make sense to use prefix. I'm sorry that I was >>> not clear. >>> >> Upon Thy request I purged the Function that Gets the Name of the Zone Reverse >> of the crawling evil thee caleth the Prefixlen. >> >> The shallow impostor of The Function whose services no Module required nor >> used was also banished to oblivion and His noisome vapors shall bother the >> Kingdom of Identity no more. >> >> Thou shalt rejoice when Thy review the rewritten Patch attached herein or else >> I shall be smitten by the mighty NACK thee wieldeth. > Mighty ACK! :-D > > Thank you for your patience with me. > Pushed to: ipa-4-2: 2d4854480c1457a77dde2a3ed53f464521dd7254 master: c43dce3a61e17791cc31f45498bae2d52edcf969 From tbabej at redhat.com Fri Oct 23 07:25:05 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 23 Oct 2015 09:25:05 +0200 Subject: [Freeipa-devel] [PATCH 0086] disable ipa-replica prepare in non-zero domain levels In-Reply-To: <5628D6B9.5090703@redhat.com> References: <561FB85B.3070202@redhat.com> <5624E66C.7090809@redhat.com> <56250369.3090400@redhat.com> <56264F5B.6080109@redhat.com> <56266209.8060705@redhat.com> <5628D37B.80908@redhat.com> <5628D57F.1010607@redhat.com> <5628D6B9.5090703@redhat.com> Message-ID: <5629E0D1.7040201@redhat.com> > One more point: > > + if domain_level > MIN_DOMAIN_LEVEL: > + raise RuntimeError( > + UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE.format( > > It is kind of weird that error happens if domain level is greater than some > minimal value. Better naming is badly needed. > Actually, this is not about naming, MIN_DOMAIN_LEVEL constant should not be used at all. The constant can be increased to 2 or 3 in later releases, which will allow the usage of ipa-replica-prepare even if the domain level of the IPA domain is 1. Unlike other issues with this patch, which could be considered cosmetic, this actually is a real bug in the implementation. Tomas From tbabej at redhat.com Fri Oct 23 07:31:02 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 23 Oct 2015 09:31:02 +0200 Subject: [Freeipa-devel] Freeipa domain levels naming In-Reply-To: <56290595.9090602@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> Message-ID: <5629E236.2090200@redhat.com> On 10/22/2015 05:49 PM, Simo Sorce wrote: > On 22/10/15 11:29, Martin Basti wrote: >> Hello all, >> >> in current master branch we have mixed usage of literals 0, 1 and >> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >> >> I suggest to use names for domain levels: >> >> COMPAT_DOMAIN_LEVEL = 0 >> PROMOTION_DOMAIN_LEVEL = 1 >> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >> >> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >> >> Benefits: >> * ability to grep it in code > > Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 > >> * better readability in code > > Sure, but random names are not appropriate imo I'm with you guys on this, it's a good idea. Let's go with the DOMAIN_LEVEL_X naming though, it will be probably easier to remember. One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only the minimal/maximal domain level supported by the given IPA server, not the minimal/maximal domain level ever shipped by FreeIPA project. Currently, those two coincide, but in general they might be different if we ever raise the minimal level a decide to deprecate, say, domain level 0 or 1. It's a subtle but important difference. Tomas From mbabinsk at redhat.com Fri Oct 23 07:33:46 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 23 Oct 2015 09:33:46 +0200 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628F435.7070403@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <5628F435.7070403@redhat.com> Message-ID: <5629E2DA.2010101@redhat.com> On 10/22/2015 04:35 PM, Petr Spacek wrote: > On 22.10.2015 16:13, Martin Basti wrote: >> On 22.10.2015 10:44, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5181 >>> >>> >>> >> >> Thank you for the patch. >> >> 1) >> +OPTIONAL_SERVICES = { >> + 'DNS', >> + 'CA', >> + 'KRA', >> + 'ADTRUST', >> + 'EXTID', >> + 'DNSKeyExporter', >> + 'DNSSEC', >> + 'DNSKeySync', >> +} >> >> This did not scale well, maybe we should improve it to use some general >> solution for whole IPA to distinct mandratory and optionl service, but I do >> not know how (or if it is possible) > > Personally I would not create 'generic' solution until necessary. We have too > much 'generic' code which was never tested outside the single use-case we > have. Let's generalize it when needed. > > >> 2) >> + search_filter=('(&(objectclass=ipaConfigObject)' >> + '(ipaConfigString=enabledService))') >> >> Common user cannot read ipaConfigString, so this will work only for admins, I >> do not see any limitations of access in code for other users. > > I think that this is okay. The user will see exactly what LDAP ACI allows him > to see, i.e. nothing. We do the same with DNS, for example. > > > 4) Could you extend ipa server-find with an option to search for servers with > a particular optional service? I think that it would be handy to do something like > $ ipa server-find --service=CA > to see list of CA servers. > That would actually by a very useful functionality. I tried to play around with the idea but it seems it would require some serious hacking/design changes that are beyond the scope of this ticket. Feel free to open another RFE though :). > Thank you! > -- Martin^3 Babinsky From mbasti at redhat.com Fri Oct 23 07:34:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 09:34:10 +0200 Subject: [Freeipa-devel] Freeipa domain levels naming In-Reply-To: <5629E236.2090200@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> Message-ID: <5629E2F2.6030606@redhat.com> On 23.10.2015 09:31, Tomas Babej wrote: > > On 10/22/2015 05:49 PM, Simo Sorce wrote: >> On 22/10/15 11:29, Martin Basti wrote: >>> Hello all, >>> >>> in current master branch we have mixed usage of literals 0, 1 and >>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>> >>> I suggest to use names for domain levels: >>> >>> COMPAT_DOMAIN_LEVEL = 0 >>> PROMOTION_DOMAIN_LEVEL = 1 >>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>> >>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>> >>> Benefits: >>> * ability to grep it in code >> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >> >>> * better readability in code >> Sure, but random names are not appropriate imo > I'm with you guys on this, it's a good idea. Let's go with the > DOMAIN_LEVEL_X naming though, it will be probably easier to remember. > > One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only > the minimal/maximal domain level supported by the given IPA server, not > the minimal/maximal domain level ever shipped by FreeIPA project. > > Currently, those two coincide, but in general they might be different if > we ever raise the minimal level a decide to deprecate, say, domain level > 0 or 1. It's a subtle but important difference. > > Tomas Thank you all for your opinion, I will implement DOMAIN_LEVEL_X constants and send patch. Thanks. Martin^2 From lkrispen at redhat.com Fri Oct 23 08:41:07 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 23 Oct 2015 10:41:07 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <561B96CE.9060404@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> Message-ID: <5629F2A3.40907@redhat.com> Here it is again On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: > > On 10/12/2015 12:44 PM, Martin Basti wrote: >> >> >> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>> The attached patch moves the cleaning of the RUV into the topology >>> plugin. >>> >>> I encountered a problem when removing a replica, which disconnects >>> the topology, but it was fixed with my WIP for #5072. >>> >>> I want to keep these issues separate, so please review and test the >>> patch and let me know about issues found >>> >>> Ludwig >>> >>> >> >> Is this patch still valid and pending review? > it should be still valid, waiting for review, wanted to rebase after > topology/promotion patches have been checked in and resend > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lkrispen-freeipa-0019-handle-cleaning-of-RUV-in-the-topology-plugin.patch Type: text/x-patch Size: 6722 bytes Desc: not available URL: From lkrispen at redhat.com Fri Oct 23 08:44:02 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 23 Oct 2015 10:44:02 +0200 Subject: [Freeipa-devel] [PATCH 0020-0021] some topology plugin fixes Message-ID: <5629F352.9050005@redhat.com> Hi, the attached two patches address issues I found when testing ca management in the topology plugin Thanks for review, Ludwig -------------- next part -------------- A non-text attachment was scrubbed... Name: lkrispen-freeipa-0020-reject-agreement-only-if-both-ends-are-managed.patch Type: text/x-patch Size: 1304 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lkrispen-freeipa-0021-update-list-of-managed-servers-when-a-suffix-becomes.patch Type: text/x-patch Size: 7224 bytes Desc: not available URL: From tbordaz at redhat.com Fri Oct 23 09:00:29 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 Oct 2015 11:00:29 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <561B96CE.9060404@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> Message-ID: <5629F72D.9020807@redhat.com> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: > > On 10/12/2015 12:44 PM, Martin Basti wrote: >> >> >> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>> The attached patch moves the cleaning of the RUV into the topology >>> plugin. >>> >>> I encountered a problem when removing a replica, which disconnects >>> the topology, but it was fixed with my WIP for #5072. >>> >>> I want to keep these issues separate, so please review and test the >>> patch and let me know about issues found >>> >>> Ludwig >>> >>> >> >> Is this patch still valid and pending review? > it should be still valid, waiting for review, wanted to rebase after > topology/promotion patches have been checked in and resend > > > Hello Ludwig, The patch looks good. I have few minor remarks: * Are the hostname in ruv always fqdn ? to retrieve the RUV element of a given host you use 'strstr'. If you have host vm-11 and vm-112, I wonder if it could pickup the wrong RUV element * In ipa_topo_util_cleanruv_element you need a pblock_done/free (or destroy) * In it fails to add the clearn-ruv task, you should log a message so that the admin knows what to do. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Fri Oct 23 09:24:55 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 Oct 2015 11:24:55 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <5629F72D.9020807@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> Message-ID: <5629FCE7.9070709@redhat.com> On 10/23/2015 11:00 AM, thierry bordaz wrote: > On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >> >> On 10/12/2015 12:44 PM, Martin Basti wrote: >>> >>> >>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>> The attached patch moves the cleaning of the RUV into the topology >>>> plugin. >>>> >>>> I encountered a problem when removing a replica, which disconnects >>>> the topology, but it was fixed with my WIP for #5072. >>>> >>>> I want to keep these issues separate, so please review and test the >>>> patch and let me know about issues found >>>> >>>> Ludwig >>>> >>>> >>> >>> Is this patch still valid and pending review? >> it should be still valid, waiting for review, wanted to rebase after >> topology/promotion patches have been checked in and resend >> >> >> > Hello Ludwig, > > The patch looks good. I have few minor remarks: > > * Are the hostname in ruv always fqdn ? to retrieve the RUV element > of a given host you use 'strstr'. > If you have host vm-11 and vm-112, I wonder if it could pickup the > wrong RUV element > * In ipa_topo_util_cleanruv_element you need a pblock_done/free (or > destroy) > * In it fails to add the clearn-ruv task, you should log a message > so that the admin knows what to do. > > thanks > thierry > > > Hi Ludwig, Additional question. cleanruv is done with 'replica-force-cleaning: yes'. Currently ipa-replica-manage does not implement this flag. Why do you use it in topology plugin. My concern is that if we delete a host before all the updates from that host has been received, could we receive a late update that will recreate the ruv element ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Fri Oct 23 10:39:00 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 23 Oct 2015 12:39:00 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <5629FCE7.9070709@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> Message-ID: <562A0E44.1020307@redhat.com> On 10/23/2015 11:24 AM, thierry bordaz wrote: > On 10/23/2015 11:00 AM, thierry bordaz wrote: >> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>> >>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>> >>>> >>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>> The attached patch moves the cleaning of the RUV into the topology >>>>> plugin. >>>>> >>>>> I encountered a problem when removing a replica, which disconnects >>>>> the topology, but it was fixed with my WIP for #5072. >>>>> >>>>> I want to keep these issues separate, so please review and test >>>>> the patch and let me know about issues found >>>>> >>>>> Ludwig >>>>> >>>>> >>>> >>>> Is this patch still valid and pending review? >>> it should be still valid, waiting for review, wanted to rebase >>> after topology/promotion patches have been checked in and resend >>> >>> >>> >> Hello Ludwig, >> >> The patch looks good. I have few minor remarks: >> >> * Are the hostname in ruv always fqdn ? to retrieve the RUV element >> of a given host you use 'strstr'. >> If you have host vm-11 and vm-112, I wonder if it could pickup >> the wrong RUV element >> * In ipa_topo_util_cleanruv_element you need a pblock_done/free (or >> destroy) >> * In it fails to add the clearn-ruv task, you should log a message >> so that the admin knows what to do. >> >> thanks >> thierry >> >> >> > Hi Ludwig, > I will adress the points raised, thank you > Additional question. cleanruv is done with 'replica-force-cleaning: > yes'. Currently ipa-replica-manage does not implement this flag. > Why do you use it in topology plugin. there are two potential problems with the cleanallruv task: 1] the rid could come back if not all servers were in sync, but with cleaning the changelog as part of cleanallruv I think the ris is low now 2] the cleanallruv is stuck on waiting for the task to complete on other servers even if they cannot be reached I want to avoid 2] therefore I choose this setting > My concern is that if we delete a host before all the updates from > that host has been received, could we receive a late update that will > recreate the ruv element ? > > thanks > thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Fri Oct 23 10:38:12 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 Oct 2015 12:38:12 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <562A0E44.1020307@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> <562A0E44.1020307@redhat.com> Message-ID: <562A0E14.5020106@redhat.com> On 10/23/2015 12:39 PM, Ludwig Krispenz wrote: > > On 10/23/2015 11:24 AM, thierry bordaz wrote: >> On 10/23/2015 11:00 AM, thierry bordaz wrote: >>> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>>> >>>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>>> The attached patch moves the cleaning of the RUV into the >>>>>> topology plugin. >>>>>> >>>>>> I encountered a problem when removing a replica, which >>>>>> disconnects the topology, but it was fixed with my WIP for #5072. >>>>>> >>>>>> I want to keep these issues separate, so please review and test >>>>>> the patch and let me know about issues found >>>>>> >>>>>> Ludwig >>>>>> >>>>>> >>>>> >>>>> Is this patch still valid and pending review? >>>> it should be still valid, waiting for review, wanted to rebase >>>> after topology/promotion patches have been checked in and resend >>>> >>>> >>>> >>> Hello Ludwig, >>> >>> The patch looks good. I have few minor remarks: >>> >>> * Are the hostname in ruv always fqdn ? to retrieve the RUV >>> element of a given host you use 'strstr'. >>> If you have host vm-11 and vm-112, I wonder if it could pickup >>> the wrong RUV element >>> * In ipa_topo_util_cleanruv_element you need a pblock_done/free >>> (or destroy) >>> * In it fails to add the clearn-ruv task, you should log a message >>> so that the admin knows what to do. >>> >>> thanks >>> thierry >>> >>> >>> >> Hi Ludwig, >> > I will adress the points raised, thank you >> Additional question. cleanruv is done with 'replica-force-cleaning: >> yes'. Currently ipa-replica-manage does not implement this flag. >> Why do you use it in topology plugin. > there are two potential problems with the cleanallruv task: > 1] the rid could come back if not all servers were in sync, but with > cleaning the changelog as part of cleanallruv I think the ris is low now > 2] the cleanallruv is stuck on waiting for the task to complete on > other servers even if they cannot be reached > > I want to avoid 2] therefore I choose this setting Oh yes I absolutely agree. What surprised me is that I thought IPA CLI already implemented that flag in cleanRUV. But I was wrong. thanks thierry >> My concern is that if we delete a host before all the updates from >> that host has been received, could we receive a late update that will >> recreate the ruv element ? >> >> thanks >> thierry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 23 10:48:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 12:48:04 +0200 Subject: [Freeipa-devel] [PATCH 0334] ipa-replica-manage: fix undefined variable Message-ID: <562A1064.6020301@redhat.com> In an error message the undefined variable has been used. The attached patch fixes it. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0334-ipa-replica-manage-fix-undefined-variable.patch Type: text/x-patch Size: 988 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 23 10:49:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 12:49:45 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <5629E2F2.6030606@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> Message-ID: <562A10C9.3050501@redhat.com> On 23.10.2015 09:34, Martin Basti wrote: > > > On 23.10.2015 09:31, Tomas Babej wrote: >> >> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>> On 22/10/15 11:29, Martin Basti wrote: >>>> Hello all, >>>> >>>> in current master branch we have mixed usage of literals 0, 1 and >>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>> >>>> I suggest to use names for domain levels: >>>> >>>> COMPAT_DOMAIN_LEVEL = 0 >>>> PROMOTION_DOMAIN_LEVEL = 1 >>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>> >>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>> >>>> Benefits: >>>> * ability to grep it in code >>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>> >>>> * better readability in code >>> Sure, but random names are not appropriate imo >> I'm with you guys on this, it's a good idea. Let's go with the >> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >> >> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >> the minimal/maximal domain level supported by the given IPA server, not >> the minimal/maximal domain level ever shipped by FreeIPA project. >> >> Currently, those two coincide, but in general they might be different if >> we ever raise the minimal level a decide to deprecate, say, domain level >> 0 or 1. It's a subtle but important difference. >> >> Tomas > > Thank you all for your opinion, > > I will implement DOMAIN_LEVEL_X constants and send patch. > > Thanks. > Martin^2 > Patch attached. O hope, I did not miss anything hardcoded. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0335-Domain-levels-use-constants-rather-than-hardcoded-va.patch Type: text/x-patch Size: 9327 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 23 10:55:10 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 23 Oct 2015 12:55:10 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <562A0E14.5020106@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> <562A0E44.1020307@redhat.com> <562A0E14.5020106@redhat.com> Message-ID: <562A120E.1040601@redhat.com> On 10/23/2015 12:38 PM, thierry bordaz wrote: > On 10/23/2015 12:39 PM, Ludwig Krispenz wrote: >> >> On 10/23/2015 11:24 AM, thierry bordaz wrote: >>> On 10/23/2015 11:00 AM, thierry bordaz wrote: >>>> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>>>> >>>>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>>>> The attached patch moves the cleaning of the RUV into the >>>>>>> topology plugin. >>>>>>> >>>>>>> I encountered a problem when removing a replica, which >>>>>>> disconnects the topology, but it was fixed with my WIP for #5072. >>>>>>> >>>>>>> I want to keep these issues separate, so please review and test >>>>>>> the patch and let me know about issues found >>>>>>> >>>>>>> Ludwig >>>>>>> >>>>>>> >>>>>> >>>>>> Is this patch still valid and pending review? >>>>> it should be still valid, waiting for review, wanted to rebase >>>>> after topology/promotion patches have been checked in and resend >>>>> >>>>> >>>>> >>>> Hello Ludwig, >>>> >>>> The patch looks good. I have few minor remarks: >>>> >>>> * Are the hostname in ruv always fqdn ? to retrieve the RUV >>>> element of a given host you use 'strstr'. >>>> If you have host vm-11 and vm-112, I wonder if it could pickup >>>> the wrong RUV element >>>> * In ipa_topo_util_cleanruv_element you need a pblock_done/free >>>> (or destroy) >>>> * In it fails to add the clearn-ruv task, you should log a message >>>> so that the admin knows what to do. >>>> >>>> thanks >>>> thierry >>>> >>>> >>>> >>> Hi Ludwig, >>> >> I will adress the points raised, thank you >>> Additional question. cleanruv is done with 'replica-force-cleaning: >>> yes'. Currently ipa-replica-manage does not implement this flag. >>> Why do you use it in topology plugin. >> there are two potential problems with the cleanallruv task: >> 1] the rid could come back if not all servers were in sync, but with >> cleaning the changelog as part of cleanallruv I think the ris is low now >> 2] the cleanallruv is stuck on waiting for the task to complete on >> other servers even if they cannot be reached >> >> I want to avoid 2] therefore I choose this setting > > Oh yes I absolutely agree. > What surprised me is that I thought IPA CLI already implemented that > flag in cleanRUV. But I was wrong. Could you please open a bug for ipa-replica-manage, with description of what and when should be added? > > thanks > thierry >>> My concern is that if we delete a host before all the updates from >>> that host has been received, could we receive a late update that will >>> recreate the ruv element ? >>> >>> thanks >>> thierry >> -- Petr Vobornik From mbabinsk at redhat.com Fri Oct 23 11:01:30 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 23 Oct 2015 13:01:30 +0200 Subject: [Freeipa-devel] [PATCH 0334] ipa-replica-manage: fix undefined variable In-Reply-To: <562A1064.6020301@redhat.com> References: <562A1064.6020301@redhat.com> Message-ID: <562A138A.5080302@redhat.com> On 10/23/2015 12:48 PM, Martin Basti wrote: > In an error message the undefined variable has been used. > The attached patch fixes it. > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Fri Oct 23 11:02:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 13:02:48 +0200 Subject: [Freeipa-devel] [PATCH 0334] ipa-replica-manage: fix undefined variable In-Reply-To: <562A138A.5080302@redhat.com> References: <562A1064.6020301@redhat.com> <562A138A.5080302@redhat.com> Message-ID: <562A13D8.5080609@redhat.com> On 23.10.2015 13:01, Martin Babinsky wrote: > On 10/23/2015 12:48 PM, Martin Basti wrote: >> In an error message the undefined variable has been used. >> The attached patch fixes it. >> >> > ACK > Pushed to master: 288a9b9dba05e5f87e253a3968b6431d816f94f6 From tbabej at redhat.com Fri Oct 23 11:49:56 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 23 Oct 2015 13:49:56 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A10C9.3050501@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> Message-ID: <562A1EE4.7070004@redhat.com> On 10/23/2015 12:49 PM, Martin Basti wrote: > > > On 23.10.2015 09:34, Martin Basti wrote: >> >> >> On 23.10.2015 09:31, Tomas Babej wrote: >>> >>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>> On 22/10/15 11:29, Martin Basti wrote: >>>>> Hello all, >>>>> >>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>> >>>>> I suggest to use names for domain levels: >>>>> >>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>> >>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>> >>>>> Benefits: >>>>> * ability to grep it in code >>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>> >>>>> * better readability in code >>>> Sure, but random names are not appropriate imo >>> I'm with you guys on this, it's a good idea. Let's go with the >>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>> >>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>> the minimal/maximal domain level supported by the given IPA server, not >>> the minimal/maximal domain level ever shipped by FreeIPA project. >>> >>> Currently, those two coincide, but in general they might be different if >>> we ever raise the minimal level a decide to deprecate, say, domain level >>> 0 or 1. It's a subtle but important difference. >>> >>> Tomas >> >> Thank you all for your opinion, >> >> I will implement DOMAIN_LEVEL_X constants and send patch. >> >> Thanks. >> Martin^2 >> > > Patch attached. > O hope, I did not miss anything hardcoded. I think we can safely hardcode domain levels as numbers in the error messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error message makes little sense to me, as the value of constants.DOMAIN_LEVEL_0 will not ever change. From mbasti at redhat.com Fri Oct 23 11:51:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 13:51:57 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A1EE4.7070004@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> Message-ID: <562A1F5D.3010003@redhat.com> On 23.10.2015 13:49, Tomas Babej wrote: > > On 10/23/2015 12:49 PM, Martin Basti wrote: >> >> On 23.10.2015 09:34, Martin Basti wrote: >>> >>> On 23.10.2015 09:31, Tomas Babej wrote: >>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>> Hello all, >>>>>> >>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>> >>>>>> I suggest to use names for domain levels: >>>>>> >>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>> >>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>> >>>>>> Benefits: >>>>>> * ability to grep it in code >>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>> >>>>>> * better readability in code >>>>> Sure, but random names are not appropriate imo >>>> I'm with you guys on this, it's a good idea. Let's go with the >>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>> >>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>> the minimal/maximal domain level supported by the given IPA server, not >>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>> >>>> Currently, those two coincide, but in general they might be different if >>>> we ever raise the minimal level a decide to deprecate, say, domain level >>>> 0 or 1. It's a subtle but important difference. >>>> >>>> Tomas >>> Thank you all for your opinion, >>> >>> I will implement DOMAIN_LEVEL_X constants and send patch. >>> >>> Thanks. >>> Martin^2 >>> >> Patch attached. >> O hope, I did not miss anything hardcoded. > I think we can safely hardcode domain levels as numbers in the error > messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error > message makes little sense to me, as the value of > constants.DOMAIN_LEVEL_0 will not ever change. However, with substituting is easier to find occurrences of domain levels in comments and messages in case of refactoring. From tbabej at redhat.com Fri Oct 23 11:53:05 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 23 Oct 2015 13:53:05 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A1F5D.3010003@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> Message-ID: <562A1FA1.2050303@redhat.com> On 10/23/2015 01:51 PM, Martin Basti wrote: > > > On 23.10.2015 13:49, Tomas Babej wrote: >> >> On 10/23/2015 12:49 PM, Martin Basti wrote: >>> >>> On 23.10.2015 09:34, Martin Basti wrote: >>>> >>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>> >>>>>>> I suggest to use names for domain levels: >>>>>>> >>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>> >>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>> >>>>>>> Benefits: >>>>>>> * ability to grep it in code >>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>> >>>>>>> * better readability in code >>>>>> Sure, but random names are not appropriate imo >>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>> >>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>> the minimal/maximal domain level supported by the given IPA server, >>>>> not >>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>> >>>>> Currently, those two coincide, but in general they might be >>>>> different if >>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>> level >>>>> 0 or 1. It's a subtle but important difference. >>>>> >>>>> Tomas >>>> Thank you all for your opinion, >>>> >>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>> >>>> Thanks. >>>> Martin^2 >>>> >>> Patch attached. >>> O hope, I did not miss anything hardcoded. >> I think we can safely hardcode domain levels as numbers in the error >> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >> message makes little sense to me, as the value of >> constants.DOMAIN_LEVEL_0 will not ever change. > However, with substituting is easier to find occurrences of domain > levels in comments and messages in case of refactoring. In case of refactoring of what? All the error messages containing reference to a domain level 0? :) From mbasti at redhat.com Fri Oct 23 11:53:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 13:53:49 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A1FA1.2050303@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> Message-ID: <562A1FCD.70407@redhat.com> On 23.10.2015 13:53, Tomas Babej wrote: > > On 10/23/2015 01:51 PM, Martin Basti wrote: >> >> On 23.10.2015 13:49, Tomas Babej wrote: >>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>> Hello all, >>>>>>>> >>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>> >>>>>>>> I suggest to use names for domain levels: >>>>>>>> >>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>> >>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>> >>>>>>>> Benefits: >>>>>>>> * ability to grep it in code >>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>> >>>>>>>> * better readability in code >>>>>>> Sure, but random names are not appropriate imo >>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>> >>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>> not >>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>> >>>>>> Currently, those two coincide, but in general they might be >>>>>> different if >>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>> level >>>>>> 0 or 1. It's a subtle but important difference. >>>>>> >>>>>> Tomas >>>>> Thank you all for your opinion, >>>>> >>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>> >>>>> Thanks. >>>>> Martin^2 >>>>> >>>> Patch attached. >>>> O hope, I did not miss anything hardcoded. >>> I think we can safely hardcode domain levels as numbers in the error >>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>> message makes little sense to me, as the value of >>> constants.DOMAIN_LEVEL_0 will not ever change. >> However, with substituting is easier to find occurrences of domain >> levels in comments and messages in case of refactoring. > In case of refactoring of what? All the error messages containing > reference to a domain level 0? :) Exactly! :) From mkubik at redhat.com Fri Oct 23 12:01:17 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 23 Oct 2015 14:01:17 +0200 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test In-Reply-To: <56263155.4000608@redhat.com> References: <5603F13E.4060805@redhat.com> <560BD9C8.2070205@redhat.com> <5620FEF1.70808@redhat.com> <5624D61E.20106@redhat.com> <5625F493.9020109@redhat.com> <56263155.4000608@redhat.com> Message-ID: <562A218D.6070207@redhat.com> On 10/20/2015 02:19 PM, Martin Basti wrote: > > NACK > > > > 1) > > I still see many hardcoded passwords in the code > > with change_principal(smime_user, "Secret123"): > For now changed to module variable. > > > 2) > > Also the 'alice' username can be extracted to module variable > instead hardcoding > > The fixture should take the place of module variables in the tests. Changed u'alice' into local variable. Once we fix the problems with UserTracker, we should store the password here as well. > > 3) > > File alice.conf.tmpl can be generalized to be used for more users, > replace alice in template to {username} and in code replace this > variable with alice, also do not forgot rename template to something > more general > > > Done. > > > > > > > Updated patch set attached. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0012.4-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.4-ipatests-Add-initial-CAACLTracker-implementation.patch Type: text/x-patch Size: 15040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0014.5-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 5880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0015-3-ipatests-CA-ACL-added-config-templates.patch Type: text/x-patch Size: 10502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0016-2-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-4-ipatests-CA-ACL-and-cert-profile-functional-test.patch Type: text/x-patch Size: 16654 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0012.4-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-ipa42-0013.4-ipatests-Add-initial-CAACLTracker-implementation.patch Type: text/x-patch Size: 15040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0014.5-tests-add-test-to-check-the-default-ACL.patch Type: text/x-patch Size: 5880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0015-3-ipatests-CA-ACL-added-config-templates.patch Type: text/x-patch Size: 10502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0016-2-ipatests-added-unlock_principal_password-and-change_.patch Type: text/x-patch Size: 2394 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0017-4-ipatests-CA-ACL-and-cert-profile-functional-test.patch Type: text/x-patch Size: 16654 bytes Desc: not available URL: From pspacek at redhat.com Fri Oct 23 12:07:48 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Oct 2015 14:07:48 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A1FCD.70407@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> Message-ID: <562A2314.6020006@redhat.com> On 23.10.2015 13:53, Martin Basti wrote: > > > On 23.10.2015 13:53, Tomas Babej wrote: >> >> On 10/23/2015 01:51 PM, Martin Basti wrote: >>> >>> On 23.10.2015 13:49, Tomas Babej wrote: >>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>>> >>>>>>>>> I suggest to use names for domain levels: >>>>>>>>> >>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>> >>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>> >>>>>>>>> Benefits: >>>>>>>>> * ability to grep it in code >>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>> >>>>>>>>> * better readability in code >>>>>>>> Sure, but random names are not appropriate imo >>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>>> >>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>>> not >>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>> >>>>>>> Currently, those two coincide, but in general they might be >>>>>>> different if >>>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>>> level >>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>> >>>>>>> Tomas >>>>>> Thank you all for your opinion, >>>>>> >>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>> >>>>>> Thanks. >>>>>> Martin^2 >>>>>> >>>>> Patch attached. >>>>> O hope, I did not miss anything hardcoded. >>>> I think we can safely hardcode domain levels as numbers in the error >>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>>> message makes little sense to me, as the value of >>>> constants.DOMAIN_LEVEL_0 will not ever change. >>> However, with substituting is easier to find occurrences of domain >>> levels in comments and messages in case of refactoring. >> In case of refactoring of what? All the error messages containing >> reference to a domain level 0? :) > Exactly! :) Tomas, that one day we decide to drop support for domain level 0. We will have to hunt down all references to it and using constant for help messages etc. might be handy because it will show up in results of grep, so we do not forget to wipe domain level 0 from texts. Nitpick just to make you feel that I read the patch (does not warrant a NACK): I would rather see conditions in form of (<= or >=) instead of (< or >) because now you have to grep for domain level +- 1 to get all references to particular domain level :-D Nevermind, this is just a nitpick. -- Petr^2 Spacek From mkosek at redhat.com Fri Oct 23 12:21:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Oct 2015 14:21:16 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A2314.6020006@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> <562A2314.6020006@redhat.com> Message-ID: <562A263C.6010602@redhat.com> On 10/23/2015 02:07 PM, Petr Spacek wrote: > On 23.10.2015 13:53, Martin Basti wrote: >> >> >> On 23.10.2015 13:53, Tomas Babej wrote: >>> >>> On 10/23/2015 01:51 PM, Martin Basti wrote: >>>> >>>> On 23.10.2015 13:49, Tomas Babej wrote: >>>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>>>> >>>>>>>>>> I suggest to use names for domain levels: >>>>>>>>>> >>>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>>> >>>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>>> >>>>>>>>>> Benefits: >>>>>>>>>> * ability to grep it in code >>>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>>> >>>>>>>>>> * better readability in code >>>>>>>>> Sure, but random names are not appropriate imo >>>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>>>> >>>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>>>> not >>>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>>> >>>>>>>> Currently, those two coincide, but in general they might be >>>>>>>> different if >>>>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>>>> level >>>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>>> >>>>>>>> Tomas >>>>>>> Thank you all for your opinion, >>>>>>> >>>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>>> >>>>>>> Thanks. >>>>>>> Martin^2 >>>>>>> >>>>>> Patch attached. >>>>>> O hope, I did not miss anything hardcoded. >>>>> I think we can safely hardcode domain levels as numbers in the error >>>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>>>> message makes little sense to me, as the value of >>>>> constants.DOMAIN_LEVEL_0 will not ever change. >>>> However, with substituting is easier to find occurrences of domain >>>> levels in comments and messages in case of refactoring. >>> In case of refactoring of what? All the error messages containing >>> reference to a domain level 0? :) >> Exactly! :) > > Tomas, that one day we decide to drop support for domain level 0. We will have > to hunt down all references to it and using constant for help messages etc. > might be handy because it will show up in results of grep, so we do not forget > to wipe domain level 0 from texts. > > > Nitpick just to make you feel that I read the patch (does not warrant a NACK): > I would rather see conditions in form of (<= or >=) instead of (< or >) > because now you have to grep for domain level +- 1 to get all references to > particular domain level :-D +1, listen to this smart young man! Debugability++ :-) > Nevermind, this is just a nitpick. > From lkrispen at redhat.com Fri Oct 23 12:27:56 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 23 Oct 2015 14:27:56 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <5629FCE7.9070709@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> Message-ID: <562A27CC.1070402@redhat.com> Hi Thierry, hope this addresses your concerns Ludwig On 10/23/2015 11:24 AM, thierry bordaz wrote: > On 10/23/2015 11:00 AM, thierry bordaz wrote: >> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>> >>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>> >>>> >>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>> The attached patch moves the cleaning of the RUV into the topology >>>>> plugin. >>>>> >>>>> I encountered a problem when removing a replica, which disconnects >>>>> the topology, but it was fixed with my WIP for #5072. >>>>> >>>>> I want to keep these issues separate, so please review and test >>>>> the patch and let me know about issues found >>>>> >>>>> Ludwig >>>>> >>>>> >>>> >>>> Is this patch still valid and pending review? >>> it should be still valid, waiting for review, wanted to rebase >>> after topology/promotion patches have been checked in and resend >>> >>> >>> >> Hello Ludwig, >> >> The patch looks good. I have few minor remarks: >> >> * Are the hostname in ruv always fqdn ? to retrieve the RUV element >> of a given host you use 'strstr'. >> If you have host vm-11 and vm-112, I wonder if it could pickup >> the wrong RUV element >> * In ipa_topo_util_cleanruv_element you need a pblock_done/free (or >> destroy) >> * In it fails to add the clearn-ruv task, you should log a message >> so that the admin knows what to do. >> >> thanks >> thierry >> >> >> > Hi Ludwig, > > Additional question. cleanruv is done with 'replica-force-cleaning: > yes'. Currently ipa-replica-manage does not implement this flag. > Why do you use it in topology plugin. > My concern is that if we delete a host before all the updates from > that host has been received, could we receive a late update that will > recreate the ruv element ? > > thanks > thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lkrispen-freeipa-0019-handle-cleaning-of-RUV-in-the-topology-plugin.patch Type: text/x-patch Size: 7371 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 23 12:39:50 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 23 Oct 2015 14:39:50 +0200 Subject: [Freeipa-devel] [PATCH] 924 use starttls in CSReplicationManager connection again Message-ID: <562A2A96.1080101@redhat.com> not sure if the change in2606f5aecd6ac0db31abb515b691529bb7eaf14e was a mistake or done on purpose. Anyway: commit 2606f5aecd6ac0db31abb515b691529bb7eaf14e has: - realm, hostname, dirman_passwd, port, starttls=True) + realm, hostname, dirman_passwd, port) In CSReplicationManager which causes, e.g.: ipa-csreplica-manage -p Secret123 list ipa.example.com cannot connect to 'ldaps://ipa.example.com:389': TLS error -5938:Encountered end of file Attached patch reverts it. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0924-use-starttls-in-CSReplicationManager-connection-agai.patch Type: text/x-patch Size: 1374 bytes Desc: not available URL: From ofayans at redhat.com Fri Oct 23 13:00:03 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 23 Oct 2015 15:00:03 +0200 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562902E3.8020707@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> Message-ID: <562A2F53.5050408@redhat.com> Hi Martin, Here comes the updated version. On 10/22/2015 05:38 PM, Martin Basti wrote: > > > On 22.10.2015 15:23, Martin Basti wrote: >> >> On 22.10.2015 14:13, Oleg Fayans wrote: >>> >>> >>> >> >> Hello, >> >> thank you for the patch. >> >> 1) >> please remove the added empty lines, they are unrelated to this ticket done >> >> 2) >> -def install_master(host, setup_dns=True, setup_kra=False): >> +def install_master(host, setup_dns=True, setup_kra=False, domainlevel=1): >> >> I suggest to use default domainlevel=None, which will use the default >> domain level (specified in build) done >> >> 3) >> + domain_level = domainlevel(master) >> I do not think that this meets expectations. >> >> We have to test, both domain level 0 and 1 for IPA 4.3, respectively >> new IPA must support all older domain levels, domain level is >> independent on IPA version, only admin can raise it up. >> >> So you have to find out way how to pass the domain level for which >> test will be running, we were talking about using config files, but >> feel free to find something new and better Fixed. Now, we declare domain level in config.yaml with the directive domain_level >> >> 4) >> Did you resolve the pytest fixtures which specifies which tests can be >> run under which domain level? In fact, we do not seem to have any tests yet that would require it. All the existing tests just use install_replica method, no matter how is it done. >> >> 5) >> + '--ip-address', client.ip, >> >> why this change to client install? Right, it found to be unnecessary. >> >> Martin^2 >> >> > 6) > ************* Module ipatests.test_integration.tasks > ipatests/test_integration/tasks.py:85: [E1123(unexpected-keyword-arg), > allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function call) Fixed > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: .freeipa-ofayans-0011.1-replica-promotion-changes-in-tests.patch.swp Type: application/octet-stream Size: 16384 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 23 13:08:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 15:08:33 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A263C.6010602@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> <562A2314.6020006@redhat.com> <562A263C.6010602@redhat.com> Message-ID: <562A3151.7040405@redhat.com> On 23.10.2015 14:21, Martin Kosek wrote: > On 10/23/2015 02:07 PM, Petr Spacek wrote: >> On 23.10.2015 13:53, Martin Basti wrote: >>> >>> >>> On 23.10.2015 13:53, Tomas Babej wrote: >>>> >>>> On 10/23/2015 01:51 PM, Martin Basti wrote: >>>>> >>>>> On 23.10.2015 13:49, Tomas Babej wrote: >>>>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>>>> Hello all, >>>>>>>>>>> >>>>>>>>>>> in current master branch we have mixed usage of literals 0, >>>>>>>>>>> 1 and >>>>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is >>>>>>>>>>> quite mess. >>>>>>>>>>> >>>>>>>>>>> I suggest to use names for domain levels: >>>>>>>>>>> >>>>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>>>> >>>>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>>>> >>>>>>>>>>> Benefits: >>>>>>>>>>> * ability to grep it in code >>>>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>>>> >>>>>>>>>>> * better readability in code >>>>>>>>>> Sure, but random names are not appropriate imo >>>>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to >>>>>>>>> remember. >>>>>>>>> >>>>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL >>>>>>>>> denotes only >>>>>>>>> the minimal/maximal domain level supported by the given IPA >>>>>>>>> server, >>>>>>>>> not >>>>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>>>> >>>>>>>>> Currently, those two coincide, but in general they might be >>>>>>>>> different if >>>>>>>>> we ever raise the minimal level a decide to deprecate, say, >>>>>>>>> domain >>>>>>>>> level >>>>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> Thank you all for your opinion, >>>>>>>> >>>>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Martin^2 >>>>>>>> >>>>>>> Patch attached. >>>>>>> O hope, I did not miss anything hardcoded. >>>>>> I think we can safely hardcode domain levels as numbers in the error >>>>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the >>>>>> error >>>>>> message makes little sense to me, as the value of >>>>>> constants.DOMAIN_LEVEL_0 will not ever change. >>>>> However, with substituting is easier to find occurrences of domain >>>>> levels in comments and messages in case of refactoring. >>>> In case of refactoring of what? All the error messages containing >>>> reference to a domain level 0? :) >>> Exactly! :) >> >> Tomas, that one day we decide to drop support for domain level 0. We >> will have >> to hunt down all references to it and using constant for help >> messages etc. >> might be handy because it will show up in results of grep, so we do >> not forget >> to wipe domain level 0 from texts. >> >> >> Nitpick just to make you feel that I read the patch (does not warrant >> a NACK): >> I would rather see conditions in form of (<= or >=) instead of (< or >) >> because now you have to grep for domain level +- 1 to get all >> references to >> particular domain level :-D > > +1, listen to this smart young man! Debugability++ :-) Okay, but this I will do in separate patch. So please ACK/NACK the current one. > >> Nevermind, this is just a nitpick. >> > From mbasti at redhat.com Fri Oct 23 13:10:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 15:10:25 +0200 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562A2F53.5050408@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> Message-ID: <562A31C1.5050105@redhat.com> On 23.10.2015 15:00, Oleg Fayans wrote: > Hi Martin, > > Here comes the updated version. > > On 10/22/2015 05:38 PM, Martin Basti wrote: >> >> >> On 22.10.2015 15:23, Martin Basti wrote: >>> >>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>> >>>> >>>> >>> >>> Hello, >>> >>> thank you for the patch. >>> >>> 1) >>> please remove the added empty lines, they are unrelated to this ticket > > done > >>> >>> 2) >>> -def install_master(host, setup_dns=True, setup_kra=False): >>> +def install_master(host, setup_dns=True, setup_kra=False, >>> domainlevel=1): >>> >>> I suggest to use default domainlevel=None, which will use the default >>> domain level (specified in build) > > done > >>> >>> 3) >>> + domain_level = domainlevel(master) >>> I do not think that this meets expectations. >>> >>> We have to test, both domain level 0 and 1 for IPA 4.3, respectively >>> new IPA must support all older domain levels, domain level is >>> independent on IPA version, only admin can raise it up. >>> >>> So you have to find out way how to pass the domain level for which >>> test will be running, we were talking about using config files, but >>> feel free to find something new and better > > Fixed. Now, we declare domain level in config.yaml with the directive > domain_level > >>> >>> 4) >>> Did you resolve the pytest fixtures which specifies which tests can be >>> run under which domain level? > > In fact, we do not seem to have any tests yet that would require it. > All the existing tests just use install_replica > method, no matter how is it done. How about topology CI test? This can be executed only with domain level 1, right? > >>> >>> 5) >>> + '--ip-address', client.ip, >>> >>> why this change to client install? > > Right, it found to be unnecessary. > >>> >>> Martin^2 >>> >>> >> 6) >> ************* Module ipatests.test_integration.tasks >> ipatests/test_integration/tasks.py:85: [E1123(unexpected-keyword-arg), >> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function >> call) > > Fixed > >> >> > From mbabinsk at redhat.com Fri Oct 23 13:12:20 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 23 Oct 2015 15:12:20 +0200 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <5620D475.2030200@redhat.com> References: <5620D475.2030200@redhat.com> Message-ID: <562A3234.9040509@redhat.com> On 10/16/2015 12:41 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5345 > > Patch attached. > > I have tested it on 4-2 branch and it works as expected, ACK. Obviously, master branch would require a different patch. -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Oct 23 13:15:25 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 23 Oct 2015 15:15:25 +0200 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <562A3234.9040509@redhat.com> References: <5620D475.2030200@redhat.com> <562A3234.9040509@redhat.com> Message-ID: <562A32ED.8030702@redhat.com> On 10/23/2015 03:12 PM, Martin Babinsky wrote: > On 10/16/2015 12:41 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5345 >> >> Patch attached. >> >> > I have tested it on 4-2 branch and it works as expected, ACK. > > Obviously, master branch would require a different patch. > I actually missed your check in ipaserver/install/kra.py which can break ipa-replica-install with --setup-kra, so NACK. -- Martin^3 Babinsky From tbordaz at redhat.com Fri Oct 23 13:19:29 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 Oct 2015 15:19:29 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <562A27CC.1070402@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> <562A27CC.1070402@redhat.com> Message-ID: <562A33E1.4070507@redhat.com> Hi Ludwig, Thanks for the patch. Yes it is looking good to me. Just a minor change about the message logged (if case of failure to add the cleanallruv task), you may recommend to the administrator the exact command to run. ACK thanks thierry On 10/23/2015 02:27 PM, Ludwig Krispenz wrote: > Hi Thierry, > > hope this addresses your concerns > > Ludwig > > On 10/23/2015 11:24 AM, thierry bordaz wrote: >> On 10/23/2015 11:00 AM, thierry bordaz wrote: >>> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>>> >>>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>>> The attached patch moves the cleaning of the RUV into the >>>>>> topology plugin. >>>>>> >>>>>> I encountered a problem when removing a replica, which >>>>>> disconnects the topology, but it was fixed with my WIP for #5072. >>>>>> >>>>>> I want to keep these issues separate, so please review and test >>>>>> the patch and let me know about issues found >>>>>> >>>>>> Ludwig >>>>>> >>>>>> >>>>> >>>>> Is this patch still valid and pending review? >>>> it should be still valid, waiting for review, wanted to rebase >>>> after topology/promotion patches have been checked in and resend >>>> >>>> >>>> >>> Hello Ludwig, >>> >>> The patch looks good. I have few minor remarks: >>> >>> * Are the hostname in ruv always fqdn ? to retrieve the RUV >>> element of a given host you use 'strstr'. >>> If you have host vm-11 and vm-112, I wonder if it could pickup >>> the wrong RUV element >>> * In ipa_topo_util_cleanruv_element you need a pblock_done/free >>> (or destroy) >>> * In it fails to add the clearn-ruv task, you should log a message >>> so that the admin knows what to do. >>> >>> thanks >>> thierry >>> >>> >>> >> Hi Ludwig, >> >> Additional question. cleanruv is done with 'replica-force-cleaning: >> yes'. Currently ipa-replica-manage does not implement this flag. >> Why do you use it in topology plugin. >> My concern is that if we delete a host before all the updates from >> that host has been received, could we receive a late update that will >> recreate the ruv element ? >> >> thanks >> thierry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Oct 23 13:25:37 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 23 Oct 2015 15:25:37 +0200 Subject: [Freeipa-devel] [PATCHES 0375-0376] Perform validation of the trust in the trustdomain commands Message-ID: <562A3551.6000705@redhat.com> Details in the commit messages. Fixes: https://fedorahosted.org/freeipa/ticket/5389 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0375-trusts-Make-trust_show.get_dn-raise-properly-formatt.patch Type: text/x-patch Size: 2633 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0376-trustdomain-Perform-validation-of-the-trust-domain-f.patch Type: text/x-patch Size: 1786 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-4-2-0375-trusts-Make-trust_show.get_dn-raise-properly-formatt.patch Type: text/x-patch Size: 2657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-4-2-0376-trustdomain-Perform-validation-of-the-trust-domain-f.patch Type: text/x-patch Size: 1786 bytes Desc: not available URL: From lkrispen at redhat.com Fri Oct 23 13:38:42 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 23 Oct 2015 15:38:42 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <562A33E1.4070507@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> <562A27CC.1070402@redhat.com> <562A33E1.4070507@redhat.com> Message-ID: <562A3862.3060102@redhat.com> On 10/23/2015 03:19 PM, thierry bordaz wrote: > Hi Ludwig, > > Thanks for the patch. > Yes it is looking good to me. Just a minor change about the message > logged (if case of failure to add the cleanallruv task), you may > recommend to the administrator the exact command to run. no, also we do not know why it failed, there would be the option to do it via ipa-replica-manage or ldapmodify, the logging that creating the task failed should be be enough to start investigation and do a manual cleanallruv > > ACK > > thanks > thierry > On 10/23/2015 02:27 PM, Ludwig Krispenz wrote: >> Hi Thierry, >> >> hope this addresses your concerns >> >> Ludwig >> >> On 10/23/2015 11:24 AM, thierry bordaz wrote: >>> On 10/23/2015 11:00 AM, thierry bordaz wrote: >>>> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>>>> >>>>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>>>> The attached patch moves the cleaning of the RUV into the >>>>>>> topology plugin. >>>>>>> >>>>>>> I encountered a problem when removing a replica, which >>>>>>> disconnects the topology, but it was fixed with my WIP for #5072. >>>>>>> >>>>>>> I want to keep these issues separate, so please review and test >>>>>>> the patch and let me know about issues found >>>>>>> >>>>>>> Ludwig >>>>>>> >>>>>>> >>>>>> >>>>>> Is this patch still valid and pending review? >>>>> it should be still valid, waiting for review, wanted to rebase >>>>> after topology/promotion patches have been checked in and resend >>>>> >>>>> >>>>> >>>> Hello Ludwig, >>>> >>>> The patch looks good. I have few minor remarks: >>>> >>>> * Are the hostname in ruv always fqdn ? to retrieve the RUV >>>> element of a given host you use 'strstr'. >>>> If you have host vm-11 and vm-112, I wonder if it could pickup >>>> the wrong RUV element >>>> * In ipa_topo_util_cleanruv_element you need a pblock_done/free >>>> (or destroy) >>>> * In it fails to add the clearn-ruv task, you should log a >>>> message so that the admin knows what to do. >>>> >>>> thanks >>>> thierry >>>> >>>> >>>> >>> Hi Ludwig, >>> >>> Additional question. cleanruv is done with 'replica-force-cleaning: >>> yes'. Currently ipa-replica-manage does not implement this flag. >>> Why do you use it in topology plugin. >>> My concern is that if we delete a host before all the updates from >>> that host has been received, could we receive a late update that >>> will recreate the ruv element ? >>> >>> thanks >>> thierry >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 23 13:35:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 15:35:19 +0200 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562A2F53.5050408@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> Message-ID: <562A3797.5040107@redhat.com> On 23.10.2015 15:00, Oleg Fayans wrote: > Hi Martin, > > Here comes the updated version. > > On 10/22/2015 05:38 PM, Martin Basti wrote: >> >> >> On 22.10.2015 15:23, Martin Basti wrote: >>> >>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>> >>>> >>>> >>> >>> Hello, >>> >>> thank you for the patch. >>> >>> 1) >>> please remove the added empty lines, they are unrelated to this ticket > > done > >>> >>> 2) >>> -def install_master(host, setup_dns=True, setup_kra=False): >>> +def install_master(host, setup_dns=True, setup_kra=False, >>> domainlevel=1): >>> >>> I suggest to use default domainlevel=None, which will use the default >>> domain level (specified in build) > > done > >>> >>> 3) >>> + domain_level = domainlevel(master) >>> I do not think that this meets expectations. >>> >>> We have to test, both domain level 0 and 1 for IPA 4.3, respectively >>> new IPA must support all older domain levels, domain level is >>> independent on IPA version, only admin can raise it up. >>> >>> So you have to find out way how to pass the domain level for which >>> test will be running, we were talking about using config files, but >>> feel free to find something new and better > > Fixed. Now, we declare domain level in config.yaml with the directive > domain_level > >>> >>> 4) >>> Did you resolve the pytest fixtures which specifies which tests can be >>> run under which domain level? > > In fact, we do not seem to have any tests yet that would require it. > All the existing tests just use install_replica > method, no matter how is it done. > >>> >>> 5) >>> + '--ip-address', client.ip, >>> >>> why this change to client install? > > Right, it found to be unnecessary. > >>> >>> Martin^2 >>> >>> >> 6) >> ************* Module ipatests.test_integration.tasks >> ipatests/test_integration/tasks.py:85: [E1123(unexpected-keyword-arg), >> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function >> call) > > Fixed > >> >> > You did not send the patch but a swap file. From tbabej at redhat.com Fri Oct 23 13:36:13 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 23 Oct 2015 15:36:13 +0200 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A2314.6020006@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> <562A2314.6020006@redhat.com> Message-ID: <562A37CD.7030103@redhat.com> On 10/23/2015 02:07 PM, Petr Spacek wrote: > On 23.10.2015 13:53, Martin Basti wrote: >> >> >> On 23.10.2015 13:53, Tomas Babej wrote: >>> >>> On 10/23/2015 01:51 PM, Martin Basti wrote: >>>> >>>> On 23.10.2015 13:49, Tomas Babej wrote: >>>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>>>> >>>>>>>>>> I suggest to use names for domain levels: >>>>>>>>>> >>>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>>> >>>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>>> >>>>>>>>>> Benefits: >>>>>>>>>> * ability to grep it in code >>>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>>> >>>>>>>>>> * better readability in code >>>>>>>>> Sure, but random names are not appropriate imo >>>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>>>> >>>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>>>> not >>>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>>> >>>>>>>> Currently, those two coincide, but in general they might be >>>>>>>> different if >>>>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>>>> level >>>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>>> >>>>>>>> Tomas >>>>>>> Thank you all for your opinion, >>>>>>> >>>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>>> >>>>>>> Thanks. >>>>>>> Martin^2 >>>>>>> >>>>>> Patch attached. >>>>>> O hope, I did not miss anything hardcoded. >>>>> I think we can safely hardcode domain levels as numbers in the error >>>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>>>> message makes little sense to me, as the value of >>>>> constants.DOMAIN_LEVEL_0 will not ever change. >>>> However, with substituting is easier to find occurrences of domain >>>> levels in comments and messages in case of refactoring. >>> In case of refactoring of what? All the error messages containing >>> reference to a domain level 0? :) >> Exactly! :) > > Tomas, that one day we decide to drop support for domain level 0. We will have > to hunt down all references to it and using constant for help messages etc. > might be handy because it will show up in results of grep, so we do not forget > to wipe domain level 0 from texts. > I understand all that, but those error messages are in the conditional blocks that already include greppable references to the DOMAIN_LEVEL_0: So, to continue this bikeshedding of the highest possible level :) +if current != constants.DOMAIN_LEVEL_0: raise RuntimeError( "You cannot use a replica file to join a replica when the " "domain is above level 0. Please join the system to the " "domain is above level {dl}. Please join the system to the " "domain by running ipa-client-install first, the try again " - "without a replica file." + "without a replica file.".format(dl=constants.DOMAIN_LEVEL_0) ) and -if current == 0: +if current == constants.DOMAIN_LEVEL_0: raise RuntimeError( "You must provide a file generated by ipa-replica-prepare to " - "create a replica when the domain is at level 0." + "create a replica when the domain is at level {dl}.".format( + dl=constants.DOMAIN_LEVEL_0) ) I guess we would remove the whole blocks in these cases, hence formatters are needless complication of the code here. > > Nitpick just to make you feel that I read the patch (does not warrant a NACK): > I would rather see conditions in form of (<= or >=) instead of (< or >) > because now you have to grep for domain level +- 1 to get all references to > particular domain level :-D > > Nevermind, this is just a nitpick. > From tbordaz at redhat.com Fri Oct 23 13:34:05 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 23 Oct 2015 15:34:05 +0200 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <562A3862.3060102@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> <562A27CC.1070402@redhat.com> <562A33E1.4070507@redhat.com> <562A3862.3060102@redhat.com> Message-ID: <562A374D.2000207@redhat.com> On 10/23/2015 03:38 PM, Ludwig Krispenz wrote: > > On 10/23/2015 03:19 PM, thierry bordaz wrote: >> Hi Ludwig, >> >> Thanks for the patch. >> Yes it is looking good to me. Just a minor change about the message >> logged (if case of failure to add the cleanallruv task), you may >> recommend to the administrator the exact command to run. > no, also we do not know why it failed, there would be the option to do > it via ipa-replica-manage or ldapmodify, the logging that creating the > task failed should be be enough to start investigation and do a manual > cleanallruv Ok. I agree. Thanks >> >> ACK >> >> thanks >> thierry >> On 10/23/2015 02:27 PM, Ludwig Krispenz wrote: >>> Hi Thierry, >>> >>> hope this addresses your concerns >>> >>> Ludwig >>> >>> On 10/23/2015 11:24 AM, thierry bordaz wrote: >>>> On 10/23/2015 11:00 AM, thierry bordaz wrote: >>>>> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>>>>> >>>>>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>>>>> The attached patch moves the cleaning of the RUV into the >>>>>>>> topology plugin. >>>>>>>> >>>>>>>> I encountered a problem when removing a replica, which >>>>>>>> disconnects the topology, but it was fixed with my WIP for #5072. >>>>>>>> >>>>>>>> I want to keep these issues separate, so please review and test >>>>>>>> the patch and let me know about issues found >>>>>>>> >>>>>>>> Ludwig >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Is this patch still valid and pending review? >>>>>> it should be still valid, waiting for review, wanted to rebase >>>>>> after topology/promotion patches have been checked in and resend >>>>>> >>>>>> >>>>>> >>>>> Hello Ludwig, >>>>> >>>>> The patch looks good. I have few minor remarks: >>>>> >>>>> * Are the hostname in ruv always fqdn ? to retrieve the RUV >>>>> element of a given host you use 'strstr'. >>>>> If you have host vm-11 and vm-112, I wonder if it could pickup >>>>> the wrong RUV element >>>>> * In ipa_topo_util_cleanruv_element you need a pblock_done/free >>>>> (or destroy) >>>>> * In it fails to add the clearn-ruv task, you should log a >>>>> message so that the admin knows what to do. >>>>> >>>>> thanks >>>>> thierry >>>>> >>>>> >>>>> >>>> Hi Ludwig, >>>> >>>> Additional question. cleanruv is done with 'replica-force-cleaning: >>>> yes'. Currently ipa-replica-manage does not implement this flag. >>>> Why do you use it in topology plugin. >>>> My concern is that if we delete a host before all the updates from >>>> that host has been received, could we receive a late update that >>>> will recreate the ruv element ? >>>> >>>> thanks >>>> thierry >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Oct 23 14:57:49 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 Oct 2015 10:57:49 -0400 Subject: [Freeipa-devel] [PATCH] 924 use starttls in CSReplicationManager connection again In-Reply-To: <562A2A96.1080101@redhat.com> References: <562A2A96.1080101@redhat.com> Message-ID: <562A4AED.8090801@redhat.com> On 23/10/15 08:39, Petr Vobornik wrote: > not sure if the change in2606f5aecd6ac0db31abb515b691529bb7eaf14e was a > mistake or done on purpose. > > Anyway: > commit 2606f5aecd6ac0db31abb515b691529bb7eaf14e > > has: > - realm, hostname, dirman_passwd, port, starttls=True) > + realm, hostname, dirman_passwd, port) > > In CSReplicationManager > > which causes, e.g.: > > ipa-csreplica-manage -p Secret123 list ipa.example.com > cannot connect to 'ldaps://ipa.example.com:389': TLS error > -5938:Encountered end of file > > Attached patch reverts it. I am not sure it was a mistake, we have changed replication from using TLS to always use LDAP+GSSAPI, so why is ipa-csreplica-manage depending on ldaps anyway ? It may need to when dealing with very old domains where we have split instances for CS and IPA, but not in anything modern. I would rather change the command to cope with using LDAP+GSSAPI. A simple revert may break something in replica promotion, would need to be tested with a full master+replica install. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Oct 23 15:18:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Oct 2015 17:18:29 +0200 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <562A32ED.8030702@redhat.com> References: <5620D475.2030200@redhat.com> <562A3234.9040509@redhat.com> <562A32ED.8030702@redhat.com> Message-ID: <562A4FC5.6030603@redhat.com> On 23.10.2015 15:15, Martin Babinsky wrote: > On 10/23/2015 03:12 PM, Martin Babinsky wrote: >> On 10/16/2015 12:41 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5345 >>> >>> Patch attached. >>> >>> >> I have tested it on 4-2 branch and it works as expected, ACK. >> >> Obviously, master branch would require a different patch. >> > > I actually missed your check in ipaserver/install/kra.py which can > break ipa-replica-install with --setup-kra, so NACK. > Updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ipa42-mbasti-0327.2-KRA-fix-check-that-CA-is-installed.patch Type: text/x-patch Size: 2931 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-mbasti-0327.2-KRA-fix-check-that-CA-is-installed.patch Type: text/x-patch Size: 3369 bytes Desc: not available URL: From simo at redhat.com Fri Oct 23 15:26:34 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 Oct 2015 11:26:34 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa-ca-install bug #5397 Message-ID: <562A51AA.8070304@redhat.com> This patch moves the check to see if a CA is already installed locally early. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-553-1-Check-early-if-a-CA-is-already-installed-locally.patch Type: text/x-patch Size: 2006 bytes Desc: not available URL: From simo at redhat.com Fri Oct 23 15:37:40 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 Oct 2015 11:37:40 -0400 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A2314.6020006@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> <562A2314.6020006@redhat.com> Message-ID: <562A5444.3080604@redhat.com> On 23/10/15 08:07, Petr Spacek wrote: > On 23.10.2015 13:53, Martin Basti wrote: >> >> >> On 23.10.2015 13:53, Tomas Babej wrote: >>> >>> On 10/23/2015 01:51 PM, Martin Basti wrote: >>>> >>>> On 23.10.2015 13:49, Tomas Babej wrote: >>>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>>>> >>>>>>>>>> I suggest to use names for domain levels: >>>>>>>>>> >>>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>>> >>>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>>> >>>>>>>>>> Benefits: >>>>>>>>>> * ability to grep it in code >>>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>>> >>>>>>>>>> * better readability in code >>>>>>>>> Sure, but random names are not appropriate imo >>>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>>>> >>>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>>>> not >>>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>>> >>>>>>>> Currently, those two coincide, but in general they might be >>>>>>>> different if >>>>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>>>> level >>>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>>> >>>>>>>> Tomas >>>>>>> Thank you all for your opinion, >>>>>>> >>>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>>> >>>>>>> Thanks. >>>>>>> Martin^2 >>>>>>> >>>>>> Patch attached. >>>>>> O hope, I did not miss anything hardcoded. >>>>> I think we can safely hardcode domain levels as numbers in the error >>>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>>>> message makes little sense to me, as the value of >>>>> constants.DOMAIN_LEVEL_0 will not ever change. >>>> However, with substituting is easier to find occurrences of domain >>>> levels in comments and messages in case of refactoring. >>> In case of refactoring of what? All the error messages containing >>> reference to a domain level 0? :) >> Exactly! :) > > Tomas, that one day we decide to drop support for domain level 0. We will have > to hunt down all references to it and using constant for help messages etc. > might be handy because it will show up in results of grep, so we do not forget > to wipe domain level 0 from texts. > > > Nitpick just to make you feel that I read the patch (does not warrant a NACK): > I would rather see conditions in form of (<= or >=) instead of (< or >) > because now you have to grep for domain level +- 1 to get all references to > particular domain level :-D > > Nevermind, this is just a nitpick. If we are nitpicking rather than > DOMAIN_LEVEL_0 I would use != DOMAIN_LEVEL_0 we do not have negative levels anyway ... Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Oct 23 18:21:26 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Oct 2015 20:21:26 +0200 Subject: [Freeipa-devel] [PATCHES] 0743-0747 Python 3 porting Message-ID: <562A7AA6.5040504@redhat.com> Hello, Another batch of py3 porting patches. With these, the only thing to fix to get ipapython tests passing will be handling encoding/decoding for stdin/stdout/stderr for ipautil.run(). -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0743-ipapython.nsslib-ipalib.rpc-Remove-code-for-Python-2.patch Type: text/x-patch Size: 3867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0744-ipapython.nsslib-Remove-NSSHTTPS.patch Type: text/x-patch Size: 3910 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0745-ipapython.secrets-Port-to-Python-3.patch Type: text/x-patch Size: 1607 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0746-test_parameters-Alias-long-to-int-under-Python-3.patch Type: text/x-patch Size: 763 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0747-ipalib.rpc-Update-for-Python-3.patch Type: text/x-patch Size: 3160 bytes Desc: not available URL: From marc.boorshtein at tremolosecurity.com Mon Oct 26 01:17:01 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Sun, 25 Oct 2015 21:17:01 -0400 Subject: [Freeipa-devel] Trying to add an apache authentication endpoint to freeipa web ui Message-ID: All, I'm trying to build a new login endpoint that will create a session if apache has already authenticated the user. I've got ipa-server-4.1.0-18.el7.centos.4.x86_64 Installed. To add the endpoint I: 1. Added a class to /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py with: content_type = 'text/plain' key = '/session/login_apache' 2. /etc/httpd/conf.d/ipa.conf adding: AuthType TremoloLastMile TremoloHeaderName tremoloHeader TremoloUidAttributeName uid TremoloEncodedKey xxxxxxxxxxxxxxxxx TremoloCreateHeaders On Require valid-user 3. Set apache's loglevel to debug 4. Restart Apache This is on CentOS Linux release 7.1.1503 (Core). When I try to hit /ipa/service/login_apache I get a 401. None of the debug log messages appear in /var/log/httpd/error_log. I have a few questions: 1. Where are the debug logs? I see references to self.debug(...) but I don't know where they go. 2. Am I on the right direction? I'm new to python w/wsgi so forgive me if I'm missing something obvious. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com From ofayans at redhat.com Mon Oct 26 07:59:10 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 26 Oct 2015 08:59:10 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562A31C1.5050105@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> Message-ID: <562DDD4E.5020801@redhat.com> On 10/23/2015 03:10 PM, Martin Basti wrote: > > > On 23.10.2015 15:00, Oleg Fayans wrote: >> Hi Martin, >> >> Here comes the updated version. >> >> On 10/22/2015 05:38 PM, Martin Basti wrote: >>> >>> >>> On 22.10.2015 15:23, Martin Basti wrote: >>>> >>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>> >>>>> >>>>> >>>> >>>> Hello, >>>> >>>> thank you for the patch. >>>> >>>> 1) >>>> please remove the added empty lines, they are unrelated to this ticket >> >> done >> >>>> >>>> 2) >>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>> domainlevel=1): >>>> >>>> I suggest to use default domainlevel=None, which will use the default >>>> domain level (specified in build) >> >> done >> >>>> >>>> 3) >>>> + domain_level = domainlevel(master) >>>> I do not think that this meets expectations. >>>> >>>> We have to test, both domain level 0 and 1 for IPA 4.3, respectively >>>> new IPA must support all older domain levels, domain level is >>>> independent on IPA version, only admin can raise it up. >>>> >>>> So you have to find out way how to pass the domain level for which >>>> test will be running, we were talking about using config files, but >>>> feel free to find something new and better >> >> Fixed. Now, we declare domain level in config.yaml with the directive >> domain_level >> >>>> >>>> 4) >>>> Did you resolve the pytest fixtures which specifies which tests can be >>>> run under which domain level? >> >> In fact, we do not seem to have any tests yet that would require it. >> All the existing tests just use install_replica >> method, no matter how is it done. > How about topology CI test? This can be executed only with domain level That's right. The topology test was updated. Patch is attached together with a proper version of 11-th patch (not a swap file, sorry about that). > 1, right? >> >>>> >>>> 5) >>>> + '--ip-address', client.ip, >>>> >>>> why this change to client install? >> >> Right, it found to be unnecessary. >> >>>> >>>> Martin^2 >>>> >>>> >>> 6) >>> ************* Module ipatests.test_integration.tasks >>> ipatests/test_integration/tasks.py:85: [E1123(unexpected-keyword-arg), >>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function >>> call) >> >> Fixed >> >>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0011.1-replica-promotion-changes-in-tests.patch Type: text/x-patch Size: 5297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0012-The-test-was-made-to-be-skipped-if-domainlevel-is-0.patch Type: text/x-patch Size: 1075 bytes Desc: not available URL: From ldoudova at redhat.com Mon Oct 26 08:01:29 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 26 Oct 2015 09:01:29 +0100 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker In-Reply-To: <56271A5E.3010608@redhat.com> References: <5624C63D.5020000@redhat.com> <5624DF10.4060000@redhat.com> <56264753.1000405@redhat.com> <562669F8.3060502@redhat.com> <56271A5E.3010608@redhat.com> Message-ID: <562DDDD9.1060503@redhat.com> On 10/21/2015 06:53 AM, Lenka Doudova wrote: > > > On 10/20/2015 06:21 PM, Martin Basti wrote: >> >> >> On 20.10.2015 15:53, Martin Basti wrote: >>> >>> >>> On 19.10.2015 14:16, Martin Basti wrote: >>>> >>>> >>>> On 19.10.2015 12:30, Martin Basti wrote: >>>>> Attribute nsaccountlock has not been processed correctly >>>>> >>>>> Patch attached. >>>>> >>>>> >>>> >>>> Self-NACK, more fixes required >>>> >>>> >>>> >>> Updated patch attached, but it still needs to improve because tests >>> in my patch 331 are still failing. >>> >> >> Eternal self-NACK for this patch >> >> I'm not able to fix UserTracker, I need help from somebody with >> higher view of how this tracker is supposed to work. >> Follow my patch 0331 > > Hi, I'll take a look at it today. > Lenka > > Hi, I fixed the trackers and tests, rebased patch attached. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0005-Fix-user-and-stageuser-trackers.patch Type: text/x-patch Size: 12678 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 26 08:28:32 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 26 Oct 2015 09:28:32 +0100 Subject: [Freeipa-devel] [PATCH 0336] Remove executable bit from ipa_kra_install.py Message-ID: <562DE430.9070209@redhat.com> The executable bit has been added with one of replica promotion patches, this patch reverts it. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0336-Remove-executable-bit-from-ipa_kra_install.py.patch Type: text/x-patch Size: 507 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Oct 26 08:53:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 26 Oct 2015 09:53:39 +0100 Subject: [Freeipa-devel] [PATCHES 0375-0376] Perform validation of the trust in the trustdomain commands In-Reply-To: <562A3551.6000705@redhat.com> References: <562A3551.6000705@redhat.com> Message-ID: <562DEA13.6020601@redhat.com> On 10/23/2015 03:25 PM, Tomas Babej wrote: > Details in the commit messages. > > Fixes: https://fedorahosted.org/freeipa/ticket/5389 > > Tomas > > > ACK -- Martin^3 Babinsky From abokovoy at redhat.com Mon Oct 26 09:18:01 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 26 Oct 2015 11:18:01 +0200 Subject: [Freeipa-devel] [PATCH 0336] Remove executable bit from ipa_kra_install.py In-Reply-To: <562DE430.9070209@redhat.com> References: <562DE430.9070209@redhat.com> Message-ID: <20151026091801.GD6367@redhat.com> On Mon, 26 Oct 2015, Martin Basti wrote: >The executable bit has been added with one of replica promotion >patches, this patch reverts it. > >Patch attached. ACK. -- / Alexander Bokovoy From mbabinsk at redhat.com Mon Oct 26 09:35:42 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 26 Oct 2015 10:35:42 +0100 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <562A4FC5.6030603@redhat.com> References: <5620D475.2030200@redhat.com> <562A3234.9040509@redhat.com> <562A32ED.8030702@redhat.com> <562A4FC5.6030603@redhat.com> Message-ID: <562DF3EE.1090708@redhat.com> On 10/23/2015 05:18 PM, Martin Basti wrote: > > > On 23.10.2015 15:15, Martin Babinsky wrote: >> On 10/23/2015 03:12 PM, Martin Babinsky wrote: >>> On 10/16/2015 12:41 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5345 >>>> >>>> Patch attached. >>>> >>>> >>> I have tested it on 4-2 branch and it works as expected, ACK. >>> >>> Obviously, master branch would require a different patch. >>> >> >> I actually missed your check in ipaserver/install/kra.py which can >> break ipa-replica-install with --setup-kra, so NACK. >> > Updated patches attached. NACK on the master-branch patch. You forgot a 'return' in this code snippet: + if self.installing_replica: + domain_level = dsinstance.get_domain_level(api) + if domain_level > DOMAIN_LEVEL_0: + self.options.promote = True + return that would make installation abort when domain level is greter than zero. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Oct 26 11:18:08 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 26 Oct 2015 12:18:08 +0100 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <562A4FC5.6030603@redhat.com> References: <5620D475.2030200@redhat.com> <562A3234.9040509@redhat.com> <562A32ED.8030702@redhat.com> <562A4FC5.6030603@redhat.com> Message-ID: <562E0BF0.2060702@redhat.com> On 10/23/2015 05:18 PM, Martin Basti wrote: > > > On 23.10.2015 15:15, Martin Babinsky wrote: >> On 10/23/2015 03:12 PM, Martin Babinsky wrote: >>> On 10/16/2015 12:41 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5345 >>>> >>>> Patch attached. >>>> >>>> >>> I have tested it on 4-2 branch and it works as expected, ACK. >>> >>> Obviously, master branch would require a different patch. >>> >> >> I actually missed your check in ipaserver/install/kra.py which can >> break ipa-replica-install with --setup-kra, so NACK. >> > Updated patches attached. 4-2 branch patch works as expected, ACK. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Oct 26 12:41:46 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 26 Oct 2015 13:41:46 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <5628EF01.3080809@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> Message-ID: <562E1F8A.8030202@redhat.com> On 10/22/2015 04:13 PM, Martin Basti wrote: > > > On 22.10.2015 10:44, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5181 >> >> >> > > Thank you for the patch. > > 1) > +OPTIONAL_SERVICES = { > + 'DNS', > + 'CA', > + 'KRA', > + 'ADTRUST', > + 'EXTID', > + 'DNSKeyExporter', > + 'DNSSEC', > + 'DNSKeySync', > +} > > This did not scale well, maybe we should improve it to use some general > solution for whole IPA to distinct mandratory and optionl service, but I > do not know how (or if it is possible) > Yes this does not scale well. After some playing around with relocating the SERVICE_LIST object in 'ipaserver/install/service.py' I found out that more refactoring would be needed to improve the layout and availability of LDAP service names to both server and client code. I have put the list of core services to ipalib/constants.py for now, and I suggest to open a separate ticket for more general solution. > 2) > + search_filter=('(&(objectclass=ipaConfigObject)' > + '(ipaConfigString=enabledService))') > > Common user cannot read ipaConfigString, so this will work only for > admins, I do not see any limitations of access in code for other users. > I think that you agreed with Petr^2 that this filter is OK. I left it as it is but I have rewritten it as a call to ldap.make_filter to improve readability and/or potential extensibility a bit. > 3) > + opt_components = [ > + r['cn'][0] for r in result if r['cn'][0] in OPTIONAL_SERVICES > + ] > Probably instead of indexing, you may use result.single_value['cn'] > > Martin^2 Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0090.1-show-optionally-configured-components-in-server-find.patch Type: text/x-patch Size: 3421 bytes Desc: not available URL: From tbabej at redhat.com Mon Oct 26 13:12:53 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 26 Oct 2015 14:12:53 +0100 Subject: [Freeipa-devel] [PATCHES 0375-0376] Perform validation of the trust in the trustdomain commands In-Reply-To: <562DEA13.6020601@redhat.com> References: <562A3551.6000705@redhat.com> <562DEA13.6020601@redhat.com> Message-ID: <562E26D5.2010202@redhat.com> On 10/26/2015 09:53 AM, Martin Babinsky wrote: > On 10/23/2015 03:25 PM, Tomas Babej wrote: >> Details in the commit messages. >> >> Fixes: https://fedorahosted.org/freeipa/ticket/5389 >> >> Tomas >> >> >> > ACK > Pushed to ipa-4-2: b0aea244592f15974ce76151c772e6dcb5668c83 Pushed to master: 8d291c6467961d40d8b1bc9d83c8884d40c42685 From mbasti at redhat.com Mon Oct 26 17:01:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 26 Oct 2015 18:01:48 +0100 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A37CD.7030103@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> <562A2314.6020006@redhat.com> <562A37CD.7030103@redhat.com> Message-ID: <562E5C7C.4080305@redhat.com> On 23.10.2015 15:36, Tomas Babej wrote: > > On 10/23/2015 02:07 PM, Petr Spacek wrote: >> On 23.10.2015 13:53, Martin Basti wrote: >>> >>> On 23.10.2015 13:53, Tomas Babej wrote: >>>> On 10/23/2015 01:51 PM, Martin Basti wrote: >>>>> On 23.10.2015 13:49, Tomas Babej wrote: >>>>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>>>> Hello all, >>>>>>>>>>> >>>>>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>>>>> >>>>>>>>>>> I suggest to use names for domain levels: >>>>>>>>>>> >>>>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>>>> >>>>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>>>> >>>>>>>>>>> Benefits: >>>>>>>>>>> * ability to grep it in code >>>>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>>>> >>>>>>>>>>> * better readability in code >>>>>>>>>> Sure, but random names are not appropriate imo >>>>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>>>>> >>>>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>>>>> not >>>>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>>>> >>>>>>>>> Currently, those two coincide, but in general they might be >>>>>>>>> different if >>>>>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>>>>> level >>>>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> Thank you all for your opinion, >>>>>>>> >>>>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Martin^2 >>>>>>>> >>>>>>> Patch attached. >>>>>>> O hope, I did not miss anything hardcoded. >>>>>> I think we can safely hardcode domain levels as numbers in the error >>>>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>>>>> message makes little sense to me, as the value of >>>>>> constants.DOMAIN_LEVEL_0 will not ever change. >>>>> However, with substituting is easier to find occurrences of domain >>>>> levels in comments and messages in case of refactoring. >>>> In case of refactoring of what? All the error messages containing >>>> reference to a domain level 0? :) >>> Exactly! :) >> Tomas, that one day we decide to drop support for domain level 0. We will have >> to hunt down all references to it and using constant for help messages etc. >> might be handy because it will show up in results of grep, so we do not forget >> to wipe domain level 0 from texts. >> > I understand all that, but those error messages are in the conditional > blocks that already include greppable references to the DOMAIN_LEVEL_0: > > So, to continue this bikeshedding of the highest possible level :) > > > > +if current != constants.DOMAIN_LEVEL_0: > raise RuntimeError( > "You cannot use a replica file to join a replica when the " > "domain is above level 0. Please join the system to the " > "domain is above level {dl}. Please join the system to the " > "domain by running ipa-client-install first, the try again " > - "without a replica file." > + "without a replica file.".format(dl=constants.DOMAIN_LEVEL_0) > ) > > and > > -if current == 0: > +if current == constants.DOMAIN_LEVEL_0: > raise RuntimeError( > "You must provide a file generated by ipa-replica-prepare to " > - "create a replica when the domain is at level 0." > + "create a replica when the domain is at level {dl}.".format( > + dl=constants.DOMAIN_LEVEL_0) > ) > > I guess we would remove the whole blocks in these cases, hence > formatters are needless complication of the code here. > > > >> Nitpick just to make you feel that I read the patch (does not warrant a NACK): >> I would rather see conditions in form of (<= or >=) instead of (< or >) >> because now you have to grep for domain level +- 1 to get all references to >> particular domain level :-D >> >> Nevermind, this is just a nitpick. >> Patch with removed changes in error messages is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0335.2-Domain-levels-use-constants-rather-than-hardcoded-va.patch Type: text/x-patch Size: 8746 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 26 17:05:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 26 Oct 2015 18:05:36 +0100 Subject: [Freeipa-devel] [PATCH 0329] Tests: fix user tracker In-Reply-To: <562DDDD9.1060503@redhat.com> References: <5624C63D.5020000@redhat.com> <5624DF10.4060000@redhat.com> <56264753.1000405@redhat.com> <562669F8.3060502@redhat.com> <56271A5E.3010608@redhat.com> <562DDDD9.1060503@redhat.com> Message-ID: <562E5D60.4040102@redhat.com> On 26.10.2015 09:01, Lenka Doudova wrote: > > > On 10/21/2015 06:53 AM, Lenka Doudova wrote: >> >> >> On 10/20/2015 06:21 PM, Martin Basti wrote: >>> >>> >>> On 20.10.2015 15:53, Martin Basti wrote: >>>> >>>> >>>> On 19.10.2015 14:16, Martin Basti wrote: >>>>> >>>>> >>>>> On 19.10.2015 12:30, Martin Basti wrote: >>>>>> Attribute nsaccountlock has not been processed correctly >>>>>> >>>>>> Patch attached. >>>>>> >>>>>> >>>>> >>>>> Self-NACK, more fixes required >>>>> >>>>> >>>>> >>>> Updated patch attached, but it still needs to improve because tests >>>> in my patch 331 are still failing. >>>> >>> >>> Eternal self-NACK for this patch >>> >>> I'm not able to fix UserTracker, I need help from somebody with >>> higher view of how this tracker is supposed to work. >>> Follow my patch 0331 >> >> Hi, I'll take a look at it today. >> Lenka >> >> > Hi, > > I fixed the trackers and tests, rebased patch attached. > Lenka > > Thank you, 1) ************* Module ipatests.test_xmlrpc.test_stageuser_plugin ipatests/test_xmlrpc/test_stageuser_plugin.py:938: [E0102(function-redefined), TestMultipleManagers] class already defined line 913) 2) Because the patch contains tests too, I suggest to rename patch to Multiple manager per user tests. Also you should change commiter of patch to you. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 26 17:08:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 26 Oct 2015 18:08:57 +0100 Subject: [Freeipa-devel] [PATCH 0336] Remove executable bit from ipa_kra_install.py In-Reply-To: <20151026091801.GD6367@redhat.com> References: <562DE430.9070209@redhat.com> <20151026091801.GD6367@redhat.com> Message-ID: <562E5E29.1010703@redhat.com> On 26.10.2015 10:18, Alexander Bokovoy wrote: > On Mon, 26 Oct 2015, Martin Basti wrote: >> The executable bit has been added with one of replica promotion >> patches, this patch reverts it. >> >> Patch attached. > ACK. > Pushed to master: 1195278f6b3b2d6fb5de94bb5556b6a4bc4afc5a From mbasti at redhat.com Mon Oct 26 17:12:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 26 Oct 2015 18:12:07 +0100 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <562A374D.2000207@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> <562A27CC.1070402@redhat.com> <562A33E1.4070507@redhat.com> <562A3862.3060102@redhat.com> <562A374D.2000207@redhat.com> Message-ID: <562E5EE7.9050306@redhat.com> On 23.10.2015 15:34, thierry bordaz wrote: > On 10/23/2015 03:38 PM, Ludwig Krispenz wrote: >> >> On 10/23/2015 03:19 PM, thierry bordaz wrote: >>> Hi Ludwig, >>> >>> Thanks for the patch. >>> Yes it is looking good to me. Just a minor change about the message >>> logged (if case of failure to add the cleanallruv task), you may >>> recommend to the administrator the exact command to run. >> no, also we do not know why it failed, there would be the option to >> do it via ipa-replica-manage or ldapmodify, the logging that creating >> the task failed should be be enough to start investigation and do a >> manual cleanallruv > > Ok. I agree. Thanks >>> >>> ACK >>> >>> thanks >>> thierry >>> On 10/23/2015 02:27 PM, Ludwig Krispenz wrote: >>>> Hi Thierry, >>>> >>>> hope this addresses your concerns >>>> >>>> Ludwig >>>> >>>> On 10/23/2015 11:24 AM, thierry bordaz wrote: >>>>> On 10/23/2015 11:00 AM, thierry bordaz wrote: >>>>>> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>>>>>> >>>>>>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>>>>>> The attached patch moves the cleaning of the RUV into the >>>>>>>>> topology plugin. >>>>>>>>> >>>>>>>>> I encountered a problem when removing a replica, which >>>>>>>>> disconnects the topology, but it was fixed with my WIP for #5072. >>>>>>>>> >>>>>>>>> I want to keep these issues separate, so please review and >>>>>>>>> test the patch and let me know about issues found >>>>>>>>> >>>>>>>>> Ludwig >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Is this patch still valid and pending review? >>>>>>> it should be still valid, waiting for review, wanted to rebase >>>>>>> after topology/promotion patches have been checked in and resend >>>>>>> >>>>>>> >>>>>>> >>>>>> Hello Ludwig, >>>>>> >>>>>> The patch looks good. I have few minor remarks: >>>>>> >>>>>> * Are the hostname in ruv always fqdn ? to retrieve the RUV >>>>>> element of a given host you use 'strstr'. >>>>>> If you have host vm-11 and vm-112, I wonder if it could >>>>>> pickup the wrong RUV element >>>>>> * In ipa_topo_util_cleanruv_element you need a pblock_done/free >>>>>> (or destroy) >>>>>> * In it fails to add the clearn-ruv task, you should log a >>>>>> message so that the admin knows what to do. >>>>>> >>>>>> thanks >>>>>> thierry >>>>>> >>>>>> >>>>>> >>>>> Hi Ludwig, >>>>> >>>>> Additional question. cleanruv is done with >>>>> 'replica-force-cleaning: yes'. Currently ipa-replica-manage does >>>>> not implement this flag. >>>>> Why do you use it in topology plugin. >>>>> My concern is that if we delete a host before all the updates from >>>>> that host has been received, could we receive a late update that >>>>> will recreate the ruv element ? >>>>> >>>>> thanks >>>>> thierry >>>> >>> >> > > > Pushed to master: 26bfc914d97f8698f294967e9812b0a7ebc4bce6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Oct 26 17:48:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 26 Oct 2015 18:48:26 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562DDD4E.5020801@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> Message-ID: <562E676A.7040207@redhat.com> On 26.10.2015 08:59, Oleg Fayans wrote: > > > On 10/23/2015 03:10 PM, Martin Basti wrote: >> >> >> On 23.10.2015 15:00, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Here comes the updated version. >>> >>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>> >>>> >>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>> >>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>> >>>>>> >>>>>> >>>>> >>>>> Hello, >>>>> >>>>> thank you for the patch. >>>>> >>>>> 1) >>>>> please remove the added empty lines, they are unrelated to this >>>>> ticket >>> >>> done >>> >>>>> >>>>> 2) >>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>> domainlevel=1): >>>>> >>>>> I suggest to use default domainlevel=None, which will use the default >>>>> domain level (specified in build) >>> >>> done >>> >>>>> >>>>> 3) >>>>> + domain_level = domainlevel(master) >>>>> I do not think that this meets expectations. >>>>> >>>>> We have to test, both domain level 0 and 1 for IPA 4.3, respectively >>>>> new IPA must support all older domain levels, domain level is >>>>> independent on IPA version, only admin can raise it up. >>>>> >>>>> So you have to find out way how to pass the domain level for which >>>>> test will be running, we were talking about using config files, but >>>>> feel free to find something new and better >>> >>> Fixed. Now, we declare domain level in config.yaml with the directive >>> domain_level >>> >>>>> >>>>> 4) >>>>> Did you resolve the pytest fixtures which specifies which tests >>>>> can be >>>>> run under which domain level? >>> >>> In fact, we do not seem to have any tests yet that would require it. >>> All the existing tests just use install_replica >>> method, no matter how is it done. >> How about topology CI test? This can be executed only with domain level > > That's right. The topology test was updated. Patch is attached > together with a proper version of 11-th patch (not a swap file, sorry > about that). > >> 1, right? >>> >>>>> >>>>> 5) >>>>> + '--ip-address', client.ip, >>>>> >>>>> why this change to client install? >>> >>> Right, it found to be unnecessary. >>> >>>>> >>>>> Martin^2 >>>>> >>>>> >>>> 6) >>>> ************* Module ipatests.test_integration.tasks >>>> ipatests/test_integration/tasks.py:85: [E1123(unexpected-keyword-arg), >>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function >>>> call) >>> >>> Fixed >>> >>>> >>>> >>> >> > 1) + if not host.config.domain_level == None: + args.append("--domain-level=%i" % host.config.domain_level) always use: variable *is not None* 2) Why there is specified level 1 as default? IIRC we agreed that the default level is the one which is default in tested package. These should be None and "": + "domain_level": "1" + "DOMAINLVL": "1", 3) However, as I read the patch 12, and I'm right, the pytest.fixture needs to know the value of domain level before we can do any dynamic detection on master. So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) Also I'm not sure if the values are inherited from the DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part you need default value, or the fixture will not work as expected. + self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) freeipa-tests depends on freeipa-python so the constants should be available in tests. So then you also need update this line + if not host.config.domain_level != MAX_DOMAIN_LEVEL: + args.append("--domain-level=%i" % host.config.domain_level) 4) Please add comment to function +def domainlevel(host): that it is useful for test where domain level will be raised dynamically, otherwise it may be lost after test refactoring as somebody may consider it as unneeded and replace it with config dict. So summary is the 1) and 2) are replaced by 3) :) Martin^2 From mareynol at redhat.com Mon Oct 26 18:45:14 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Mon, 26 Oct 2015 14:45:14 -0400 Subject: [Freeipa-devel] [PATCH 0019] handle cleanRUV in the topology plugin In-Reply-To: <562A0E44.1020307@redhat.com> References: <55B0A9F0.4010602@redhat.com> <561B8F0B.4070907@redhat.com> <561B96CE.9060404@redhat.com> <5629F72D.9020807@redhat.com> <5629FCE7.9070709@redhat.com> <562A0E44.1020307@redhat.com> Message-ID: <562E74BA.9030003@redhat.com> On 10/23/2015 06:39 AM, Ludwig Krispenz wrote: > > On 10/23/2015 11:24 AM, thierry bordaz wrote: >> On 10/23/2015 11:00 AM, thierry bordaz wrote: >>> On 10/12/2015 01:17 PM, Ludwig Krispenz wrote: >>>> >>>> On 10/12/2015 12:44 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 23.07.2015 10:46, Ludwig Krispenz wrote: >>>>>> The attached patch moves the cleaning of the RUV into the >>>>>> topology plugin. >>>>>> >>>>>> I encountered a problem when removing a replica, which >>>>>> disconnects the topology, but it was fixed with my WIP for #5072. >>>>>> >>>>>> I want to keep these issues separate, so please review and test >>>>>> the patch and let me know about issues found >>>>>> >>>>>> Ludwig >>>>>> >>>>>> >>>>> >>>>> Is this patch still valid and pending review? >>>> it should be still valid, waiting for review, wanted to rebase >>>> after topology/promotion patches have been checked in and resend >>>> >>>> >>>> >>> Hello Ludwig, >>> >>> The patch looks good. I have few minor remarks: >>> >>> * Are the hostname in ruv always fqdn ? to retrieve the RUV >>> element of a given host you use 'strstr'. >>> If you have host vm-11 and vm-112, I wonder if it could pickup >>> the wrong RUV element >>> * In ipa_topo_util_cleanruv_element you need a pblock_done/free >>> (or destroy) >>> * In it fails to add the clearn-ruv task, you should log a message >>> so that the admin knows what to do. >>> >>> thanks >>> thierry >>> >>> >>> >> Hi Ludwig, >> > I will adress the points raised, thank you >> Additional question. cleanruv is done with 'replica-force-cleaning: >> yes'. Currently ipa-replica-manage does not implement this flag. >> Why do you use it in topology plugin. > there are two potential problems with the cleanallruv task: > 1] the rid could come back if not all servers were in sync, but with > cleaning the changelog as part of cleanallruv I think the ris is low now > 2] the cleanallruv is stuck on waiting for the task to complete on > other servers even if they cannot be reached The fix/rfe to cleanallruv that allows the force option to skip the online replica checks(https://fedorahosted.org/389/ticket/48218) has not been pushed yet. Currently its set for 1.3.5. FYI, Mark > > I want to avoid 2] therefore I choose this setting >> My concern is that if we delete a host before all the updates from >> that host has been received, could we receive a late update that will >> recreate the ruv element ? >> >> thanks >> thierry > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrniranjan at fedoraproject.org Mon Oct 26 19:59:59 2015 From: mrniranjan at fedoraproject.org (Niranjan) Date: Tue, 27 Oct 2015 01:29:59 +0530 Subject: [Freeipa-devel] [PATCH] enable pem=True in export_pem_cert function Message-ID: <20151026195959.GA20574@mniranja.pnq.redhat.com> Greetings, export_pem_cert function from ipapython/certdb should export the certificate in pem format but instead exports the cert in der format as it doesn't enable pem=True. This patch specifies pem=True for export_pem_cert function Regards Niranjan -------------- next part -------------- From 85c28405e80efbf65c013f3b615bdacee12856b5 Mon Sep 17 00:00:00 2001 From: Niranjan MR Date: Tue, 27 Oct 2015 01:22:05 +0530 Subject: [PATCH] enable pem=True in export_pem_cert function export_pem_cert should export the certificate in pem format but instead exports the cert in der format as it doesn't enable pem=True. This patch specifies pem=True for export_pem_cert function Signed-off-by: Niranjan MR --- ipapython/certdb.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipapython/certdb.py b/ipapython/certdb.py index d6de01100f323c4aa318dc78aabd39b35501f008..704bae528b44a3a3b978d25982a7e75a8e3af0f6 100644 --- a/ipapython/certdb.py +++ b/ipapython/certdb.py @@ -417,7 +417,7 @@ class NSSDatabase(object): def export_pem_cert(self, nickname, location): """Export the given cert to PEM file in the given location""" - cert = self.get_cert(nickname) + cert = self.get_cert(nickname, pem=True) with open(location, "w+") as fd: fd.write(cert) os.chmod(location, 0o444) -- 1.9.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 27 08:59:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 09:59:48 +0100 Subject: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test In-Reply-To: <562A218D.6070207@redhat.com> References: <5603F13E.4060805@redhat.com> <560BD9C8.2070205@redhat.com> <5620FEF1.70808@redhat.com> <5624D61E.20106@redhat.com> <5625F493.9020109@redhat.com> <56263155.4000608@redhat.com> <562A218D.6070207@redhat.com> Message-ID: <562F3D04.1080107@redhat.com> On 23.10.2015 14:01, Milan Kub?k wrote: > On 10/20/2015 02:19 PM, Martin Basti wrote: >> >> NACK >> >> >> >> 1) >> >> I still see many hardcoded passwords in the code >> >> with change_principal(smime_user, "Secret123"): >> > For now changed to module variable. >> >> >> 2) >> >> Also the 'alice' username can be extracted to module variable >> instead hardcoding >> >> > The fixture should take the place of module variables in the tests. > Changed u'alice' into local variable. > Once we fix the problems with UserTracker, we should store the > password here as well. >> >> 3) >> >> File alice.conf.tmpl can be generalized to be used for more users, >> replace alice in template to {username} and in code replace this >> variable with alice, also do not forgot rename template to something >> more general >> >> >> > Done. >> >> >> >> >> >> >> > > Updated patch set attached. > ACK Pushed to master: 5ab0fcabf3e6ac7970c1803893717301a4b4cfe8 Pushed to ipa-4-2: 21fed035beab7dbee59f1e0c29d203345f0d0c7f From ofayans at redhat.com Tue Oct 27 09:00:12 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 27 Oct 2015 10:00:12 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562E676A.7040207@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> Message-ID: <562F3D1C.6070901@redhat.com> Hi Martin, The updated version of the patch is attached. Please, see my comments below On 10/26/2015 06:48 PM, Martin Basti wrote: > > > On 26.10.2015 08:59, Oleg Fayans wrote: >> >> >> On 10/23/2015 03:10 PM, Martin Basti wrote: >>> >>> >>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Here comes the updated version. >>>> >>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>> >>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> thank you for the patch. >>>>>> >>>>>> 1) >>>>>> please remove the added empty lines, they are unrelated to this >>>>>> ticket >>>> >>>> done >>>> >>>>>> >>>>>> 2) >>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>> domainlevel=1): >>>>>> >>>>>> I suggest to use default domainlevel=None, which will use the default >>>>>> domain level (specified in build) >>>> >>>> done >>>> >>>>>> >>>>>> 3) >>>>>> + domain_level = domainlevel(master) >>>>>> I do not think that this meets expectations. >>>>>> >>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, respectively >>>>>> new IPA must support all older domain levels, domain level is >>>>>> independent on IPA version, only admin can raise it up. >>>>>> >>>>>> So you have to find out way how to pass the domain level for which >>>>>> test will be running, we were talking about using config files, but >>>>>> feel free to find something new and better >>>> >>>> Fixed. Now, we declare domain level in config.yaml with the directive >>>> domain_level >>>> >>>>>> >>>>>> 4) >>>>>> Did you resolve the pytest fixtures which specifies which tests >>>>>> can be >>>>>> run under which domain level? >>>> >>>> In fact, we do not seem to have any tests yet that would require it. >>>> All the existing tests just use install_replica >>>> method, no matter how is it done. >>> How about topology CI test? This can be executed only with domain level >> >> That's right. The topology test was updated. Patch is attached >> together with a proper version of 11-th patch (not a swap file, sorry >> about that). >> >>> 1, right? >>>> >>>>>> >>>>>> 5) >>>>>> + '--ip-address', client.ip, >>>>>> >>>>>> why this change to client install? >>>> >>>> Right, it found to be unnecessary. >>>> >>>>>> >>>>>> Martin^2 >>>>>> >>>>>> >>>>> 6) >>>>> ************* Module ipatests.test_integration.tasks >>>>> ipatests/test_integration/tasks.py:85: [E1123(unexpected-keyword-arg), >>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function >>>>> call) >>>> >>>> Fixed >>>> >>>>> >>>>> >>>> >>> >> > > 1) > + if not host.config.domain_level == None: > + args.append("--domain-level=%i" % host.config.domain_level) > > always use: variable *is not None* > > 2) > Why there is specified level 1 as default? IIRC we agreed that the > default level is the one which is default in tested package. > These should be None and "": > + "domain_level": "1" > > + "DOMAINLVL": "1", > > 3) > However, as I read the patch 12, and I'm right, the pytest.fixture needs > to know the value of domain level before we can do any dynamic detection > on master. > > So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) Done > > Also I'm not sure if the values are inherited from the > DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part you > need default value, or the fixture will not work as expected. > + self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) This won't work in cases when domainlevel is explicitly set to 0 in config.yaml. This default value will always override the explicit one. > > freeipa-tests depends on freeipa-python so the constants should be > available in tests. > > So then you also need update this line > > + if not host.config.domain_level != MAX_DOMAIN_LEVEL: > + args.append("--domain-level=%i" % host.config.domain_level) This would not work if domainlevel is not set in config.yaml, in which case the host.config.domain_level is None. > > 4) > Please add comment to function +def domainlevel(host): that it is useful > for test where domain level will be raised dynamically, otherwise it may > be lost after test refactoring as somebody may consider it as unneeded > and replace it with config dict. Done > > So summary is the 1) and 2) are replaced by 3) :) > > Martin^2 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0011.2-replica-promotion-changes-in-tests.patch Type: text/x-patch Size: 5746 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 27 09:12:40 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Oct 2015 10:12:40 +0100 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562A2314.6020006@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> <562A2314.6020006@redhat.com> Message-ID: <562F4008.9020506@redhat.com> On 23.10.2015 14:07, Petr Spacek wrote: > On 23.10.2015 13:53, Martin Basti wrote: >> >> >> On 23.10.2015 13:53, Tomas Babej wrote: >>> >>> On 10/23/2015 01:51 PM, Martin Basti wrote: >>>> >>>> On 23.10.2015 13:49, Tomas Babej wrote: >>>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>>>> >>>>>>>>>> I suggest to use names for domain levels: >>>>>>>>>> >>>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>>> >>>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>>> >>>>>>>>>> Benefits: >>>>>>>>>> * ability to grep it in code >>>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>>> >>>>>>>>>> * better readability in code >>>>>>>>> Sure, but random names are not appropriate imo >>>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>>>> >>>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>>>> not >>>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>>> >>>>>>>> Currently, those two coincide, but in general they might be >>>>>>>> different if >>>>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>>>> level >>>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>>> >>>>>>>> Tomas >>>>>>> Thank you all for your opinion, >>>>>>> >>>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>>> >>>>>>> Thanks. >>>>>>> Martin^2 >>>>>>> >>>>>> Patch attached. >>>>>> O hope, I did not miss anything hardcoded. >>>>> I think we can safely hardcode domain levels as numbers in the error >>>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>>>> message makes little sense to me, as the value of >>>>> constants.DOMAIN_LEVEL_0 will not ever change. >>>> However, with substituting is easier to find occurrences of domain >>>> levels in comments and messages in case of refactoring. >>> In case of refactoring of what? All the error messages containing >>> reference to a domain level 0? :) >> Exactly! :) > > Tomas, that one day we decide to drop support for domain level 0. We will have > to hunt down all references to it and using constant for help messages etc. > might be handy because it will show up in results of grep, so we do not forget > to wipe domain level 0 from texts. > > > Nitpick just to make you feel that I read the patch (does not warrant a NACK): > I would rather see conditions in form of (<= or >=) instead of (< or >) > because now you have to grep for domain level +- 1 to get all references to > particular domain level :-D > > Nevermind, this is just a nitpick. ACK, I did not find any breakage. -- Petr^2 Spacek From mbasti at redhat.com Tue Oct 27 09:22:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 10:22:21 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F3D1C.6070901@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> Message-ID: <562F424D.3060003@redhat.com> On 27.10.2015 10:00, Oleg Fayans wrote: > Hi Martin, > > The updated version of the patch is attached. Please, see my comments > below My comments inline, I may be completely wrong in how the test suite work, so feel free to correct me. Martin > > On 10/26/2015 06:48 PM, Martin Basti wrote: >> >> >> On 26.10.2015 08:59, Oleg Fayans wrote: >>> >>> >>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>> >>>> >>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Here comes the updated version. >>>>> >>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>> >>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> thank you for the patch. >>>>>>> >>>>>>> 1) >>>>>>> please remove the added empty lines, they are unrelated to this >>>>>>> ticket >>>>> >>>>> done >>>>> >>>>>>> >>>>>>> 2) >>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>> domainlevel=1): >>>>>>> >>>>>>> I suggest to use default domainlevel=None, which will use the >>>>>>> default >>>>>>> domain level (specified in build) >>>>> >>>>> done >>>>> >>>>>>> >>>>>>> 3) >>>>>>> + domain_level = domainlevel(master) >>>>>>> I do not think that this meets expectations. >>>>>>> >>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>> respectively >>>>>>> new IPA must support all older domain levels, domain level is >>>>>>> independent on IPA version, only admin can raise it up. >>>>>>> >>>>>>> So you have to find out way how to pass the domain level for which >>>>>>> test will be running, we were talking about using config files, but >>>>>>> feel free to find something new and better >>>>> >>>>> Fixed. Now, we declare domain level in config.yaml with the directive >>>>> domain_level >>>>> >>>>>>> >>>>>>> 4) >>>>>>> Did you resolve the pytest fixtures which specifies which tests >>>>>>> can be >>>>>>> run under which domain level? >>>>> >>>>> In fact, we do not seem to have any tests yet that would require it. >>>>> All the existing tests just use install_replica >>>>> method, no matter how is it done. >>>> How about topology CI test? This can be executed only with domain >>>> level >>> >>> That's right. The topology test was updated. Patch is attached >>> together with a proper version of 11-th patch (not a swap file, sorry >>> about that). >>> >>>> 1, right? >>>>> >>>>>>> >>>>>>> 5) >>>>>>> + '--ip-address', client.ip, >>>>>>> >>>>>>> why this change to client install? >>>>> >>>>> Right, it found to be unnecessary. >>>>> >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>>> >>>>>> 6) >>>>>> ************* Module ipatests.test_integration.tasks >>>>>> ipatests/test_integration/tasks.py:85: >>>>>> [E1123(unexpected-keyword-arg), >>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in function >>>>>> call) >>>>> >>>>> Fixed >>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> 1) >> + if not host.config.domain_level == None: >> + args.append("--domain-level=%i" % host.config.domain_level) >> >> always use: variable *is not None* >> >> 2) >> Why there is specified level 1 as default? IIRC we agreed that the >> default level is the one which is default in tested package. >> These should be None and "": >> + "domain_level": "1" >> >> + "DOMAINLVL": "1", >> >> 3) >> However, as I read the patch 12, and I'm right, the pytest.fixture needs >> to know the value of domain level before we can do any dynamic detection >> on master. >> >> So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) > Done >> >> Also I'm not sure if the values are inherited from the >> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part you >> need default value, or the fixture will not work as expected. >> + self.domain_level = kwargs.get('domain_level', >> MAX_DOMAIN_LEVEL) > > This won't work in cases when domainlevel is explicitly set to 0 in > config.yaml. This default value will always override the explicit one. wat? in case that kwargs is dict containing values from config file: In [1]: kwargs = dict(domain_level=0) In [2]: kwargs.get('domain_level', 123) Out[2]: 0 > >> >> freeipa-tests depends on freeipa-python so the constants should be >> available in tests. >> >> So then you also need update this line >> >> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >> + args.append("--domain-level=%i" % host.config.domain_level) > > This would not work if domainlevel is not set in config.yaml, in which > case the host.config.domain_level is None. Domain level will never be None because self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) > >> >> 4) >> Please add comment to function +def domainlevel(host): that it is useful >> for test where domain level will be raised dynamically, otherwise it may >> be lost after test refactoring as somebody may consider it as unneeded >> and replace it with config dict. > Done > >> >> So summary is the 1) and 2) are replaced by 3) :) >> >> Martin^2 > From mbasti at redhat.com Tue Oct 27 09:30:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 10:30:09 +0100 Subject: [Freeipa-devel] [PATCH 0335] Freeipa domain levels naming In-Reply-To: <562F4008.9020506@redhat.com> References: <562900BD.2000104@redhat.com> <56290595.9090602@redhat.com> <5629E236.2090200@redhat.com> <5629E2F2.6030606@redhat.com> <562A10C9.3050501@redhat.com> <562A1EE4.7070004@redhat.com> <562A1F5D.3010003@redhat.com> <562A1FA1.2050303@redhat.com> <562A1FCD.70407@redhat.com> <562A2314.6020006@redhat.com> <562F4008.9020506@redhat.com> Message-ID: <562F4421.5030106@redhat.com> On 27.10.2015 10:12, Petr Spacek wrote: > On 23.10.2015 14:07, Petr Spacek wrote: >> On 23.10.2015 13:53, Martin Basti wrote: >>> >>> On 23.10.2015 13:53, Tomas Babej wrote: >>>> On 10/23/2015 01:51 PM, Martin Basti wrote: >>>>> On 23.10.2015 13:49, Tomas Babej wrote: >>>>>> On 10/23/2015 12:49 PM, Martin Basti wrote: >>>>>>> On 23.10.2015 09:34, Martin Basti wrote: >>>>>>>> On 23.10.2015 09:31, Tomas Babej wrote: >>>>>>>>> On 10/22/2015 05:49 PM, Simo Sorce wrote: >>>>>>>>>> On 22/10/15 11:29, Martin Basti wrote: >>>>>>>>>>> Hello all, >>>>>>>>>>> >>>>>>>>>>> in current master branch we have mixed usage of literals 0, 1 and >>>>>>>>>>> constants MIN_DOMAIN_LEVEL, MAX_DOMAIN_LEVEL, and it is quite mess. >>>>>>>>>>> >>>>>>>>>>> I suggest to use names for domain levels: >>>>>>>>>>> >>>>>>>>>>> COMPAT_DOMAIN_LEVEL = 0 >>>>>>>>>>> PROMOTION_DOMAIN_LEVEL = 1 >>>>>>>>>>> UBER_NEW_FEATURE_DOMAIN_LEVEL = 2 >>>>>>>>>>> >>>>>>>>>>> MIN_DOMAIN_LEVEL = COMPAT_DOMAIN_LEVEL (=0) >>>>>>>>>>> MAX_DOMAIN_LEVEL = UBER_NEW_FEATURE_DOMAIN_LEVEL (=2) >>>>>>>>>>> >>>>>>>>>>> Benefits: >>>>>>>>>>> * ability to grep it in code >>>>>>>>>> Call them DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 >>>>>>>>>> >>>>>>>>>>> * better readability in code >>>>>>>>>> Sure, but random names are not appropriate imo >>>>>>>>> I'm with you guys on this, it's a good idea. Let's go with the >>>>>>>>> DOMAIN_LEVEL_X naming though, it will be probably easier to remember. >>>>>>>>> >>>>>>>>> One thing to add to the discussion - MIN/MAX_DOMAIN_LEVEL denotes only >>>>>>>>> the minimal/maximal domain level supported by the given IPA server, >>>>>>>>> not >>>>>>>>> the minimal/maximal domain level ever shipped by FreeIPA project. >>>>>>>>> >>>>>>>>> Currently, those two coincide, but in general they might be >>>>>>>>> different if >>>>>>>>> we ever raise the minimal level a decide to deprecate, say, domain >>>>>>>>> level >>>>>>>>> 0 or 1. It's a subtle but important difference. >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> Thank you all for your opinion, >>>>>>>> >>>>>>>> I will implement DOMAIN_LEVEL_X constants and send patch. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Martin^2 >>>>>>>> >>>>>>> Patch attached. >>>>>>> O hope, I did not miss anything hardcoded. >>>>>> I think we can safely hardcode domain levels as numbers in the error >>>>>> messages. Substituting {dl} for constants.DOMAIN_LEVEL_0 in the error >>>>>> message makes little sense to me, as the value of >>>>>> constants.DOMAIN_LEVEL_0 will not ever change. >>>>> However, with substituting is easier to find occurrences of domain >>>>> levels in comments and messages in case of refactoring. >>>> In case of refactoring of what? All the error messages containing >>>> reference to a domain level 0? :) >>> Exactly! :) >> Tomas, that one day we decide to drop support for domain level 0. We will have >> to hunt down all references to it and using constant for help messages etc. >> might be handy because it will show up in results of grep, so we do not forget >> to wipe domain level 0 from texts. >> >> >> Nitpick just to make you feel that I read the patch (does not warrant a NACK): >> I would rather see conditions in form of (<= or >=) instead of (< or >) >> because now you have to grep for domain level +- 1 to get all references to >> particular domain level :-D >> >> Nevermind, this is just a nitpick. > ACK, I did not find any breakage. > Pushed to master: beb6a3236d5c10acd990aaf92eddc74fee456909 From mbasti at redhat.com Tue Oct 27 09:43:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 10:43:13 +0100 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <562DF3EE.1090708@redhat.com> References: <5620D475.2030200@redhat.com> <562A3234.9040509@redhat.com> <562A32ED.8030702@redhat.com> <562A4FC5.6030603@redhat.com> <562DF3EE.1090708@redhat.com> Message-ID: <562F4731.5010104@redhat.com> On 26.10.2015 10:35, Martin Babinsky wrote: > On 10/23/2015 05:18 PM, Martin Basti wrote: >> >> >> On 23.10.2015 15:15, Martin Babinsky wrote: >>> On 10/23/2015 03:12 PM, Martin Babinsky wrote: >>>> On 10/16/2015 12:41 PM, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5345 >>>>> >>>>> Patch attached. >>>>> >>>>> >>>> I have tested it on 4-2 branch and it works as expected, ACK. >>>> >>>> Obviously, master branch would require a different patch. >>>> >>> >>> I actually missed your check in ipaserver/install/kra.py which can >>> break ipa-replica-install with --setup-kra, so NACK. >>> >> Updated patches attached. > > NACK on the master-branch patch. > > You forgot a 'return' in this code snippet: > > + if self.installing_replica: > + domain_level = dsinstance.get_domain_level(api) > + if domain_level > DOMAIN_LEVEL_0: > + self.options.promote = True > + return > > that would make installation abort when domain level is greter than zero. > Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0327.3-KRA-fix-check-that-CA-is-installed.patch Type: text/x-patch Size: 3345 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 27 09:50:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 10:50:16 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F424D.3060003@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> Message-ID: <562F48D8.6010500@redhat.com> On 27.10.2015 10:22, Martin Basti wrote: > > > On 27.10.2015 10:00, Oleg Fayans wrote: >> Hi Martin, >> >> The updated version of the patch is attached. Please, see my comments >> below > My comments inline, I may be completely wrong in how the test suite > work, so feel free to correct me. > > Martin > >> >> On 10/26/2015 06:48 PM, Martin Basti wrote: >>> >>> >>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>> >>>> >>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Here comes the updated version. >>>>>> >>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>> >>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> thank you for the patch. >>>>>>>> >>>>>>>> 1) >>>>>>>> please remove the added empty lines, they are unrelated to this >>>>>>>> ticket >>>>>> >>>>>> done >>>>>> >>>>>>>> >>>>>>>> 2) >>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>> domainlevel=1): >>>>>>>> >>>>>>>> I suggest to use default domainlevel=None, which will use the >>>>>>>> default >>>>>>>> domain level (specified in build) >>>>>> >>>>>> done >>>>>> >>>>>>>> >>>>>>>> 3) >>>>>>>> + domain_level = domainlevel(master) >>>>>>>> I do not think that this meets expectations. >>>>>>>> >>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>> respectively >>>>>>>> new IPA must support all older domain levels, domain level is >>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>> >>>>>>>> So you have to find out way how to pass the domain level for which >>>>>>>> test will be running, we were talking about using config files, >>>>>>>> but >>>>>>>> feel free to find something new and better >>>>>> >>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>> directive >>>>>> domain_level >>>>>> >>>>>>>> >>>>>>>> 4) >>>>>>>> Did you resolve the pytest fixtures which specifies which tests >>>>>>>> can be >>>>>>>> run under which domain level? >>>>>> >>>>>> In fact, we do not seem to have any tests yet that would require it. >>>>>> All the existing tests just use install_replica >>>>>> method, no matter how is it done. >>>>> How about topology CI test? This can be executed only with domain >>>>> level >>>> >>>> That's right. The topology test was updated. Patch is attached >>>> together with a proper version of 11-th patch (not a swap file, sorry >>>> about that). >>>> >>>>> 1, right? >>>>>> >>>>>>>> >>>>>>>> 5) >>>>>>>> + '--ip-address', client.ip, >>>>>>>> >>>>>>>> why this change to client install? >>>>>> >>>>>> Right, it found to be unnecessary. >>>>>> >>>>>>>> >>>>>>>> Martin^2 >>>>>>>> >>>>>>>> >>>>>>> 6) >>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>> [E1123(unexpected-keyword-arg), >>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>> function >>>>>>> call) >>>>>> >>>>>> Fixed >>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> 1) >>> + if not host.config.domain_level == None: >>> + args.append("--domain-level=%i" % host.config.domain_level) >>> >>> always use: variable *is not None* >>> >>> 2) >>> Why there is specified level 1 as default? IIRC we agreed that the >>> default level is the one which is default in tested package. >>> These should be None and "": >>> + "domain_level": "1" >>> >>> + "DOMAINLVL": "1", >>> >>> 3) >>> However, as I read the patch 12, and I'm right, the pytest.fixture >>> needs >>> to know the value of domain level before we can do any dynamic >>> detection >>> on master. >>> >>> So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) >> Done >>> >>> Also I'm not sure if the values are inherited from the >>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part you >>> need default value, or the fixture will not work as expected. >>> + self.domain_level = kwargs.get('domain_level', >>> MAX_DOMAIN_LEVEL) >> >> This won't work in cases when domainlevel is explicitly set to 0 in >> config.yaml. This default value will always override the explicit one. > wat? in case that kwargs is dict containing values from config file: > > In [1]: kwargs = dict(domain_level=0) > > In [2]: kwargs.get('domain_level', 123) > Out[2]: 0 > Respectively you should use this: self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL because kwargs IMO contains undefined config values as None >> >>> >>> freeipa-tests depends on freeipa-python so the constants should be >>> available in tests. >>> >>> So then you also need update this line >>> >>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>> + args.append("--domain-level=%i" % host.config.domain_level) >> >> This would not work if domainlevel is not set in config.yaml, in >> which case the host.config.domain_level is None. > Domain level will never be None because self.domain_level = > kwargs.get('domain_level', MAX_DOMAIN_LEVEL) > >> >>> >>> 4) >>> Please add comment to function +def domainlevel(host): that it is >>> useful >>> for test where domain level will be raised dynamically, otherwise it >>> may >>> be lost after test refactoring as somebody may consider it as unneeded >>> and replace it with config dict. >> Done >> >>> >>> So summary is the 1) and 2) are replaced by 3) :) >>> >>> Martin^2 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Tue Oct 27 11:06:12 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 27 Oct 2015 12:06:12 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F48D8.6010500@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> Message-ID: <562F5AA4.2060502@redhat.com> Hi Martin, On 10/27/2015 10:50 AM, Martin Basti wrote: > > > On 27.10.2015 10:22, Martin Basti wrote: >> >> >> On 27.10.2015 10:00, Oleg Fayans wrote: >>> Hi Martin, >>> >>> The updated version of the patch is attached. Please, see my comments >>> below >> My comments inline, I may be completely wrong in how the test suite >> work, so feel free to correct me. >> >> Martin >> >>> >>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>> >>>> >>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>> >>>>> >>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> Here comes the updated version. >>>>>>> >>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> thank you for the patch. >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> please remove the added empty lines, they are unrelated to this >>>>>>>>> ticket >>>>>>> >>>>>>> done >>>>>>> >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>> domainlevel=1): >>>>>>>>> >>>>>>>>> I suggest to use default domainlevel=None, which will use the >>>>>>>>> default >>>>>>>>> domain level (specified in build) >>>>>>> >>>>>>> done >>>>>>> >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>> I do not think that this meets expectations. >>>>>>>>> >>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>> respectively >>>>>>>>> new IPA must support all older domain levels, domain level is >>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>> >>>>>>>>> So you have to find out way how to pass the domain level for which >>>>>>>>> test will be running, we were talking about using config files, >>>>>>>>> but >>>>>>>>> feel free to find something new and better >>>>>>> >>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>> directive >>>>>>> domain_level >>>>>>> >>>>>>>>> >>>>>>>>> 4) >>>>>>>>> Did you resolve the pytest fixtures which specifies which tests >>>>>>>>> can be >>>>>>>>> run under which domain level? >>>>>>> >>>>>>> In fact, we do not seem to have any tests yet that would require it. >>>>>>> All the existing tests just use install_replica >>>>>>> method, no matter how is it done. >>>>>> How about topology CI test? This can be executed only with domain >>>>>> level >>>>> >>>>> That's right. The topology test was updated. Patch is attached >>>>> together with a proper version of 11-th patch (not a swap file, sorry >>>>> about that). >>>>> >>>>>> 1, right? >>>>>>> >>>>>>>>> >>>>>>>>> 5) >>>>>>>>> + '--ip-address', client.ip, >>>>>>>>> >>>>>>>>> why this change to client install? >>>>>>> >>>>>>> Right, it found to be unnecessary. >>>>>>> >>>>>>>>> >>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>>> >>>>>>>> 6) >>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>> function >>>>>>>> call) >>>>>>> >>>>>>> Fixed >>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> 1) >>>> + if not host.config.domain_level == None: >>>> + args.append("--domain-level=%i" % host.config.domain_level) >>>> >>>> always use: variable *is not None* >>>> >>>> 2) >>>> Why there is specified level 1 as default? IIRC we agreed that the >>>> default level is the one which is default in tested package. >>>> These should be None and "": >>>> + "domain_level": "1" >>>> >>>> + "DOMAINLVL": "1", >>>> >>>> 3) >>>> However, as I read the patch 12, and I'm right, the pytest.fixture >>>> needs >>>> to know the value of domain level before we can do any dynamic >>>> detection >>>> on master. >>>> >>>> So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) >>> Done >>>> >>>> Also I'm not sure if the values are inherited from the >>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part you >>>> need default value, or the fixture will not work as expected. >>>> + self.domain_level = kwargs.get('domain_level', >>>> MAX_DOMAIN_LEVEL) >>> >>> This won't work in cases when domainlevel is explicitly set to 0 in >>> config.yaml. This default value will always override the explicit one. >> wat? in case that kwargs is dict containing values from config file: >> >> In [1]: kwargs = dict(domain_level=0) >> >> In [2]: kwargs.get('domain_level', 123) >> Out[2]: 0 Yep, right you are, it works as expected. Now the line looks like: self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >> > Respectively you should use this: > > self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL Now that would definitely not work in case of domain_level is 0: 0 or 1 is always 1 > > because kwargs IMO contains undefined config values as None > > > >>> >>>> >>>> freeipa-tests depends on freeipa-python so the constants should be >>>> available in tests. >>>> >>>> So then you also need update this line >>>> >>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>> + args.append("--domain-level=%i" % host.config.domain_level) >>> >>> This would not work if domainlevel is not set in config.yaml, in >>> which case the host.config.domain_level is None. >> Domain level will never be None because self.domain_level = >> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >> >>> >>>> >>>> 4) >>>> Please add comment to function +def domainlevel(host): that it is >>>> useful >>>> for test where domain level will be raised dynamically, otherwise it >>>> may >>>> be lost after test refactoring as somebody may consider it as unneeded >>>> and replace it with config dict. >>> Done >>> >>>> >>>> So summary is the 1) and 2) are replaced by 3) :) >>>> >>>> Martin^2 >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0011.3-replica-promotion-changes-in-tests.patch Type: text/x-patch Size: 6021 bytes Desc: not available URL: From akasurde at redhat.com Tue Oct 27 12:00:36 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Tue, 27 Oct 2015 17:30:36 +0530 Subject: [Freeipa-devel] [PATCH] DNSZone command with user friendly message Message-ID: <562F6764.3000704@redhat.com> Hi All, This patch fixes bug - https://fedorahosted.org/freeipa/ticket/4811 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-1-Added-user-friendly-error-message-for-dnszone-enable.patch Type: text/x-patch Size: 1758 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 27 12:22:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 13:22:21 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F5AA4.2060502@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> Message-ID: <562F6C7D.8090808@redhat.com> On 27.10.2015 12:06, Oleg Fayans wrote: > Hi Martin, > > On 10/27/2015 10:50 AM, Martin Basti wrote: >> >> >> On 27.10.2015 10:22, Martin Basti wrote: >>> >>> >>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> The updated version of the patch is attached. Please, see my comments >>>> below >>> My comments inline, I may be completely wrong in how the test suite >>> work, so feel free to correct me. >>> >>> Martin >>> >>>> >>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>> >>>>>> >>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Here comes the updated version. >>>>>>>> >>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> thank you for the patch. >>>>>>>>>> >>>>>>>>>> 1) >>>>>>>>>> please remove the added empty lines, they are unrelated to this >>>>>>>>>> ticket >>>>>>>> >>>>>>>> done >>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>> domainlevel=1): >>>>>>>>>> >>>>>>>>>> I suggest to use default domainlevel=None, which will use the >>>>>>>>>> default >>>>>>>>>> domain level (specified in build) >>>>>>>> >>>>>>>> done >>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) >>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>> >>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>> respectively >>>>>>>>>> new IPA must support all older domain levels, domain level is >>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>> >>>>>>>>>> So you have to find out way how to pass the domain level for >>>>>>>>>> which >>>>>>>>>> test will be running, we were talking about using config files, >>>>>>>>>> but >>>>>>>>>> feel free to find something new and better >>>>>>>> >>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>> directive >>>>>>>> domain_level >>>>>>>> >>>>>>>>>> >>>>>>>>>> 4) >>>>>>>>>> Did you resolve the pytest fixtures which specifies which tests >>>>>>>>>> can be >>>>>>>>>> run under which domain level? >>>>>>>> >>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>> require it. >>>>>>>> All the existing tests just use install_replica >>>>>>>> method, no matter how is it done. >>>>>>> How about topology CI test? This can be executed only with domain >>>>>>> level >>>>>> >>>>>> That's right. The topology test was updated. Patch is attached >>>>>> together with a proper version of 11-th patch (not a swap file, >>>>>> sorry >>>>>> about that). >>>>>> >>>>>>> 1, right? >>>>>>>> >>>>>>>>>> >>>>>>>>>> 5) >>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>> >>>>>>>>>> why this change to client install? >>>>>>>> >>>>>>>> Right, it found to be unnecessary. >>>>>>>> >>>>>>>>>> >>>>>>>>>> Martin^2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> 6) >>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>> function >>>>>>>>> call) >>>>>>>> >>>>>>>> Fixed >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> 1) >>>>> + if not host.config.domain_level == None: >>>>> + args.append("--domain-level=%i" % host.config.domain_level) >>>>> >>>>> always use: variable *is not None* >>>>> >>>>> 2) >>>>> Why there is specified level 1 as default? IIRC we agreed that the >>>>> default level is the one which is default in tested package. >>>>> These should be None and "": >>>>> + "domain_level": "1" >>>>> >>>>> + "DOMAINLVL": "1", >>>>> >>>>> 3) >>>>> However, as I read the patch 12, and I'm right, the pytest.fixture >>>>> needs >>>>> to know the value of domain level before we can do any dynamic >>>>> detection >>>>> on master. >>>>> >>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) >>>> Done >>>>> >>>>> Also I'm not sure if the values are inherited from the >>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part you >>>>> need default value, or the fixture will not work as expected. >>>>> + self.domain_level = kwargs.get('domain_level', >>>>> MAX_DOMAIN_LEVEL) >>>> >>>> This won't work in cases when domainlevel is explicitly set to 0 in >>>> config.yaml. This default value will always override the explicit one. >>> wat? in case that kwargs is dict containing values from config file: >>> >>> In [1]: kwargs = dict(domain_level=0) >>> >>> In [2]: kwargs.get('domain_level', 123) >>> Out[2]: 0 > > Yep, right you are, it works as expected. Now the line looks like: > self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) > >>> >> Respectively you should use this: >> >> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL > Now that would definitely not work in case of domain_level is 0: > 0 or 1 is always 1 Oh right. I had discussion with Tomas, and we should add there check if it is not None, in case that kwargs contains {'domain_level': None} (One does not know with test when the None value appears there) self.domain_level = kwargs.get('domain_level') if self.domain_level is None: self.domain_level = MAX_DOMAIN_LEVEL As we cannot user 'or' expression with integers, so this is the right way. > >> >> because kwargs IMO contains undefined config values as None >> >> >> >>>> >>>>> >>>>> freeipa-tests depends on freeipa-python so the constants should be >>>>> available in tests. >>>>> >>>>> So then you also need update this line >>>>> >>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>> + args.append("--domain-level=%i" % host.config.domain_level) >>>> >>>> This would not work if domainlevel is not set in config.yaml, in >>>> which case the host.config.domain_level is None. >>> Domain level will never be None because self.domain_level = >>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>> >>>> >>>>> >>>>> 4) >>>>> Please add comment to function +def domainlevel(host): that it is >>>>> useful >>>>> for test where domain level will be raised dynamically, otherwise it >>>>> may >>>>> be lost after test refactoring as somebody may consider it as >>>>> unneeded >>>>> and replace it with config dict. >>>> Done >>>> >>>>> >>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>> >>>>> Martin^2 >>>> >>> >> > From ofayans at redhat.com Tue Oct 27 12:56:58 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 27 Oct 2015 13:56:58 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F6C7D.8090808@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> Message-ID: <562F749A.3080204@redhat.com> On 10/27/2015 01:22 PM, Martin Basti wrote: > > > On 27.10.2015 12:06, Oleg Fayans wrote: >> Hi Martin, >> >> On 10/27/2015 10:50 AM, Martin Basti wrote: >>> >>> >>> On 27.10.2015 10:22, Martin Basti wrote: >>>> >>>> >>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> The updated version of the patch is attached. Please, see my comments >>>>> below >>>> My comments inline, I may be completely wrong in how the test suite >>>> work, so feel free to correct me. >>>> >>>> Martin >>>> >>>>> >>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>> >>>>>>> >>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> Here comes the updated version. >>>>>>>>> >>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> thank you for the patch. >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> please remove the added empty lines, they are unrelated to this >>>>>>>>>>> ticket >>>>>>>>> >>>>>>>>> done >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>>> domainlevel=1): >>>>>>>>>>> >>>>>>>>>>> I suggest to use default domainlevel=None, which will use the >>>>>>>>>>> default >>>>>>>>>>> domain level (specified in build) >>>>>>>>> >>>>>>>>> done >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3) >>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>> >>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>> respectively >>>>>>>>>>> new IPA must support all older domain levels, domain level is >>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>> >>>>>>>>>>> So you have to find out way how to pass the domain level for >>>>>>>>>>> which >>>>>>>>>>> test will be running, we were talking about using config files, >>>>>>>>>>> but >>>>>>>>>>> feel free to find something new and better >>>>>>>>> >>>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>>> directive >>>>>>>>> domain_level >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 4) >>>>>>>>>>> Did you resolve the pytest fixtures which specifies which tests >>>>>>>>>>> can be >>>>>>>>>>> run under which domain level? >>>>>>>>> >>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>> require it. >>>>>>>>> All the existing tests just use install_replica >>>>>>>>> method, no matter how is it done. >>>>>>>> How about topology CI test? This can be executed only with domain >>>>>>>> level >>>>>>> >>>>>>> That's right. The topology test was updated. Patch is attached >>>>>>> together with a proper version of 11-th patch (not a swap file, >>>>>>> sorry >>>>>>> about that). >>>>>>> >>>>>>>> 1, right? >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5) >>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>> >>>>>>>>>>> why this change to client install? >>>>>>>>> >>>>>>>>> Right, it found to be unnecessary. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Martin^2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> 6) >>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>>> function >>>>>>>>>> call) >>>>>>>>> >>>>>>>>> Fixed >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> 1) >>>>>> + if not host.config.domain_level == None: >>>>>> + args.append("--domain-level=%i" % host.config.domain_level) >>>>>> >>>>>> always use: variable *is not None* >>>>>> >>>>>> 2) >>>>>> Why there is specified level 1 as default? IIRC we agreed that the >>>>>> default level is the one which is default in tested package. >>>>>> These should be None and "": >>>>>> + "domain_level": "1" >>>>>> >>>>>> + "DOMAINLVL": "1", >>>>>> >>>>>> 3) >>>>>> However, as I read the patch 12, and I'm right, the pytest.fixture >>>>>> needs >>>>>> to know the value of domain level before we can do any dynamic >>>>>> detection >>>>>> on master. >>>>>> >>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) >>>>> Done >>>>>> >>>>>> Also I'm not sure if the values are inherited from the >>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part you >>>>>> need default value, or the fixture will not work as expected. >>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>> MAX_DOMAIN_LEVEL) >>>>> >>>>> This won't work in cases when domainlevel is explicitly set to 0 in >>>>> config.yaml. This default value will always override the explicit one. >>>> wat? in case that kwargs is dict containing values from config file: >>>> >>>> In [1]: kwargs = dict(domain_level=0) >>>> >>>> In [2]: kwargs.get('domain_level', 123) >>>> Out[2]: 0 >> >> Yep, right you are, it works as expected. Now the line looks like: >> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >> >>>> >>> Respectively you should use this: >>> >>> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL >> Now that would definitely not work in case of domain_level is 0: >> 0 or 1 is always 1 > Oh right. > > I had discussion with Tomas, and we should add there check if it is not > None, in case that kwargs contains {'domain_level': None} (One does not > know with test when the None value appears there) I do not get this. If we do not specify domain_level in config.yaml, it will automatically be populated with a MAX_DOMAIN_LEVEL value. That means domain_level will never ever possibly be None. > > self.domain_level = kwargs.get('domain_level') > if self.domain_level is None: > self.domain_level = MAX_DOMAIN_LEVEL > > As we cannot user 'or' expression with integers, so this is the right way. >> >>> >>> because kwargs IMO contains undefined config values as None >>> >>> >>> >>>>> >>>>>> >>>>>> freeipa-tests depends on freeipa-python so the constants should be >>>>>> available in tests. >>>>>> >>>>>> So then you also need update this line >>>>>> >>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>> + args.append("--domain-level=%i" % host.config.domain_level) >>>>> >>>>> This would not work if domainlevel is not set in config.yaml, in >>>>> which case the host.config.domain_level is None. >>>> Domain level will never be None because self.domain_level = >>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>> >>>>> >>>>>> >>>>>> 4) >>>>>> Please add comment to function +def domainlevel(host): that it is >>>>>> useful >>>>>> for test where domain level will be raised dynamically, otherwise it >>>>>> may >>>>>> be lost after test refactoring as somebody may consider it as >>>>>> unneeded >>>>>> and replace it with config dict. >>>>> Done >>>>> >>>>>> >>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>> >>>>>> Martin^2 >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Tue Oct 27 12:58:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 13:58:59 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F749A.3080204@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> Message-ID: <562F7513.2040403@redhat.com> On 27.10.2015 13:56, Oleg Fayans wrote: > > > On 10/27/2015 01:22 PM, Martin Basti wrote: >> >> >> On 27.10.2015 12:06, Oleg Fayans wrote: >>> Hi Martin, >>> >>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>> >>>> >>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>> >>>>> >>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> The updated version of the patch is attached. Please, see my >>>>>> comments >>>>>> below >>>>> My comments inline, I may be completely wrong in how the test suite >>>>> work, so feel free to correct me. >>>>> >>>>> Martin >>>>> >>>>>> >>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> Here comes the updated version. >>>>>>>>>> >>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>> >>>>>>>>>>>> 1) >>>>>>>>>>>> please remove the added empty lines, they are unrelated to >>>>>>>>>>>> this >>>>>>>>>>>> ticket >>>>>>>>>> >>>>>>>>>> done >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) >>>>>>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>> >>>>>>>>>>>> I suggest to use default domainlevel=None, which will use the >>>>>>>>>>>> default >>>>>>>>>>>> domain level (specified in build) >>>>>>>>>> >>>>>>>>>> done >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3) >>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>> >>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>> respectively >>>>>>>>>>>> new IPA must support all older domain levels, domain level is >>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>> >>>>>>>>>>>> So you have to find out way how to pass the domain level for >>>>>>>>>>>> which >>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>> files, >>>>>>>>>>>> but >>>>>>>>>>>> feel free to find something new and better >>>>>>>>>> >>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>>>> directive >>>>>>>>>> domain_level >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 4) >>>>>>>>>>>> Did you resolve the pytest fixtures which specifies which >>>>>>>>>>>> tests >>>>>>>>>>>> can be >>>>>>>>>>>> run under which domain level? >>>>>>>>>> >>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>> require it. >>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>> method, no matter how is it done. >>>>>>>>> How about topology CI test? This can be executed only with domain >>>>>>>>> level >>>>>>>> >>>>>>>> That's right. The topology test was updated. Patch is attached >>>>>>>> together with a proper version of 11-th patch (not a swap file, >>>>>>>> sorry >>>>>>>> about that). >>>>>>>> >>>>>>>>> 1, right? >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5) >>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>> >>>>>>>>>>>> why this change to client install? >>>>>>>>>> >>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Martin^2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 6) >>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>>>> function >>>>>>>>>>> call) >>>>>>>>>> >>>>>>>>>> Fixed >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> 1) >>>>>>> + if not host.config.domain_level == None: >>>>>>> + args.append("--domain-level=%i" % >>>>>>> host.config.domain_level) >>>>>>> >>>>>>> always use: variable *is not None* >>>>>>> >>>>>>> 2) >>>>>>> Why there is specified level 1 as default? IIRC we agreed that the >>>>>>> default level is the one which is default in tested package. >>>>>>> These should be None and "": >>>>>>> + "domain_level": "1" >>>>>>> >>>>>>> + "DOMAINLVL": "1", >>>>>>> >>>>>>> 3) >>>>>>> However, as I read the patch 12, and I'm right, the pytest.fixture >>>>>>> needs >>>>>>> to know the value of domain level before we can do any dynamic >>>>>>> detection >>>>>>> on master. >>>>>>> >>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) >>>>>> Done >>>>>>> >>>>>>> Also I'm not sure if the values are inherited from the >>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part >>>>>>> you >>>>>>> need default value, or the fixture will not work as expected. >>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>> MAX_DOMAIN_LEVEL) >>>>>> >>>>>> This won't work in cases when domainlevel is explicitly set to 0 in >>>>>> config.yaml. This default value will always override the explicit >>>>>> one. >>>>> wat? in case that kwargs is dict containing values from config file: >>>>> >>>>> In [1]: kwargs = dict(domain_level=0) >>>>> >>>>> In [2]: kwargs.get('domain_level', 123) >>>>> Out[2]: 0 >>> >>> Yep, right you are, it works as expected. Now the line looks like: >>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>> >>>>> >>>> Respectively you should use this: >>>> >>>> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL >>> Now that would definitely not work in case of domain_level is 0: >>> 0 or 1 is always 1 >> Oh right. >> >> I had discussion with Tomas, and we should add there check if it is not >> None, in case that kwargs contains {'domain_level': None} (One does not >> know with test when the None value appears there) > > I do not get this. If we do not specify domain_level in config.yaml, > it will automatically be populated with a MAX_DOMAIN_LEVEL value. That > means domain_level will never ever possibly be None. I do not know how pytest works inside, if you are 100% sure, that the case written above cannot happen, I'm fine with it. Martin > >> >> self.domain_level = kwargs.get('domain_level') >> if self.domain_level is None: >> self.domain_level = MAX_DOMAIN_LEVEL >> >> As we cannot user 'or' expression with integers, so this is the right >> way. >>> >>>> >>>> because kwargs IMO contains undefined config values as None >>>> >>>> >>>> >>>>>> >>>>>>> >>>>>>> freeipa-tests depends on freeipa-python so the constants should be >>>>>>> available in tests. >>>>>>> >>>>>>> So then you also need update this line >>>>>>> >>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>> + args.append("--domain-level=%i" % >>>>>>> host.config.domain_level) >>>>>> >>>>>> This would not work if domainlevel is not set in config.yaml, in >>>>>> which case the host.config.domain_level is None. >>>>> Domain level will never be None because self.domain_level = >>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>> >>>>>> >>>>>>> >>>>>>> 4) >>>>>>> Please add comment to function +def domainlevel(host): that it is >>>>>>> useful >>>>>>> for test where domain level will be raised dynamically, >>>>>>> otherwise it >>>>>>> may >>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>> unneeded >>>>>>> and replace it with config dict. >>>>>> Done >>>>>> >>>>>>> >>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>> >>>>>>> Martin^2 >>>>>> >>>>> >>>> >>> >> > From mbasti at redhat.com Tue Oct 27 13:46:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 14:46:01 +0100 Subject: [Freeipa-devel] [PATCH] DNSZone command with user friendly message In-Reply-To: <562F6764.3000704@redhat.com> References: <562F6764.3000704@redhat.com> Message-ID: <562F8019.8020809@redhat.com> On 27.10.2015 13:00, Abhijeet Kasurde wrote: > Hi All, > > This patch fixes bug - https://fedorahosted.org/freeipa/ticket/4811 > > Thanks, > Abhijeet Kasurde > > [Tue Oct 27 14:44:51.328615 2015] [wsgi:error] [pid 5556] ipa: ERROR: non-public: AttributeError: 'dnszone' object has no attribute 'handle_obj_found' [Tue Oct 27 14:44:51.328654 2015] [wsgi:error] [pid 5556] Traceback (most recent call last): [Tue Oct 27 14:44:51.328659 2015] [wsgi:error] [pid 5556] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in wsgi_execute [Tue Oct 27 14:44:51.328664 2015] [wsgi:error] [pid 5556] result = self.Command[name](*args, **options) [Tue Oct 27 14:44:51.328669 2015] [wsgi:error] [pid 5556] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__ [Tue Oct 27 14:44:51.328674 2015] [wsgi:error] [pid 5556] ret = self.run(*args, **options) [Tue Oct 27 14:44:51.328678 2015] [wsgi:error] [pid 5556] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 764, in run [Tue Oct 27 14:44:51.328683 2015] [wsgi:error] [pid 5556] return self.execute(*args, **options) [Tue Oct 27 14:44:51.328687 2015] [wsgi:error] [pid 5556] File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2935, in execute [Tue Oct 27 14:44:51.328692 2015] [wsgi:error] [pid 5556] result = super(dnszone_enable, self).execute(*keys, **options) [Tue Oct 27 14:44:51.328696 2015] [wsgi:error] [pid 5556] File "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2262, in execute [Tue Oct 27 14:44:51.328701 2015] [wsgi:error] [pid 5556] self.obj.handle_obj_found(*keys) [Tue Oct 27 14:44:51.328705 2015] [wsgi:error] [pid 5556] AttributeError: 'dnszone' object has no attribute 'handle_obj_found' -------------- next part -------------- An HTML attachment was scrubbed... URL: From akasurde at redhat.com Tue Oct 27 13:52:03 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Tue, 27 Oct 2015 19:22:03 +0530 Subject: [Freeipa-devel] [PATCH] DNSZone command with user friendly message In-Reply-To: <562F8019.8020809@redhat.com> References: <562F6764.3000704@redhat.com> <562F8019.8020809@redhat.com> Message-ID: <562F8183.7070200@redhat.com> On 10/27/2015 07:16 PM, Martin Basti wrote: > > > On 27.10.2015 13:00, Abhijeet Kasurde wrote: >> Hi All, >> >> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/4811 >> >> Thanks, >> Abhijeet Kasurde >> >> Sorry, my bad. Please find the new patch. > [Tue Oct 27 14:44:51.328615 2015] [wsgi:error] [pid 5556] ipa: ERROR: > non-public: AttributeError: 'dnszone' object has no attribute > 'handle_obj_found' > [Tue Oct 27 14:44:51.328654 2015] [wsgi:error] [pid 5556] Traceback > (most recent call last): > [Tue Oct 27 14:44:51.328659 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, > in wsgi_execute > [Tue Oct 27 14:44:51.328664 2015] [wsgi:error] [pid 5556] result = > self.Command[name](*args, **options) > [Tue Oct 27 14:44:51.328669 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in > __call__ > [Tue Oct 27 14:44:51.328674 2015] [wsgi:error] [pid 5556] ret = > self.run(*args, **options) > [Tue Oct 27 14:44:51.328678 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 764, in run > [Tue Oct 27 14:44:51.328683 2015] [wsgi:error] [pid 5556] return > self.execute(*args, **options) > [Tue Oct 27 14:44:51.328687 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2935, > in execute > [Tue Oct 27 14:44:51.328692 2015] [wsgi:error] [pid 5556] result = > super(dnszone_enable, self).execute(*keys, **options) > [Tue Oct 27 14:44:51.328696 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2262, > in execute > [Tue Oct 27 14:44:51.328701 2015] [wsgi:error] [pid 5556] > self.obj.handle_obj_found(*keys) > [Tue Oct 27 14:44:51.328705 2015] [wsgi:error] [pid 5556] > AttributeError: 'dnszone' object has no attribute 'handle_obj_found' > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-2-Added-user-friendly-error-message-for-dnszone-enable.patch Type: text/x-patch Size: 1758 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 27 13:59:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 14:59:07 +0100 Subject: [Freeipa-devel] [PATCH 0331, 0337] User plugin: allow multiple managers per user - CLI part In-Reply-To: <56266FCF.80909@redhat.com> References: <56264855.50606@redhat.com> <56264AA6.5010003@redhat.com> <56266FCF.80909@redhat.com> Message-ID: <562F832B.4060303@redhat.com> On 20.10.2015 18:46, Martin Basti wrote: > > > On 20.10.2015 16:07, Martin Basti wrote: >> >> >> On 20.10.2015 15:57, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5344 >>> >>> Patch attached. >>> >>> Test are failing, a fix in UserTracker has to be done (partially in >>> my patch 329) >>> >>> >> SelfNACK, I forgot to add stageuser tests >> >> > Updated patch attached. > > I extracted tests to the separate patch, tests do not work, I had > issues with user and stageuser trackers. > > > Patch to fix issues with --addattr and managers added and attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0337-Fix-add-attr-with-multiple-managers.patch Type: text/x-patch Size: 1769 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0331.2-Allow-multiple-managers-per-user-CLI-part.patch Type: text/x-patch Size: 7437 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 27 14:54:27 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 Oct 2015 15:54:27 +0100 Subject: [Freeipa-devel] [draft] Fate of ipa-replica-manage and ipa-csreplica-manage tools Message-ID: <562F9023.6020207@redhat.com> Both tools serve primarily for managing replication agreements and replicas. ipa-replica-manage also manages winsync agreements and DNA ranges. FreeIPA 4.3 will introduce managed topology which affects these tools. Let's go trough all sub-commands of both tools and decide what is the fate of them/how they should be replaced. Comments are welcome. In text, term 'disable' means: print an error message with help what is the new alternative. For domain level == 0 all sub-commands should behave the same way as before. Proposals are for domain level 1 if not stated otherwise. == ipa-replica-manage == === list === Lists all IPA server or replication agreements of a specific IPA server including winsync agreements. Server list is replaced by ipa server-find Replication agreements by: ipa topologysegment-find realm I see following paths: 1. do not change (current state) 2. list only winsync agreements - IMO it will be easier to maintain If winsync was not in play we could 'disable' it but winsync is not planned to be centrally managed. Mainly because the preferred alternative is trust. === connect === Allow for winsync, disable for REALM agmts. (current state) === disconenct === Allow for winsync, disable for REALM agmts. (current state) === del === (current state) With domain level 0: - removes replica and repl. agmts for REALM suffix and winsync With domain level 1: - removes replica entry and therefore repl. agmts for all suffices(REALM, CS) - ensure last services, e.g. sets renewal master - does additional cleanup I'm not aware of any operation which needs directory manager. IMO it can be moved to API in future release(e.g. 4.4), especially if ipa-server-install --uninstall is modified to do most of the cleanup. === re-initialize === Not changed. Can be disabled (long-term solution) Same capability is in topologysegment_reinitialize API command. The only difference is that no API command shows state of the pending operation. Should we transform presence of 'start' and 'stop' in nsds5beginreplicarefresh;left|right attribute into an output of topologysegment_show, e.g.: 'initialization in progress', 'cancellation of re-initialization requested'. === force-sync === no change yet Currently done by setting nsDS5ReplicaUpdateSchedule attribute of repl. agreement. 1. Is it required? 2. Should the functionality be transferred to topologysegment/topology plugin? 3. Is current approach good? IMO if we want to preserve the possibility then the long-term solution is to move it to topology plugin. === list-ruv, clean-ruv, abort-clean-ruv, list-clean-ruv === Commands manages clean-all-ruv operations on REALM suffix. ipa-csreplica-manage doesn't have these commands #4987. These operations are meant for removal of dangling ruvs but they can also remove "correct" RUV which is not desired. The UX is not the best because if replica still exists it won't tell the admin what is the correct RUV and which are the dangling one(s) and therefore admin must get the info in cn=replica,cn=$SUFFIX,cn=mapping tree,cn=config We have a ticket to automate it: https://fedorahosted.org/freeipa/ticket/5411 Is it possible to manage it in topology plugin in centralized manner? I see $5411 as short-term solution for 4.3 or 4.4. + {list|clean|abort-clean-list-clean}-ruv sub-commands should be extended to work with all suffices. Long term solution not in 4.3 is to move it to topology plugin. === dna(next)range-{show|set} commands No change in 4.3. Long term solution is to make it centrally manageable. Not sure if by topo plugin or something else. == ipa-csreplica-manage == This tool manages only CS replication agreements. === list === Not needed. We have `ipa server-find` and `ipa topologysegment-find ipaca` commands. Should be disabled, add to #5405 === connect and disconnect === Replaced by `ipa topologysegment-{add,del}` commands. disable #5405 === del === The work is done in `ipa-replica-manage del` therefore disable #5405 === re-initialize === Same as in ipa-replica-manage - can be disabled. No ticket yet. === force-sync === Same as in ipa-replica-manage - decide what to do. No ticket yet. === set-renewal-master === AFAIK it's only update in cn=masters so could be moved to API then this could be disabled. The change is simple enough for changing in 4.3. No ticket yet. == Conclusion == ipa-csreplica-manage could be abandoned in 4.3 which plays well with topic "simplify management of CA replication agreements". ipa-replica-manage is still needed for RUV handling and removal of replicas in 4.3. This can change in a future. Same situation with DNA ranges handling. There is no future plan for winsync agreements and ipa-replica-manage can remain solely for this purpose in environments with managed topology. -- Petr Vobornik From mbasti at redhat.com Tue Oct 27 14:58:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 15:58:54 +0100 Subject: [Freeipa-devel] [PATCH] DNSZone command with user friendly message In-Reply-To: <562F8019.8020809@redhat.com> References: <562F6764.3000704@redhat.com> <562F8019.8020809@redhat.com> Message-ID: <562F912E.9040702@redhat.com> On 27.10.2015 14:46, Martin Basti wrote: > > > On 27.10.2015 13:00, Abhijeet Kasurde wrote: >> Hi All, >> >> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/4811 >> >> Thanks, >> Abhijeet Kasurde >> >> > [Tue Oct 27 14:44:51.328615 2015] [wsgi:error] [pid 5556] ipa: ERROR: > non-public: AttributeError: 'dnszone' object has no attribute > 'handle_obj_found' > [Tue Oct 27 14:44:51.328654 2015] [wsgi:error] [pid 5556] Traceback > (most recent call last): > [Tue Oct 27 14:44:51.328659 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, > in wsgi_execute > [Tue Oct 27 14:44:51.328664 2015] [wsgi:error] [pid 5556] result = > self.Command[name](*args, **options) > [Tue Oct 27 14:44:51.328669 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in > __call__ > [Tue Oct 27 14:44:51.328674 2015] [wsgi:error] [pid 5556] ret = > self.run(*args, **options) > [Tue Oct 27 14:44:51.328678 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 764, in run > [Tue Oct 27 14:44:51.328683 2015] [wsgi:error] [pid 5556] return > self.execute(*args, **options) > [Tue Oct 27 14:44:51.328687 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2935, > in execute > [Tue Oct 27 14:44:51.328692 2015] [wsgi:error] [pid 5556] result = > super(dnszone_enable, self).execute(*keys, **options) > [Tue Oct 27 14:44:51.328696 2015] [wsgi:error] [pid 5556] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2262, > in execute > [Tue Oct 27 14:44:51.328701 2015] [wsgi:error] [pid 5556] > self.obj.handle_obj_found(*keys) > [Tue Oct 27 14:44:51.328705 2015] [wsgi:error] [pid 5556] > AttributeError: 'dnszone' object has no attribute 'handle_obj_found' > > > Thank you, ACK patch works as expected However now 2 tests are failing because error message was changed, please fix tests too. test_xmlrpc/test_dns_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_forward_zones::test_command[0071: dnsforwardzone_disable: Try to disable non-existent forward zone] FAILED test_xmlrpc/test_dns_plugin.py <- test_xmlrpc/xmlrpc_test.py::test_forward_zones::test_command[0075: dnsforwardzone_enable: Try to enable non-existent forward zone] FAILED E AssertionError: assert_deepequal: expected != got. E E expected = u'no such entry' E got = u'non-existent.fwzone.test.: DNS forward zone not found' E path = () Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Oct 27 15:23:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Oct 2015 16:23:33 +0100 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <5628C334.20100@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561FBE0F.5040601@redhat.com> <562128A9.80600@redhat.com> <5628C334.20100@redhat.com> Message-ID: <562F96F5.1090108@redhat.com> On 10/22/2015 01:06 PM, Petr Vobornik wrote: > On 10/16/2015 06:41 PM, Endi Sukma Dewata wrote: >> On 10/15/2015 9:54 AM, Simo Sorce wrote: >>>> 3) ipa-ca-install fails with: >>>> >>>> Traceback (most recent call last): >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 445, in start_creation >>>> run_step(full_msg, method) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 435, in run_step >>>> method() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line >>>> 631, in __spawn_instance >>>> DogtagInstance.spawn_instance(self, cfg_file) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>>> line 185, in spawn_instance >>>> self.handle_setup_error(e) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>>> line 448, in handle_setup_error >>>> raise RuntimeError("%s configuration failed." % self.subsystem) >>>> RuntimeError: CA configuration failed. >>>> >>>> I guess I'm hitting the authentication bug in Dogtag. It is supposed to >>>> be fixed in pki-core-10.2.6-10, but is it fixed in pki-core-10.2.7-0.2? >>>> We might need a new 10.2.7 build. >>> >>> I am not sure which version has it fixed, Endi ? >> >> PKI ticket #1580 was fixed in pki-core-10.2.6-10 for F23 and F24. We >> never released a pki-core-10.2.7. I suppose that is a custom build? >> > > Yes it is a custom build[4]. > > It was advertised that #1414[1] will be in PKI 10.2.7 but it was > laterincluded into 10.2.6-5. I don't know what's a plan for 10.2.7. > > Required patch for the discussed issue #1580[2] is included in 10.2.6-10 > > So I propose to change requires - patch attached, remove 10.2.7 custom > build from mkosek/freeipa-master repo and add new build(for f22) based > on pki-core-10.2.6-10.fc23 from koji[3] > > > [1] https://fedorahosted.org/pki/ticket/1414 > [2] https://fedorahosted.org/pki/ticket/1580 > [3] http://koji.fedoraproject.org/koji/buildinfo?buildID=689985 > [4] > https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/121544/ > > ACK -- Martin^3 Babinsky From tbabej at redhat.com Tue Oct 27 15:24:58 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 27 Oct 2015 16:24:58 +0100 Subject: [Freeipa-devel] [PATCHES 377-379] Hardening of ipa-adtrust-install Message-ID: <562F974A.2070909@redhat.com> Hi, this couple of patches harden the adtrust installer. Details in the commit messages. Fixes: https://fedorahosted.org/freeipa/ticket/5134 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0377-adtrustinstance-Wait-for-sidgen-task-completion.patch Type: text/x-patch Size: 2196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0378-adtrustinstance-Restart-samba-service-at-the-end-of-.patch Type: text/x-patch Size: 1542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0379-adtrustinstance-Do-not-use-bare-except-clauses.patch Type: text/x-patch Size: 3115 bytes Desc: not available URL: From ofayans at redhat.com Tue Oct 27 15:34:11 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 27 Oct 2015 16:34:11 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F7513.2040403@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> Message-ID: <562F9973.2000309@redhat.com> Hi Martin, The updated patch is attached On 10/27/2015 01:58 PM, Martin Basti wrote: > > > On 27.10.2015 13:56, Oleg Fayans wrote: >> >> >> On 10/27/2015 01:22 PM, Martin Basti wrote: >>> >>> >>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> The updated version of the patch is attached. Please, see my >>>>>>> comments >>>>>>> below >>>>>> My comments inline, I may be completely wrong in how the test suite >>>>>> work, so feel free to correct me. >>>>>> >>>>>> Martin >>>>>> >>>>>>> >>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> Here comes the updated version. >>>>>>>>>>> >>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>> >>>>>>>>>>>>> 1) >>>>>>>>>>>>> please remove the added empty lines, they are unrelated to >>>>>>>>>>>>> this >>>>>>>>>>>>> ticket >>>>>>>>>>> >>>>>>>>>>> done >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2) >>>>>>>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>> >>>>>>>>>>>>> I suggest to use default domainlevel=None, which will use the >>>>>>>>>>>>> default >>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>> >>>>>>>>>>> done >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 3) >>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>> >>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>>> respectively >>>>>>>>>>>>> new IPA must support all older domain levels, domain level is >>>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>>> >>>>>>>>>>>>> So you have to find out way how to pass the domain level for >>>>>>>>>>>>> which >>>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>>> files, >>>>>>>>>>>>> but >>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>> >>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>>>>> directive >>>>>>>>>>> domain_level >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 4) >>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies which >>>>>>>>>>>>> tests >>>>>>>>>>>>> can be >>>>>>>>>>>>> run under which domain level? >>>>>>>>>>> >>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>> require it. >>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>> method, no matter how is it done. >>>>>>>>>> How about topology CI test? This can be executed only with domain >>>>>>>>>> level >>>>>>>>> >>>>>>>>> That's right. The topology test was updated. Patch is attached >>>>>>>>> together with a proper version of 11-th patch (not a swap file, >>>>>>>>> sorry >>>>>>>>> about that). >>>>>>>>> >>>>>>>>>> 1, right? >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 5) >>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>> >>>>>>>>>>>>> why this change to client install? >>>>>>>>>>> >>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> 6) >>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>>>>> function >>>>>>>>>>>> call) >>>>>>>>>>> >>>>>>>>>>> Fixed >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> 1) >>>>>>>> + if not host.config.domain_level == None: >>>>>>>> + args.append("--domain-level=%i" % >>>>>>>> host.config.domain_level) >>>>>>>> >>>>>>>> always use: variable *is not None* >>>>>>>> >>>>>>>> 2) >>>>>>>> Why there is specified level 1 as default? IIRC we agreed that the >>>>>>>> default level is the one which is default in tested package. >>>>>>>> These should be None and "": >>>>>>>> + "domain_level": "1" >>>>>>>> >>>>>>>> + "DOMAINLVL": "1", >>>>>>>> >>>>>>>> 3) >>>>>>>> However, as I read the patch 12, and I'm right, the pytest.fixture >>>>>>>> needs >>>>>>>> to know the value of domain level before we can do any dynamic >>>>>>>> detection >>>>>>>> on master. >>>>>>>> >>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, for 2) >>>>>>> Done >>>>>>>> >>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part >>>>>>>> you >>>>>>>> need default value, or the fixture will not work as expected. >>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>> >>>>>>> This won't work in cases when domainlevel is explicitly set to 0 in >>>>>>> config.yaml. This default value will always override the explicit >>>>>>> one. >>>>>> wat? in case that kwargs is dict containing values from config file: >>>>>> >>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>> >>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>> Out[2]: 0 >>>> >>>> Yep, right you are, it works as expected. Now the line looks like: >>>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>> >>>>>> >>>>> Respectively you should use this: >>>>> >>>>> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL >>>> Now that would definitely not work in case of domain_level is 0: >>>> 0 or 1 is always 1 >>> Oh right. >>> >>> I had discussion with Tomas, and we should add there check if it is not >>> None, in case that kwargs contains {'domain_level': None} (One does not >>> know with test when the None value appears there) >> >> I do not get this. If we do not specify domain_level in config.yaml, >> it will automatically be populated with a MAX_DOMAIN_LEVEL value. That >> means domain_level will never ever possibly be None. > I do not know how pytest works inside, if you are 100% sure, that the > case written above cannot happen, I'm fine with it. > Martin >> >>> >>> self.domain_level = kwargs.get('domain_level') >>> if self.domain_level is None: >>> self.domain_level = MAX_DOMAIN_LEVEL >>> >>> As we cannot user 'or' expression with integers, so this is the right >>> way. >>>> >>>>> >>>>> because kwargs IMO contains undefined config values as None >>>>> >>>>> >>>>> >>>>>>> >>>>>>>> >>>>>>>> freeipa-tests depends on freeipa-python so the constants should be >>>>>>>> available in tests. >>>>>>>> >>>>>>>> So then you also need update this line >>>>>>>> >>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>> + args.append("--domain-level=%i" % >>>>>>>> host.config.domain_level) >>>>>>> >>>>>>> This would not work if domainlevel is not set in config.yaml, in >>>>>>> which case the host.config.domain_level is None. >>>>>> Domain level will never be None because self.domain_level = >>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>> >>>>>>> >>>>>>>> >>>>>>>> 4) >>>>>>>> Please add comment to function +def domainlevel(host): that it is >>>>>>>> useful >>>>>>>> for test where domain level will be raised dynamically, >>>>>>>> otherwise it >>>>>>>> may >>>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>>> unneeded >>>>>>>> and replace it with config dict. >>>>>>> Done >>>>>>> >>>>>>>> >>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>> >>>>>>>> Martin^2 >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0011.4-replica-promotion-changes-in-tests.patch Type: text/x-patch Size: 6171 bytes Desc: not available URL: From lkrispen at redhat.com Tue Oct 27 15:40:05 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 27 Oct 2015 16:40:05 +0100 Subject: [Freeipa-devel] [draft] Fate of ipa-replica-manage and ipa-csreplica-manage tools In-Reply-To: <562F9023.6020207@redhat.com> References: <562F9023.6020207@redhat.com> Message-ID: <562F9AD5.4070400@redhat.com> On 10/27/2015 03:54 PM, Petr Vobornik wrote: > Both tools serve primarily for managing replication agreements and > replicas. ipa-replica-manage also manages winsync agreements and DNA > ranges. > > FreeIPA 4.3 will introduce managed topology which affects these tools. > > Let's go trough all sub-commands of both tools and decide what is the > fate of them/how they should be replaced. Comments are welcome. > > In text, term 'disable' means: print an error message with help what > is the new alternative. > > For domain level == 0 all sub-commands should behave the same way as > before. Proposals are for domain level 1 if not stated otherwise. > > == ipa-replica-manage == > === list === > Lists all IPA server or replication agreements of a specific IPA > server including winsync agreements. > > Server list is replaced by > ipa server-find > Replication agreements by: > ipa topologysegment-find realm > > I see following paths: > 1. do not change (current state) > 2. list only winsync agreements - IMO it will be easier to maintain > > If winsync was not in play we could 'disable' it but winsync is not > planned to be centrally managed. Mainly because the preferred > alternative is trust. > > === connect === > Allow for winsync, disable for REALM agmts. (current state) > > === disconenct === > Allow for winsync, disable for REALM agmts. (current state) > > === del === > (current state) > With domain level 0: > - removes replica and repl. agmts for REALM suffix and winsync > With domain level 1: > - removes replica entry and therefore repl. agmts for all > suffices(REALM, CS) > - ensure last services, e.g. sets renewal master > - does additional cleanup > > I'm not aware of any operation which needs directory manager. IMO it > can be moved to API in future release(e.g. 4.4), especially if > ipa-server-install --uninstall is modified to do most of the cleanup. > > === re-initialize === > Not changed. > > Can be disabled (long-term solution) > > Same capability is in topologysegment_reinitialize API command. The > only difference is that no API command shows state of the pending > operation. Should we transform presence of 'start' and 'stop' in > nsds5beginreplicarefresh;left|right attribute into an output of > topologysegment_show, e.g.: 'initialization in progress', > 'cancellation of re-initialization requested'. yes, something like this would be possible, maybe this can be part of the replication monitoring work, allowing to query the state of specific agreements. > > === force-sync === > no change yet > > Currently done by setting nsDS5ReplicaUpdateSchedule attribute of > repl. agreement. > > 1. Is it required? > 2. Should the functionality be transferred to topologysegment/topology > plugin? > 3. Is current approach good? in fact it is a hack, it uses the fact that a change in the replication agremeent will trigger a fresh start of the protocol thread. It woul be more clean to have "sendupdatesnow" attribute or as a value of the refresh attribute, would require a change in DS > > IMO if we want to preserve the possibility then the long-term solution > is to move it to topology plugin. yes > > === list-ruv, clean-ruv, abort-clean-ruv, list-clean-ruv === > Commands manages clean-all-ruv operations on REALM suffix. > ipa-csreplica-manage doesn't have these commands #4987. These > operations are meant for removal of dangling ruvs but they can also > remove "correct" RUV which is not desired. > > The UX is not the best because if replica still exists it won't tell > the admin what is the correct RUV and which are the dangling one(s) > and therefore admin must get the info in > cn=replica,cn=$SUFFIX,cn=mapping tree,cn=config > > We have a ticket to automate it: > https://fedorahosted.org/freeipa/ticket/5411 > > Is it possible to manage it in topology plugin in centralized manner? > > I see $5411 as short-term solution for 4.3 or 4.4. + > {list|clean|abort-clean-list-clean}-ruv sub-commands should be > extended to work with all suffices. > > Long term solution not in 4.3 is to move it to topology plugin. > > === dna(next)range-{show|set} commands > No change in 4.3. > > Long term solution is to make it centrally manageable. Not sure if by > topo plugin or something else. > > > == ipa-csreplica-manage == > This tool manages only CS replication agreements. > > === list === > Not needed. We have `ipa server-find` and `ipa topologysegment-find > ipaca` commands. > > Should be disabled, add to #5405 > > === connect and disconnect === > Replaced by `ipa topologysegment-{add,del}` commands. > > disable #5405 > > === del === > The work is done in `ipa-replica-manage del` therefore disable #5405 > > === re-initialize === > Same as in ipa-replica-manage - can be disabled. No ticket yet. > > === force-sync === > Same as in ipa-replica-manage - decide what to do. No ticket yet. > > === set-renewal-master === > AFAIK it's only update in cn=masters so could be moved to API then > this could be disabled. > > The change is simple enough for changing in 4.3. No ticket yet. > > == Conclusion == > ipa-csreplica-manage could be abandoned in 4.3 which plays well with > topic "simplify management of CA replication agreements". for domainlevel == 0 we need to keep it > > ipa-replica-manage is still needed for RUV handling and removal of > replicas in 4.3. This can change in a future. Same situation with DNA > ranges handling. > > There is no future plan for winsync agreements and ipa-replica-manage > can remain solely for this purpose in environments with managed topology. yes, and we could rename it to ipa-winsync-manage From tbabej at redhat.com Tue Oct 27 15:44:15 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 27 Oct 2015 16:44:15 +0100 Subject: [Freeipa-devel] [PATCH] enable pem=True in export_pem_cert function In-Reply-To: <20151026195959.GA20574@mniranja.pnq.redhat.com> References: <20151026195959.GA20574@mniranja.pnq.redhat.com> Message-ID: <562F9BCF.2090502@redhat.com> On 10/26/2015 08:59 PM, Niranjan wrote: > Greetings, > > export_pem_cert function from ipapython/certdb should export the certificate > in pem format but instead exports the cert in der format as it doesn't enable pem=True. > > This patch specifies pem=True for export_pem_cert function > > Regards > Niranjan Hi, the patch looks good, however, I'm curious as to how did you find this bug? Does it affect anything? It seems to me that this part of the code is a dead branch which should be removed. $ git grep export_pem_cert ipapython/certdb.py: def export_pem_cert(self, nickname, location): ipaserver/install/certs.py: def export_pem_cert(self, nickname, ipaserver/install/certs.py: return self.nssdb.export_pem_ce.. Tomas From tbabej at redhat.com Tue Oct 27 16:22:52 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 27 Oct 2015 17:22:52 +0100 Subject: [Freeipa-devel] [PATCHES] 0743-0747 Python 3 porting In-Reply-To: <562A7AA6.5040504@redhat.com> References: <562A7AA6.5040504@redhat.com> Message-ID: <562FA4DC.1090000@redhat.com> On 10/23/2015 08:21 PM, Petr Viktorin wrote: > Hello, > Another batch of py3 porting patches. > > With these, the only thing to fix to get ipapython tests passing will be > handling encoding/decoding for stdin/stdout/stderr for ipautil.run(). ACK, it's nice to see some of that old code go. Tomas From tbabej at redhat.com Tue Oct 27 16:23:53 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 27 Oct 2015 17:23:53 +0100 Subject: [Freeipa-devel] [PATCHES] 0743-0747 Python 3 porting In-Reply-To: <562FA4DC.1090000@redhat.com> References: <562A7AA6.5040504@redhat.com> <562FA4DC.1090000@redhat.com> Message-ID: <562FA519.7070709@redhat.com> On 10/27/2015 05:22 PM, Tomas Babej wrote: > > > On 10/23/2015 08:21 PM, Petr Viktorin wrote: >> Hello, >> Another batch of py3 porting patches. >> >> With these, the only thing to fix to get ipapython tests passing will be >> handling encoding/decoding for stdin/stdout/stderr for ipautil.run(). > > ACK, it's nice to see some of that old code go. > > Tomas > Pushed to master: c38516eab7b82f3ba7334cdea7a422a070048b59 From mbasti at redhat.com Tue Oct 27 16:43:28 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Oct 2015 17:43:28 +0100 Subject: [Freeipa-devel] [PATCH] Fix ipa-ca-install bug #5397 In-Reply-To: <562A51AA.8070304@redhat.com> References: <562A51AA.8070304@redhat.com> Message-ID: <562FA9B0.4080209@redhat.com> On 23.10.2015 17:26, Simo Sorce wrote: > This patch moves the check to see if a CA is already installed locally > early. > > Simo. > > > ACK Pushed to master: 53294aa7a7db7eff527455fc35283306b37fc777 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Oct 27 17:06:09 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 Oct 2015 18:06:09 +0100 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <562F96F5.1090108@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> <1443030466.6835.4.camel@willson.usersys.redhat.com> <561F6794.1040201@redhat.com> <561FBE0F.5040601@redhat.com> <562128A9.80600@redhat.com> <5628C334.20100@redhat.com> <562F96F5.1090108@redhat.com> Message-ID: <562FAF01.6060401@redhat.com> On 10/27/2015 04:23 PM, Martin Babinsky wrote: > On 10/22/2015 01:06 PM, Petr Vobornik wrote: >> On 10/16/2015 06:41 PM, Endi Sukma Dewata wrote: >>> On 10/15/2015 9:54 AM, Simo Sorce wrote: >>>>> 3) ipa-ca-install fails with: >>>>> >>>>> Traceback (most recent call last): >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> line 445, in start_creation >>>>> run_step(full_msg, method) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> line 435, in run_step >>>>> method() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line >>>>> 631, in __spawn_instance >>>>> DogtagInstance.spawn_instance(self, cfg_file) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>>>> >>>>> line 185, in spawn_instance >>>>> self.handle_setup_error(e) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >>>>> >>>>> line 448, in handle_setup_error >>>>> raise RuntimeError("%s configuration failed." % self.subsystem) >>>>> RuntimeError: CA configuration failed. >>>>> >>>>> I guess I'm hitting the authentication bug in Dogtag. It is >>>>> supposed to >>>>> be fixed in pki-core-10.2.6-10, but is it fixed in >>>>> pki-core-10.2.7-0.2? >>>>> We might need a new 10.2.7 build. >>>> >>>> I am not sure which version has it fixed, Endi ? >>> >>> PKI ticket #1580 was fixed in pki-core-10.2.6-10 for F23 and F24. We >>> never released a pki-core-10.2.7. I suppose that is a custom build? >>> >> >> Yes it is a custom build[4]. >> >> It was advertised that #1414[1] will be in PKI 10.2.7 but it was >> laterincluded into 10.2.6-5. I don't know what's a plan for 10.2.7. >> >> Required patch for the discussed issue #1580[2] is included in 10.2.6-10 >> >> So I propose to change requires - patch attached, remove 10.2.7 custom >> build from mkosek/freeipa-master repo and add new build(for f22) based >> on pki-core-10.2.6-10.fc23 from koji[3] >> >> >> [1] https://fedorahosted.org/pki/ticket/1414 >> [2] https://fedorahosted.org/pki/ticket/1580 >> [3] http://koji.fedoraproject.org/koji/buildinfo?buildID=689985 >> [4] >> https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/121544/ >> >> > ACK > Pushed to master: 3f0707a199dae98d55d8e1f69b750f2d1ed4dcab pki-core-10.2.6-11 was built for f22 and f23 in mkosek/freeipa-master copr [1] pki-core-10.2.7-0.2 was removed from the copr [1] https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/130759/ -- Petr Vobornik From mbabinsk at redhat.com Tue Oct 27 17:21:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Oct 2015 18:21:33 +0100 Subject: [Freeipa-devel] [PATCH 0091] Silence of the linters Message-ID: <562FB29D.5050900@redhat.com> this patch silences a false-positive pylint error introduced by recent python 3 porting patches (commit c38516eab7b82f3ba7334cdea7a422a070048b59) -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0091-silence-pylint-in-Python-3-specific-portion-of-ipali.patch Type: text/x-patch Size: 905 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Oct 27 17:25:51 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Oct 2015 18:25:51 +0100 Subject: [Freeipa-devel] [PATCH 0091] Silence of the linters In-Reply-To: <562FB29D.5050900@redhat.com> References: <562FB29D.5050900@redhat.com> Message-ID: <562FB39F.9050500@redhat.com> On 10/27/2015 06:21 PM, Martin Babinsky wrote: > this patch silences a false-positive pylint error introduced by recent > python 3 porting patches (commit c38516eab7b82f3ba7334cdea7a422a070048b59) > > > pep8 fail. Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0091.1-silence-pylint-in-Python-3-specific-portion-of-ipali.patch Type: text/x-patch Size: 906 bytes Desc: not available URL: From tbabej at redhat.com Tue Oct 27 17:26:50 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 27 Oct 2015 18:26:50 +0100 Subject: [Freeipa-devel] [PATCH 0091] Silence of the linters In-Reply-To: <562FB39F.9050500@redhat.com> References: <562FB29D.5050900@redhat.com> <562FB39F.9050500@redhat.com> Message-ID: <562FB3DA.5030302@redhat.com> On 10/27/2015 06:25 PM, Martin Babinsky wrote: > On 10/27/2015 06:21 PM, Martin Babinsky wrote: >> this patch silences a false-positive pylint error introduced by recent >> python 3 porting patches (commit >> c38516eab7b82f3ba7334cdea7a422a070048b59) >> >> >> > pep8 fail. > > Attaching updated patch. > > > Thanks for the PEP8 compliant version - now we're reducing the number of errors on all fronts! ACK. Tomas From tbabej at redhat.com Tue Oct 27 17:27:49 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 27 Oct 2015 18:27:49 +0100 Subject: [Freeipa-devel] [PATCH 0091] Silence of the linters In-Reply-To: <562FB3DA.5030302@redhat.com> References: <562FB29D.5050900@redhat.com> <562FB39F.9050500@redhat.com> <562FB3DA.5030302@redhat.com> Message-ID: <562FB415.6070603@redhat.com> On 10/27/2015 06:26 PM, Tomas Babej wrote: > > > On 10/27/2015 06:25 PM, Martin Babinsky wrote: >> On 10/27/2015 06:21 PM, Martin Babinsky wrote: >>> this patch silences a false-positive pylint error introduced by recent >>> python 3 porting patches (commit >>> c38516eab7b82f3ba7334cdea7a422a070048b59) >>> >>> >>> >> pep8 fail. >> >> Attaching updated patch. >> >> >> > > Thanks for the PEP8 compliant version - now we're reducing the number of > errors on all fronts! > > ACK. > > Tomas > Pushed to master: 82fd4250b9b4f408174edec7c7f070dc9fc73ab0 From mbabinsk at redhat.com Tue Oct 27 18:00:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Oct 2015 19:00:05 +0100 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <562F4731.5010104@redhat.com> References: <5620D475.2030200@redhat.com> <562A3234.9040509@redhat.com> <562A32ED.8030702@redhat.com> <562A4FC5.6030603@redhat.com> <562DF3EE.1090708@redhat.com> <562F4731.5010104@redhat.com> Message-ID: <562FBBA5.6020209@redhat.com> On 10/27/2015 10:43 AM, Martin Basti wrote: > > > On 26.10.2015 10:35, Martin Babinsky wrote: >> On 10/23/2015 05:18 PM, Martin Basti wrote: >>> >>> >>> On 23.10.2015 15:15, Martin Babinsky wrote: >>>> On 10/23/2015 03:12 PM, Martin Babinsky wrote: >>>>> On 10/16/2015 12:41 PM, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5345 >>>>>> >>>>>> Patch attached. >>>>>> >>>>>> >>>>> I have tested it on 4-2 branch and it works as expected, ACK. >>>>> >>>>> Obviously, master branch would require a different patch. >>>>> >>>> >>>> I actually missed your check in ipaserver/install/kra.py which can >>>> break ipa-replica-install with --setup-kra, so NACK. >>>> >>> Updated patches attached. >> >> NACK on the master-branch patch. >> >> You forgot a 'return' in this code snippet: >> >> + if self.installing_replica: >> + domain_level = dsinstance.get_domain_level(api) >> + if domain_level > DOMAIN_LEVEL_0: >> + self.options.promote = True >> + return >> >> that would make installation abort when domain level is greter than zero. >> > Updated patch attached. ACK. -- Martin^3 Babinsky From mrniranjan at fedoraproject.org Wed Oct 28 00:29:19 2015 From: mrniranjan at fedoraproject.org (Niranjan) Date: Wed, 28 Oct 2015 05:59:19 +0530 Subject: [Freeipa-devel] [PATCH] enable pem=True in export_pem_cert function In-Reply-To: <562F9BCF.2090502@redhat.com> References: <20151026195959.GA20574@mniranja.pnq.redhat.com> <562F9BCF.2090502@redhat.com> Message-ID: <20151028002919.GA10557@mniranja.pnq.redhat.com> Tomas Babej wrote: > On 10/26/2015 08:59 PM, Niranjan wrote: > > Greetings, > > > > export_pem_cert function from ipapython/certdb should export the certificate > > in pem format but instead exports the cert in der format as it doesn't enable pem=True. > > > > This patch specifies pem=True for export_pem_cert function > > > > Regards > > Niranjan > > Hi, > > the patch looks good, however, I'm curious as to how did you find this > bug? Does it affect anything? I am part of the CS(dogtag) QE team, and as part of CS Automation, i am relying on some generic functions provided by ipapython. While using those functions for our automation, I found it. > > It seems to me that this part of the code is a dead branch which should > be removed. I did not look further ipapython, so i am not aware where else export_pem_cert is being used, but i would like the functions in certdb.py be available. > > $ git grep export_pem_cert > ipapython/certdb.py: def export_pem_cert(self, nickname, location): > ipaserver/install/certs.py: def export_pem_cert(self, nickname, > ipaserver/install/certs.py: return self.nssdb.export_pem_ce.. > > Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From redhatrises at gmail.com Wed Oct 28 01:35:48 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 27 Oct 2015 19:35:48 -0600 Subject: [Freeipa-devel] [PATCH 0058] interactive installer does not ignore leading/trailing whitespace Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5355 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0058-interactive-installer-does-not-ignore-leading-traili.patch Type: text/x-patch Size: 1280 bytes Desc: not available URL: From akasurde at redhat.com Wed Oct 28 07:06:14 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 28 Oct 2015 12:36:14 +0530 Subject: [Freeipa-devel] [PATCH] DNSZone command with user friendly message In-Reply-To: <562F912E.9040702@redhat.com> References: <562F6764.3000704@redhat.com> <562F8019.8020809@redhat.com> <562F912E.9040702@redhat.com> Message-ID: <563073E6.6030201@redhat.com> On 10/27/2015 08:28 PM, Martin Basti wrote: > > > On 27.10.2015 14:46, Martin Basti wrote: >> >> >> On 27.10.2015 13:00, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/4811 >>> >>> Thanks, >>> Abhijeet Kasurde >>> >>> >> [Tue Oct 27 14:44:51.328615 2015] [wsgi:error] [pid 5556] ipa: ERROR: >> non-public: AttributeError: 'dnszone' object has no attribute >> 'handle_obj_found' >> [Tue Oct 27 14:44:51.328654 2015] [wsgi:error] [pid 5556] Traceback >> (most recent call last): >> [Tue Oct 27 14:44:51.328659 2015] [wsgi:error] [pid 5556] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, >> in wsgi_execute >> [Tue Oct 27 14:44:51.328664 2015] [wsgi:error] [pid 5556] result = >> self.Command[name](*args, **options) >> [Tue Oct 27 14:44:51.328669 2015] [wsgi:error] [pid 5556] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in >> __call__ >> [Tue Oct 27 14:44:51.328674 2015] [wsgi:error] [pid 5556] ret = >> self.run(*args, **options) >> [Tue Oct 27 14:44:51.328678 2015] [wsgi:error] [pid 5556] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 764, in run >> [Tue Oct 27 14:44:51.328683 2015] [wsgi:error] [pid 5556] return >> self.execute(*args, **options) >> [Tue Oct 27 14:44:51.328687 2015] [wsgi:error] [pid 5556] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2935, >> in execute >> [Tue Oct 27 14:44:51.328692 2015] [wsgi:error] [pid 5556] result = >> super(dnszone_enable, self).execute(*keys, **options) >> [Tue Oct 27 14:44:51.328696 2015] [wsgi:error] [pid 5556] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2262, >> in execute >> [Tue Oct 27 14:44:51.328701 2015] [wsgi:error] [pid 5556] >> self.obj.handle_obj_found(*keys) >> [Tue Oct 27 14:44:51.328705 2015] [wsgi:error] [pid 5556] >> AttributeError: 'dnszone' object has no attribute 'handle_obj_found' >> >> >> > Thank you, ACK patch works as expected > > However now 2 tests are failing because error message was changed, > please fix tests too. > > test_xmlrpc/test_dns_plugin.py <- > test_xmlrpc/xmlrpc_test.py::test_forward_zones::test_command[0071: > dnsforwardzone_disable: Try to disable non-existent forward zone] FAILED > test_xmlrpc/test_dns_plugin.py <- > test_xmlrpc/xmlrpc_test.py::test_forward_zones::test_command[0075: > dnsforwardzone_enable: Try to enable non-existent forward zone] FAILED > > E AssertionError: assert_deepequal: expected != got. > E > E expected = u'no such entry' > E got = u'non-existent.fwzone.test.: DNS forward zone not > found' > E path = () > Updated patch with testcase > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-3-Added-user-friendly-error-message-for-dnszone-enable.patch Type: text/x-patch Size: 2974 bytes Desc: not available URL: From ofayans at redhat.com Wed Oct 28 18:56:24 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 28 Oct 2015 19:56:24 +0100 Subject: [Freeipa-devel] File contains no config_file_version Message-ID: <56311A58.2090202@redhat.com> Hi guys, The following error is thrown at the attempt to install a new replica from a freshly built upstream packages: [24/24]: enabling CA instance Done configuring certificate server (pki-tomcatd). ipa.ipapython.install.cli.install_tool(Replica): ERROR File contains no config_file_version ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. The log is attached The basic replica's functionality is OK though. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log.gz Type: application/gzip Size: 169495 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Oct 29 07:44:30 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 29 Oct 2015 08:44:30 +0100 Subject: [Freeipa-devel] File contains no config_file_version In-Reply-To: <56311A58.2090202@redhat.com> References: <56311A58.2090202@redhat.com> Message-ID: <5631CE5E.4040603@redhat.com> On 10/28/2015 07:56 PM, Oleg Fayans wrote: > Hi guys, > > > The following error is thrown at the attempt to install a new replica > from a freshly built upstream packages: > > [24/24]: enabling CA instance > Done configuring certificate server (pki-tomcatd). > ipa.ipapython.install.cli.install_tool(Replica): ERROR File contains > no config_file_version > ipa.ipapython.install.cli.install_tool(Replica): ERROR The > ipa-replica-install command failed. See /var/log/ipareplica-install.log > for more information > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > The log is attached > > The basic replica's functionality is OK though. > > > > Hi Oleg, this is caused by a bug in sssd. The following build for F22 fixes it https://bodhi.fedoraproject.org/updates/FEDORA-2015-5e1da56d16 -- Martin^3 Babinsky From pspacek at redhat.com Thu Oct 29 08:56:55 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 29 Oct 2015 09:56:55 +0100 Subject: [Freeipa-devel] [draft] Fate of ipa-replica-manage and ipa-csreplica-manage tools In-Reply-To: <562F9023.6020207@redhat.com> References: <562F9023.6020207@redhat.com> Message-ID: <5631DF57.4080301@redhat.com> On 27.10.2015 15:54, Petr Vobornik wrote: > Both tools serve primarily for managing replication agreements and replicas. > ipa-replica-manage also manages winsync agreements and DNA ranges. > > FreeIPA 4.3 will introduce managed topology which affects these tools. > > Let's go trough all sub-commands of both tools and decide what is the fate of > them/how they should be replaced. Comments are welcome. > > In text, term 'disable' means: print an error message with help what is the > new alternative. > > For domain level == 0 all sub-commands should behave the same way as before. > Proposals are for domain level 1 if not stated otherwise. > > == ipa-replica-manage == > === list === > Lists all IPA server or replication agreements of a specific IPA server > including winsync agreements. > > Server list is replaced by > ipa server-find > Replication agreements by: > ipa topologysegment-find realm > > I see following paths: > 1. do not change (current state) > 2. list only winsync agreements - IMO it will be easier to maintain > > If winsync was not in play we could 'disable' it but winsync is not planned to > be centrally managed. Mainly because the preferred alternative is trust. > > === connect === > Allow for winsync, disable for REALM agmts. (current state) > > === disconenct === > Allow for winsync, disable for REALM agmts. (current state) > > === del === > (current state) > With domain level 0: > - removes replica and repl. agmts for REALM suffix and winsync > With domain level 1: > - removes replica entry and therefore repl. agmts for all suffices(REALM, CS) > - ensure last services, e.g. sets renewal master > - does additional cleanup > > I'm not aware of any operation which needs directory manager. IMO it can be > moved to API in future release(e.g. 4.4), especially if ipa-server-install > --uninstall is modified to do most of the cleanup. > > === re-initialize === > Not changed. > > Can be disabled (long-term solution) > > Same capability is in topologysegment_reinitialize API command. The only > difference is that no API command shows state of the pending operation. Should > we transform presence of 'start' and 'stop' in > nsds5beginreplicarefresh;left|right attribute into an output of > topologysegment_show, e.g.: 'initialization in progress', 'cancellation of > re-initialization requested'. > > === force-sync === > no change yet > > Currently done by setting nsDS5ReplicaUpdateSchedule attribute of repl. > agreement. > > 1. Is it required? > 2. Should the functionality be transferred to topologysegment/topology plugin? > 3. Is current approach good? > > IMO if we want to preserve the possibility then the long-term solution is to > move it to topology plugin. > > === list-ruv, clean-ruv, abort-clean-ruv, list-clean-ruv === > Commands manages clean-all-ruv operations on REALM suffix. > ipa-csreplica-manage doesn't have these commands #4987. These operations are > meant for removal of dangling ruvs but they can also remove "correct" RUV > which is not desired. > > The UX is not the best because if replica still exists it won't tell the admin > what is the correct RUV and which are the dangling one(s) and therefore admin > must get the info in cn=replica,cn=$SUFFIX,cn=mapping tree,cn=config > > We have a ticket to automate it: https://fedorahosted.org/freeipa/ticket/5411 > > Is it possible to manage it in topology plugin in centralized manner? > > I see $5411 as short-term solution for 4.3 or 4.4. + > {list|clean|abort-clean-list-clean}-ruv sub-commands should be extended to > work with all suffices. > > Long term solution not in 4.3 is to move it to topology plugin. > > === dna(next)range-{show|set} commands > No change in 4.3. > > Long term solution is to make it centrally manageable. Not sure if by topo > plugin or something else. > > > == ipa-csreplica-manage == > This tool manages only CS replication agreements. > > === list === > Not needed. We have `ipa server-find` and `ipa topologysegment-find ipaca` > commands. > > Should be disabled, add to #5405 > > === connect and disconnect === > Replaced by `ipa topologysegment-{add,del}` commands. > > disable #5405 > > === del === > The work is done in `ipa-replica-manage del` therefore disable #5405 > > === re-initialize === > Same as in ipa-replica-manage - can be disabled. No ticket yet. > > === force-sync === > Same as in ipa-replica-manage - decide what to do. No ticket yet. > > === set-renewal-master === > AFAIK it's only update in cn=masters so could be moved to API then this could > be disabled. > > The change is simple enough for changing in 4.3. No ticket yet. > > == Conclusion == > ipa-csreplica-manage could be abandoned in 4.3 which plays well with topic > "simplify management of CA replication agreements". > > ipa-replica-manage is still needed for RUV handling and removal of replicas in > 4.3. This can change in a future. Same situation with DNA ranges handling. > > There is no future plan for winsync agreements and ipa-replica-manage can > remain solely for this purpose in environments with managed topology. Generally +1, we just need to make sure that ipa-{,cs}replica-manage print useful help message if domainlevel != 0. We need to make migration for users as easy as possible. -- Petr^2 Spacek From mbabinsk at redhat.com Thu Oct 29 10:19:50 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 29 Oct 2015 11:19:50 +0100 Subject: [Freeipa-devel] [PATCH 0092] ipa-replica-prepare: more robust and concise check for supported domain level Message-ID: <5631F2C6.8010802@redhat.com> Petr^2 and Tomas were not happy by the way https://fedorahosted.org/freeipa/ticket/5175 was handled initially, so here is a patch that tries to amend some of the issues. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0092-ipa-replica-prepare-more-robust-and-concise-check-fo.patch Type: text/x-patch Size: 3357 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 29 12:10:02 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 Oct 2015 13:10:02 +0100 Subject: [Freeipa-devel] [PATCH 0092] ipa-replica-prepare: more robust and concise check for supported domain level In-Reply-To: <5631F2C6.8010802@redhat.com> References: <5631F2C6.8010802@redhat.com> Message-ID: <56320C9A.4020109@redhat.com> On 10/29/2015 11:19 AM, Martin Babinsky wrote: > Petr^2 and Tomas were not happy by the way > https://fedorahosted.org/freeipa/ticket/5175 was handled initially, so > here is a patch that tries to amend some of the issues. > > > IMHO the original text was good. Tomas, why is the huge blob thing in exception bad? Issues with new code/text. 1. it is supported but not for domain level != 0: self.log.error("Using replica files to set up IPA replicas is not " + "supported." + ) 2. format() is not needed: + self.log.info( + "To create a replica, you must promote an existing " + "IPA client.".format(domain_level=domain_level) + ) 3. I don't like that the exception text says 'requires', which might imply something to be done - lower domain level - which is not possible. "allowed only" might be better. Just changing RuntimeError to InvalidDomainLevelError would be fine with me since the MIN_DOMAIN_LEVEL was already changed to DOMAIN_LEVEL_0. -- Petr Vobornik From tbabej at redhat.com Thu Oct 29 12:28:03 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 29 Oct 2015 13:28:03 +0100 Subject: [Freeipa-devel] [PATCH 0092] ipa-replica-prepare: more robust and concise check for supported domain level In-Reply-To: <56320C9A.4020109@redhat.com> References: <5631F2C6.8010802@redhat.com> <56320C9A.4020109@redhat.com> Message-ID: <563210D3.8020209@redhat.com> On 10/29/2015 01:10 PM, Petr Vobornik wrote: > On 10/29/2015 11:19 AM, Martin Babinsky wrote: >> Petr^2 and Tomas were not happy by the way >> https://fedorahosted.org/freeipa/ticket/5175 was handled initially, so >> here is a patch that tries to amend some of the issues. >> >> >> > > IMHO the original text was good. > > Tomas, why is the huge blob thing in exception bad? > > Issues with new code/text. > > 1. it is supported but not for domain level != 0: > self.log.error("Using replica files to set up IPA replicas is not " > + "supported." > + ) > > 2. format() is not needed: > + self.log.info( > + "To create a replica, you must promote an existing " > + "IPA client.".format(domain_level=domain_level) > + ) > > 3. I don't like that the exception text says 'requires', which might > imply something to be done - lower domain level - which is not possible. > "allowed only" might be better. > > > Just changing RuntimeError to InvalidDomainLevelError would be fine with > me since the MIN_DOMAIN_LEVEL was already changed to DOMAIN_LEVEL_0. I was fine with the old text too. In my opinion exceptions should not be used to handle detailed instructions to the user, they should be used to briefly summarize the gist of the error that occurred. If not bad practice, it's at least quite unconventional. There are better mechanisms to handle the detailed instructions spanning over multiple lines (with newlines hardcoded) down to the user, such as using the logger with sufficient level. So I would approach this issue by just dumping the formatted UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE down the logger at the error level and then raising the InvalidDomainLevelError exception with the brief reasoning. Tomas From redhatrises at gmail.com Thu Oct 29 12:28:35 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 29 Oct 2015 06:28:35 -0600 Subject: [Freeipa-devel] [PATCH 0059] Add Firefox options to ipa-client-install man page Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5375 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0059-Add-Firefox-options-to-ipa-client-install-man-page.patch Type: text/x-patch Size: 2269 bytes Desc: not available URL: From tbordaz at redhat.com Thu Oct 29 12:28:16 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 29 Oct 2015 13:28:16 +0100 Subject: [Freeipa-devel] [PATCH 0020-0021] some topology plugin fixes In-Reply-To: <5629F352.9050005@redhat.com> References: <5629F352.9050005@redhat.com> Message-ID: <563210E0.4060607@redhat.com> On 10/23/2015 10:44 AM, Ludwig Krispenz wrote: > Hi, > the attached two patches address issues I found when testing ca > management in the topology plugin > > Thanks for review, > Ludwig > > Hi Ludwig, Patch 20 is good to me. I have one remark, you call ipa_topo_cfg_host_find with lock flag. So that the replica config is not updated during the test. Now the lock protects each call separately. The risk is very low that the target host could become unmanaged by the time we test the source host. ACK. Patch 21 is also good. Just in ipa_topo_util_init_hosts, why not calling ipa_topo_cfg_host_add to not duplicate the source ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 29 12:42:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Oct 2015 13:42:44 +0100 Subject: [Freeipa-devel] [PATCH] DNSZone command with user friendly message In-Reply-To: <563073E6.6030201@redhat.com> References: <562F6764.3000704@redhat.com> <562F8019.8020809@redhat.com> <562F912E.9040702@redhat.com> <563073E6.6030201@redhat.com> Message-ID: <56321444.1090409@redhat.com> On 28.10.2015 08:06, Abhijeet Kasurde wrote: > > > On 10/27/2015 08:28 PM, Martin Basti wrote: >> >> >> On 27.10.2015 14:46, Martin Basti wrote: >>> >>> >>> On 27.10.2015 13:00, Abhijeet Kasurde wrote: >>>> Hi All, >>>> >>>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/4811 >>>> >>>> Thanks, >>>> Abhijeet Kasurde >>>> >>>> >>> [Tue Oct 27 14:44:51.328615 2015] [wsgi:error] [pid 5556] ipa: >>> ERROR: non-public: AttributeError: 'dnszone' object has no attribute >>> 'handle_obj_found' >>> [Tue Oct 27 14:44:51.328654 2015] [wsgi:error] [pid 5556] Traceback >>> (most recent call last): >>> [Tue Oct 27 14:44:51.328659 2015] [wsgi:error] [pid 5556] File >>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, >>> in wsgi_execute >>> [Tue Oct 27 14:44:51.328664 2015] [wsgi:error] [pid 5556] result = >>> self.Command[name](*args, **options) >>> [Tue Oct 27 14:44:51.328669 2015] [wsgi:error] [pid 5556] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in >>> __call__ >>> [Tue Oct 27 14:44:51.328674 2015] [wsgi:error] [pid 5556] ret = >>> self.run(*args, **options) >>> [Tue Oct 27 14:44:51.328678 2015] [wsgi:error] [pid 5556] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 764, in run >>> [Tue Oct 27 14:44:51.328683 2015] [wsgi:error] [pid 5556] return >>> self.execute(*args, **options) >>> [Tue Oct 27 14:44:51.328687 2015] [wsgi:error] [pid 5556] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2935, >>> in execute >>> [Tue Oct 27 14:44:51.328692 2015] [wsgi:error] [pid 5556] result = >>> super(dnszone_enable, self).execute(*keys, **options) >>> [Tue Oct 27 14:44:51.328696 2015] [wsgi:error] [pid 5556] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py", line 2262, >>> in execute >>> [Tue Oct 27 14:44:51.328701 2015] [wsgi:error] [pid 5556] >>> self.obj.handle_obj_found(*keys) >>> [Tue Oct 27 14:44:51.328705 2015] [wsgi:error] [pid 5556] >>> AttributeError: 'dnszone' object has no attribute 'handle_obj_found' >>> >>> >>> >> Thank you, ACK patch works as expected >> >> However now 2 tests are failing because error message was changed, >> please fix tests too. >> >> test_xmlrpc/test_dns_plugin.py <- >> test_xmlrpc/xmlrpc_test.py::test_forward_zones::test_command[0071: >> dnsforwardzone_disable: Try to disable non-existent forward zone] FAILED >> test_xmlrpc/test_dns_plugin.py <- >> test_xmlrpc/xmlrpc_test.py::test_forward_zones::test_command[0075: >> dnsforwardzone_enable: Try to enable non-existent forward zone] FAILED >> >> E AssertionError: assert_deepequal: expected != got. >> E >> E expected = u'no such entry' >> E got = u'non-existent.fwzone.test.: DNS forward zone not >> found' >> E path = () >> > Updated patch with testcase >> Martin > Pushed to master: c60cec4fa7adf004d383b68b78f6fd51d5cecb21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 29 13:02:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Oct 2015 14:02:21 +0100 Subject: [Freeipa-devel] [PATCH 0059] Add Firefox options to ipa-client-install man page In-Reply-To: References: Message-ID: <563218DD.5030606@redhat.com> On 29.10.2015 13:28, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5375 > > Thanks, > > Gabe > > Thank you! ACK Pushed to master: cc5a659d4304873d6f89c47a11877026cd442199 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 29 13:14:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Oct 2015 14:14:04 +0100 Subject: [Freeipa-devel] [PATCH 0058] interactive installer does not ignore leading/trailing whitespace In-Reply-To: References: Message-ID: <56321B9C.5040305@redhat.com> On 28.10.2015 02:35, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5355 > > Thanks, > > Gabe > > Thank you Gabe, but patch needs more work to be complete: Bool and integer choices also need to strip whitespaces, see bellow: Do you want to configure DNS forwarders? [yes]: no Do you want to configure DNS forwarders? [yes]: no Do you want to configure DNS forwarders? [yes]: no Do you want to configure DNS forwarders? [yes]: no No DNS forwarders configured Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 29 13:28:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Oct 2015 14:28:53 +0100 Subject: [Freeipa-devel] [PATCH 0327] KRA: fix check if CA is installed on replica In-Reply-To: <562FBBA5.6020209@redhat.com> References: <5620D475.2030200@redhat.com> <562A3234.9040509@redhat.com> <562A32ED.8030702@redhat.com> <562A4FC5.6030603@redhat.com> <562DF3EE.1090708@redhat.com> <562F4731.5010104@redhat.com> <562FBBA5.6020209@redhat.com> Message-ID: <56321F15.8000900@redhat.com> On 27.10.2015 19:00, Martin Babinsky wrote: > On 10/27/2015 10:43 AM, Martin Basti wrote: >> >> >> On 26.10.2015 10:35, Martin Babinsky wrote: >>> On 10/23/2015 05:18 PM, Martin Basti wrote: >>>> >>>> >>>> On 23.10.2015 15:15, Martin Babinsky wrote: >>>>> On 10/23/2015 03:12 PM, Martin Babinsky wrote: >>>>>> On 10/16/2015 12:41 PM, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5345 >>>>>>> >>>>>>> Patch attached. >>>>>>> >>>>>>> >>>>>> I have tested it on 4-2 branch and it works as expected, ACK. >>>>>> >>>>>> Obviously, master branch would require a different patch. >>>>>> >>>>> >>>>> I actually missed your check in ipaserver/install/kra.py which can >>>>> break ipa-replica-install with --setup-kra, so NACK. >>>>> >>>> Updated patches attached. >>> >>> NACK on the master-branch patch. >>> >>> You forgot a 'return' in this code snippet: >>> >>> + if self.installing_replica: >>> + domain_level = dsinstance.get_domain_level(api) >>> + if domain_level > DOMAIN_LEVEL_0: >>> + self.options.promote = True >>> + return >>> >>> that would make installation abort when domain level is greter than >>> zero. >>> >> Updated patch attached. > ACK. > Pushed to ipa-4-2: 0f77745c5033ee321447a86a0499865c3c4b29e4 Pushed to master: 4ec8df27392b4f47c03c2cded26d6695d8c38186 From redhatrises at gmail.com Thu Oct 29 13:42:03 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 29 Oct 2015 07:42:03 -0600 Subject: [Freeipa-devel] [PATCH 0058] interactive installer does not ignore leading/trailing whitespace In-Reply-To: <56321B9C.5040305@redhat.com> References: <56321B9C.5040305@redhat.com> Message-ID: My bad Martin^2. Here is an updated patch. Gabe On Thu, Oct 29, 2015 at 7:14 AM, Martin Basti wrote: > > > On 28.10.2015 02:35, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/5355 > > Thanks, > > Gabe > > > Thank you Gabe, but patch needs more work to be complete: > > Bool and integer choices also need to strip whitespaces, see bellow: > > Do you want to configure DNS forwarders? [yes]: no > Do you want to configure DNS forwarders? [yes]: no > Do you want to configure DNS forwarders? [yes]: no > Do you want to configure DNS forwarders? [yes]: no > No DNS forwarders configured > > Martin^2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0058-2-interactive-installer-does-not-ignore-leading-traili.patch Type: text/x-patch Size: 1922 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Oct 29 14:01:09 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 29 Oct 2015 15:01:09 +0100 Subject: [Freeipa-devel] [PATCH 0092] ipa-replica-prepare: more robust and concise check for supported domain level In-Reply-To: <563210D3.8020209@redhat.com> References: <5631F2C6.8010802@redhat.com> <56320C9A.4020109@redhat.com> <563210D3.8020209@redhat.com> Message-ID: <563226A5.30808@redhat.com> On 10/29/2015 01:28 PM, Tomas Babej wrote: > > > On 10/29/2015 01:10 PM, Petr Vobornik wrote: >> On 10/29/2015 11:19 AM, Martin Babinsky wrote: >>> Petr^2 and Tomas were not happy by the way >>> https://fedorahosted.org/freeipa/ticket/5175 was handled initially, so >>> here is a patch that tries to amend some of the issues. >>> >>> >>> >> >> IMHO the original text was good. >> >> Tomas, why is the huge blob thing in exception bad? >> >> Issues with new code/text. >> >> 1. it is supported but not for domain level != 0: >> self.log.error("Using replica files to set up IPA replicas is not " >> + "supported." >> + ) >> >> 2. format() is not needed: >> + self.log.info( >> + "To create a replica, you must promote an existing " >> + "IPA client.".format(domain_level=domain_level) >> + ) >> >> 3. I don't like that the exception text says 'requires', which might >> imply something to be done - lower domain level - which is not possible. >> "allowed only" might be better. >> >> >> Just changing RuntimeError to InvalidDomainLevelError would be fine with >> me since the MIN_DOMAIN_LEVEL was already changed to DOMAIN_LEVEL_0. > > > I was fine with the old text too. In my opinion exceptions should not be > used to handle detailed instructions to the user, they should be used to > briefly summarize the gist of the error that occurred. > > If not bad practice, it's at least quite unconventional. There are > better mechanisms to handle the detailed instructions spanning over > multiple lines (with newlines hardcoded) down to the user, such as using > the logger with sufficient level. > > So I would approach this issue by just dumping the formatted > UNSUPPORTED_DOMAIN_LEVEL_TEMPLATE down the logger at the error level and > then raising the InvalidDomainLevelError exception with the brief reasoning. > > Tomas > OK i seemed to misunderstand your concerns. Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0092.1-ipa-replica-prepare-domain-level-check-improvements.patch Type: text/x-patch Size: 2466 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Oct 29 16:45:32 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 29 Oct 2015 17:45:32 +0100 Subject: [Freeipa-devel] [PATCH 0082] remove Kerberos authenticators after service uninstall In-Reply-To: <56324A4A.900@redhat.com> References: <56324A4A.900@redhat.com> Message-ID: <56324D2C.9030009@redhat.com> Once again for the whole list: On 10/22/2015 05:32 PM, Petr Spacek wrote: > On 21.10.2015 17:55, Martin Babinsky wrote: >> On 10/13/2015 09:17 AM, Petr Spacek wrote: >>> On 12.10.2015 13:38, Martin Babinsky wrote: >>>> >>>> each service possessing Kerberos keytab wiil now remove it and destroy any >>>> associated credentials cache during its uninstall >>>> >>>> https://fedorahosted.org/freeipa/ticket/5243 >>> >>> BTW some time ago Simo proposed that we should remove caches and old keytabs >>> during *install* so problems caused by failing uninstallation will be fixed on >>> repeated install. This is yet another step towards idempotent installer. >>> >>> To me this makes more sense than doing so on uninstall. Does it make sense to >>> you, too? >>> >> >> Attaching updated patch that does cleanup also before each instance creation. >> It is a bit ugly I admit, but I couldn't think of a better way to do it and >> didn't want to poke into service/instance code more than neccesary. > > NACK, but we are almost there! > > * kdestroy -A is too aggressive and wipes root's keyring after each run of > ipa-*-install utils. > That was caused by the env variables of running process being leaked into the subprocess running kdestroy. The attached patch should fix that. > * There are some scattered leftovers of ipautil.run['kdestroy'...] in the > tree. Please get rid of them. > I will make that in a separate patch if you are OK with it. > Thank you! > -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0082.2-remove-Kerberos-authenticators-when-installing-unins.patch Type: text/x-patch Size: 8317 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 29 17:03:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Oct 2015 18:03:13 +0100 Subject: [Freeipa-devel] [PATCH 0058] interactive installer does not ignore leading/trailing whitespace In-Reply-To: References: <56321B9C.5040305@redhat.com> Message-ID: <56325151.9090008@redhat.com> On 29.10.2015 14:42, Gabe Alford wrote: > My bad Martin^2. Here is an updated patch. > > Gabe Thanks, ACK Pushed to master: 9ffb3882532436dfd475831ee74b06e1b785251f > > On Thu, Oct 29, 2015 at 7:14 AM, Martin Basti > wrote: > > > > On 28.10.2015 02:35, Gabe Alford wrote: >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5355 >> >> Thanks, >> >> Gabe >> >> > Thank you Gabe, but patch needs more work to be complete: > > Bool and integer choices also need to strip whitespaces, see bellow: > > Do you want to configure DNS forwarders? [yes]: no > Do you want to configure DNS forwarders? [yes]: no > Do you want to configure DNS forwarders? [yes]: no > Do you want to configure DNS forwarders? [yes]: no > No DNS forwarders configured > > Martin^2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 29 17:31:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Oct 2015 18:31:02 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <562F9973.2000309@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> Message-ID: <563257D6.2000701@redhat.com> NACK 1) DO NOT use tabs in code to indent 2) Replica uninstallation does not work, uninstallation works different with domain level 0 and 1 (currently uninstallation with domain 1 level will not work, it is known issue, but still the patch should solve the uninstallation) 3) apply_common_fixes(host) Method for domain_level 1 is called twice, first time in replica install, second time in client install 4) during testing this patch I used test_simple_replication and I found 4 bugs: #5419, #5420, #5421 IMO it is related only to this one test case and to pass this test case #5419 or #5421 must be fixed. On 27.10.2015 16:34, Oleg Fayans wrote: > Hi Martin, > > The updated patch is attached > > On 10/27/2015 01:58 PM, Martin Basti wrote: >> >> >> On 27.10.2015 13:56, Oleg Fayans wrote: >>> >>> >>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>> >>>> >>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>> comments >>>>>>>> below >>>>>>> My comments inline, I may be completely wrong in how the test suite >>>>>>> work, so feel free to correct me. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>>> >>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>> >>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> please remove the added empty lines, they are unrelated to >>>>>>>>>>>>>> this >>>>>>>>>>>>>> ticket >>>>>>>>>>>> >>>>>>>>>>>> done >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) >>>>>>>>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>> >>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will use >>>>>>>>>>>>>> the >>>>>>>>>>>>>> default >>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>> >>>>>>>>>>>> done >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) >>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>>>> respectively >>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>> level is >>>>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So you have to find out way how to pass the domain level for >>>>>>>>>>>>>> which >>>>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>>>> files, >>>>>>>>>>>>>> but >>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>> >>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>>>>>> directive >>>>>>>>>>>> domain_level >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4) >>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies which >>>>>>>>>>>>>> tests >>>>>>>>>>>>>> can be >>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>> >>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>> require it. >>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>> How about topology CI test? This can be executed only with >>>>>>>>>>> domain >>>>>>>>>>> level >>>>>>>>>> >>>>>>>>>> That's right. The topology test was updated. Patch is attached >>>>>>>>>> together with a proper version of 11-th patch (not a swap file, >>>>>>>>>> sorry >>>>>>>>>> about that). >>>>>>>>>> >>>>>>>>>>> 1, right? >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 5) >>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>> >>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>> >>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> 6) >>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>>>>>> function >>>>>>>>>>>>> call) >>>>>>>>>>>> >>>>>>>>>>>> Fixed >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>> host.config.domain_level) >>>>>>>>> >>>>>>>>> always use: variable *is not None* >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> Why there is specified level 1 as default? IIRC we agreed that >>>>>>>>> the >>>>>>>>> default level is the one which is default in tested package. >>>>>>>>> These should be None and "": >>>>>>>>> + "domain_level": "1" >>>>>>>>> >>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>> pytest.fixture >>>>>>>>> needs >>>>>>>>> to know the value of domain level before we can do any dynamic >>>>>>>>> detection >>>>>>>>> on master. >>>>>>>>> >>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>> for 2) >>>>>>>> Done >>>>>>>>> >>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part >>>>>>>>> you >>>>>>>>> need default value, or the fixture will not work as expected. >>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>> >>>>>>>> This won't work in cases when domainlevel is explicitly set to >>>>>>>> 0 in >>>>>>>> config.yaml. This default value will always override the explicit >>>>>>>> one. >>>>>>> wat? in case that kwargs is dict containing values from config >>>>>>> file: >>>>>>> >>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>> >>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>> Out[2]: 0 >>>>> >>>>> Yep, right you are, it works as expected. Now the line looks like: >>>>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>> >>>>>>> >>>>>> Respectively you should use this: >>>>>> >>>>>> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL >>>>> Now that would definitely not work in case of domain_level is 0: >>>>> 0 or 1 is always 1 >>>> Oh right. >>>> >>>> I had discussion with Tomas, and we should add there check if it is >>>> not >>>> None, in case that kwargs contains {'domain_level': None} (One does >>>> not >>>> know with test when the None value appears there) >>> >>> I do not get this. If we do not specify domain_level in config.yaml, >>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. That >>> means domain_level will never ever possibly be None. >> I do not know how pytest works inside, if you are 100% sure, that the >> case written above cannot happen, I'm fine with it. >> Martin >>> >>>> >>>> self.domain_level = kwargs.get('domain_level') >>>> if self.domain_level is None: >>>> self.domain_level = MAX_DOMAIN_LEVEL >>>> >>>> As we cannot user 'or' expression with integers, so this is the right >>>> way. >>>>> >>>>>> >>>>>> because kwargs IMO contains undefined config values as None >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>> should be >>>>>>>>> available in tests. >>>>>>>>> >>>>>>>>> So then you also need update this line >>>>>>>>> >>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>> host.config.domain_level) >>>>>>>> >>>>>>>> This would not work if domainlevel is not set in config.yaml, in >>>>>>>> which case the host.config.domain_level is None. >>>>>>> Domain level will never be None because self.domain_level = >>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 4) >>>>>>>>> Please add comment to function +def domainlevel(host): that it is >>>>>>>>> useful >>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>> otherwise it >>>>>>>>> may >>>>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>>>> unneeded >>>>>>>>> and replace it with config dict. >>>>>>>> Done >>>>>>>> >>>>>>>>> >>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>> >>>>>>>>> Martin^2 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mbasti at redhat.com Thu Oct 29 17:32:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Oct 2015 18:32:58 +0100 Subject: [Freeipa-devel] [PATCH 0011] Replica promotion related changes in integration tests In-Reply-To: <563257D6.2000701@redhat.com> References: <5628D2CF.2000107@redhat.com> <5628E35A.30308@redhat.com> <562902E3.8020707@redhat.com> <562A2F53.5050408@redhat.com> <562A31C1.5050105@redhat.com> <562DDD4E.5020801@redhat.com> <562E676A.7040207@redhat.com> <562F3D1C.6070901@redhat.com> <562F424D.3060003@redhat.com> <562F48D8.6010500@redhat.com> <562F5AA4.2060502@redhat.com> <562F6C7D.8090808@redhat.com> <562F749A.3080204@redhat.com> <562F7513.2040403@redhat.com> <562F9973.2000309@redhat.com> <563257D6.2000701@redhat.com> Message-ID: <5632584A.7070607@redhat.com> On 29.10.2015 18:31, Martin Basti wrote: > NACK > > 1) > DO NOT use tabs in code to indent > > 2) > Replica uninstallation does not work, uninstallation works different > with domain level 0 and 1 (currently uninstallation with domain 1 > level will not work, it is known issue, but still the patch should > solve the uninstallation) > > 3) > apply_common_fixes(host) > Method for domain_level 1 is called twice, first time in replica > install, second time in client install > > 4) > during testing this patch I used test_simple_replication and I found 4 > bugs: 3 bugs -----------------^^^ > #5419, #5420, #5421 > IMO it is related only to this one test case and to pass this test > case #5419 or #5421 must be fixed. > > > On 27.10.2015 16:34, Oleg Fayans wrote: >> Hi Martin, >> >> The updated patch is attached >> >> On 10/27/2015 01:58 PM, Martin Basti wrote: >>> >>> >>> On 27.10.2015 13:56, Oleg Fayans wrote: >>>> >>>> >>>> On 10/27/2015 01:22 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 27.10.2015 12:06, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> On 10/27/2015 10:50 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 27.10.2015 10:22, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 27.10.2015 10:00, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> The updated version of the patch is attached. Please, see my >>>>>>>>> comments >>>>>>>>> below >>>>>>>> My comments inline, I may be completely wrong in how the test >>>>>>>> suite >>>>>>>> work, so feel free to correct me. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>>> >>>>>>>>> On 10/26/2015 06:48 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 26.10.2015 08:59, Oleg Fayans wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/23/2015 03:10 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 23.10.2015 15:00, Oleg Fayans wrote: >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> Here comes the updated version. >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/22/2015 05:38 PM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22.10.2015 15:23, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 22.10.2015 14:13, Oleg Fayans wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thank you for the patch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> please remove the added empty lines, they are unrelated to >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> ticket >>>>>>>>>>>>> >>>>>>>>>>>>> done >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>> -def install_master(host, setup_dns=True, setup_kra=False): >>>>>>>>>>>>>>> +def install_master(host, setup_dns=True, setup_kra=False, >>>>>>>>>>>>>>> domainlevel=1): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I suggest to use default domainlevel=None, which will >>>>>>>>>>>>>>> use the >>>>>>>>>>>>>>> default >>>>>>>>>>>>>>> domain level (specified in build) >>>>>>>>>>>>> >>>>>>>>>>>>> done >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>> + domain_level = domainlevel(master) >>>>>>>>>>>>>>> I do not think that this meets expectations. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have to test, both domain level 0 and 1 for IPA 4.3, >>>>>>>>>>>>>>> respectively >>>>>>>>>>>>>>> new IPA must support all older domain levels, domain >>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>> independent on IPA version, only admin can raise it up. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So you have to find out way how to pass the domain level >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>> test will be running, we were talking about using config >>>>>>>>>>>>>>> files, >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>> feel free to find something new and better >>>>>>>>>>>>> >>>>>>>>>>>>> Fixed. Now, we declare domain level in config.yaml with the >>>>>>>>>>>>> directive >>>>>>>>>>>>> domain_level >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>> Did you resolve the pytest fixtures which specifies which >>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>> run under which domain level? >>>>>>>>>>>>> >>>>>>>>>>>>> In fact, we do not seem to have any tests yet that would >>>>>>>>>>>>> require it. >>>>>>>>>>>>> All the existing tests just use install_replica >>>>>>>>>>>>> method, no matter how is it done. >>>>>>>>>>>> How about topology CI test? This can be executed only with >>>>>>>>>>>> domain >>>>>>>>>>>> level >>>>>>>>>>> >>>>>>>>>>> That's right. The topology test was updated. Patch is attached >>>>>>>>>>> together with a proper version of 11-th patch (not a swap file, >>>>>>>>>>> sorry >>>>>>>>>>> about that). >>>>>>>>>>> >>>>>>>>>>>> 1, right? >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>> + '--ip-address', client.ip, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> why this change to client install? >>>>>>>>>>>>> >>>>>>>>>>>>> Right, it found to be unnecessary. >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> 6) >>>>>>>>>>>>>> ************* Module ipatests.test_integration.tasks >>>>>>>>>>>>>> ipatests/test_integration/tasks.py:85: >>>>>>>>>>>>>> [E1123(unexpected-keyword-arg), >>>>>>>>>>>>>> allow_sync_ptr] Unexpected keyword argument 'raiseonerr' in >>>>>>>>>>>>>> function >>>>>>>>>>>>>> call) >>>>>>>>>>>>> >>>>>>>>>>>>> Fixed >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1) >>>>>>>>>> + if not host.config.domain_level == None: >>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>> host.config.domain_level) >>>>>>>>>> >>>>>>>>>> always use: variable *is not None* >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> Why there is specified level 1 as default? IIRC we agreed >>>>>>>>>> that the >>>>>>>>>> default level is the one which is default in tested package. >>>>>>>>>> These should be None and "": >>>>>>>>>> + "domain_level": "1" >>>>>>>>>> >>>>>>>>>> + "DOMAINLVL": "1", >>>>>>>>>> >>>>>>>>>> 3) >>>>>>>>>> However, as I read the patch 12, and I'm right, the >>>>>>>>>> pytest.fixture >>>>>>>>>> needs >>>>>>>>>> to know the value of domain level before we can do any dynamic >>>>>>>>>> detection >>>>>>>>>> on master. >>>>>>>>>> >>>>>>>>>> So we should use the constants MAX_DOMAIN_LEVEL as default, >>>>>>>>>> for 2) >>>>>>>>> Done >>>>>>>>>> >>>>>>>>>> Also I'm not sure if the values are inherited from the >>>>>>>>>> DEFAULT_OUTPUT_DICT to code, I think it is not, so for this part >>>>>>>>>> you >>>>>>>>>> need default value, or the fixture will not work as expected. >>>>>>>>>> + self.domain_level = kwargs.get('domain_level', >>>>>>>>>> MAX_DOMAIN_LEVEL) >>>>>>>>> >>>>>>>>> This won't work in cases when domainlevel is explicitly set to >>>>>>>>> 0 in >>>>>>>>> config.yaml. This default value will always override the explicit >>>>>>>>> one. >>>>>>>> wat? in case that kwargs is dict containing values from config >>>>>>>> file: >>>>>>>> >>>>>>>> In [1]: kwargs = dict(domain_level=0) >>>>>>>> >>>>>>>> In [2]: kwargs.get('domain_level', 123) >>>>>>>> Out[2]: 0 >>>>>> >>>>>> Yep, right you are, it works as expected. Now the line looks like: >>>>>> self.domain_level = kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>> >>>>>>>> >>>>>>> Respectively you should use this: >>>>>>> >>>>>>> self.domain_level = kwargs.get('domain_level')or MAX_DOMAIN_LEVEL >>>>>> Now that would definitely not work in case of domain_level is 0: >>>>>> 0 or 1 is always 1 >>>>> Oh right. >>>>> >>>>> I had discussion with Tomas, and we should add there check if it >>>>> is not >>>>> None, in case that kwargs contains {'domain_level': None} (One >>>>> does not >>>>> know with test when the None value appears there) >>>> >>>> I do not get this. If we do not specify domain_level in config.yaml, >>>> it will automatically be populated with a MAX_DOMAIN_LEVEL value. That >>>> means domain_level will never ever possibly be None. >>> I do not know how pytest works inside, if you are 100% sure, that the >>> case written above cannot happen, I'm fine with it. >>> Martin >>>> >>>>> >>>>> self.domain_level = kwargs.get('domain_level') >>>>> if self.domain_level is None: >>>>> self.domain_level = MAX_DOMAIN_LEVEL >>>>> >>>>> As we cannot user 'or' expression with integers, so this is the right >>>>> way. >>>>>> >>>>>>> >>>>>>> because kwargs IMO contains undefined config values as None >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> freeipa-tests depends on freeipa-python so the constants >>>>>>>>>> should be >>>>>>>>>> available in tests. >>>>>>>>>> >>>>>>>>>> So then you also need update this line >>>>>>>>>> >>>>>>>>>> + if not host.config.domain_level != MAX_DOMAIN_LEVEL: >>>>>>>>>> + args.append("--domain-level=%i" % >>>>>>>>>> host.config.domain_level) >>>>>>>>> >>>>>>>>> This would not work if domainlevel is not set in config.yaml, in >>>>>>>>> which case the host.config.domain_level is None. >>>>>>>> Domain level will never be None because self.domain_level = >>>>>>>> kwargs.get('domain_level', MAX_DOMAIN_LEVEL) >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 4) >>>>>>>>>> Please add comment to function +def domainlevel(host): that >>>>>>>>>> it is >>>>>>>>>> useful >>>>>>>>>> for test where domain level will be raised dynamically, >>>>>>>>>> otherwise it >>>>>>>>>> may >>>>>>>>>> be lost after test refactoring as somebody may consider it as >>>>>>>>>> unneeded >>>>>>>>>> and replace it with config dict. >>>>>>>>> Done >>>>>>>>> >>>>>>>>>> >>>>>>>>>> So summary is the 1) and 2) are replaced by 3) :) >>>>>>>>>> >>>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From redhatrises at gmail.com Fri Oct 30 03:39:53 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 29 Oct 2015 21:39:53 -0600 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5414 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0060-Incomplete-ports-for-IPA-AD-Trust.patch Type: text/x-patch Size: 781 bytes Desc: not available URL: From redhatrises at gmail.com Fri Oct 30 03:39:55 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 29 Oct 2015 21:39:55 -0600 Subject: [Freeipa-devel] [PATCH 0061] Remove 50-lockout-policy.update file Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5418 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0061-Remove-50-lockout-policy.update-file.patch Type: text/x-patch Size: 1332 bytes Desc: not available URL: From abokovoy at redhat.com Fri Oct 30 06:54:31 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 08:54:31 +0200 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust In-Reply-To: References: Message-ID: <20151030065431.GI8374@redhat.com> On Thu, 29 Oct 2015, Gabe Alford wrote: >Hello, > >Fix for https://fedorahosted.org/freeipa/ticket/5414 > >Thanks, > >Gabe >From 515582d66252521a3cbf6a6a48f33745bd788c86 Mon Sep 17 00:00:00 2001 >From: Gabe >Date: Thu, 29 Oct 2015 20:28:27 -0600 >Subject: [PATCH] Incomplete ports for IPA AD Trust > >https://fedorahosted.org/freeipa/ticket/5414 >--- > install/tools/ipa-adtrust-install | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install >index 1f41cc437e8a930c350eac0fb34e5bebc9f9b55b..84e28b57524b2c3308e52cc56b4b370276add0b7 100755 >--- a/install/tools/ipa-adtrust-install >+++ b/install/tools/ipa-adtrust-install >@@ -472,6 +472,7 @@ Setup complete > > You must make sure these network ports are open: > \tTCP Ports: >+\t * 135: epmap > \t * 138: netbios-dgm > \t * 139: netbios-ssn > \t * 445: microsoft-ds This is good but not complete. What end-point mapper does is creating a listener based on the incoming request and access to the listener needs to be provided as well. A listener is created currently in the range of 1024..1300/TCP but we already have request to make this range configurable (it is hard coded right now in Samba code) because with Windows 2008 Microsoft moved it from 1025..5000 to 49152..65535: https://support.microsoft.com/en-us/kb/929851 We were thinking to add a call out hook on Samba side to call firewall-related script that could do hole punching on demand but it is not there yet. What we could do in ipa-adtrust-install, is to add section about TCP/UDP ports to the manual page and explicitly reference that one in case of epmap line: \t *135: epmap (see ipa-adtrust-install(1) man page for details) We don't have the firewall section in the manpage at all, btw. What do you think? -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 30 06:56:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 08:56:56 +0200 Subject: [Freeipa-devel] [PATCH 0061] Remove 50-lockout-policy.update file In-Reply-To: References: Message-ID: <20151030065656.GJ8374@redhat.com> On Thu, 29 Oct 2015, Gabe Alford wrote: >Hello, > >Fix for https://fedorahosted.org/freeipa/ticket/5418 ACK but can you please add something like this in the commit message: ---- Remove lockout policy update file because all currently supported FreeIPA versions already have krbPwdMaxFailure defaulting to 6 and krbPwdLockoutDuration defaulting to 600. Keeping lockout policy update file prevents from creating a more strict policy in environments where it is subject to regulatory compliance. ---- > >Thanks, > >Gabe >From 7a9086162717bc414a1d65ea71a2d65729f6fa7e Mon Sep 17 00:00:00 2001 >From: Gabe >Date: Thu, 29 Oct 2015 20:30:35 -0600 >Subject: [PATCH] Remove 50-lockout-policy.update file > >https://fedorahosted.org/freeipa/ticket/5418 >--- > install/updates/50-lockout-policy.update | 4 ---- > install/updates/Makefile.am | 1 - > 2 files changed, 5 deletions(-) > delete mode 100644 install/updates/50-lockout-policy.update > >diff --git a/install/updates/50-lockout-policy.update b/install/updates/50-lockout-policy.update >deleted file mode 100644 >index a5730709e2b649466118502ece1cc530c10e0b40..0000000000000000000000000000000000000000 >--- a/install/updates/50-lockout-policy.update >+++ /dev/null >@@ -1,4 +0,0 @@ >-dn: cn=global_policy,cn=$REALM,cn=kerberos,$SUFFIX >-replace:krbPwdLockoutDuration:10::600 >-replace: krbPwdMaxFailure:3::6 >- >diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am >index 26e4c04ed66a4a2061a3bb3ca2f4a6cd84502598..04ddeb96de4e88d5909f13b13885d3207184e798 100644 >--- a/install/updates/Makefile.am >+++ b/install/updates/Makefile.am >@@ -39,7 +39,6 @@ app_DATA = \ > 45-roles.update \ > 50-7_bit_check.update \ > 50-dogtag10-migration.update \ >- 50-lockout-policy.update \ > 50-groupuuid.update \ > 50-hbacservice.update \ > 50-krbenctypes.update \ >-- >2.4.3 > >-- >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 pspacek at redhat.com Fri Oct 30 08:18:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 30 Oct 2015 09:18:59 +0100 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust In-Reply-To: <20151030065431.GI8374@redhat.com> References: <20151030065431.GI8374@redhat.com> Message-ID: <563327F3.7090703@redhat.com> On 30.10.2015 07:54, Alexander Bokovoy wrote: > On Thu, 29 Oct 2015, Gabe Alford wrote: >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5414 >> >> Thanks, >> >> Gabe > >> From 515582d66252521a3cbf6a6a48f33745bd788c86 Mon Sep 17 00:00:00 2001 >> From: Gabe >> Date: Thu, 29 Oct 2015 20:28:27 -0600 >> Subject: [PATCH] Incomplete ports for IPA AD Trust >> >> https://fedorahosted.org/freeipa/ticket/5414 >> --- >> install/tools/ipa-adtrust-install | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/install/tools/ipa-adtrust-install >> b/install/tools/ipa-adtrust-install >> index >> 1f41cc437e8a930c350eac0fb34e5bebc9f9b55b..84e28b57524b2c3308e52cc56b4b370276add0b7 >> 100755 >> --- a/install/tools/ipa-adtrust-install >> +++ b/install/tools/ipa-adtrust-install >> @@ -472,6 +472,7 @@ Setup complete >> >> You must make sure these network ports are open: >> \tTCP Ports: >> +\t * 135: epmap >> \t * 138: netbios-dgm >> \t * 139: netbios-ssn >> \t * 445: microsoft-ds > This is good but not complete. What end-point mapper does is creating a > listener based on the incoming request and access to the listener needs > to be provided as well. A listener is created currently in the range of > 1024..1300/TCP but we already have request to make this range > configurable (it is hard coded right now in Samba code) because with > Windows 2008 Microsoft moved it from 1025..5000 to 49152..65535: > https://support.microsoft.com/en-us/kb/929851 > > We were thinking to add a call out hook on Samba side to call > firewall-related script that could do hole punching on demand but it is > not there yet. > > What we could do in ipa-adtrust-install, is to add section about TCP/UDP > ports to the manual page and explicitly reference that one in case of > epmap line: > \t *135: epmap (see ipa-adtrust-install(1) man page for details) > > We don't have the firewall section in the manpage at all, btw. > > What do you think? Maybe I'm missing something, but ... Could we simply put current range 1024..1300/TCP to the installer now and do other changes as Samba evolves? I think that it is good enough as a hotfix and that we do not need to over-complicate it in the beginning. -- Petr^2 Spacek From mbasti at redhat.com Fri Oct 30 08:31:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 09:31:59 +0100 Subject: [Freeipa-devel] [PATCH 0338] Drop configure.jar file Message-ID: <56332AFF.8050904@redhat.com> https://fedorahosted.org/freeipa/ticket/5144 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0338-Drop-configure.jar.patch Type: text/x-patch Size: 6552 bytes Desc: not available URL: From lkrispen at redhat.com Fri Oct 30 08:57:48 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 30 Oct 2015 09:57:48 +0100 Subject: [Freeipa-devel] [PATCH 0020-0021] some topology plugin fixes In-Reply-To: <563210E0.4060607@redhat.com> References: <5629F352.9050005@redhat.com> <563210E0.4060607@redhat.com> Message-ID: <5633310C.6050109@redhat.com> On 10/29/2015 01:28 PM, thierry bordaz wrote: > On 10/23/2015 10:44 AM, Ludwig Krispenz wrote: >> Hi, >> the attached two patches address issues I found when testing ca >> management in the topology plugin >> >> Thanks for review, >> Ludwig >> >> > Hi Ludwig, > > Patch 20 is good to me. I have one remark, you call > ipa_topo_cfg_host_find with lock flag. So that the replica config is > not updated during the test. > Now the lock protects each call separately. The risk is very low that > the target host could become unmanaged by the time we test the source > host. yes, and if two paralle operations do related things like adding an agreement and making a host managed/unmanaged there is a race for the lock. The lock itself cannot prevent these things, it only can protect the data structures from being read while modified. Also with two separate locked calls the second call has a chance to be aware of parallel changes > ACK. > > Patch 21 is also good. Just in ipa_topo_util_init_hosts, why not > calling ipa_topo_cfg_host_add to not duplicate the source ? no reason, revised patch is attached, thanks for noticing > > thanks > thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lkrispen-freeipa-0021-1-update-list-of-managed-servers-when-a-suffix-becomes.patch Type: text/x-patch Size: 6816 bytes Desc: not available URL: From tbordaz at redhat.com Fri Oct 30 09:08:19 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 30 Oct 2015 10:08:19 +0100 Subject: [Freeipa-devel] [PATCH 0020-0021] some topology plugin fixes In-Reply-To: <5633310C.6050109@redhat.com> References: <5629F352.9050005@redhat.com> <563210E0.4060607@redhat.com> <5633310C.6050109@redhat.com> Message-ID: <56333383.2060604@redhat.com> On 10/30/2015 09:57 AM, Ludwig Krispenz wrote: > > On 10/29/2015 01:28 PM, thierry bordaz wrote: >> On 10/23/2015 10:44 AM, Ludwig Krispenz wrote: >>> Hi, >>> the attached two patches address issues I found when testing ca >>> management in the topology plugin >>> >>> Thanks for review, >>> Ludwig >>> >>> >> Hi Ludwig, >> >> Patch 20 is good to me. I have one remark, you call >> ipa_topo_cfg_host_find with lock flag. So that the replica config is >> not updated during the test. >> Now the lock protects each call separately. The risk is very low that >> the target host could become unmanaged by the time we test the source >> host. > yes, and if two paralle operations do related things like adding an > agreement and making a host managed/unmanaged there is a race for the > lock. The lock itself cannot prevent these things, it only can protect > the data structures from being read while modified. > Also with two separate locked calls the second call has a chance to be > aware of parallel changes >> ACK. >> >> Patch 21 is also good. Just in ipa_topo_util_init_hosts, why not >> calling ipa_topo_cfg_host_add to not duplicate the source ? > no reason, revised patch is attached, thanks for noticing Thanks Ludwig for the changes. ACK >> >> thanks >> thierry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Oct 30 09:41:18 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 30 Oct 2015 10:41:18 +0100 Subject: [Freeipa-devel] [PATCH 0060-0061] DNSSEC improvements in uninstaller Message-ID: <56333B3E.40104@redhat.com> Hello, DNSSEC: on uninstall, do not restore OpenDNSSEC kasp.db if backup failed DNSSEC: improve log messages in uninstaller This is suitable for ipa-4-2 branch and newer. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0060-DNSSEC-improve-log-messages-in-uninstaller.patch Type: text/x-patch Size: 1225 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0061-DNSSEC-on-uninstall-do-not-restore-OpenDNSSEC-kasp.d.patch Type: text/x-patch Size: 2142 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 30 09:42:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 Oct 2015 10:42:01 +0100 Subject: [Freeipa-devel] [draft] Fate of ipa-replica-manage and ipa-csreplica-manage tools In-Reply-To: <562F9AD5.4070400@redhat.com> References: <562F9023.6020207@redhat.com> <562F9AD5.4070400@redhat.com> Message-ID: <56333B69.3080306@redhat.com> On 10/27/2015 04:40 PM, Ludwig Krispenz wrote: > > On 10/27/2015 03:54 PM, Petr Vobornik wrote: >> Both tools serve primarily for managing replication agreements and replicas. >> ipa-replica-manage also manages winsync agreements and DNA ranges. >> >> FreeIPA 4.3 will introduce managed topology which affects these tools. >> >> Let's go trough all sub-commands of both tools and decide what is the fate of >> them/how they should be replaced. Comments are welcome. >> >> In text, term 'disable' means: print an error message with help what is the >> new alternative. >> >> For domain level == 0 all sub-commands should behave the same way as before. >> Proposals are for domain level 1 if not stated otherwise. >> >> == ipa-replica-manage == >> === list === >> Lists all IPA server or replication agreements of a specific IPA server >> including winsync agreements. Note that people are used to use "-v" switch to show status of these agreements. There would need to be a replacement for this functionality to get rid of this command. >> Server list is replaced by >> ipa server-find >> Replication agreements by: >> ipa topologysegment-find realm >> >> I see following paths: >> 1. do not change (current state) >> 2. list only winsync agreements - IMO it will be easier to maintain >> >> If winsync was not in play we could 'disable' it but winsync is not planned >> to be centrally managed. Mainly because the preferred alternative is trust. 2 may be a good choice, but we first need to find the alternative for above. I do not think deprecating a list is a "must" for 4.3. >> === connect === >> Allow for winsync, disable for REALM agmts. (current state) >> >> === disconenct === >> Allow for winsync, disable for REALM agmts. (current state) +1. >> === del === >> (current state) >> With domain level 0: >> - removes replica and repl. agmts for REALM suffix and winsync >> With domain level 1: >> - removes replica entry and therefore repl. agmts for all suffices(REALM, CS) >> - ensure last services, e.g. sets renewal master >> - does additional cleanup >> >> I'm not aware of any operation which needs directory manager. IMO it can be >> moved to API in future release(e.g. 4.4), especially if ipa-server-install >> --uninstall is modified to do most of the cleanup. Ok. >> >> === re-initialize === >> Not changed. >> >> Can be disabled (long-term solution) >> >> Same capability is in topologysegment_reinitialize API command. The only >> difference is that no API command shows state of the pending operation. >> Should we transform presence of 'start' and 'stop' in >> nsds5beginreplicarefresh;left|right attribute into an output of >> topologysegment_show, e.g.: 'initialization in progress', 'cancellation of >> re-initialization requested'. > yes, something like this would be possible, > maybe this can be part of the replication monitoring work, allowing to query > the state of specific agreements. Can topologysegment-reinitialize simply wait? The behavior and related options could be similar as with automember-rebuild. I am wondering if topologysegment-reinitialize is not too low level. Normally, the problem you are solving is that some of your master is out of sync and cannot be fixed. Then you want to have some command to re-intitialize *the master*, with the command potentially picking the best topologysegment to be used. >> === force-sync === >> no change yet >> >> Currently done by setting nsDS5ReplicaUpdateSchedule attribute of repl. >> agreement. >> >> 1. Is it required? >> 2. Should the functionality be transferred to topologysegment/topology plugin? >> 3. Is current approach good? > in fact it is a hack, it uses the fact that a change in the replication > agremeent will trigger a fresh start of the protocol thread. It woul be more > clean to have "sendupdatesnow" attribute or as a value of the refresh > attribute, would require a change in DS Change in DS to support some of the Topology functionality is tricky. Is this a blocker for releasing 4.3 with DL 1? Where I am coming from is that if Topology functionality depend on a DS function, we cannot be sure that the Topology call works for all masters. And I do not think we want to release DL 2 to support also this command. >> IMO if we want to preserve the possibility then the long-term solution is to >> move it to topology plugin. > yes Yes, but see above. >> === list-ruv, clean-ruv, abort-clean-ruv, list-clean-ruv === >> Commands manages clean-all-ruv operations on REALM suffix. >> ipa-csreplica-manage doesn't have these commands #4987. These operations are >> meant for removal of dangling ruvs but they can also remove "correct" RUV >> which is not desired. >> >> The UX is not the best because if replica still exists it won't tell the >> admin what is the correct RUV and which are the dangling one(s) and therefore >> admin must get the info in cn=replica,cn=$SUFFIX,cn=mapping tree,cn=config >> >> We have a ticket to automate it: https://fedorahosted.org/freeipa/ticket/5411 >> >> Is it possible to manage it in topology plugin in centralized manner? >> >> I see $5411 as short-term solution for 4.3 or 4.4. + >> {list|clean|abort-clean-list-clean}-ruv sub-commands should be extended to >> work with all suffices. >> >> Long term solution not in 4.3 is to move it to topology plugin. Would be nice to be moved to Topology. But same as above, we should think if the change breaks the DL 1 or the fact that some of the servers has the patch and some don't do not break anything. >> === dna(next)range-{show|set} commands >> No change in 4.3. >> >> Long term solution is to make it centrally manageable. Not sure if by topo >> plugin or something else. Currently, this configuration is set in cn=config. So here are 2 ways - enhance Topology plugin or have some other Config Sync related plugin. >> == ipa-csreplica-manage == >> This tool manages only CS replication agreements. Yes. I think we want to stop using it completely in 4.3 in order to really simplify CS management: https://fedorahosted.org/freeipa/ticket/3053 >> === list === >> Not needed. We have `ipa server-find` and `ipa topologysegment-find ipaca` >> commands. >> >> Should be disabled, add to #5405 Yes, but also consider the "-v" option question above. >> >> === connect and disconnect === >> Replaced by `ipa topologysegment-{add,del}` commands. >> >> disable #5405 >> >> === del === >> The work is done in `ipa-replica-manage del` therefore disable #5405 >> >> === re-initialize === >> Same as in ipa-replica-manage - can be disabled. No ticket yet. >> >> === force-sync === >> Same as in ipa-replica-manage - decide what to do. No ticket yet. >> >> === set-renewal-master === >> AFAIK it's only update in cn=masters so could be moved to API then this could >> be disabled. >> >> The change is simple enough for changing in 4.3. No ticket yet. Yup, looks like server-add-role type of command. >> == Conclusion == >> ipa-csreplica-manage could be abandoned in 4.3 which plays well with topic >> "simplify management of CA replication agreements". > for domainlevel == 0 we need to keep it >> >> ipa-replica-manage is still needed for RUV handling and removal of replicas >> in 4.3. This can change in a future. Same situation with DNA ranges handling. >> >> There is no future plan for winsync agreements and ipa-replica-manage can >> remain solely for this purpose in environments with managed topology. > yes, and we could rename it to ipa-winsync-manage +1, that sounds as the end-game we want. From mbasti at redhat.com Fri Oct 30 09:55:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 10:55:03 +0100 Subject: [Freeipa-devel] [PATCH 0060-0061] DNSSEC improvements in uninstaller In-Reply-To: <56333B3E.40104@redhat.com> References: <56333B3E.40104@redhat.com> Message-ID: <56333E77.9050802@redhat.com> On 30.10.2015 10:41, Petr Spacek wrote: > Hello, > > DNSSEC: on uninstall, do not restore OpenDNSSEC kasp.db if backup failed > DNSSEC: improve log messages in uninstaller > > This is suitable for ipa-4-2 branch and newer. > NACK Please extract the list from for cycle to separate variable and do extend with that variable. Also this code doesnt work, I tried simillar in python and I got: In [1]: t=[1] In [2]: for f in [10, 20, 30].extend(t): ...: print f ...: --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 for f in [10, 20, 30].extend(t): 2 print f 3 TypeError: 'NoneType' object is not iterable From abokovoy at redhat.com Fri Oct 30 10:10:30 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 12:10:30 +0200 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust In-Reply-To: <563327F3.7090703@redhat.com> References: <20151030065431.GI8374@redhat.com> <563327F3.7090703@redhat.com> Message-ID: <20151030101029.GN8374@redhat.com> On Fri, 30 Oct 2015, Petr Spacek wrote: >On 30.10.2015 07:54, Alexander Bokovoy wrote: >> On Thu, 29 Oct 2015, Gabe Alford wrote: >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/5414 >>> >>> Thanks, >>> >>> Gabe >> >>> From 515582d66252521a3cbf6a6a48f33745bd788c86 Mon Sep 17 00:00:00 2001 >>> From: Gabe >>> Date: Thu, 29 Oct 2015 20:28:27 -0600 >>> Subject: [PATCH] Incomplete ports for IPA AD Trust >>> >>> https://fedorahosted.org/freeipa/ticket/5414 >>> --- >>> install/tools/ipa-adtrust-install | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/install/tools/ipa-adtrust-install >>> b/install/tools/ipa-adtrust-install >>> index >>> 1f41cc437e8a930c350eac0fb34e5bebc9f9b55b..84e28b57524b2c3308e52cc56b4b370276add0b7 >>> 100755 >>> --- a/install/tools/ipa-adtrust-install >>> +++ b/install/tools/ipa-adtrust-install >>> @@ -472,6 +472,7 @@ Setup complete >>> >>> You must make sure these network ports are open: >>> \tTCP Ports: >>> +\t * 135: epmap >>> \t * 138: netbios-dgm >>> \t * 139: netbios-ssn >>> \t * 445: microsoft-ds >> This is good but not complete. What end-point mapper does is creating a >> listener based on the incoming request and access to the listener needs >> to be provided as well. A listener is created currently in the range of >> 1024..1300/TCP but we already have request to make this range >> configurable (it is hard coded right now in Samba code) because with >> Windows 2008 Microsoft moved it from 1025..5000 to 49152..65535: >> https://support.microsoft.com/en-us/kb/929851 >> >> We were thinking to add a call out hook on Samba side to call >> firewall-related script that could do hole punching on demand but it is >> not there yet. >> >> What we could do in ipa-adtrust-install, is to add section about TCP/UDP >> ports to the manual page and explicitly reference that one in case of >> epmap line: >> \t *135: epmap (see ipa-adtrust-install(1) man page for details) >> >> We don't have the firewall section in the manpage at all, btw. >> >> What do you think? > >Maybe I'm missing something, but ... Could we simply put current range >1024..1300/TCP to the installer now and do other changes as Samba evolves? I >think that it is good enough as a hotfix and that we do not need to >over-complicate it in the beginning. That's essentially what I said too -- but I want to have firewall requirements documented in the manpage so that they are available beforehand _and_ people actually read them when they are referenced in the output. I'm not asking for anything else here. Documentation is needed. -- / Alexander Bokovoy From pspacek at redhat.com Fri Oct 30 10:12:44 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 30 Oct 2015 11:12:44 +0100 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust In-Reply-To: <20151030101029.GN8374@redhat.com> References: <20151030065431.GI8374@redhat.com> <563327F3.7090703@redhat.com> <20151030101029.GN8374@redhat.com> Message-ID: <5633429C.7090401@redhat.com> On 30.10.2015 11:10, Alexander Bokovoy wrote: > On Fri, 30 Oct 2015, Petr Spacek wrote: >> On 30.10.2015 07:54, Alexander Bokovoy wrote: >>> On Thu, 29 Oct 2015, Gabe Alford wrote: >>>> Hello, >>>> >>>> Fix for https://fedorahosted.org/freeipa/ticket/5414 >>>> >>>> Thanks, >>>> >>>> Gabe >>> >>>> From 515582d66252521a3cbf6a6a48f33745bd788c86 Mon Sep 17 00:00:00 2001 >>>> From: Gabe >>>> Date: Thu, 29 Oct 2015 20:28:27 -0600 >>>> Subject: [PATCH] Incomplete ports for IPA AD Trust >>>> >>>> https://fedorahosted.org/freeipa/ticket/5414 >>>> --- >>>> install/tools/ipa-adtrust-install | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/install/tools/ipa-adtrust-install >>>> b/install/tools/ipa-adtrust-install >>>> index >>>> 1f41cc437e8a930c350eac0fb34e5bebc9f9b55b..84e28b57524b2c3308e52cc56b4b370276add0b7 >>>> >>>> 100755 >>>> --- a/install/tools/ipa-adtrust-install >>>> +++ b/install/tools/ipa-adtrust-install >>>> @@ -472,6 +472,7 @@ Setup complete >>>> >>>> You must make sure these network ports are open: >>>> \tTCP Ports: >>>> +\t * 135: epmap >>>> \t * 138: netbios-dgm >>>> \t * 139: netbios-ssn >>>> \t * 445: microsoft-ds >>> This is good but not complete. What end-point mapper does is creating a >>> listener based on the incoming request and access to the listener needs >>> to be provided as well. A listener is created currently in the range of >>> 1024..1300/TCP but we already have request to make this range >>> configurable (it is hard coded right now in Samba code) because with >>> Windows 2008 Microsoft moved it from 1025..5000 to 49152..65535: >>> https://support.microsoft.com/en-us/kb/929851 >>> >>> We were thinking to add a call out hook on Samba side to call >>> firewall-related script that could do hole punching on demand but it is >>> not there yet. >>> >>> What we could do in ipa-adtrust-install, is to add section about TCP/UDP >>> ports to the manual page and explicitly reference that one in case of >>> epmap line: >>> \t *135: epmap (see ipa-adtrust-install(1) man page for details) >>> >>> We don't have the firewall section in the manpage at all, btw. >>> >>> What do you think? >> >> Maybe I'm missing something, but ... Could we simply put current range >> 1024..1300/TCP to the installer now and do other changes as Samba evolves? I >> think that it is good enough as a hotfix and that we do not need to >> over-complicate it in the beginning. > That's essentially what I said too -- but I want to have firewall > requirements documented in the manpage so that they are available > beforehand _and_ people actually read them when they are referenced in > the output. > > I'm not asking for anything else here. Documentation is needed. Thanks for clarification, I was under the impression that you wanted to put it only into the man page :-) -- Petr^2 Spacek From pspacek at redhat.com Fri Oct 30 10:16:03 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 30 Oct 2015 11:16:03 +0100 Subject: [Freeipa-devel] [PATCH 0060-0061] DNSSEC improvements in uninstaller In-Reply-To: <56333E77.9050802@redhat.com> References: <56333B3E.40104@redhat.com> <56333E77.9050802@redhat.com> Message-ID: <56334363.6030803@redhat.com> On 30.10.2015 10:55, Martin Basti wrote: > > > On 30.10.2015 10:41, Petr Spacek wrote: >> Hello, >> >> DNSSEC: on uninstall, do not restore OpenDNSSEC kasp.db if backup failed >> DNSSEC: improve log messages in uninstaller >> >> This is suitable for ipa-4-2 branch and newer. >> > NACK > > Please extract the list from for cycle to separate variable and do extend with > that variable. > > Also this code doesnt work, I tried simillar in python and I got: > > In [1]: t=[1] > > In [2]: for f in [10, 20, 30].extend(t): > ...: print f > ...: > --------------------------------------------------------------------------- > TypeError Traceback (most recent call last) > in () > ----> 1 for f in [10, 20, 30].extend(t): > 2 print f > 3 > > TypeError: 'NoneType' object is not iterable Thank you for catching this. I believed to lint and that was a bad idea! Push only to master is fine with me, I'm not willing to go though more bureaucracy for this small change. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0061-2-DNSSEC-on-uninstall-do-not-restore-OpenDNSSEC-kasp.d.patch Type: text/x-patch Size: 2192 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0060-DNSSEC-improve-log-messages-in-uninstaller.patch Type: text/x-patch Size: 1225 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Oct 30 10:53:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Oct 2015 11:53:29 +0100 Subject: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output In-Reply-To: <562E1F8A.8030202@redhat.com> References: <5628A1F1.8050602@redhat.com> <5628EF01.3080809@redhat.com> <562E1F8A.8030202@redhat.com> Message-ID: <56334C29.5070305@redhat.com> On 10/26/2015 01:41 PM, Martin Babinsky wrote: > On 10/22/2015 04:13 PM, Martin Basti wrote: >> >> >> On 22.10.2015 10:44, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5181 >>> >>> >>> >> >> Thank you for the patch. >> >> 1) >> +OPTIONAL_SERVICES = { >> + 'DNS', >> + 'CA', >> + 'KRA', >> + 'ADTRUST', >> + 'EXTID', >> + 'DNSKeyExporter', >> + 'DNSSEC', >> + 'DNSKeySync', >> +} >> >> This did not scale well, maybe we should improve it to use some general >> solution for whole IPA to distinct mandratory and optionl service, but I >> do not know how (or if it is possible) >> > Yes this does not scale well. After some playing around with relocating > the SERVICE_LIST object in 'ipaserver/install/service.py' I found out > that more refactoring would be needed to improve the layout and > availability of LDAP service names to both server and client code. I > have put the list of core services to ipalib/constants.py for now, and I > suggest to open a separate ticket for more general solution. > >> 2) >> + search_filter=('(&(objectclass=ipaConfigObject)' >> + '(ipaConfigString=enabledService))') >> >> Common user cannot read ipaConfigString, so this will work only for >> admins, I do not see any limitations of access in code for other users. >> > > I think that you agreed with Petr^2 that this filter is OK. I left it as > it is but I have rewritten it as a call to ldap.make_filter to improve > readability and/or potential extensibility a bit. > >> 3) >> + opt_components = [ >> + r['cn'][0] for r in result if r['cn'][0] in >> OPTIONAL_SERVICES >> + ] >> Probably instead of indexing, you may use result.single_value['cn'] >> >> Martin^2 > > Attaching updated patch. > > > Self-NACK, I found a bug in the patch during work on topology management stuff. -- Martin^3 Babinsky From redhatrises at gmail.com Fri Oct 30 12:34:12 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 30 Oct 2015 06:34:12 -0600 Subject: [Freeipa-devel] [PATCH 0061] Remove 50-lockout-policy.update file In-Reply-To: <20151030065656.GJ8374@redhat.com> References: <20151030065656.GJ8374@redhat.com> Message-ID: Can do Alexander. Here is the updated patch. Gabe On Fri, Oct 30, 2015 at 12:56 AM, Alexander Bokovoy wrote: > On Thu, 29 Oct 2015, Gabe Alford wrote: > >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/5418 >> > ACK but can you please add something like this in the commit message: > > ---- > Remove lockout policy update file because all currently supported > FreeIPA versions already have krbPwdMaxFailure defaulting to 6 and > krbPwdLockoutDuration defaulting to 600. > > Keeping lockout policy update file prevents from creating a more strict > policy in environments where it is subject to regulatory compliance. > ---- > > >> Thanks, >> >> Gabe >> > > From 7a9086162717bc414a1d65ea71a2d65729f6fa7e Mon Sep 17 00:00:00 2001 >> From: Gabe >> Date: Thu, 29 Oct 2015 20:30:35 -0600 >> Subject: [PATCH] Remove 50-lockout-policy.update file >> >> https://fedorahosted.org/freeipa/ticket/5418 >> --- >> install/updates/50-lockout-policy.update | 4 ---- >> install/updates/Makefile.am | 1 - >> 2 files changed, 5 deletions(-) >> delete mode 100644 install/updates/50-lockout-policy.update >> >> diff --git a/install/updates/50-lockout-policy.update >> b/install/updates/50-lockout-policy.update >> deleted file mode 100644 >> index >> a5730709e2b649466118502ece1cc530c10e0b40..0000000000000000000000000000000000000000 >> --- a/install/updates/50-lockout-policy.update >> +++ /dev/null >> @@ -1,4 +0,0 @@ >> -dn: cn=global_policy,cn=$REALM,cn=kerberos,$SUFFIX >> -replace:krbPwdLockoutDuration:10::600 >> -replace: krbPwdMaxFailure:3::6 >> - >> diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am >> index >> 26e4c04ed66a4a2061a3bb3ca2f4a6cd84502598..04ddeb96de4e88d5909f13b13885d3207184e798 >> 100644 >> --- a/install/updates/Makefile.am >> +++ b/install/updates/Makefile.am >> @@ -39,7 +39,6 @@ app_DATA = \ >> 45-roles.update \ >> 50-7_bit_check.update \ >> 50-dogtag10-migration.update \ >> - 50-lockout-policy.update \ >> 50-groupuuid.update \ >> 50-hbacservice.update \ >> 50-krbenctypes.update \ >> -- >> 2.4.3 >> >> > -- >> Manage your subscription for the Freeipa-devel mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code >> > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0061-2-Remove-50-lockout-policy.update-file.patch Type: text/x-patch Size: 1622 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 30 12:46:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 13:46:07 +0100 Subject: [Freeipa-devel] [PATCH 0060-0061] DNSSEC improvements in uninstaller In-Reply-To: <56334363.6030803@redhat.com> References: <56333B3E.40104@redhat.com> <56333E77.9050802@redhat.com> <56334363.6030803@redhat.com> Message-ID: <5633668F.4070004@redhat.com> On 30.10.2015 11:16, Petr Spacek wrote: > On 30.10.2015 10:55, Martin Basti wrote: >> >> On 30.10.2015 10:41, Petr Spacek wrote: >>> Hello, >>> >>> DNSSEC: on uninstall, do not restore OpenDNSSEC kasp.db if backup failed >>> DNSSEC: improve log messages in uninstaller >>> >>> This is suitable for ipa-4-2 branch and newer. >>> >> NACK >> >> Please extract the list from for cycle to separate variable and do extend with >> that variable. >> >> Also this code doesnt work, I tried simillar in python and I got: >> >> In [1]: t=[1] >> >> In [2]: for f in [10, 20, 30].extend(t): >> ...: print f >> ...: >> --------------------------------------------------------------------------- >> TypeError Traceback (most recent call last) >> in () >> ----> 1 for f in [10, 20, 30].extend(t): >> 2 print f >> 3 >> >> TypeError: 'NoneType' object is not iterable > Thank you for catching this. I believed to lint and that was a bad idea! > > Push only to master is fine with me, I'm not willing to go though more > bureaucracy for this small change. > ACK Pushed to master: 6f855dcc5cbd4a316ae03cdf0e2cc7e8c21bec88 From mbasti at redhat.com Fri Oct 30 12:48:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 13:48:02 +0100 Subject: [Freeipa-devel] [PATCH 0020-0021] some topology plugin fixes In-Reply-To: <56333383.2060604@redhat.com> References: <5629F352.9050005@redhat.com> <563210E0.4060607@redhat.com> <5633310C.6050109@redhat.com> <56333383.2060604@redhat.com> Message-ID: <56336702.9020504@redhat.com> On 30.10.2015 10:08, thierry bordaz wrote: > On 10/30/2015 09:57 AM, Ludwig Krispenz wrote: >> >> On 10/29/2015 01:28 PM, thierry bordaz wrote: >>> On 10/23/2015 10:44 AM, Ludwig Krispenz wrote: >>>> Hi, >>>> the attached two patches address issues I found when testing ca >>>> management in the topology plugin >>>> >>>> Thanks for review, >>>> Ludwig >>>> >>>> >>> Hi Ludwig, >>> >>> Patch 20 is good to me. I have one remark, you call >>> ipa_topo_cfg_host_find with lock flag. So that the replica config is >>> not updated during the test. >>> Now the lock protects each call separately. The risk is very low >>> that the target host could become unmanaged by the time we test the >>> source host. >> yes, and if two paralle operations do related things like adding an >> agreement and making a host managed/unmanaged there is a race for the >> lock. The lock itself cannot prevent these things, it only can >> protect the data structures from being read while modified. >> Also with two separate locked calls the second call has a chance to >> be aware of parallel changes >>> ACK. >>> >>> Patch 21 is also good. Just in ipa_topo_util_init_hosts, why not >>> calling ipa_topo_cfg_host_add to not duplicate the source ? >> no reason, revised patch is attached, thanks for noticing > > Thanks Ludwig for the changes. > > ACK Pushed to master: 3f70c9aed7d1357ac5031b8f8b48af320acba567 > >>> >>> thanks >>> thierry >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 30 12:57:31 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 14:57:31 +0200 Subject: [Freeipa-devel] [PATCH 0061] Remove 50-lockout-policy.update file In-Reply-To: References: <20151030065656.GJ8374@redhat.com> Message-ID: <20151030125731.GS8374@redhat.com> On Fri, 30 Oct 2015, Gabe Alford wrote: >From 24bcde6042d90322883350b5fd97aa41f2e4d77d Mon Sep 17 00:00:00 2001 >From: Gabe >Date: Fri, 30 Oct 2015 06:27:11 -0600 >Subject: [PATCH] Remove 50-lockout-policy.update file > >Remove lockout policy update file because all currently supported versions >have krbPwdMaxFailure defaulting to 6 and krbPwdLockoutDuration defaulting to 600. > >Keeping lockout policy update file prevents from creating a more scrict policy in >environments subject to regulatory compliance > >https://fedorahosted.org/freeipa/ticket/5418 >--- > install/updates/50-lockout-policy.update | 4 ---- > install/updates/Makefile.am | 1 - > 2 files changed, 5 deletions(-) > delete mode 100644 install/updates/50-lockout-policy.update ACK -- / Alexander Bokovoy From mbasti at redhat.com Fri Oct 30 13:09:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 14:09:47 +0100 Subject: [Freeipa-devel] [PATCH 0339] ipa-csreplica-manage: disable connect/disconnect/del subcommands Message-ID: <56336C1B.6070807@redhat.com> https://fedorahosted.org/freeipa/ticket/5405 Patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0339-ipa-csreplica-manage-disable-connect-disconnect-del-.patch Type: text/x-patch Size: 6637 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 30 13:20:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 14:20:45 +0100 Subject: [Freeipa-devel] [PATCH 0061] Remove 50-lockout-policy.update file In-Reply-To: <20151030125731.GS8374@redhat.com> References: <20151030065656.GJ8374@redhat.com> <20151030125731.GS8374@redhat.com> Message-ID: <56336EAD.6010308@redhat.com> On 30.10.2015 13:57, Alexander Bokovoy wrote: > On Fri, 30 Oct 2015, Gabe Alford wrote: >> From 24bcde6042d90322883350b5fd97aa41f2e4d77d Mon Sep 17 00:00:00 2001 >> From: Gabe >> Date: Fri, 30 Oct 2015 06:27:11 -0600 >> Subject: [PATCH] Remove 50-lockout-policy.update file >> >> Remove lockout policy update file because all currently supported >> versions >> have krbPwdMaxFailure defaulting to 6 and krbPwdLockoutDuration >> defaulting to 600. >> >> Keeping lockout policy update file prevents from creating a more >> scrict policy in >> environments subject to regulatory compliance >> >> https://fedorahosted.org/freeipa/ticket/5418 >> --- >> install/updates/50-lockout-policy.update | 4 ---- >> install/updates/Makefile.am | 1 - >> 2 files changed, 5 deletions(-) >> delete mode 100644 install/updates/50-lockout-policy.update > > ACK > Pushed to master: 7ef827eeb6b65af8915019bac82932a2c831fc95 From mbabinsk at redhat.com Fri Oct 30 13:49:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Oct 2015 14:49:34 +0100 Subject: [Freeipa-devel] [PATCH 0339] ipa-csreplica-manage: disable connect/disconnect/del subcommands In-Reply-To: <56336C1B.6070807@redhat.com> References: <56336C1B.6070807@redhat.com> Message-ID: <5633756E.50609@redhat.com> On 10/30/2015 02:09 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5405 > > > Patch attached > > Hi Martin, NACK since I'm not a big fan of having (nearly) the same function defined in multiple modules: """ $ git grep -n 'def exit_on_managed_topology' install/tools/ipa-csreplica-manage:397:def exit_on_managed_topology(what, hint="topologysegment"): install/tools/ipa-replica-manage:1386:def exit_on_managed_topology(what): """ Otherwise the patch works fine. -- Martin^3 Babinsky From ofayans at redhat.com Fri Oct 30 13:57:25 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 30 Oct 2015 14:57:25 +0100 Subject: [Freeipa-devel] [PATCH] ca-less tests updated - POC Message-ID: <56337745.109@redhat.com> Hi, The following patches contain updates to ca-less integration tests. It's still a proof of concept: 2 tests still fail seemingly due to the change in target system logic (marked as xfail with "ask jcholast comment") The test output looks like this: $ ipa-run-tests test_integration/test_caless.py --pdb ==================================================================================== test session starts ===================================================================================== platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 plugins: multihost, sourceorder collected 88 items test_integration/test_caless.py ......xx......ss............sssssssssssssssssss.ssssss.........xx......ssxx............. ==================================================================== 53 passed, 29 skipped, 6 xfailed in 5620.17 seconds ===================================================================== Numerous skips correspond to the tests related to ipa-replica-prepare (unsupported under domain level 1) -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0013-Updated-the-script-creating-test-certificate-chains.patch Type: text/x-patch Size: 2678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0014-Updated-ca-less-tests.patch Type: text/x-patch Size: 29085 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Oct 30 14:26:25 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Oct 2015 15:26:25 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion Message-ID: <56337E11.6050603@redhat.com> patch for https://fedorahosted.org/freeipa/ticket/5309 The ticket itself is about connectivity checks in topology suffixes, but there is a code (install/tools/ipa-replica-manage starting at line 788 after applying my patch) which monitors whether the segments pointing to/from the deleted host are already deleted. These checks are currently hardcoded for 'realm' prefix, should we generalize them as well or is it a part of other effort? -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0093-perform-connectivity-checks-for-all-topology-suffixe.patch Type: text/x-patch Size: 4341 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 30 14:38:49 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 30 Oct 2015 15:38:49 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <56337E11.6050603@redhat.com> References: <56337E11.6050603@redhat.com> Message-ID: <563380F9.30208@redhat.com> On 10/30/2015 03:26 PM, Martin Babinsky wrote: > patch for https://fedorahosted.org/freeipa/ticket/5309 > > The ticket itself is about connectivity checks in topology suffixes, but > there is a code (install/tools/ipa-replica-manage starting at line 788 > after applying my patch) which monitors whether the segments pointing > to/from the deleted host are already deleted. > > These checks are currently hardcoded for 'realm' prefix, should we > generalize them as well or is it a part of other effort? > Could be separate patch but yes. -- Petr Vobornik From mbasti at redhat.com Fri Oct 30 14:47:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 15:47:55 +0100 Subject: [Freeipa-devel] [PATCH 0339] ipa-csreplica-manage: disable connect/disconnect/del subcommands In-Reply-To: <5633756E.50609@redhat.com> References: <56336C1B.6070807@redhat.com> <5633756E.50609@redhat.com> Message-ID: <5633831B.7010007@redhat.com> On 30.10.2015 14:49, Martin Babinsky wrote: > On 10/30/2015 02:09 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5405 >> >> >> Patch attached >> >> > Hi Martin, > > NACK since I'm not a big fan of having (nearly) the same function > defined in multiple modules: > > """ > $ git grep -n 'def exit_on_managed_topology' > install/tools/ipa-csreplica-manage:397:def > exit_on_managed_topology(what, hint="topologysegment"): > install/tools/ipa-replica-manage:1386:def exit_on_managed_topology(what): > """ > > Otherwise the patch works fine. > I tried to do that, but I could not find any suitable module for that, and the method do just exit() with proper error message, thus it can be just copy paste (as ipa-csreplica-manage is full of it). From mbabinsk at redhat.com Fri Oct 30 14:49:34 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Oct 2015 15:49:34 +0100 Subject: [Freeipa-devel] [PATCH 0339] ipa-csreplica-manage: disable connect/disconnect/del subcommands In-Reply-To: <5633831B.7010007@redhat.com> References: <56336C1B.6070807@redhat.com> <5633756E.50609@redhat.com> <5633831B.7010007@redhat.com> Message-ID: <5633837E.9010100@redhat.com> On 10/30/2015 03:47 PM, Martin Basti wrote: > > > On 30.10.2015 14:49, Martin Babinsky wrote: >> On 10/30/2015 02:09 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5405 >>> >>> >>> Patch attached >>> >>> >> Hi Martin, >> >> NACK since I'm not a big fan of having (nearly) the same function >> defined in multiple modules: >> >> """ >> $ git grep -n 'def exit_on_managed_topology' >> install/tools/ipa-csreplica-manage:397:def >> exit_on_managed_topology(what, hint="topologysegment"): >> install/tools/ipa-replica-manage:1386:def exit_on_managed_topology(what): >> """ >> >> Otherwise the patch works fine. >> > I tried to do that, but I could not find any suitable module for that, > and the method do just exit() with proper error message, thus it can be > just copy paste (as ipa-csreplica-manage is full of it). Yes it is a nice plate of copypasta anyway. ACK then. -- Martin^3 Babinsky From rcritten at redhat.com Fri Oct 30 14:49:58 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 10:49:58 -0400 Subject: [Freeipa-devel] [PATCH 0339] ipa-csreplica-manage: disable connect/disconnect/del subcommands In-Reply-To: <5633831B.7010007@redhat.com> References: <56336C1B.6070807@redhat.com> <5633756E.50609@redhat.com> <5633831B.7010007@redhat.com> Message-ID: <56338396.6070404@redhat.com> Martin Basti wrote: > > > On 30.10.2015 14:49, Martin Babinsky wrote: >> On 10/30/2015 02:09 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5405 >>> >>> >>> Patch attached >>> >>> >> Hi Martin, >> >> NACK since I'm not a big fan of having (nearly) the same function >> defined in multiple modules: >> >> """ >> $ git grep -n 'def exit_on_managed_topology' >> install/tools/ipa-csreplica-manage:397:def >> exit_on_managed_topology(what, hint="topologysegment"): >> install/tools/ipa-replica-manage:1386:def exit_on_managed_topology(what): >> """ >> >> Otherwise the patch works fine. >> > I tried to do that, but I could not find any suitable module for that, > and the method do just exit() with proper error message, thus it can be > just copy paste (as ipa-csreplica-manage is full of it). > Some common code can be found in ipaserver/install/replication.py rob From mbasti at redhat.com Fri Oct 30 14:55:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 15:55:22 +0100 Subject: [Freeipa-devel] [PATCH 0339] ipa-csreplica-manage: disable connect/disconnect/del subcommands In-Reply-To: <56338396.6070404@redhat.com> References: <56336C1B.6070807@redhat.com> <5633756E.50609@redhat.com> <5633831B.7010007@redhat.com> <56338396.6070404@redhat.com> Message-ID: <563384DA.9060207@redhat.com> On 30.10.2015 15:49, Rob Crittenden wrote: > Martin Basti wrote: >> >> On 30.10.2015 14:49, Martin Babinsky wrote: >>> On 10/30/2015 02:09 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5405 >>>> >>>> >>>> Patch attached >>>> >>>> >>> Hi Martin, >>> >>> NACK since I'm not a big fan of having (nearly) the same function >>> defined in multiple modules: >>> >>> """ >>> $ git grep -n 'def exit_on_managed_topology' >>> install/tools/ipa-csreplica-manage:397:def >>> exit_on_managed_topology(what, hint="topologysegment"): >>> install/tools/ipa-replica-manage:1386:def exit_on_managed_topology(what): >>> """ >>> >>> Otherwise the patch works fine. >>> >> I tried to do that, but I could not find any suitable module for that, >> and the method do just exit() with proper error message, thus it can be >> just copy paste (as ipa-csreplica-manage is full of it). >> > Some common code can be found in ipaserver/install/replication.py > > rob I prefer not to mess replication.py module with this method, it is just wrapped exit, anything useful. Martin^2 From mbabinsk at redhat.com Fri Oct 30 16:06:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Oct 2015 17:06:29 +0100 Subject: [Freeipa-devel] [PATCH 0093] perform connectivity checks for all topology suffixes during node deletion In-Reply-To: <563380F9.30208@redhat.com> References: <56337E11.6050603@redhat.com> <563380F9.30208@redhat.com> Message-ID: <56339585.7020505@redhat.com> On 10/30/2015 03:38 PM, Petr Vobornik wrote: > On 10/30/2015 03:26 PM, Martin Babinsky wrote: >> patch for https://fedorahosted.org/freeipa/ticket/5309 >> >> The ticket itself is about connectivity checks in topology suffixes, but >> there is a code (install/tools/ipa-replica-manage starting at line 788 >> after applying my patch) which monitors whether the segments pointing >> to/from the deleted host are already deleted. >> >> These checks are currently hardcoded for 'realm' prefix, should we >> generalize them as well or is it a part of other effort? >> > > Could be separate patch but yes. Ok I have included it in the attached patch so that both of these operations are performed for all suffixes. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0093.1-check-for-disconnected-topology-and-deleted-agreemen.patch Type: text/x-patch Size: 7627 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 30 16:51:43 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 30 Oct 2015 17:51:43 +0100 Subject: [Freeipa-devel] [draft] Fate of ipa-replica-manage and ipa-csreplica-manage tools In-Reply-To: <56333B69.3080306@redhat.com> References: <562F9023.6020207@redhat.com> <562F9AD5.4070400@redhat.com> <56333B69.3080306@redhat.com> Message-ID: <5633A01F.2050401@redhat.com> On 10/30/2015 10:42 AM, Martin Kosek wrote: > On 10/27/2015 04:40 PM, Ludwig Krispenz wrote: >> >> On 10/27/2015 03:54 PM, Petr Vobornik wrote: >>> Both tools serve primarily for managing replication agreements and >>> replicas. >>> ipa-replica-manage also manages winsync agreements and DNA ranges. >>> >>> FreeIPA 4.3 will introduce managed topology which affects these tools. >>> >>> Let's go trough all sub-commands of both tools and decide what is the >>> fate of >>> them/how they should be replaced. Comments are welcome. >>> >>> In text, term 'disable' means: print an error message with help what >>> is the >>> new alternative. >>> >>> For domain level == 0 all sub-commands should behave the same way as >>> before. >>> Proposals are for domain level 1 if not stated otherwise. >>> >>> == ipa-replica-manage == >>> === list === >>> Lists all IPA server or replication agreements of a specific IPA server >>> including winsync agreements. > > Note that people are used to use "-v" switch to show status of these > agreements. There would need to be a replacement for this functionality > to get rid of this command. I always forgot about this option - from help it's not clear which commands supports it. Yes, this implies that it should remain enabled, till we have the functionality in topo plugin. > >>> Server list is replaced by >>> ipa server-find >>> Replication agreements by: >>> ipa topologysegment-find realm >>> >>> I see following paths: >>> 1. do not change (current state) >>> 2. list only winsync agreements - IMO it will be easier to maintain >>> >>> If winsync was not in play we could 'disable' it but winsync is not >>> planned >>> to be centrally managed. Mainly because the preferred alternative is >>> trust. > > 2 may be a good choice, but we first need to find the alternative for > above. I do not think deprecating a list is a "must" for 4.3. +1 > >>> === connect === >>> Allow for winsync, disable for REALM agmts. (current state) >>> >>> === disconenct === >>> Allow for winsync, disable for REALM agmts. (current state) > > +1. > >>> === del === >>> (current state) >>> With domain level 0: >>> - removes replica and repl. agmts for REALM suffix and winsync >>> With domain level 1: >>> - removes replica entry and therefore repl. agmts for all >>> suffices(REALM, CS) >>> - ensure last services, e.g. sets renewal master >>> - does additional cleanup >>> >>> I'm not aware of any operation which needs directory manager. IMO it >>> can be >>> moved to API in future release(e.g. 4.4), especially if >>> ipa-server-install >>> --uninstall is modified to do most of the cleanup. > > Ok. > >>> >>> === re-initialize === >>> Not changed. >>> >>> Can be disabled (long-term solution) >>> >>> Same capability is in topologysegment_reinitialize API command. The only >>> difference is that no API command shows state of the pending operation. >>> Should we transform presence of 'start' and 'stop' in >>> nsds5beginreplicarefresh;left|right attribute into an output of >>> topologysegment_show, e.g.: 'initialization in progress', >>> 'cancellation of >>> re-initialization requested'. >> yes, something like this would be possible, >> maybe this can be part of the replication monitoring work, allowing to >> query >> the state of specific agreements. > > Can topologysegment-reinitialize simply wait? The behavior and related > options could be similar as with automember-rebuild. Then we risk that CLI will timeout, same issue is in automember-rebuild and migrate-ds (there is a ticket for improving long running tasks). > > I am wondering if topologysegment-reinitialize is not too low level. > Normally, the problem you are solving is that some of your master is out > of sync and cannot be fixed. Then you want to have some command to > re-intitialize *the master*, with the command potentially picking the > best topologysegment to be used. It is quite low-level. That is also one of the reasons why I didn't put it to Web UI. > >>> === force-sync === >>> no change yet >>> >>> Currently done by setting nsDS5ReplicaUpdateSchedule attribute of repl. >>> agreement. >>> >>> 1. Is it required? >>> 2. Should the functionality be transferred to >>> topologysegment/topology plugin? >>> 3. Is current approach good? >> in fact it is a hack, it uses the fact that a change in the replication >> agremeent will trigger a fresh start of the protocol thread. It woul >> be more >> clean to have "sendupdatesnow" attribute or as a value of the refresh >> attribute, would require a change in DS > > Change in DS to support some of the Topology functionality is tricky. Is > this a blocker for releasing 4.3 with DL 1? I don't think so. > > Where I am coming from is that if Topology functionality depend on a DS > function, we cannot be sure that the Topology call works for all > masters. And I do not think we want to release DL 2 to support also this > command. We don't. We need some general approach for this. Every time we will add some new functionality to topology plugin or fix a bug there this very question will be raised again. The simplest thing to do is have it enabled so the servers which don't support it will still have a usable method. > >>> IMO if we want to preserve the possibility then the long-term >>> solution is to >>> move it to topology plugin. >> yes > > Yes, but see above. > >>> === list-ruv, clean-ruv, abort-clean-ruv, list-clean-ruv === >>> Commands manages clean-all-ruv operations on REALM suffix. >>> ipa-csreplica-manage doesn't have these commands #4987. These >>> operations are >>> meant for removal of dangling ruvs but they can also remove "correct" >>> RUV >>> which is not desired. >>> >>> The UX is not the best because if replica still exists it won't tell the >>> admin what is the correct RUV and which are the dangling one(s) and >>> therefore >>> admin must get the info in cn=replica,cn=$SUFFIX,cn=mapping >>> tree,cn=config >>> >>> We have a ticket to automate it: >>> https://fedorahosted.org/freeipa/ticket/5411 >>> >>> Is it possible to manage it in topology plugin in centralized manner? >>> >>> I see $5411 as short-term solution for 4.3 or 4.4. + >>> {list|clean|abort-clean-list-clean}-ruv sub-commands should be >>> extended to >>> work with all suffices. >>> >>> Long term solution not in 4.3 is to move it to topology plugin. > > Would be nice to be moved to Topology. But same as above, we should > think if the change breaks the DL 1 or the fact that some of the servers > has the patch and some don't do not break anything. > >>> === dna(next)range-{show|set} commands >>> No change in 4.3. >>> >>> Long term solution is to make it centrally manageable. Not sure if by >>> topo >>> plugin or something else. > > Currently, this configuration is set in cn=config. So here are 2 ways - > enhance Topology plugin or have some other Config Sync related plugin. > >>> == ipa-csreplica-manage == >>> This tool manages only CS replication agreements. > > Yes. I think we want to stop using it completely in 4.3 in order to > really simplify CS management: > https://fedorahosted.org/freeipa/ticket/3053 > >>> === list === >>> Not needed. We have `ipa server-find` and `ipa topologysegment-find >>> ipaca` >>> commands. >>> >>> Should be disabled, add to #5405 > > Yes, but also consider the "-v" option question above. > >>> >>> === connect and disconnect === >>> Replaced by `ipa topologysegment-{add,del}` commands. >>> >>> disable #5405 >>> >>> === del === >>> The work is done in `ipa-replica-manage del` therefore disable #5405 >>> >>> === re-initialize === >>> Same as in ipa-replica-manage - can be disabled. No ticket yet. >>> >>> === force-sync === >>> Same as in ipa-replica-manage - decide what to do. No ticket yet. >>> >>> === set-renewal-master === >>> AFAIK it's only update in cn=masters so could be moved to API then >>> this could >>> be disabled. >>> >>> The change is simple enough for changing in 4.3. No ticket yet. > > Yup, looks like server-add-role type of command. > >>> == Conclusion == >>> ipa-csreplica-manage could be abandoned in 4.3 which plays well with >>> topic >>> "simplify management of CA replication agreements". >> for domainlevel == 0 we need to keep it >>> >>> ipa-replica-manage is still needed for RUV handling and removal of >>> replicas >>> in 4.3. This can change in a future. Same situation with DNA ranges >>> handling. >>> >>> There is no future plan for winsync agreements and ipa-replica-manage >>> can >>> remain solely for this purpose in environments with managed topology. >> yes, and we could rename it to ipa-winsync-manage > > +1, that sounds as the end-game we want. > -- Petr Vobornik From redhatrises at gmail.com Fri Oct 30 16:03:19 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 30 Oct 2015 10:03:19 -0600 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust In-Reply-To: <5633429C.7090401@redhat.com> References: <20151030065431.GI8374@redhat.com> <563327F3.7090703@redhat.com> <20151030101029.GN8374@redhat.com> <5633429C.7090401@redhat.com> Message-ID: Okay. Added the port range to ipa-adtrust-install and updated the man page to reflect firewall requirements. The firewall section seems a little rough, so let me know what you think it would need to be smoothed over (if anything). thanks, Gabe On Fri, Oct 30, 2015 at 4:12 AM, Petr Spacek wrote: > On 30.10.2015 11:10, Alexander Bokovoy wrote: > > On Fri, 30 Oct 2015, Petr Spacek wrote: > >> On 30.10.2015 07:54, Alexander Bokovoy wrote: > >>> On Thu, 29 Oct 2015, Gabe Alford wrote: > >>>> Hello, > >>>> > >>>> Fix for https://fedorahosted.org/freeipa/ticket/5414 > >>>> > >>>> Thanks, > >>>> > >>>> Gabe > >>> > >>>> From 515582d66252521a3cbf6a6a48f33745bd788c86 Mon Sep 17 00:00:00 2001 > >>>> From: Gabe > >>>> Date: Thu, 29 Oct 2015 20:28:27 -0600 > >>>> Subject: [PATCH] Incomplete ports for IPA AD Trust > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/5414 > >>>> --- > >>>> install/tools/ipa-adtrust-install | 1 + > >>>> 1 file changed, 1 insertion(+) > >>>> > >>>> diff --git a/install/tools/ipa-adtrust-install > >>>> b/install/tools/ipa-adtrust-install > >>>> index > >>>> > 1f41cc437e8a930c350eac0fb34e5bebc9f9b55b..84e28b57524b2c3308e52cc56b4b370276add0b7 > >>>> > >>>> 100755 > >>>> --- a/install/tools/ipa-adtrust-install > >>>> +++ b/install/tools/ipa-adtrust-install > >>>> @@ -472,6 +472,7 @@ Setup complete > >>>> > >>>> You must make sure these network ports are open: > >>>> \tTCP Ports: > >>>> +\t * 135: epmap > >>>> \t * 138: netbios-dgm > >>>> \t * 139: netbios-ssn > >>>> \t * 445: microsoft-ds > >>> This is good but not complete. What end-point mapper does is creating a > >>> listener based on the incoming request and access to the listener needs > >>> to be provided as well. A listener is created currently in the range of > >>> 1024..1300/TCP but we already have request to make this range > >>> configurable (it is hard coded right now in Samba code) because with > >>> Windows 2008 Microsoft moved it from 1025..5000 to 49152..65535: > >>> https://support.microsoft.com/en-us/kb/929851 > >>> > >>> We were thinking to add a call out hook on Samba side to call > >>> firewall-related script that could do hole punching on demand but it is > >>> not there yet. > >>> > >>> What we could do in ipa-adtrust-install, is to add section about > TCP/UDP > >>> ports to the manual page and explicitly reference that one in case of > >>> epmap line: > >>> \t *135: epmap (see ipa-adtrust-install(1) man page for details) > >>> > >>> We don't have the firewall section in the manpage at all, btw. > >>> > >>> What do you think? > >> > >> Maybe I'm missing something, but ... Could we simply put current range > >> 1024..1300/TCP to the installer now and do other changes as Samba > evolves? I > >> think that it is good enough as a hotfix and that we do not need to > >> over-complicate it in the beginning. > > That's essentially what I said too -- but I want to have firewall > > requirements documented in the manpage so that they are available > > beforehand _and_ people actually read them when they are referenced in > > the output. > > > > I'm not asking for anything else here. Documentation is needed. > > Thanks for clarification, I was under the impression that you wanted to > put it > only into the man page :-) > > -- > Petr^2 Spacek > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0060-2-Incomplete-ports-for-IPA-AD-Trust.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: From abokovoy at redhat.com Sat Oct 31 10:38:13 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 31 Oct 2015 12:38:13 +0200 Subject: [Freeipa-devel] [PATCH 0060] Incomplete ports for IPA AD Trust In-Reply-To: References: <20151030065431.GI8374@redhat.com> <563327F3.7090703@redhat.com> <20151030101029.GN8374@redhat.com> <5633429C.7090401@redhat.com> Message-ID: <20151031103813.GW8374@redhat.com> On Fri, 30 Oct 2015, Gabe Alford wrote: >Okay. Added the port range to ipa-adtrust-install and updated the man page >to reflect firewall requirements. >The firewall section seems a little rough, so let me know what you think it >would need to be smoothed over (if anything). Thanks, this is a good start. I'm sure we can improve it later, when Samba adds configurable setup for the ports. ACK -- / Alexander Bokovoy