From ofayans at redhat.com Fri Apr 1 09:41:16 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 1 Apr 2016 11:41:16 +0200 Subject: [Freeipa-devel] [TEST][Patch-0030]Next part of replica promotion tests In-Reply-To: <56F41F03.9020609@redhat.com> References: <56EFEE3E.5010202@redhat.com> <56F41F03.9020609@redhat.com> Message-ID: <56FE423C.1090600@redhat.com> Hi Martin, Thanks for the review! The new version is attached On 03/24/2016 06:08 PM, Martin Babinsky wrote: > On 03/21/2016 01:51 PM, Oleg Fayans wrote: >> >> >> > Hi Oleg, > > I have a few comments: > > 1.) > please make the commit message more clear, briefly describe what kind of > test cases were added to the suite and maybe add a link to the test plan. Done > > 2.) > I see negative test scenarios for attempting to issue > 'ipa-csreplica-manage connect' and 'disconnect' under domain level 1. > However, for full coverage there should be also a negative test case for > 'ipa-csreplica-manage del' which should also issue error in domain level > 1, see > https://git.fedorahosted.org/cgit/freeipa.git/commit/install/tools/ipa-csreplica-manage?h=ipa-4-3&id=6119dbb9a915283434f718b38a70017e3ad00840 > > > Could you please add this case to the patch and also to the Test plan so > that we have full coverage of this? Done > > 3.) > test_one_command_installation exploded during client enrollment part on > "Joining realm failed: incorrect password". This is probably caused by > missing '-P', 'admin' option here: > """ > + self.replicas[0].run_command(['ipa-replica-install', '-p', > + self.master.config.admin_password, > + '-n', self.master.domain.name, > + '-r', self.master.domain.realm]) > + > """ Fixed. Turned out, it's enough to just provide '-w' > > 4.) > I am not very happy about the organization of > 'TestUnprivilegedUserPermissions' class. > > For starters, I would add this whole block: > """ > + password = self.master.config.dirman_password > + new_password = '$ome0therPaaS' > + replica = self.replicas[0] > + adduser_stdin_text = "%s\n%s\n" % > (self.master.config.admin_password, > + self.master.config.admin_password) > + user_kinit_stdin_text = "%s\n%s\n%s\n" % (password, new_password, > + new_password) > + tasks.kinit_admin(self.master) > + self.master.run_command(['ipa', 'user-add', 'testuser', > '--password', > + '--first', 'John', '--last', 'Donn'], > + stdin_text=adduser_stdin_text) > + # Now we need to change the password for the user > + self.master.run_command(['kinit', 'testuser'], > + stdin_text=user_kinit_stdin_text) > + # And again kinit admin > + tasks.kinit_admin(self.master) > """ > > into 'install()' method, since it indeed sets-up the test harness. You > can add the user name and password to class members so that you can then > use them from the test cases. Which brings me to the second point: I > know that the test plan mentions this as a single test case, but I would > like this: > > """ > + result1 = replica.run_command(['ipa-client-install', '-p', > 'testuser', > + '-w', new_password, > + '--domain', replica.domain.name, > + '--realm', replica.domain.realm, > '-U'], > + raiseonerr=False) > + assert_error(result1, "No permission to join this host", 1) > + tasks.install_client(self.master, replica) > + result2 = replica.run_command(['ipa-replica-install', '-P', > 'testuser', > + '-p', new_password, > + '-n', self.master.domain.name, > + '-r', self.master.domain.realm], > + raiseonerr=False) > + assert_error(result2, > + "Insufficient privileges to promote the server", 1) > + self.master.run_command(['ipa', 'group-add-member', 'admins', > + '--users=testuser']) > + > + replica.run_command(['ipa-replica-install', '-P', 'testuser', > + '-p', new_password, > + '-n', self.master.domain.name, > + '-r', self.master.domain.realm]) > """ > > to be split into three separate test methods for the sake of clarity, e.g.: > "test_client_enrollment_by_unprivileged_user" > "test_replica_install_by_unprovileged_user" > "test_replica_install_after_adding_to_admin_group" I like that! Implemented. > > 5.) > """ > + result = self.replicas[0].run_command(['ipa-server-install', > + '--uninstall', '-U'], > + raiseonerr=False) > + assert("Uninstallation leads to disconnected topology" > + in result.stderr_text) > + self.replicas[0].run_command(['ipa-server-install', '--uninstall', > + '-U', > '--ignore-topology-disconnect']) > """ > here you should assert against command stdout, since the error message > is emitted only by plain print(). Yes it is weird but that's the way it > is. It will probably be changed when I implement > https://fedorahosted.org/freeipa/ticket/5588 so we can fix it when the > ticket is finished. Yeah, I've noticed that already. Fixed > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0030.1-Added-5-more-tests-to-Replica-Promotion-testsuite.patch Type: text/x-patch Size: 8897 bytes Desc: not available URL: From pbrezina at redhat.com Fri Apr 1 10:01:38 2016 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Fri, 01 Apr 2016 12:01:38 +0200 Subject: [Freeipa-devel] [SSSD] HOWTO: Troubleshooting SUDO In-Reply-To: <5617A693.6080204@redhat.com> References: <5617A693.6080204@redhat.com> Message-ID: <56FE4702.8010904@redhat.com> On 10/09/2015 01:35 PM, Pavel B?ezina wrote: > 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 Hi, I added examples of sudo debug logs into the troubleshooting guide. You can find it useful when you investigating why sudo denies access when you expect that access is allowed. https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO From mkubik at redhat.com Fri Apr 1 10:02:26 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 1 Apr 2016 12:02:26 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. Message-ID: <56FE4732.30904@redhat.com> Patches attached. https://fedorahosted.org/freeipa/ticket/5733 -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0035-ipatests-Add-test-case-for-requesting-a-certificate-.patch Type: text/x-patch Size: 2686 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0035-ipatests-Add-test-case-for-requesting-a-certificate-.patch Type: text/x-patch Size: 2590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa43-0035-ipatests-Add-test-case-for-requesting-a-certificate-.patch Type: text/x-patch Size: 2686 bytes Desc: not available URL: From pvomacka at redhat.com Fri Apr 1 12:34:22 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 1 Apr 2016 14:34:22 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0011] WebUI: Creating user without private group In-Reply-To: <56FD314C.4080809@redhat.com> References: <56CF0AD6.4060505@redhat.com> <56DD9E73.1020609@redhat.com> <56DEBE89.70808@redhat.com> <56DEC2DF.3000801@redhat.com> <56E1B5CC.7070208@redhat.com> <56EBD74C.40709@redhat.com> <56FCFF33.7060801@redhat.com> <56FD314C.4080809@redhat.com> Message-ID: <56FE6ACE.1050705@redhat.com> On 03/31/2016 04:16 PM, Lenka Doudova wrote: > > > On 03/31/2016 12:42 PM, Pavel Vomacka wrote: >> >> >> On 03/18/2016 11:24 AM, Lenka Doudova wrote: >>> >>> >>> On 03/10/2016 06:58 PM, Petr Vobornik wrote: >>>> On 03/08/2016 01:17 PM, Lenka Doudova wrote: >>>>> >>>>> >>>>> On 03/08/2016 12:59 PM, Petr Vobornik wrote: >>>>>> On 03/07/2016 04:29 PM, Pavel Vomacka wrote: >>>>>>> >>>>>>> >>>>>>> On 02/25/2016 03:08 PM, Lenka Doudova wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> here's a patch for webUI tests that provides test for creating >>>>>>>> user >>>>>>>> without private group. >>>>>>>> Related to ticket https://fedorahosted.org/freeipa/ticket/4986 >>>>>>>> >>>>>>>> Since the option to specify GID when creating a user is not >>>>>>>> available >>>>>>>> https://fedorahosted.org/freeipa/ticket/5505 the test creates a >>>>>>>> new >>>>>>>> posix group, makes it a default user group instead of >>>>>>>> 'ipausers' and >>>>>>>> then attemps to create the user without private group. Returning >>>>>>>> default user group value to 'ipausers' is provided even for >>>>>>>> cases when >>>>>>>> the test fails so it would not block other tests from performing >>>>>>>> properly. >>>>>>>> >>>>>>>> Lenka >>>>>>>> >>>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> ACK, works well. >>>>>>> >>>>>>> Pavel^3 Vomacka >>>>>>> >>>>>> >>>>>> NACK, don't use naked except, specify at least 'Exception' >>>>>> + except: >>>>>> >>>>> >>>>> Thanks, patch fixed according to Petr's review attached. >>>>> >>>>> Lenka >>>> >>>> Ticket 5505 was pushed. So the workaround can be removed. Do you >>>> prefer to do it in this patch? >>>> >>>> Also, maybe it would be good to test both cases and check if the >>>> error is actually the right one. >>> >>> Hi, >>> >>> attaching patch fixed according to recently pushed changes. >>> >>> Lenka >> Hi, >> >> NACK, >> >> 1) The data definition for user3 (user.DATA3) is not used anywhere. >> And the definition is actually the same as definition of user4. So, I >> think that it could be removed. >> >> 2) This is just a detail, but I would rather use 'combobox_input' or >> 'combobox_textbox' as parameter name because the parameter actually >> doesn't represent the value of combobox. >> >> Otherwise it works as expected. >> >> -- >> Pavel^3 Vomacka >> > Hi, > > thanks for comments, updated patch attached. > > Lenka > > Thank you, ACK. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Apr 1 14:53:19 2016 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 1 Apr 2016 16:53:19 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides Message-ID: <56FE8B5F.8040803@redhat.com> Hi, this extends the user ID overrides with capability to store the user certificate. https://fedorahosted.org/freeipa/ticket/4955 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0405-idviews-Add-user-certificate-attribute-to-user-ID-ov.patch Type: text/x-patch Size: 10640 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Apr 1 15:37:20 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 1 Apr 2016 17:37:20 +0200 Subject: [Freeipa-devel] [PATCH 0143-0144] different errors/warnings for different LDAP limit type exceeded In-Reply-To: <56F40464.7000804@redhat.com> References: <56EBCA37.6020306@redhat.com> <56EBF959.3060807@redhat.com> <56EFBC2C.8030300@redhat.com> <56EFDA20.9090005@redhat.com> <56F1608A.4060805@redhat.com> <56F16481.9070304@redhat.com> <56F40464.7000804@redhat.com> Message-ID: <56FE95B0.90501@redhat.com> On 03/24/2016 04:14 PM, Martin Babinsky wrote: > On 03/22/2016 04:28 PM, Rob Crittenden wrote: >> Martin Babinsky wrote: >>> On 03/21/2016 12:25 PM, Jan Cholasta wrote: >>>> On 21.3.2016 10:17, Petr Spacek wrote: >>>>> On 18.3.2016 13:49, Rob Crittenden wrote: >>>>>> Martin Babinsky wrote: >>>>>>> These patches implement behavior agreed upon during discussion of >>>>>>> https://fedorahosted.org/freeipa/ticket/5677 >>>>>>> >>>>>>> However I'm not sure if we want to push them into 4-3 branch (the >>>>>>> ticket >>>>>>> is triaged into 4.3.2 milestone) since they modify the framework >>>>>>> behavior quite a bit. >>>>>>> >>>>>>> If there is no need to have it there (CC'ing Milan since he is the >>>>>>> reporter), I would retriage it into 4.4 milestone. >>>>>> >>>>>> >>>>>> + desc="while getting entries (search base: '{}'," >>>>>> + "filter: {})".format(base_dn, filter)) >>>>>> >>>>>> This is going to expose parts of the DIT in an error message to >>>>>> users. We have >>>>>> tried in the past to hide the implementation. I'd propose logging the >>>>>> error >>>>>> and making the exception less verbose. >>>> >>>> I agree with Rob here, we shouldn't expose internal stuff in error >>>> messages for users. >>>> >>>> In this particular case, even if we included internal stuff in the >>>> error >>>> message, it should be the error message returned by the server rather >>>> than this ad-hoc message. >>>> >>>>> >>>>> IMHO it actually helps to print the DN. At very least the user can see >>>>> if the >>>>> error is happening always with the same DN or if it keeps changing. >>>>> >>>>> In other words, for user it is not that important to understand >>>>> meaning of the >>>>> DN but it might be important to see if it is the same or not. >>>> >>>> I can't imagine a situation where it would actually be useful for the >>>> user (as opposed to the admin, who has access to logs) to know the base >>>> DN of some arbitrary LDAP search operation. Could you give an example? >>>> >>> Right, attaching updated patches. >> >> I may have suggested debug logging the detailed error. I was wrong. This >> should log at the error level so it always appears in the logs. This may >> be a spurious error and having the user turn on debug logging to capture >> the reasons would be asking a lot. >> >> rob > That's right, the user would then have to enable debug mode and re-run > the command. I have changed the log level to error as you suggested. > > > Bump for review. -- Martin^3 Babinsky From tbabej at redhat.com Fri Apr 1 16:21:56 2016 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 1 Apr 2016 18:21:56 +0200 Subject: [Freeipa-devel] [PATCH 0406] admintool: Remove the option to override the log file Message-ID: <56FEA024.1090904@redhat.com> Hi, This option has been rarely used, and can be replaced by proper shell output redirection. https://fedorahosted.org/freeipa/ticket/5385 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0406-admintool-Remove-the-option-to-override-the-log-file.patch Type: text/x-patch Size: 4797 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 1 16:30:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 1 Apr 2016 18:30:45 +0200 Subject: [Freeipa-devel] [PATCH 0453 - 0458] host-del: fix updatedns option Message-ID: <56FEA235.9010202@redhat.com> https://fedorahosted.org/freeipa/ticket/5675 Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0453-host_del-fix-removal-of-host-records.patch Type: text/x-patch Size: 3301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0454-host_del-replace-dns-record-find-command-with-show.patch Type: text/x-patch Size: 2576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0455-host_del-remove-unneeded-dnszone-show-command-call.patch Type: text/x-patch Size: 2783 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0456-host_del-split-removing-A-AAAA-and-PTR-records-to-se.patch Type: text/x-patch Size: 2458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0457-host_del-remove-only-A-AAAA-SSHFP-PTR-records.patch Type: text/x-patch Size: 3701 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0458-host_del-update-help-for-updatedns-option.patch Type: text/x-patch Size: 1003 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 1 17:06:22 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 1 Apr 2016 13:06:22 -0400 Subject: [Freeipa-devel] [PATCH 0406] admintool: Remove the option to override the log file In-Reply-To: <56FEA024.1090904@redhat.com> References: <56FEA024.1090904@redhat.com> Message-ID: <56FEAA8E.30109@redhat.com> Tomas Babej wrote: > Hi, > > This option has been rarely used, and can be replaced by proper shell > output redirection. > > https://fedorahosted.org/freeipa/ticket/5385 Should the ticket be re-opened? I'm not opposed to removing it I guess, but how can you know it is rarely used? Nobody has provided one in a bug report perhaps? The advantage of it over the shell is that it always logs in debug mode, so if something goes horribly wrong and the user didn't specify debug you still get the output vs having to re-run it and hope the same thing happens again. rob From ftweedal at redhat.com Mon Apr 4 02:47:47 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 4 Apr 2016 12:47:47 +1000 Subject: [Freeipa-devel] Short-lived VPN certificates In-Reply-To: <1459248424.25498.38.camel@redhat.com> References: <1459248424.25498.38.camel@redhat.com> Message-ID: <20160404024747.GG18277@dhcp-40-8.bne.redhat.com> On Tue, Mar 29, 2016 at 12:47:04PM +0200, Lubomir Rintel wrote: > Hi, > > I'm part of the Red Hat's NetworkManager crowd. We're aware that you've > made some effort on making it easy to get a short-lived certificate for > use with VPN (and EAP-TLS) [1]. > > [1] http://www.freeipa.org/page/User_certificate_use_cases#VPN_certificates > > We're interested in this. I'm wondering if you could share you plans, > what is the present functionality and at which point could we get > involved to get this supported in NetworkManager? > > Thanks, > Lubo > Hi Lubo, thanks for getting in touch. Cc Alexander who knows a lot more about the desktop integration experience than me :) The bits for issuing short-lived user certs (custom profiles) are available in FreeIPA 4.2 / RHEL 7.2. A further desirable enhacement, the ability to issue these certs from a dedicated sub-CA, is what I am currently working on. The general outline of acquiring a short-lived cert for VPN authentication is similar to the GSS-API authentication story (e.g. see the blog post[1] about OpenConnect). [1] https://securityblog.redhat.com/2015/06/17/single-sign-on-with-openconnect-vpn-server-over-freeipa/ In brief: 1. User acquires Kerberos TGT via MS-KKDCP (Kerberos over public HTTP proxy) 2. User uses Kerberos ticket to acquire short-lived certificate via `ipa cert-request' command, selecting the appropriate profile for VPN authentication. 3. Certificate is used for VPN authentication. So the start of the process is the same as the GSS-API use case, but after acquiring the TGT it is used to get a cert for VPN auth instead of a service ticket for same purpose. Since Kerberos is a necessary part of the exchange I do not think that certificate authentication in this scenario gives any advantage over GSS-API (but it is more work and more complex, for sure!) Am I correct in believing that NetworkManager already has support for GSS-API VPN authentication with TGT acquired over MS-KKDCP? The other (more important IMO) VPN certificate authentication scenario is smart card authentiction, where a (longer-lived) certificate on a smart card is used to authenticate to a VPN. Does NetworkManager support this already? Cheers, Fraser From jcholast at redhat.com Mon Apr 4 05:58:49 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 4 Apr 2016 07:58:49 +0200 Subject: [Freeipa-devel] server_del (re)implementation in domain level 1 topology management In-Reply-To: <56FBC776.8020509@redhat.com> References: <56EAB37A.5070606@redhat.com> <56EAB764.5060200@redhat.com> <56EABC90.2080205@redhat.com> <56EAC116.3000504@redhat.com> <56EAC8D2.5020008@redhat.com> <56EACA2F.6060509@redhat.com> <56FBC0D4.2040902@redhat.com> <56FBC776.8020509@redhat.com> Message-ID: <57020299.2010304@redhat.com> On 30.3.2016 14:32, Petr Vobornik wrote: > On 03/30/2016 02:04 PM, Martin Babinsky wrote: >> On 03/17/2016 04:15 PM, Petr Vobornik wrote: >>> On 03/17/2016 04:10 PM, Martin Babinsky wrote: >>>> On 03/17/2016 03:37 PM, Petr Vobornik wrote: >>>>> On 03/17/2016 03:17 PM, Martin Babinsky wrote: >>>>>> On 03/17/2016 02:55 PM, Petr Vobornik wrote: >>>>>>> On 03/17/2016 02:39 PM, Martin Babinsky wrote: >>>>>>>> Hi list, >>>>>>>> >>>>>>>> I would like to discuss the merge of `del_master_managed()` >>>>>>>> function >>>>>>>> from `ipa-replica-manage` command into the server_del API call that >>>>>>>> is a >>>>>>>> part of the managed replication topology design update[1] (see also >>>>>>>> the >>>>>>>> corresponding upstream ticket [2]). >>>>>>>> >>>>>>>> Before I head down into coding I want to be sure that everyone is >>>>>>>> one >>>>>>>> the same page regarding the expected use-cases which govern the API >>>>>>>> design. >>>>>>>> >>>>>>>> IIUC, there are two main uses of the new functionality according to >>>>>>>> design document: >>>>>>>> >>>>>>>> 1.) run 'server_del' when 'ipa-replica-manage del' is run in >>>>>>>> domain-level 1 >>>>>>> >>>>>>> Right, this is for backwards compatibility(BC). >>>>>>> >>>>>>>> >>>>>>>> 2.) during 'ipa-server-install --uninstall', 'server_del' should be >>>>>>>> called on one of remote masters to remove the uninstalled server >>>>>>>> from >>>>>>>> the managed topology >>>>>>>> >>>>>>>> What I didn't get from the design document is whether the method >>>>>>>> should >>>>>>>> have some kind of 'force' option which should bypass all topology >>>>>>>> connectivity checks. Currently both `ipa-replica-manage del` and >>>>>>>> server >>>>>>>> uninstaller have options which will force the removal even if it >>>>>>>> disconnects the topology ('--force' in the former, >>>>>>>> '--ignore-disconnected-topology' in the latter). >>>>>>> >>>>>>> I would say that uninstaller should do checks in validate method >>>>>>> therefore the subsequent `server-del` doesn't need to do it again >>>>>>> but it >>>>>>> shouldn't harm. I.e. it should follow what the user specified. If >>>>>>> user >>>>>>> wants to skip (--ignore-d..-t..) then skip. If not then it will >>>>>>> fail in >>>>>>> validate method. >>>>>>> >>>>>>> Only issue might be error state where servers have different >>>>>>> picture of >>>>>>> the topology. >>>>>>> >>>>>> If the view of the topology is not self-consistent then you have >>>>>> plenty >>>>>> of other issues to take care of and that may include some forced >>>>>> removal >>>>>> and recreation of nodes. >>>>>> >>>>>>>> >>>>>>>> I guess the 'server_del' method should inherit this flag so that we >>>>>>>> retain the original functionality (for better or worse). I >>>>>>>> propose to >>>>>>>> name this option 'ignore_topology_disconnect' because it is more >>>>>>>> descriptive than plain 'force'. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> And in BC case, `ipa-replica-manage --force` would call `server-del >>>>>>> --ig..-d..-t...` >>>>>>> >>>>>> Yes. >>>>>>>> >>>>>>>> I would also like to ask whether 'server_del' (which is currently >>>>>>>> NO_CLI) should be usable also from command line. >>>>>>> >>>>>>> IMO yes, it should mostly as a couterpart of `ipa-replica-manage >>>>>>> --force >>>>>>> --clean` >>>>>>> >>>>>>> Which bring us to --clean option and what it should do... >>>>>>> >>>>>> According to the design, '--clean' should be used as a cleanup of >>>>>> leftovers after deleted servers. How I image it from the >>>>>> implementation >>>>>> point of view is that when '--clean' is specified and the server was >>>>>> already deleted, the NotFound error raised from the framework >>>>>> should be >>>>>> ignored and the code should continue in clean up. (I assume that >>>>>> segment/service/dns cleanup will be done in post_callback portion and >>>>>> the topology connectivity/sanity checks in the pre_callback). >>>>> >>>>> When thinking about it, clean could be a separate command which >>>>> would be >>>>> called internally in post callback of server-del. It would reduce the >>>>> number of ifs in server-del and simplify it in general. It would work >>>>> only if server entry doesn't exists. >>>>> >>>> That was my original idea. I also thought that >>>> 'check_last_link_managed' >>>> could be a separate command, but it is probably not a very good idea to >>>> add the overhead of calling two separate commands to a single API call. >>>> OTOH it would improve the code organization IMHO. >>> >>> Not sure if check_last_link_managed should be an API command. It is >>> already a separate function. What would be the use case for it as a >>> command? >>> >>> Maybe the function should be moved from ipaserver/install/replication to >>> a more suitable place given that it's used from API - it's up to you. >>> >>>> >>>>>> That means that '--clean' has no additional effect when the server >>>>>> exists. >>>>> >>>>> Right >>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 >>>>>>>> [2] https://fedorahosted.org/freeipa/ticket/5588 >>>>>>>> >>>> >>>> >> >> There are two more things I would like to clarify before I can finish >> the patch: >> >> 1.) We have discussed offline that the ensure_last_services function[1] >> shall be reimplemented in the API command using server roles (I will >> open a ticket for this when time comes). Currently the code works >> interactively, prompting the user about removing last DNS/CA/etc server. >> The behavior is overriden by --force option. >> >> I guess we do not want to have interactive prompting in the API command, >> so we will have to handle this somehow. A proposal would be to by >> default abort removal of last DNS/CA server and add a '--force' option >> which will override this check and also override the disconnected >> topology check (IMHO it is not of much use to keep both options in this >> case). What do you think? > > In general +1. > > * move services automatically but fail if it is the last > * have override param to force it. It can be mapped to `ipa server-del > --force`. Or maybe other name than --force (too easy to use, very general). Actually I would like if *all* del commands had --force, which, if used, would make the commands idempotent - if the target object does not exist, do not fail - just like rm and virtually every other rm-like command. > >> >> 2.) Removal of DNS entries is handled by directly calling >> bindinstance/dnskeysyncinstance code[2]. Obviously this is not very >> desirable in the context of API code since we would then need to >> conditionally import these modules on server side (one option but not >> very nice IMHO). Should I reimplement this code using API commands or >> move the relevant bits into ipapython/ipalib? > > Both methods (ensure_last_services, removal of DNS records) should be > moved. There is no need for separate API calls. > > But we might want to consider other option if simple move is not so simple. > >> >> >> [1] >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/tools/ipa-replica-manage?h=ipa-4-3#n753 >> >> >> >> [2] >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/tools/ipa-replica-manage?h=ipa-4-3#n810 >> >> >> > > -- Jan Cholasta From mbabinsk at redhat.com Mon Apr 4 07:29:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 4 Apr 2016 09:29:36 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <56EFB09F.9010200@redhat.com> References: <56EAE651.4040603@redhat.com> <56EFB09F.9010200@redhat.com> Message-ID: <570217E0.9010903@redhat.com> On 03/21/2016 09:28 AM, Jan Cholasta wrote: > On 17.3.2016 18:16, Martin Babinsky wrote: >> Hi list, >> >> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >> design document concerning the concept of Server Roles as a >> user-friendly abstraction of the services running on IPA masters. >> >> The main aim of this feature is to provide a higher level interface to >> query and manipulate service-related information stored in dirsrv >> backend. >> >> I have not touched the design much from the post-Devconf session, mainly >> because there are some points to clarify and agree upon. >> >> I have the following points to discuss: >> >> 1.) the design assumes that there is a distinction between roles such as >> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >> master, CRL master, etc. Now in the hindsight I think this distinction >> is quite artificial and just clutters the interface unnecessarily. We >> might implement this kind of hierarchy in the code itself but that is >> something the user needs not be aware of. > > These shouldn't be (sub-)roles at all - they are inherently a > one-to-many relationship between the logical services and servers, > whereas roles are many-to-many relationship between the logical services > and servers. I would rather see them exposed in the global service > config, such as: > > $ ipa dnsconfig-mod --sec-master=ipa12.example.com > DNSSEC master: ipa12.example.com > >> >> 2.) I guess the role names should be case insensitive so that users are >> not hindered by trying to get the case right. > > +1 > >> >> 3.) Do we need an internal API call which will add all services >> belonging to a role to the corresponding master entry? (basically a >> 'server_add_role' type of command). Currently, each service instance >> adds its own service entry during service installation so we probably do >> not need to duplicate this functionality. > > +1, we don't need more duplicate code. > >> >> That is all I can think of right now. I had many more questions popping >> up during this night's bout of insomnia, but they got lost during the >> day. > > How are we going to expose the different states of server roles? They > can be: > > a) available/unavailable (the package providing the role was/was not > installed on the server) How would we query whether the package providing the role was installed? By trying to import the module(s) providing the package on the server side and catching the error? That could be manageable IMHO. > b) configured/unconfigured (the installer for the role was/was not > successfully run on the server, LDAP service entries exist) Presence of LDAP entry would indicate that installer was run succesfully, although this is not guaranteed since the installer could crash *after* the entry was added to the service container. > c) enabled/disabled > > My preference would be to make server-role commands work on top of > available services, like this: > > # ipa server-role-show $HOSTNAME DNS > ipa: ERROR: DNS: server role not found > > # dnf install freeipa-server-dns > ... > > # ipa server-role-show $HOSTNAME DNS > Name: DNS > Configured: False > Enabled: False > > # ipa-dns-install > ... > > # ipa server-role-show $HOSTNAME DNS > Name: DNS > Configured: True > Enabled: True > >> >> Do not be afraid to bring up other questions/remarks/comments. This is >> my first design documents so I expect them to be plenty. > > The CLI commands are a little bit self-inconsistent, see any other > plugin for how the general layout of arguments should look like. > Ok I will fix that. -- Martin^3 Babinsky From mbasti at redhat.com Mon Apr 4 11:39:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 4 Apr 2016 13:39:32 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56FCD8A4.70107@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> Message-ID: <57025274.8020908@redhat.com> On 31.03.2016 09:58, Petr Spacek wrote: > On 26.2.2016 15:37, Petr Spacek wrote: >> On 25.2.2016 16:46, Simo Sorce wrote: >>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>> Variant C >>>>>> --------- >>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>> the first >>>>>> round ... >>>>>> >>>>>> We would retain >>>>>> [first step - no change from variant A] >>>>>> * create locations >>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>> manually >>>>>> input (server, weight) tuples >>>>>> >>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>> from all >>>>>> other locations. >>>>>> >>>>>> Additional storage complexity: 0 >>>>>> >>>>>> This covers the scenario "always prefer local servers and use remote >>>>>> only as >>>>>> fallback" easily. It does not cover any other scenario. >>>>>> >>>>>> This might be sufficient for the first run and would allow us to >>>>>> gather some >>>>>> feedback from the field. >>>>>> >>>>>> Now I'm inclined to this variant :-) >>>>> To be honest, this is all I always had in mind, for the first step. >>>>> >>>>> To recap: >>>>> - define a location with the list of servers (perhaps location is a >>>>> property of server objects so you can have only one location per server, >>>>> and if you remove the server it is automatically removed from the >>>>> location w/o additional work or referential integrity necessary), if >>>>> weight is not defined (default) then they all have the same weight. >>>> Agreed. >>>> >>>> >>>>> - Allow to specify backup locations in the location object, priorities >>>>> are calculated automatically and all backup locations have same weight. >>>> Hmm, weights have to be inherited form the original location in all cases. Did >>>> you mean that all backup locations have the same *priority*? >>> Yes, sorry. >>> >>>> Anyway, explicit configuration of backup locations is introducing API and >>>> schema for variant A and that is what I'm questioning above. It is hard to >>>> make it extensible so we do not have headache in future when somebody decides >>>> that more flexibility is needed OR that link-based approach is better. >>> I think no matter we do we'll need to allow admins to override backup >>> locations, in future if we can calculate them automatically admins will >>> simply not set any backup location explicitly (or set some special value >>> like "autogenerate" and the system will do it for them. >>> >>> Forcing admins to mentally calculate weights to force the system to >>> autogenerate the configuration they want would be a bad experience, I >>> personally would find it very annoying. >>> >>>> In other words, for doing what you propose above we would have to design >>>> complete schema and API for variant A anyway to make sure we do not lock >>>> ourselves, so we are not getting any saving by doing so. >>> A seemed much more complicated to me, as you wanted to define a ful >>> matrix for weights of servers when they are served as backups and all >>> that. >>> >>>>> - Define a *default* location, which is the backup for any other >>>>> location but always with lower priority to any other explicitly defined >>>>> backup locations. >>>> I would rather *always* use the default location as backup for all other >>>> locations. It does not require any API or schema (as it equals to "all >>>> servers" except "servers in this location" which can be easily calculated on fly). >>> We can start with this, but it works well only in a stellar topology >>> where you have a central location all other location connect to. >>> As soon as you have a super-stellar topology where you have hub location >>> to which regional locations connect to, then this is wasteful. >>> >>>> This can be later on extended in whatever direction we want without any >>>> upgrade/migration problem. >>>> >>>> More importantly, all the schema and API will be common for all other variants >>>> anyway so we can start doing so and see how much time is left when it is done. >>> I am ok with this for the first step. >>> After all location is mostly about the "normal" case where clients want >>> to reach the local servers, the backup part is only an additional >>> feature we can keep simple for now. It's a degraded mode of operation >>> anyway so it is probably ok to have just one default backup location as >>> a starting point. >> Okay, now we are in agreement. I will think about minimal schema and API over >> the weekend. > Well, it took longer than one weekend. > > There was couple of changes in the design document: > * ?Feature Management: CLI proposal > * ?Feature Management: web UI - idea with topology graph replaced original > complicated table > * Feature Management: described necessary configuration outside of IPA DNS > * Version 1 parts which were moved into separate document: > V4/DNS_Location_Mechanism_with_per_client_override > * ?Assumptions: removed misleading reference to DHCP, clarified role of DNS views > * Assumptions: removed misleading mention of 'different networks' and added > summary explaining how Location is defined > * Implementation: high-level outline added > > Current version: > http://www.freeipa.org/page/V4/DNS_Location_Mechanism > > Full diff: > http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 > > Practical usage is described in section How to test: > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test > > > I will think about LDAP schema after we agree on CLI. > > Petr^2 Spacek > > >> Petr^2 Spacek >> >> >>>>> - Weights for backup location servers are the same as the weight defined >>>>> within the backup location itself, so no additional weights are defined >>>>> for backups. >>>> Yes, that was somehow implied in the variant A. Sorry for not mentioning it. >>>> Weight is always relative number for servers inside one location. >>> Ok it looked a lot more complex from your description. >>> >>> Simo. Design review: 1) You missed warning when there is no backup DNS server in location 2) "Number of IPA DNS servers <= number of configured IPA locations" I dont understand You need at least one DNS server per location, thus DNS servers >= locations 3) Design (Version 1: DNAME per client) Link to design doesn't work for me CLI looks good to me. Maybe we should explicitly write in design that priorities of the SRV records will be set statically (What values? 0 - servers in location, 100 - backup?) Martin^2 From pspacek at redhat.com Mon Apr 4 11:51:43 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 4 Apr 2016 13:51:43 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <57025274.8020908@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> Message-ID: <5702554F.3050207@redhat.com> On 4.4.2016 13:39, Martin Basti wrote: > > > On 31.03.2016 09:58, Petr Spacek wrote: >> On 26.2.2016 15:37, Petr Spacek wrote: >>> On 25.2.2016 16:46, Simo Sorce wrote: >>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>> Variant C >>>>>>> --------- >>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>> the first >>>>>>> round ... >>>>>>> >>>>>>> We would retain >>>>>>> [first step - no change from variant A] >>>>>>> * create locations >>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>> manually >>>>>>> input (server, weight) tuples >>>>>>> >>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>> from all >>>>>>> other locations. >>>>>>> >>>>>>> Additional storage complexity: 0 >>>>>>> >>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>> only as >>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>> >>>>>>> This might be sufficient for the first run and would allow us to >>>>>>> gather some >>>>>>> feedback from the field. >>>>>>> >>>>>>> Now I'm inclined to this variant :-) >>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>> >>>>>> To recap: >>>>>> - define a location with the list of servers (perhaps location is a >>>>>> property of server objects so you can have only one location per server, >>>>>> and if you remove the server it is automatically removed from the >>>>>> location w/o additional work or referential integrity necessary), if >>>>>> weight is not defined (default) then they all have the same weight. >>>>> Agreed. >>>>> >>>>> >>>>>> - Allow to specify backup locations in the location object, priorities >>>>>> are calculated automatically and all backup locations have same weight. >>>>> Hmm, weights have to be inherited form the original location in all >>>>> cases. Did >>>>> you mean that all backup locations have the same *priority*? >>>> Yes, sorry. >>>> >>>>> Anyway, explicit configuration of backup locations is introducing API and >>>>> schema for variant A and that is what I'm questioning above. It is hard to >>>>> make it extensible so we do not have headache in future when somebody >>>>> decides >>>>> that more flexibility is needed OR that link-based approach is better. >>>> I think no matter we do we'll need to allow admins to override backup >>>> locations, in future if we can calculate them automatically admins will >>>> simply not set any backup location explicitly (or set some special value >>>> like "autogenerate" and the system will do it for them. >>>> >>>> Forcing admins to mentally calculate weights to force the system to >>>> autogenerate the configuration they want would be a bad experience, I >>>> personally would find it very annoying. >>>> >>>>> In other words, for doing what you propose above we would have to design >>>>> complete schema and API for variant A anyway to make sure we do not lock >>>>> ourselves, so we are not getting any saving by doing so. >>>> A seemed much more complicated to me, as you wanted to define a ful >>>> matrix for weights of servers when they are served as backups and all >>>> that. >>>> >>>>>> - Define a *default* location, which is the backup for any other >>>>>> location but always with lower priority to any other explicitly defined >>>>>> backup locations. >>>>> I would rather *always* use the default location as backup for all other >>>>> locations. It does not require any API or schema (as it equals to "all >>>>> servers" except "servers in this location" which can be easily calculated >>>>> on fly). >>>> We can start with this, but it works well only in a stellar topology >>>> where you have a central location all other location connect to. >>>> As soon as you have a super-stellar topology where you have hub location >>>> to which regional locations connect to, then this is wasteful. >>>> >>>>> This can be later on extended in whatever direction we want without any >>>>> upgrade/migration problem. >>>>> >>>>> More importantly, all the schema and API will be common for all other >>>>> variants >>>>> anyway so we can start doing so and see how much time is left when it is >>>>> done. >>>> I am ok with this for the first step. >>>> After all location is mostly about the "normal" case where clients want >>>> to reach the local servers, the backup part is only an additional >>>> feature we can keep simple for now. It's a degraded mode of operation >>>> anyway so it is probably ok to have just one default backup location as >>>> a starting point. >>> Okay, now we are in agreement. I will think about minimal schema and API over >>> the weekend. >> Well, it took longer than one weekend. >> >> There was couple of changes in the design document: >> * ?Feature Management: CLI proposal >> * ?Feature Management: web UI - idea with topology graph replaced original >> complicated table >> * Feature Management: described necessary configuration outside of IPA DNS >> * Version 1 parts which were moved into separate document: >> V4/DNS_Location_Mechanism_with_per_client_override >> * ?Assumptions: removed misleading reference to DHCP, clarified role of DNS >> views >> * Assumptions: removed misleading mention of 'different networks' and added >> summary explaining how Location is defined >> * Implementation: high-level outline added >> >> Current version: >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >> >> Full diff: >> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >> >> >> Practical usage is described in section How to test: >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >> >> >> I will think about LDAP schema after we agree on CLI. >> >> Petr^2 Spacek >> >> >>> Petr^2 Spacek >>> >>> >>>>>> - Weights for backup location servers are the same as the weight defined >>>>>> within the backup location itself, so no additional weights are defined >>>>>> for backups. >>>>> Yes, that was somehow implied in the variant A. Sorry for not mentioning it. >>>>> Weight is always relative number for servers inside one location. >>>> Ok it looked a lot more complex from your description. >>>> >>>> Simo. > > Design review: > > 1) > You missed warning when there is no backup DNS server in location Thanks, added. > 2) > "Number of IPA DNS servers <= number of configured IPA locations" I dont > understand > > You need at least one DNS server per location, thus DNS servers >= locations Good catch, fixed. > 3) > Design (Version 1: DNAME per client) Link to design doesn't work for me Oh, my wiki-fu was weak. Fixed. > CLI looks good to me. Maybe we should explicitly write in design that > priorities of the SRV records will be set statically (What values? 0 - servers > in location, 100 - backup?) I've added a note about static priorities. Particular values are just an implementation detail so I would not clutter feature management section with that. -- Petr^2 Spacek From jcholast at redhat.com Mon Apr 4 14:27:02 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 4 Apr 2016 16:27:02 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides In-Reply-To: <56FE8B5F.8040803@redhat.com> References: <56FE8B5F.8040803@redhat.com> Message-ID: <570279B6.1070504@redhat.com> Hi, On 1.4.2016 16:53, Tomas Babej wrote: > Hi, > > this extends the user ID overrides with capability to store the user > certificate. > > https://fedorahosted.org/freeipa/ticket/4955 The preferred way of managing certificates nowadays is using $OBJ-add-cert and $OBJ-remove-cert commands, you should add them here as well. I would even go as far as not allowing to modify certificates using idoverrideuser-mod - in user-mod and host-mod, it's there just for backward compatibility, which is not the case here. But I don't have a strong opinion on that. For consistency with user-find and host-find, the full certificate blob should not be shown in idoverrideuser-find. You can do that by setting search_display_attributes attribute on the idoverrideuser class appropriately. Honza -- Jan Cholasta From pspacek at redhat.com Mon Apr 4 15:37:33 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 4 Apr 2016 17:37:33 +0200 Subject: [Freeipa-devel] [PATCH 0088-0095] Add --forward-policy option into installers In-Reply-To: <56FD0DBF.7030307@redhat.com> References: <56E1E3B2.3070907@redhat.com> <20160310211744.GD32482@mail.corp.redhat.com> <56F01891.5030704@redhat.com> <56FD0DBF.7030307@redhat.com> Message-ID: <57028A3D.1010204@redhat.com> On 31.3.2016 13:45, Martin Basti wrote: > > > On 21.03.2016 16:51, Petr Spacek wrote: >> On 10.3.2016 22:17, Lukas Slebodnik wrote: >>> On (10/03/16 22:14), Petr Spacek wrote: >>>> Hello, >>>> >>>> I forgot to send a patches before I leave, so here it is: >>>> >>>> Auto-detect default value for --forward-policy option in installers >>>> >>>> See >>>> https://fedorahosted.org/freeipa/ticket/5710 >>>> commit messages, and design page >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>> >>>> >>>> >>>> I did not have time to test it thoroughly but it LGTM :-D >>>> >>>> Please note that this is first part, it does not solve upgrade (yet) and >>>> warnings in forwardzone-* interface. >>>> >>>> This can be solved in another patch set, this can be pushed if it passes >>>> review. >>>> >>> ENOPATH >> LOL, here it is. >> >> >> > * Remove function ipapython.ipautil.host_exists() * > ACK > > > * Extend installers with --forward-policy option * > 1) > There is no --forward-policy option in ipa-dns-install > > > * Move automatic empty zone list into ipapython.dnsutil and make it reusable * > ACK > > > * Add assert_absolute_dnsname() helper to ipapython.dnsutil * > ACK > > > * Move function is_auto_empty_zone() into ipapython.dnsutil * > ACK > > > * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * > ACK > > * Add function ipapython.dnsutil.inside_auto_empty_zone() * > ACK > > * Auto-detect default value for --forward-policy option in installers * > LGTM, but ipa-dns-install is missing option --forward-policy > > # ipa-dns-install > ... > Unexpected error - see /var/log/ipaserver-install.log for details: > AttributeError: Values instance has no attribute 'forward_policy' > > > Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK Thank you very much for review. Here is my second attempt :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0088-2-Remove-function-ipapython.ipautil.host_exists.patch Type: text/x-patch Size: 2546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0089-2-Extend-installers-with-forward-policy-option.patch Type: text/x-patch Size: 9143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0090-2-Move-automatic-empty-zone-list-into-ipapython.dnsuti.patch Type: text/x-patch Size: 8307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0091-2-Add-assert_absolute_dnsname-helper-to-ipapython.dnsu.patch Type: text/x-patch Size: 1574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0092-2-Move-function-is_auto_empty_zone-into-ipapython.dnsu.patch Type: text/x-patch Size: 2212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0093-2-Use-shared-sanity-check-and-tests-ipapython.dnsutil..patch Type: text/x-patch Size: 1299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0094-2-Add-function-ipapython.dnsutil.inside_auto_empty_zon.patch Type: text/x-patch Size: 1508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0095-2-Auto-detect-default-value-for-forward-policy-option-.patch Type: text/x-patch Size: 6542 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Apr 4 16:03:04 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 4 Apr 2016 18:03:04 +0200 Subject: [Freeipa-devel] [PATCH 0452] Add missing pre_common_callback to stageuser-add In-Reply-To: <56FCD688.80204@redhat.com> References: <56FCD688.80204@redhat.com> Message-ID: <57029038.4020309@redhat.com> On 03/31/2016 09:49 AM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5759 > > Patch attached. > > ACK. -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Apr 4 16:46:49 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 4 Apr 2016 18:46:49 +0200 Subject: [Freeipa-devel] [TEST][patch-0033] Added assertion errors to topology tests, track N 5772 In-Reply-To: <56FD3F17.8000507@redhat.com> References: <56FCF65C.8000709@redhat.com> <56FCF6F3.9040007@redhat.com> <56FD05C3.6010305@redhat.com> <56FD3F17.8000507@redhat.com> Message-ID: <57029A79.8080408@redhat.com> On 03/31/2016 05:15 PM, Oleg Fayans wrote: > Hi Martin, > > Thanks for the review. The updated patch(es) are included > > Testrun output can be found here: > > http://fpaste.org/347800/59421745/ > > On 03/31/2016 01:10 PM, Martin Basti wrote: >> >> >> On 31.03.2016 12:07, Oleg Fayans wrote: >>> Please, disregard it for a while, it does not pass lint. >>> >>> On 03/31/2016 12:05 PM, Oleg Fayans wrote: >>>> >>>> >> NACK >> >> Please send unrelated changes in separate patches. I do not see relation >> between changing variable names, adding assertion messages and setting >> replication sleep-a-bit wait. > > Agreed. There are two necessary bugfixes for the testsuite to run. They > were put into a separate patch > >> >> IMO to the ticket in the patch only assertion changes are related. >> >> For the pylint related errors: >> assert ('any value', 'in tuple') >> is always true. >> right syntax is >> assert (any test), ('error msg') > > thank you! > >> >> Martin^2 > > > Hi Oleg, Patch 0033: 1.) First of all, the commit message does not tell much about what the patch does, I would prefer something like "Improve reporting of failed tests in topology test suite". 2.) Since what you are doing is basically comparing the contents of a list of dicts containing expected data with a list of dicts with data parsed from test results, why are you not using "assert_deepequal" function from 'ipatests/util.py' module? It is also used in e.g. XMLRPC tests and it reports the failures fairly well (e.g. redundant keys, missing keys, expected value mismatch, container length mismatch etc.) Patch 034: I think this is a good use case for 'wait_for_replication' function from 'ipatests/test_integration/tasks.py' module. You need to establish LDAP connection to the host but this is very easy, see how it's done in 'test_simple_replication' suite[1]. I would prefer this approach (if applicable) instead of using sleep(). In any way, your formatting of assertions is wrong and makes the code nearly unreadable. See the attached patch for an example of pep8 compliant and pleasant formatting [1] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_integration/test_simple_replication.py#n42 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: assert_fmt.patch Type: text/x-patch Size: 4540 bytes Desc: not available URL: From mbasti at redhat.com Mon Apr 4 16:54:27 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 4 Apr 2016 18:54:27 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0011] WebUI: Creating user without private group In-Reply-To: <56FE6ACE.1050705@redhat.com> References: <56CF0AD6.4060505@redhat.com> <56DD9E73.1020609@redhat.com> <56DEBE89.70808@redhat.com> <56DEC2DF.3000801@redhat.com> <56E1B5CC.7070208@redhat.com> <56EBD74C.40709@redhat.com> <56FCFF33.7060801@redhat.com> <56FD314C.4080809@redhat.com> <56FE6ACE.1050705@redhat.com> Message-ID: <57029C43.7000309@redhat.com> On 01.04.2016 14:34, Pavel Vomacka wrote: > > > On 03/31/2016 04:16 PM, Lenka Doudova wrote: >> >> >> On 03/31/2016 12:42 PM, Pavel Vomacka wrote: >>> >>> >>> On 03/18/2016 11:24 AM, Lenka Doudova wrote: >>>> >>>> >>>> On 03/10/2016 06:58 PM, Petr Vobornik wrote: >>>>> On 03/08/2016 01:17 PM, Lenka Doudova wrote: >>>>>> >>>>>> >>>>>> On 03/08/2016 12:59 PM, Petr Vobornik wrote: >>>>>>> On 03/07/2016 04:29 PM, Pavel Vomacka wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 02/25/2016 03:08 PM, Lenka Doudova wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> here's a patch for webUI tests that provides test for creating >>>>>>>>> user >>>>>>>>> without private group. >>>>>>>>> Related to ticket https://fedorahosted.org/freeipa/ticket/4986 >>>>>>>>> >>>>>>>>> Since the option to specify GID when creating a user is not >>>>>>>>> available >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5505 the test creates >>>>>>>>> a new >>>>>>>>> posix group, makes it a default user group instead of >>>>>>>>> 'ipausers' and >>>>>>>>> then attemps to create the user without private group. Returning >>>>>>>>> default user group value to 'ipausers' is provided even for >>>>>>>>> cases when >>>>>>>>> the test fails so it would not block other tests from performing >>>>>>>>> properly. >>>>>>>>> >>>>>>>>> Lenka >>>>>>>>> >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> ACK, works well. >>>>>>>> >>>>>>>> Pavel^3 Vomacka >>>>>>>> >>>>>>> >>>>>>> NACK, don't use naked except, specify at least 'Exception' >>>>>>> + except: >>>>>>> >>>>>> >>>>>> Thanks, patch fixed according to Petr's review attached. >>>>>> >>>>>> Lenka >>>>> >>>>> Ticket 5505 was pushed. So the workaround can be removed. Do you >>>>> prefer to do it in this patch? >>>>> >>>>> Also, maybe it would be good to test both cases and check if the >>>>> error is actually the right one. >>>> >>>> Hi, >>>> >>>> attaching patch fixed according to recently pushed changes. >>>> >>>> Lenka >>> Hi, >>> >>> NACK, >>> >>> 1) The data definition for user3 (user.DATA3) is not used anywhere. >>> And the definition is actually the same as definition of user4. So, >>> I think that it could be removed. >>> >>> 2) This is just a detail, but I would rather use 'combobox_input' or >>> 'combobox_textbox' as parameter name because the parameter actually >>> doesn't represent the value of combobox. >>> >>> Otherwise it works as expected. >>> >>> -- >>> Pavel^3 Vomacka >>> >> Hi, >> >> thanks for comments, updated patch attached. >> >> Lenka >> >> > Thank you, ACK. > > -- > Pavel^3 Vomacka > > > Ticket is in closed milestone, this patch cannot be attached to closed milestone, please create a new ticket/or post the proper ticket. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Apr 5 07:31:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 5 Apr 2016 09:31:36 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <56FE4732.30904@redhat.com> References: <56FE4732.30904@redhat.com> Message-ID: <570369D8.609@redhat.com> On 04/01/2016 12:02 PM, Milan Kub?k wrote: > Patches attached. > > https://fedorahosted.org/freeipa/ticket/5733 > > > Hi Milan, I would be more happy if you could send a separate patch for the context manager fix, since the issue is orthogonal to the added test case (even if the test suite explodes without it). Otherwise LGTM. -- Martin^3 Babinsky From mkubik at redhat.com Tue Apr 5 08:17:58 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 5 Apr 2016 10:17:58 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <570369D8.609@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> Message-ID: <570374B6.5020702@redhat.com> On 04/05/2016 09:31 AM, Martin Babinsky wrote: > On 04/01/2016 12:02 PM, Milan Kub?k wrote: > >> Patches attached. >> >> >> >> https://fedorahosted.org/freeipa/ticket/5733 >> >> >> >> >> >> >> > Hi Milan, > > > > I would be more happy if you could send a separate patch for the context > manager fix, since the issue is orthogonal to the added test case (even > if the test suite explodes without it). > > > > Otherwise LGTM. > > > > > Done. Patch 0035 now applies to all branches, context manager fix needs separate patch for ipa-4-2. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0035-1-ipatests-Add-test-case-for-requesting-a-certificate-.patch Type: text/x-patch Size: 1494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0036-ipatests-fix-for-change_principal-context-manager.patch Type: text/x-patch Size: 1477 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0036-ipatests-fix-for-change_principal-context-manager.patch Type: text/x-patch Size: 1378 bytes Desc: not available URL: From mkubik at redhat.com Tue Apr 5 08:24:02 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 5 Apr 2016 10:24:02 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <570374B6.5020702@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> Message-ID: <57037622.9050305@redhat.com> On 04/05/2016 10:17 AM, Milan Kub?k wrote: > On 04/05/2016 09:31 AM, Martin Babinsky wrote: >> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >> >>> Patches attached. >>> >>> >>> >>> https://fedorahosted.org/freeipa/ticket/5733 >>> >>> >>> >>> >>> >>> >>> >> Hi Milan, >> >> >> >> I would be more happy if you could send a separate patch for the context >> manager fix, since the issue is orthogonal to the added test case (even >> if the test suite explodes without it). >> >> >> >> Otherwise LGTM. >> >> >> >> >> > > Done. Patch 0035 now applies to all branches, context manager fix > needs separate patch for ipa-4-2. > Updated commit message in patches 0036 to include the ticket. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0035-1-ipatests-Add-test-case-for-requesting-a-certificate-.patch Type: text/x-patch Size: 1494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0036-1-ipatests-fix-for-change_principal-context-manager.patch Type: text/x-patch Size: 1519 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0036-1-ipatests-fix-for-change_principal-context-manager.patch Type: text/x-patch Size: 1424 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Apr 5 16:14:13 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 5 Apr 2016 18:14:13 +0200 Subject: [Freeipa-devel] [TEST][patch-0032] Added a kdestroy call to clean ccache In-Reply-To: <56FCC8B6.8080605@redhat.com> References: <56FBACBF.8050906@redhat.com> <56FBE61F.4000202@redhat.com> <56FCC8B6.8080605@redhat.com> Message-ID: <5703E455.1010904@redhat.com> On 03/31/2016 08:50 AM, Oleg Fayans wrote: > Hi, > > The updated patch is included > > On 03/30/2016 08:50 PM, Robbie Harwood wrote: >> Rob Crittenden writes: >> >>> Would it be more robust to call kdestroy -A or is that just overkill in >>> this case? >> >> I believe it would be superior to call `kdestroy -A`, yes. >> > > > ACK -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Apr 5 16:15:37 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 5 Apr 2016 18:15:37 +0200 Subject: [Freeipa-devel] [TEST][Patch-0030]Next part of replica promotion tests In-Reply-To: <56FE423C.1090600@redhat.com> References: <56EFEE3E.5010202@redhat.com> <56F41F03.9020609@redhat.com> <56FE423C.1090600@redhat.com> Message-ID: <5703E4A9.5050000@redhat.com> On 04/01/2016 11:41 AM, Oleg Fayans wrote: > Hi Martin, > > Thanks for the review! The new version is attached > > On 03/24/2016 06:08 PM, Martin Babinsky wrote: >> On 03/21/2016 01:51 PM, Oleg Fayans wrote: >>> >>> >>> >> Hi Oleg, >> >> I have a few comments: >> >> 1.) >> please make the commit message more clear, briefly describe what kind of >> test cases were added to the suite and maybe add a link to the test plan. > > Done > >> >> 2.) >> I see negative test scenarios for attempting to issue >> 'ipa-csreplica-manage connect' and 'disconnect' under domain level 1. >> However, for full coverage there should be also a negative test case for >> 'ipa-csreplica-manage del' which should also issue error in domain level >> 1, see >> https://git.fedorahosted.org/cgit/freeipa.git/commit/install/tools/ipa-csreplica-manage?h=ipa-4-3&id=6119dbb9a915283434f718b38a70017e3ad00840 >> >> >> Could you please add this case to the patch and also to the Test plan so >> that we have full coverage of this? > > Done > >> >> 3.) >> test_one_command_installation exploded during client enrollment part on >> "Joining realm failed: incorrect password". This is probably caused by >> missing '-P', 'admin' option here: >> """ >> + self.replicas[0].run_command(['ipa-replica-install', '-p', >> + self.master.config.admin_password, >> + '-n', self.master.domain.name, >> + '-r', self.master.domain.realm]) >> + >> """ > > Fixed. Turned out, it's enough to just provide '-w' > >> >> 4.) >> I am not very happy about the organization of >> 'TestUnprivilegedUserPermissions' class. >> >> For starters, I would add this whole block: >> """ >> + password = self.master.config.dirman_password >> + new_password = '$ome0therPaaS' >> + replica = self.replicas[0] >> + adduser_stdin_text = "%s\n%s\n" % >> (self.master.config.admin_password, >> + self.master.config.admin_password) >> + user_kinit_stdin_text = "%s\n%s\n%s\n" % (password, new_password, >> + new_password) >> + tasks.kinit_admin(self.master) >> + self.master.run_command(['ipa', 'user-add', 'testuser', >> '--password', >> + '--first', 'John', '--last', 'Donn'], >> + stdin_text=adduser_stdin_text) >> + # Now we need to change the password for the user >> + self.master.run_command(['kinit', 'testuser'], >> + stdin_text=user_kinit_stdin_text) >> + # And again kinit admin >> + tasks.kinit_admin(self.master) >> """ >> >> into 'install()' method, since it indeed sets-up the test harness. You >> can add the user name and password to class members so that you can then >> use them from the test cases. Which brings me to the second point: I >> know that the test plan mentions this as a single test case, but I would >> like this: >> >> """ >> + result1 = replica.run_command(['ipa-client-install', '-p', >> 'testuser', >> + '-w', new_password, >> + '--domain', replica.domain.name, >> + '--realm', replica.domain.realm, >> '-U'], >> + raiseonerr=False) >> + assert_error(result1, "No permission to join this host", 1) >> + tasks.install_client(self.master, replica) >> + result2 = replica.run_command(['ipa-replica-install', '-P', >> 'testuser', >> + '-p', new_password, >> + '-n', self.master.domain.name, >> + '-r', self.master.domain.realm], >> + raiseonerr=False) >> + assert_error(result2, >> + "Insufficient privileges to promote the server", 1) >> + self.master.run_command(['ipa', 'group-add-member', 'admins', >> + '--users=testuser']) >> + >> + replica.run_command(['ipa-replica-install', '-P', 'testuser', >> + '-p', new_password, >> + '-n', self.master.domain.name, >> + '-r', self.master.domain.realm]) >> """ >> >> to be split into three separate test methods for the sake of clarity, e.g.: >> "test_client_enrollment_by_unprivileged_user" >> "test_replica_install_by_unprovileged_user" >> "test_replica_install_after_adding_to_admin_group" > > I like that! Implemented. > >> >> 5.) >> """ >> + result = self.replicas[0].run_command(['ipa-server-install', >> + '--uninstall', '-U'], >> + raiseonerr=False) >> + assert("Uninstallation leads to disconnected topology" >> + in result.stderr_text) >> + self.replicas[0].run_command(['ipa-server-install', '--uninstall', >> + '-U', >> '--ignore-topology-disconnect']) >> """ >> here you should assert against command stdout, since the error message >> is emitted only by plain print(). Yes it is weird but that's the way it >> is. It will probably be changed when I implement >> https://fedorahosted.org/freeipa/ticket/5588 so we can fix it when the >> ticket is finished. > > Yeah, I've noticed that already. Fixed > >> > Thanks, ACK, the code looks good and tests are shining green. -- Martin^3 Babinsky From pvoborni at redhat.com Tue Apr 5 16:37:13 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 5 Apr 2016 18:37:13 +0200 Subject: [Freeipa-devel] CentOS 7 COPR repository with ipa 4.3.1 available for testing Message-ID: <5703E9B9.8060008@redhat.com> Hello everyone, Copr repository @freeipa/freeipa-4-3-centos-7 is available for testing of Freeipa 4.3.1[1] on CentOS 7. https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-3-centos-7/ Your feedback is welcome! Disclaimer: the build was not thoroughly tested and works mainly as a preview. Use at your own risk. Do not use in production. There is no guarantee of update stability of the repository. The repository could be deleted or recreated at any time. Known issues: Testing replica promotion[2]: CentOS 7.2 doesn't have updated SELinux policy with policies[3] required for this build therefore replica promotion will fail in SELinux enforcing mode. [1] http://www.freeipa.org/page/Releases/4.3.1 [2] http://www.freeipa.org/page/Releases/4.3.0#New_method_-_domain_level_1 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1289930 -- Petr Vobornik From jcholast at redhat.com Wed Apr 6 08:50:12 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 6 Apr 2016 10:50:12 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5702554F.3050207@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> Message-ID: <5704CDC4.40907@redhat.com> On 4.4.2016 13:51, Petr Spacek wrote: > On 4.4.2016 13:39, Martin Basti wrote: >> >> >> On 31.03.2016 09:58, Petr Spacek wrote: >>> On 26.2.2016 15:37, Petr Spacek wrote: >>>> On 25.2.2016 16:46, Simo Sorce wrote: >>>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>>> Variant C >>>>>>>> --------- >>>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>>> the first >>>>>>>> round ... >>>>>>>> >>>>>>>> We would retain >>>>>>>> [first step - no change from variant A] >>>>>>>> * create locations >>>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>>> manually >>>>>>>> input (server, weight) tuples >>>>>>>> >>>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>>> from all >>>>>>>> other locations. >>>>>>>> >>>>>>>> Additional storage complexity: 0 >>>>>>>> >>>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>>> only as >>>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>>> >>>>>>>> This might be sufficient for the first run and would allow us to >>>>>>>> gather some >>>>>>>> feedback from the field. >>>>>>>> >>>>>>>> Now I'm inclined to this variant :-) >>>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>>> >>>>>>> To recap: >>>>>>> - define a location with the list of servers (perhaps location is a >>>>>>> property of server objects so you can have only one location per server, >>>>>>> and if you remove the server it is automatically removed from the >>>>>>> location w/o additional work or referential integrity necessary), if >>>>>>> weight is not defined (default) then they all have the same weight. >>>>>> Agreed. >>>>>> >>>>>> >>>>>>> - Allow to specify backup locations in the location object, priorities >>>>>>> are calculated automatically and all backup locations have same weight. >>>>>> Hmm, weights have to be inherited form the original location in all >>>>>> cases. Did >>>>>> you mean that all backup locations have the same *priority*? >>>>> Yes, sorry. >>>>> >>>>>> Anyway, explicit configuration of backup locations is introducing API and >>>>>> schema for variant A and that is what I'm questioning above. It is hard to >>>>>> make it extensible so we do not have headache in future when somebody >>>>>> decides >>>>>> that more flexibility is needed OR that link-based approach is better. >>>>> I think no matter we do we'll need to allow admins to override backup >>>>> locations, in future if we can calculate them automatically admins will >>>>> simply not set any backup location explicitly (or set some special value >>>>> like "autogenerate" and the system will do it for them. >>>>> >>>>> Forcing admins to mentally calculate weights to force the system to >>>>> autogenerate the configuration they want would be a bad experience, I >>>>> personally would find it very annoying. >>>>> >>>>>> In other words, for doing what you propose above we would have to design >>>>>> complete schema and API for variant A anyway to make sure we do not lock >>>>>> ourselves, so we are not getting any saving by doing so. >>>>> A seemed much more complicated to me, as you wanted to define a ful >>>>> matrix for weights of servers when they are served as backups and all >>>>> that. >>>>> >>>>>>> - Define a *default* location, which is the backup for any other >>>>>>> location but always with lower priority to any other explicitly defined >>>>>>> backup locations. >>>>>> I would rather *always* use the default location as backup for all other >>>>>> locations. It does not require any API or schema (as it equals to "all >>>>>> servers" except "servers in this location" which can be easily calculated >>>>>> on fly). >>>>> We can start with this, but it works well only in a stellar topology >>>>> where you have a central location all other location connect to. >>>>> As soon as you have a super-stellar topology where you have hub location >>>>> to which regional locations connect to, then this is wasteful. >>>>> >>>>>> This can be later on extended in whatever direction we want without any >>>>>> upgrade/migration problem. >>>>>> >>>>>> More importantly, all the schema and API will be common for all other >>>>>> variants >>>>>> anyway so we can start doing so and see how much time is left when it is >>>>>> done. >>>>> I am ok with this for the first step. >>>>> After all location is mostly about the "normal" case where clients want >>>>> to reach the local servers, the backup part is only an additional >>>>> feature we can keep simple for now. It's a degraded mode of operation >>>>> anyway so it is probably ok to have just one default backup location as >>>>> a starting point. >>>> Okay, now we are in agreement. I will think about minimal schema and API over >>>> the weekend. >>> Well, it took longer than one weekend. >>> >>> There was couple of changes in the design document: >>> * ?Feature Management: CLI proposal >>> * ?Feature Management: web UI - idea with topology graph replaced original >>> complicated table >>> * Feature Management: described necessary configuration outside of IPA DNS >>> * Version 1 parts which were moved into separate document: >>> V4/DNS_Location_Mechanism_with_per_client_override >>> * ?Assumptions: removed misleading reference to DHCP, clarified role of DNS >>> views >>> * Assumptions: removed misleading mention of 'different networks' and added >>> summary explaining how Location is defined >>> * Implementation: high-level outline added >>> >>> Current version: >>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>> >>> Full diff: >>> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >>> >>> >>> Practical usage is described in section How to test: >>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >>> >>> >>> I will think about LDAP schema after we agree on CLI. >>> >>> Petr^2 Spacek >>> >>> >>>> Petr^2 Spacek >>>> >>>> >>>>>>> - Weights for backup location servers are the same as the weight defined >>>>>>> within the backup location itself, so no additional weights are defined >>>>>>> for backups. >>>>>> Yes, that was somehow implied in the variant A. Sorry for not mentioning it. >>>>>> Weight is always relative number for servers inside one location. >>>>> Ok it looked a lot more complex from your description. >>>>> >>>>> Simo. >> >> Design review: >> >> 1) >> You missed warning when there is no backup DNS server in location > > Thanks, added. > > >> 2) >> "Number of IPA DNS servers <= number of configured IPA locations" I dont >> understand >> >> You need at least one DNS server per location, thus DNS servers >= locations > > Good catch, fixed. > > >> 3) >> Design (Version 1: DNAME per client) Link to design doesn't work for me > > Oh, my wiki-fu was weak. Fixed. > > >> CLI looks good to me. Maybe we should explicitly write in design that >> priorities of the SRV records will be set statically (What values? 0 - servers >> in location, 100 - backup?) > > I've added a note about static priorities. Particular values are just an > implementation detail so I would not clutter feature management section with that. If server can be only in one location, why bother with location-{add,mod,remove}-member and not use server-mod: server-mod --location= [--location-weight=0..65535] ? This is the natural way to model one-to-many relationships in the API, consistent with existing stuff. -- Jan Cholasta From mrniranjan at fedoraproject.org Wed Apr 6 08:55:14 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Wed, 6 Apr 2016 14:25:14 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows Message-ID: <20160406085514.GA17358@mniranja.pnq.redhat.com> Greetings, For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed a patch, I think this patch is more of a workaround , than a solution. I would like to get more inputs on how to use pytest-multihost to execute commands on Windows. The method i am using requires cygwin with openssh/bash to be installed. Request to review the patch. Regards Niranjan -------------- next part -------------- From 5944e86f881516209fcb030ec3da7ad1b58ab4cc Mon Sep 17 00:00:00 2001 From: Niranjan MR Date: Wed, 6 Apr 2016 14:08:13 +0530 Subject: [PATCH] Add new parameter "type" for hosts to have Expand class WinHost to add function run_win_command which executes commands on Windows. Signed-off-by: Niranjan MR --- pytest_multihost/config.py | 4 ++++ pytest_multihost/host.py | 44 +++++++++++++++++++++++++++++++++++++++----- 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py index 31045c21e8ee67c1793f154f841375f8df7b365f..e42b2743dd7b4cf17b935c961248803a8e1dd46e 100644 --- a/pytest_multihost/config.py +++ b/pytest_multihost/config.py @@ -182,6 +182,10 @@ class Domain(object): from pytest_multihost.host import Host return Host + def get_winhost_class(self, host_dict): + from pytest_multihost.host import WinHost + return WinHost + @property def roles(self): """All the roles of the hosts in this domain""" diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py index e6c0db50799b2042e699d66ed9ec5f04f6592d31..113035753b216fcc7053706d9855e85399dd5e53 100644 --- a/pytest_multihost/host.py +++ b/pytest_multihost/host.py @@ -27,9 +27,10 @@ class BaseHost(object): transport_class = None def __init__(self, domain, hostname, role, ip=None, - external_hostname=None, username=None, password=None): + external_hostname=None, username=None, password=None, host_type=None): self.domain = domain self.role = str(role) + self.host_type = str(host_type) if username is None: self.ssh_username = self.config.ssh_username else: @@ -118,11 +119,12 @@ class BaseHost(object): username = dct.pop('username', None) password = dct.pop('password', None) + host_type = dct.pop('host_type', None) check_config_dict_empty(dct, 'host %s' % hostname) return cls(domain, hostname, role, ip, external_hostname, - username, password) + username, password, host_type) def to_dict(self): """Export info about this Host to a dict""" @@ -250,8 +252,40 @@ class Host(BaseHost): class WinHost(BaseHost): """ Representation of a remote Windows host. - - This is a stub; Windows hosts can't currently be interacted with. """ + transport_class = transport.SSHTransport + def run_win_command(self, argv, set_env=True, stdin_text=None, + log_stdout=True, raiseonerr=True, + cwd=None): + command = self.transport.start_shell(argv, log_stdout=log_stdout) + #self.config.test_dir = '%s/%s' % ('/home',self.config.username) + print("self.config",dir(self.config)) + + # Set working directory + if cwd is None: + cwd = self.config.test_dir + command.stdin.write('cd %s\n' % shell_quote(cwd)) + + # Set the environment + if set_env: + command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) + + if isinstance(argv, basestring): + # Run a shell command given as a string + command.stdin.write('(') + command.stdin.write(argv) + command.stdin.write(')') + else: + # Run a command given as a popen-style list (no shell expansion) + for arg in argv: + command.stdin.write(shell_quote(arg)) + command.stdin.write(' ') + + command.stdin.write(';exit\n') + if stdin_text: + command.stdin.write(stdin_text) + command.stdin.flush() + + command.wait(raiseonerr=raiseonerr) + return command - pass -- 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 pspacek at redhat.com Wed Apr 6 08:57:42 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 6 Apr 2016 10:57:42 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5704CDC4.40907@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> Message-ID: <5704CF86.3000709@redhat.com> On 6.4.2016 10:50, Jan Cholasta wrote: > On 4.4.2016 13:51, Petr Spacek wrote: >> On 4.4.2016 13:39, Martin Basti wrote: >>> >>> >>> On 31.03.2016 09:58, Petr Spacek wrote: >>>> On 26.2.2016 15:37, Petr Spacek wrote: >>>>> On 25.2.2016 16:46, Simo Sorce wrote: >>>>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>>>> Variant C >>>>>>>>> --------- >>>>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>>>> the first >>>>>>>>> round ... >>>>>>>>> >>>>>>>>> We would retain >>>>>>>>> [first step - no change from variant A] >>>>>>>>> * create locations >>>>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>>>> manually >>>>>>>>> input (server, weight) tuples >>>>>>>>> >>>>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>>>> from all >>>>>>>>> other locations. >>>>>>>>> >>>>>>>>> Additional storage complexity: 0 >>>>>>>>> >>>>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>>>> only as >>>>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>>>> >>>>>>>>> This might be sufficient for the first run and would allow us to >>>>>>>>> gather some >>>>>>>>> feedback from the field. >>>>>>>>> >>>>>>>>> Now I'm inclined to this variant :-) >>>>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>>>> >>>>>>>> To recap: >>>>>>>> - define a location with the list of servers (perhaps location is a >>>>>>>> property of server objects so you can have only one location per server, >>>>>>>> and if you remove the server it is automatically removed from the >>>>>>>> location w/o additional work or referential integrity necessary), if >>>>>>>> weight is not defined (default) then they all have the same weight. >>>>>>> Agreed. >>>>>>> >>>>>>> >>>>>>>> - Allow to specify backup locations in the location object, priorities >>>>>>>> are calculated automatically and all backup locations have same weight. >>>>>>> Hmm, weights have to be inherited form the original location in all >>>>>>> cases. Did >>>>>>> you mean that all backup locations have the same *priority*? >>>>>> Yes, sorry. >>>>>> >>>>>>> Anyway, explicit configuration of backup locations is introducing API and >>>>>>> schema for variant A and that is what I'm questioning above. It is hard to >>>>>>> make it extensible so we do not have headache in future when somebody >>>>>>> decides >>>>>>> that more flexibility is needed OR that link-based approach is better. >>>>>> I think no matter we do we'll need to allow admins to override backup >>>>>> locations, in future if we can calculate them automatically admins will >>>>>> simply not set any backup location explicitly (or set some special value >>>>>> like "autogenerate" and the system will do it for them. >>>>>> >>>>>> Forcing admins to mentally calculate weights to force the system to >>>>>> autogenerate the configuration they want would be a bad experience, I >>>>>> personally would find it very annoying. >>>>>> >>>>>>> In other words, for doing what you propose above we would have to design >>>>>>> complete schema and API for variant A anyway to make sure we do not lock >>>>>>> ourselves, so we are not getting any saving by doing so. >>>>>> A seemed much more complicated to me, as you wanted to define a ful >>>>>> matrix for weights of servers when they are served as backups and all >>>>>> that. >>>>>> >>>>>>>> - Define a *default* location, which is the backup for any other >>>>>>>> location but always with lower priority to any other explicitly defined >>>>>>>> backup locations. >>>>>>> I would rather *always* use the default location as backup for all other >>>>>>> locations. It does not require any API or schema (as it equals to "all >>>>>>> servers" except "servers in this location" which can be easily calculated >>>>>>> on fly). >>>>>> We can start with this, but it works well only in a stellar topology >>>>>> where you have a central location all other location connect to. >>>>>> As soon as you have a super-stellar topology where you have hub location >>>>>> to which regional locations connect to, then this is wasteful. >>>>>> >>>>>>> This can be later on extended in whatever direction we want without any >>>>>>> upgrade/migration problem. >>>>>>> >>>>>>> More importantly, all the schema and API will be common for all other >>>>>>> variants >>>>>>> anyway so we can start doing so and see how much time is left when it is >>>>>>> done. >>>>>> I am ok with this for the first step. >>>>>> After all location is mostly about the "normal" case where clients want >>>>>> to reach the local servers, the backup part is only an additional >>>>>> feature we can keep simple for now. It's a degraded mode of operation >>>>>> anyway so it is probably ok to have just one default backup location as >>>>>> a starting point. >>>>> Okay, now we are in agreement. I will think about minimal schema and API >>>>> over >>>>> the weekend. >>>> Well, it took longer than one weekend. >>>> >>>> There was couple of changes in the design document: >>>> * ?Feature Management: CLI proposal >>>> * ?Feature Management: web UI - idea with topology graph replaced original >>>> complicated table >>>> * Feature Management: described necessary configuration outside of IPA DNS >>>> * Version 1 parts which were moved into separate document: >>>> V4/DNS_Location_Mechanism_with_per_client_override >>>> * ?Assumptions: removed misleading reference to DHCP, clarified role of DNS >>>> views >>>> * Assumptions: removed misleading mention of 'different networks' and added >>>> summary explaining how Location is defined >>>> * Implementation: high-level outline added >>>> >>>> Current version: >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>> >>>> Full diff: >>>> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >>>> >>>> >>>> >>>> Practical usage is described in section How to test: >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >>>> >>>> >>>> I will think about LDAP schema after we agree on CLI. >>>> >>>> Petr^2 Spacek >>>> >>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>>>>> - Weights for backup location servers are the same as the weight defined >>>>>>>> within the backup location itself, so no additional weights are defined >>>>>>>> for backups. >>>>>>> Yes, that was somehow implied in the variant A. Sorry for not >>>>>>> mentioning it. >>>>>>> Weight is always relative number for servers inside one location. >>>>>> Ok it looked a lot more complex from your description. >>>>>> >>>>>> Simo. >>> >>> Design review: >>> >>> 1) >>> You missed warning when there is no backup DNS server in location >> >> Thanks, added. >> >> >>> 2) >>> "Number of IPA DNS servers <= number of configured IPA locations" I dont >>> understand >>> >>> You need at least one DNS server per location, thus DNS servers >= locations >> >> Good catch, fixed. >> >> >>> 3) >>> Design (Version 1: DNAME per client) Link to design doesn't work for me >> >> Oh, my wiki-fu was weak. Fixed. >> >> >>> CLI looks good to me. Maybe we should explicitly write in design that >>> priorities of the SRV records will be set statically (What values? 0 - servers >>> in location, 100 - backup?) >> >> I've added a note about static priorities. Particular values are just an >> implementation detail so I would not clutter feature management section with >> that. > > If server can be only in one location, why bother with > location-{add,mod,remove}-member and not use server-mod: > > server-mod --location= [--location-weight=0..65535] > > ? This is the natural way to model one-to-many relationships in the API, > consistent with existing stuff. I originally wanted to have location-add-member command so (external) DNS servers and IPA servers can be assigned to a location using the same command: location-add-member LOCATION_NAME --ipa-server= location-add-member LOCATION_NAME --advertising-server= Should I split this between server-mod --location= [--location-weight=0..65535] and dnsserver-mod --type=external --advertise-location=... I do not like splitting server-to-location assignment management between two commands very much. Current proposal in design page was inspired by group-add-member command which has --users and --groups options which seemed philosophically similar to me. Anyway, I'm open to suggestions how to handle this. -- Petr^2 Spacek From pviktori at redhat.com Wed Apr 6 11:25:55 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 6 Apr 2016 13:25:55 +0200 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160406085514.GA17358@mniranja.pnq.redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> Message-ID: <5704F243.5000006@redhat.com> On 04/06/2016 10:55 AM, Niranjan wrote: > Greetings, > > For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > a patch, I think this patch is more of a workaround , than a solution. I would > like to get more inputs on how to use pytest-multihost to execute commands > on Windows. The method i am using requires cygwin with openssh/bash to be > installed. Wow. I'm surprised the only problem on Windows is the "set -e". Regarding the patch: - Why is get_winhost_class needed? I don't see it called anywhere. - Similarly, why is host_type needed? Your patch only sets it. If run_command of WinHost and Unix hosts are this similar, I would put the 'set -e\n' for Unix (and an empty string for Windows) in a class attribute named e.g. "command_prelude", use it in run_command, and move run_command from Host to BaseHost. Would that work, or am I missing something? -- Petr Viktorin From pspacek at redhat.com Wed Apr 6 11:42:34 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 6 Apr 2016 13:42:34 +0200 Subject: [Freeipa-devel] [PATCH 0393-0398] Unload automatic empty zones only if conflicting forward zone has policy 'only'Add ability to log warningsUnload automatic empty zones which are super/sub/equal domain as forward zoneDo not touch global forwarders from named.conf if there is no config in LDAPAdd missing includes to util.hMove zone_isempty() and delete_bind_zone() to zone_register.c Message-ID: <5704F62A.8050606@redhat.com> Hello, attached patch set implements https://fedorahosted.org/bind-dyndb-ldap/ticket/160 described in https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones It will be accompanied with upgrade code in FreeIPA which will automatically convert forward zones as necessary. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0393-Move-zone_isempty-and-delete_bind_zone-to-zone_regis.patch Type: text/x-patch Size: 5670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0394-Add-missing-includes-to-util.h.patch Type: text/x-patch Size: 721 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0395-Do-not-touch-global-forwarders-from-named.conf-if-th.patch Type: text/x-patch Size: 1692 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0396-Unload-automatic-empty-zones-which-are-super-sub-equ.patch Type: text/x-patch Size: 14725 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0397-Add-ability-to-log-warnings.patch Type: text/x-patch Size: 797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0398-Unload-automatic-empty-zones-only-if-conflicting-for.patch Type: text/x-patch Size: 6091 bytes Desc: not available URL: From slaznick at redhat.com Wed Apr 6 12:04:12 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 6 Apr 2016 14:04:12 +0200 Subject: [Freeipa-devel] [PATCH 0024] ipa-replica-manage: added --suffix option for certain commands In-Reply-To: <56FBE818.80805@redhat.com> References: <56E29266.8000501@redhat.com> <56E6E43B.4050805@redhat.com> <56E7AADC.3060407@redhat.com> <56E7F642.8010109@redhat.com> <56E90C5C.2020703@redhat.com> <56E925D0.2080305@redhat.com> <56E9637B.5080307@redhat.com> <56F2B380.9030504@redhat.com> <1183297765.33667649.1458760420403.JavaMail.zimbra@redhat.com> <56F42D93.5050505@redhat.com> <56FBE818.80805@redhat.com> Message-ID: <5704FB3C.2050003@redhat.com> On 03/30/2016 04:52 PM, Martin Basti wrote: > On 24.03.2016 19:10, Stanislav Laznicka wrote: >> On 03/23/2016 08:13 PM, Martin Basti wrote: >>> [...] >>> Can you please update design >>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 (mainly >>> the --suffix option)? Also there are missing clean-ruv and list-ruv >>> commands in design, and fix usage at the bottom. >>> >>> 1) >>> I don't understand this expression >>> + if dirman_passwd is None or ( >>> + not dirman_passwd and args[0] in cs_enabled_commands): >>> >>> You already tested if subcommand belongs to cs_enabled_commands few >>> lines above, IMO the 'dirman_password is None' expression is enough. >> If I understand it well, when empty password is entered, the program >> continues and uses Kerberos credentials for some operations. E.g. for >> list-ruv, if empty password is entered, the command would only >> display RUVs for domain tree but not for the CA tree no matter if CA >> is set up or not (in the current state of the patch, after get_ruv >> refactoring). This here is one possible way around this, although the >> check for non-empty password might probably just as well be in >> get_ruv_both_suffixes. > > ok >>> 2) >>> +# tuple of commands that work with ca tree and need Directory Manager >>> password >>> +cs_enabled_commands = ("list-ruv", "clean-ruv", "abort-clean-ruv") >>> >>> this variable is used only toi detect if dirman passwd is needed, I >>> suggest to rename it to commands_req_dirman_passwd, or something >>> better. >>> >>> 3) >>> Q: Do we need is_cs_set() function? >>> A: Yes! >>> >>> I wanted to give you ultimate NACK, but then I checked how get_ruv code >>> works and I changed my mind. >>> >>> Please write a comment where is_cs_set function is used, why we need >>> extra function instead of catching an exception, possibly you can >>> open a >>> refactoring ticket. >> After the refactoring changes, is_cs_set should not be needed >> anymore, removed it. >>> >>> Shame: >>> 1) >>> + if not test_connection(realm, host, options.nolookup) or\ >>> Please use parentheses instead of backslash >>> >>> 2) >>> + args[0] in cs_enabled_commands: >>> >>> + not dirman_passwd and args[0] in cs_enabled_commands): >>> >>> Indentation is not multiplication of 4 >> Shame on me indeed, fixed it. >>> >>> Nitpicks (I don't insist on fixing these): >>> 1) >>> + if servers.get('ca', None): >>> >>> None is default >>> >>> 2) >>> + for (netloc, rid) in servers['ca']: >>> parentheses are not needed >>> >>> 3) >>> + print("\t%s: %s" % (netloc, rid)) >>> Would be nice to use .format() instead of % >>> >>> Martin^2 >>> >>> >>> >>> I changed my mind, ultimate NACK. >>> Please fix get_ruv function, is_cs_set will not help. In case there >>> are no RUVs but CA is installed, sys.exit there prevents us from >>> removing RUVs (or any else operation) on domain suffix, and vice versa. >>> I propose to move ticket to 4.4 milestone because I would like to >>> avoid breaking something in 4.3, as this will hit many places in >>> ipa-replica-manage. >>> >>> Please provide the refactoring of get_ruv as separate patch a put >>> these patches on top of it. >>> >>> Martin2 >> Did the refactoring. There also seemed to be duplicit code in >> abort_clean_ruv for some reason, removed it (I hope it does not break >> anything, but it seemed rather useless). Also had to change the >> numbers of the patches so that they would apply. > > NACK > > * ipa-replica-manage refactoring * > > 1) > Instead of: > - print("Failed to connect to server %s: %s" % (host, e)) > - sys.exit(1) > + root_logger.debug("Failed to connect to server {host}: {err}" > + .format(host=host, err=e)) > + raise RuntimeError(e) > > I expected > > - print("Failed to connect to server %s: %s" % (host, e)) > - sys.exit(1) > + root_logger.debug(traceback.format_exc()) > + raise RuntimeError("Failed to connect to server {host}: {err}" > + .format(host=host, err=e))) Should be fixed now. > > 2) > - print("No RUV records found.") > - sys.exit(0) > > Here is exit state 0, so we should not raise error. > > I think that we should create new nonfatal exception. Made a new nonfatal error exception, then. This step was a bit controversial when it comes to get_ruv_both_suffixes because it needs to catch both this new exception and a RuntimeError exception for both trees. As the main idea here was not to stop if either tree is missing (resulting in RuntimeError in get_ruv) or contains no records (NonFatalError), it is only printed that something bad may have happened (or it's debug-logged in case of nonfatal errors). In the end, only NonFatalError exception is raised if no records were found for whatever reason resulting in the script always returning 0. > > 3) > - print("unable to decode: %s" % ruv) > + root_logger.debug("unable to decode: %s" % ruv) > This may break tests, because the logger logs to stderr, leave it as > print for now > > 4) > - servers = get_ruv(realm, host, dirman_passwd, nolookup) > + try: > + servers = get_ruv(realm, host, dirman_passwd, nolookup) > + except RuntimeError as e: > + print(e) > + sys.exit(1) > > again we have to print it to stdout for now. 3), 4) done, although it might be better to log to stderr from patch number 27 and on since the default behavior is changed anyway. > > * abort-clean/list/clean-ruv now work for both suffixes * > > - if dirman_passwd is None: > + if dirman_passwd is None or ( > + not dirman_passwd and args[0] in > dirman_passwd_req_commands): > sys.exit("Directory Manager password required") Done. > > Please fix other patch accordingly. > Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0026-2-ipa-replica-manage-refactoring.patch Type: text/x-patch Size: 5748 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0027-2-abort-clean-list-clean-ruv-now-work-for-both-suffixe.patch Type: text/x-patch Size: 10018 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0028-2-Moved-password-check-from-clean_dangling_ruv.patch Type: text/x-patch Size: 1829 bytes Desc: not available URL: From ofayans at redhat.com Wed Apr 6 12:40:20 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 6 Apr 2016 14:40:20 +0200 Subject: [Freeipa-devel] [TEST][patch-0033] Added assertion errors to topology tests, track N 5772 In-Reply-To: <57029A79.8080408@redhat.com> References: <56FCF65C.8000709@redhat.com> <56FCF6F3.9040007@redhat.com> <56FD05C3.6010305@redhat.com> <56FD3F17.8000507@redhat.com> <57029A79.8080408@redhat.com> Message-ID: <570503B4.9010702@redhat.com> Hi Martin, The updated patches are attached On 04/04/2016 06:46 PM, Martin Babinsky wrote: > On 03/31/2016 05:15 PM, Oleg Fayans wrote: >> Hi Martin, >> >> Thanks for the review. The updated patch(es) are included >> >> Testrun output can be found here: >> >> http://fpaste.org/347800/59421745/ >> >> On 03/31/2016 01:10 PM, Martin Basti wrote: >>> >>> >>> On 31.03.2016 12:07, Oleg Fayans wrote: >>>> Please, disregard it for a while, it does not pass lint. >>>> >>>> On 03/31/2016 12:05 PM, Oleg Fayans wrote: >>>>> >>>>> >>> NACK >>> >>> Please send unrelated changes in separate patches. I do not see relation >>> between changing variable names, adding assertion messages and setting >>> replication sleep-a-bit wait. >> >> Agreed. There are two necessary bugfixes for the testsuite to run. They >> were put into a separate patch >> >>> >>> IMO to the ticket in the patch only assertion changes are related. >>> >>> For the pylint related errors: >>> assert ('any value', 'in tuple') >>> is always true. >>> right syntax is >>> assert (any test), ('error msg') >> >> thank you! >> >>> >>> Martin^2 >> >> >> > Hi Oleg, > > Patch 0033: > > 1.) > First of all, the commit message does not tell much about what the patch > does, I would prefer something like "Improve reporting of failed tests > in topology test suite". Done > > 2.) Since what you are doing is basically comparing the contents of a > list of dicts containing expected data with a list of dicts with data > parsed from test results, why are you not using "assert_deepequal" > function from 'ipatests/util.py' module? It is also used in e.g. XMLRPC > tests and it reports the failures fairly well (e.g. redundant keys, > missing keys, expected value mismatch, container length mismatch etc.) Indeed :) Done. > > Patch 034: > > I think this is a good use case for 'wait_for_replication' function from > 'ipatests/test_integration/tasks.py' module. You need to establish LDAP > connection to the host but this is very easy, see how it's done in > 'test_simple_replication' suite[1]. > > I would prefer this approach (if applicable) instead of using sleep(). Implemented. > > In any way, your formatting of assertions is wrong and makes the code > nearly unreadable. See the attached patch for an example of pep8 > compliant and pleasant formatting Thank you, that looks really way more readable. > > [1] > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_integration/test_simple_replication.py#n42 > > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0033.2-Improve-reporting-of-failed-tests-in-topology-test.patch Type: text/x-patch Size: 5871 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0034.1-Bugfixes-in-managed-topology-tests.patch Type: text/x-patch Size: 2232 bytes Desc: not available URL: From pvomacka at redhat.com Wed Apr 6 13:46:10 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 6 Apr 2016 15:46:10 +0200 Subject: [Freeipa-devel] [PATCHES 551-552] ipalib: add basecert plugins In-Reply-To: <56E956B0.9000804@redhat.com> References: <56E956B0.9000804@redhat.com> Message-ID: <57051322.8090706@redhat.com> On 03/16/2016 01:50 PM, Jan Cholasta wrote: > Hi, > > the attached patches implement the server-side part of > . > > Honza > Hi, thank you for the patches. I tested them and they work well. But I would like to ask you whether would be possible to extend the response of 'basecert_find' method and probably also 'basecert_show' response. I think of these information: 1) information whether the certificate is issued by our CA or not. 2) this probably wouldn't be possible (as we discussed), but I rather write it too - the information about revocation reason. The same as the 'cert_show' provides. 3) MD5 and SHA1 fingerprints as the 'cert_show' method returns Thank you again. -- Pavel^3 Vomacka From mbasti at redhat.com Wed Apr 6 14:01:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 6 Apr 2016 16:01:16 +0200 Subject: [Freeipa-devel] [TEST][patch-0032] Added a kdestroy call to clean ccache In-Reply-To: <5703E455.1010904@redhat.com> References: <56FBACBF.8050906@redhat.com> <56FBE61F.4000202@redhat.com> <56FCC8B6.8080605@redhat.com> <5703E455.1010904@redhat.com> Message-ID: <570516AC.1090909@redhat.com> On 05.04.2016 18:14, Martin Babinsky wrote: > On 03/31/2016 08:50 AM, Oleg Fayans wrote: >> Hi, >> >> The updated patch is included >> >> On 03/30/2016 08:50 PM, Robbie Harwood wrote: >>> Rob Crittenden writes: >>> >>>> Would it be more robust to call kdestroy -A or is that just >>>> overkill in >>>> this case? >>> >>> I believe it would be superior to call `kdestroy -A`, yes. >>> >> >> >> > ACK > Pushed to: master: f836ee7b9c06f282e71dacbefb6f7f34b3addddc ipa-4-3: c1b21ba093f929d2946017b91db23df34b0c4dce From mbasti at redhat.com Wed Apr 6 14:03:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 6 Apr 2016 16:03:46 +0200 Subject: [Freeipa-devel] [TEST][Patch-0030]Next part of replica promotion tests In-Reply-To: <5703E4A9.5050000@redhat.com> References: <56EFEE3E.5010202@redhat.com> <56F41F03.9020609@redhat.com> <56FE423C.1090600@redhat.com> <5703E4A9.5050000@redhat.com> Message-ID: <57051742.9000407@redhat.com> On 05.04.2016 18:15, Martin Babinsky wrote: > On 04/01/2016 11:41 AM, Oleg Fayans wrote: >> Hi Martin, >> >> Thanks for the review! The new version is attached >> >> On 03/24/2016 06:08 PM, Martin Babinsky wrote: >>> On 03/21/2016 01:51 PM, Oleg Fayans wrote: >>>> >>>> >>>> >>> Hi Oleg, >>> >>> I have a few comments: >>> >>> 1.) >>> please make the commit message more clear, briefly describe what >>> kind of >>> test cases were added to the suite and maybe add a link to the test >>> plan. >> >> Done >> >>> >>> 2.) >>> I see negative test scenarios for attempting to issue >>> 'ipa-csreplica-manage connect' and 'disconnect' under domain level 1. >>> However, for full coverage there should be also a negative test case >>> for >>> 'ipa-csreplica-manage del' which should also issue error in domain >>> level >>> 1, see >>> https://git.fedorahosted.org/cgit/freeipa.git/commit/install/tools/ipa-csreplica-manage?h=ipa-4-3&id=6119dbb9a915283434f718b38a70017e3ad00840 >>> >>> >>> >>> Could you please add this case to the patch and also to the Test >>> plan so >>> that we have full coverage of this? >> >> Done >> >>> >>> 3.) >>> test_one_command_installation exploded during client enrollment part on >>> "Joining realm failed: incorrect password". This is probably caused by >>> missing '-P', 'admin' option here: >>> """ >>> + self.replicas[0].run_command(['ipa-replica-install', '-p', >>> + self.master.config.admin_password, >>> + '-n', self.master.domain.name, >>> + '-r', self.master.domain.realm]) >>> + >>> """ >> >> Fixed. Turned out, it's enough to just provide '-w' >> >>> >>> 4.) >>> I am not very happy about the organization of >>> 'TestUnprivilegedUserPermissions' class. >>> >>> For starters, I would add this whole block: >>> """ >>> + password = self.master.config.dirman_password >>> + new_password = '$ome0therPaaS' >>> + replica = self.replicas[0] >>> + adduser_stdin_text = "%s\n%s\n" % >>> (self.master.config.admin_password, >>> + self.master.config.admin_password) >>> + user_kinit_stdin_text = "%s\n%s\n%s\n" % (password, >>> new_password, >>> + new_password) >>> + tasks.kinit_admin(self.master) >>> + self.master.run_command(['ipa', 'user-add', 'testuser', >>> '--password', >>> + '--first', 'John', '--last', 'Donn'], >>> + stdin_text=adduser_stdin_text) >>> + # Now we need to change the password for the user >>> + self.master.run_command(['kinit', 'testuser'], >>> + stdin_text=user_kinit_stdin_text) >>> + # And again kinit admin >>> + tasks.kinit_admin(self.master) >>> """ >>> >>> into 'install()' method, since it indeed sets-up the test harness. You >>> can add the user name and password to class members so that you can >>> then >>> use them from the test cases. Which brings me to the second point: I >>> know that the test plan mentions this as a single test case, but I >>> would >>> like this: >>> >>> """ >>> + result1 = replica.run_command(['ipa-client-install', '-p', >>> 'testuser', >>> + '-w', new_password, >>> + '--domain', >>> replica.domain.name, >>> + '--realm', >>> replica.domain.realm, >>> '-U'], >>> + raiseonerr=False) >>> + assert_error(result1, "No permission to join this host", 1) >>> + tasks.install_client(self.master, replica) >>> + result2 = replica.run_command(['ipa-replica-install', '-P', >>> 'testuser', >>> + '-p', new_password, >>> + '-n', self.master.domain.name, >>> + '-r', >>> self.master.domain.realm], >>> + raiseonerr=False) >>> + assert_error(result2, >>> + "Insufficient privileges to promote the >>> server", 1) >>> + self.master.run_command(['ipa', 'group-add-member', 'admins', >>> + '--users=testuser']) >>> + >>> + replica.run_command(['ipa-replica-install', '-P', 'testuser', >>> + '-p', new_password, >>> + '-n', self.master.domain.name, >>> + '-r', self.master.domain.realm]) >>> """ >>> >>> to be split into three separate test methods for the sake of >>> clarity, e.g.: >>> "test_client_enrollment_by_unprivileged_user" >>> "test_replica_install_by_unprovileged_user" >>> "test_replica_install_after_adding_to_admin_group" >> >> I like that! Implemented. >> >>> >>> 5.) >>> """ >>> + result = self.replicas[0].run_command(['ipa-server-install', >>> + '--uninstall', '-U'], >>> + raiseonerr=False) >>> + assert("Uninstallation leads to disconnected topology" >>> + in result.stderr_text) >>> + self.replicas[0].run_command(['ipa-server-install', >>> '--uninstall', >>> + '-U', >>> '--ignore-topology-disconnect']) >>> """ >>> here you should assert against command stdout, since the error message >>> is emitted only by plain print(). Yes it is weird but that's the way it >>> is. It will probably be changed when I implement >>> https://fedorahosted.org/freeipa/ticket/5588 so we can fix it when the >>> ticket is finished. >> >> Yeah, I've noticed that already. Fixed >> >>> >> > > Thanks, > > ACK, the code looks good and tests are shining green. > Pushed to: master: ab3b4a92a85b550429429acc238f2e90128de565 ipa-4-3: fb8e97b06db8fbca517fb9c91bc5c28368b3da56 From mbabinsk at redhat.com Wed Apr 6 14:37:25 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 6 Apr 2016 16:37:25 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <56EFB09F.9010200@redhat.com> References: <56EAE651.4040603@redhat.com> <56EFB09F.9010200@redhat.com> Message-ID: <57051F25.5090307@redhat.com> On 03/21/2016 09:28 AM, Jan Cholasta wrote: > On 17.3.2016 18:16, Martin Babinsky wrote: >> Hi list, >> >> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >> design document concerning the concept of Server Roles as a >> user-friendly abstraction of the services running on IPA masters. >> >> The main aim of this feature is to provide a higher level interface to >> query and manipulate service-related information stored in dirsrv >> backend. >> >> I have not touched the design much from the post-Devconf session, mainly >> because there are some points to clarify and agree upon. >> >> I have the following points to discuss: >> >> 1.) the design assumes that there is a distinction between roles such as >> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >> master, CRL master, etc. Now in the hindsight I think this distinction >> is quite artificial and just clutters the interface unnecessarily. We >> might implement this kind of hierarchy in the code itself but that is >> something the user needs not be aware of. > > These shouldn't be (sub-)roles at all - they are inherently a > one-to-many relationship between the logical services and servers, > whereas roles are many-to-many relationship between the logical services > and servers. I would rather see them exposed in the global service > config, such as: > > $ ipa dnsconfig-mod --sec-master=ipa12.example.com > DNSSEC master: ipa12.example.com > >> >> 2.) I guess the role names should be case insensitive so that users are >> not hindered by trying to get the case right. > > +1 > >> >> 3.) Do we need an internal API call which will add all services >> belonging to a role to the corresponding master entry? (basically a >> 'server_add_role' type of command). Currently, each service instance >> adds its own service entry during service installation so we probably do >> not need to duplicate this functionality. > > +1, we don't need more duplicate code. > >> >> That is all I can think of right now. I had many more questions popping >> up during this night's bout of insomnia, but they got lost during the >> day. > > How are we going to expose the different states of server roles? They > can be: > > a) available/unavailable (the package providing the role was/was not > installed on the server) > b) configured/unconfigured (the installer for the role was/was not > successfully run on the server, LDAP service entries exist) > c) enabled/disabled > > My preference would be to make server-role commands work on top of > available services, like this: > > # ipa server-role-show $HOSTNAME DNS > ipa: ERROR: DNS: server role not found > > # dnf install freeipa-server-dns > ... > > # ipa server-role-show $HOSTNAME DNS > Name: DNS > Configured: False > Enabled: False > > # ipa-dns-install > ... > > # ipa server-role-show $HOSTNAME DNS > Name: DNS > Configured: True > Enabled: True > >> >> Do not be afraid to bring up other questions/remarks/comments. This is >> my first design documents so I expect them to be plenty. > > The CLI commands are a little bit self-inconsistent, see any other > plugin for how the general layout of arguments should look like. > I have updated the design page[1] according to the comments gathered in this thread and offline discussion with principal reviewer, e.g. Jan. Again comments are welcome. [1] http://www.freeipa.org/page/V4/Server_Roles -- Martin^3 Babinsky From ftweedal at redhat.com Thu Apr 7 06:43:29 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 7 Apr 2016 16:43:29 +1000 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia Message-ID: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> Hi team, I updated the Sub-CAs design page with more detail for the key replication[1]. This part of the design is nearly complete (a large patchset is in review over at pki-devel@) but there are various options about how to authenticate to Custodia. [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication In brief, the options are: 1) authenticate as host principal; install binary setuid root:pkiuser to read host keytab and custodia keys. 2) authenticate as host principal; copy host keytab and custodia keys to location readable by pkiuser. 3) create new principal for pkiuser to use, along with custodia keys and keytab in location readable by pkiuser. I prefer option (1) for reasons outlined in the design page. The design page goes into quite a bit more detail so please review the section linked above and get back to me with your thoughts. Cheers, Fraser From pspacek at redhat.com Thu Apr 7 08:28:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 7 Apr 2016 10:28:06 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <57051F25.5090307@redhat.com> References: <56EAE651.4040603@redhat.com> <56EFB09F.9010200@redhat.com> <57051F25.5090307@redhat.com> Message-ID: <57061A16.5000904@redhat.com> On 6.4.2016 16:37, Martin Babinsky wrote: > On 03/21/2016 09:28 AM, Jan Cholasta wrote: >> On 17.3.2016 18:16, Martin Babinsky wrote: >>> Hi list, >>> >>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >>> design document concerning the concept of Server Roles as a >>> user-friendly abstraction of the services running on IPA masters. >>> >>> The main aim of this feature is to provide a higher level interface to >>> query and manipulate service-related information stored in dirsrv >>> backend. >>> >>> I have not touched the design much from the post-Devconf session, mainly >>> because there are some points to clarify and agree upon. >>> >>> I have the following points to discuss: >>> >>> 1.) the design assumes that there is a distinction between roles such as >>> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >>> master, CRL master, etc. Now in the hindsight I think this distinction >>> is quite artificial and just clutters the interface unnecessarily. We >>> might implement this kind of hierarchy in the code itself but that is >>> something the user needs not be aware of. >> >> These shouldn't be (sub-)roles at all - they are inherently a >> one-to-many relationship between the logical services and servers, >> whereas roles are many-to-many relationship between the logical services >> and servers. I would rather see them exposed in the global service >> config, such as: >> >> $ ipa dnsconfig-mod --sec-master=ipa12.example.com >> DNSSEC master: ipa12.example.com >> >>> >>> 2.) I guess the role names should be case insensitive so that users are >>> not hindered by trying to get the case right. >> >> +1 >> >>> >>> 3.) Do we need an internal API call which will add all services >>> belonging to a role to the corresponding master entry? (basically a >>> 'server_add_role' type of command). Currently, each service instance >>> adds its own service entry during service installation so we probably do >>> not need to duplicate this functionality. >> >> +1, we don't need more duplicate code. >> >>> >>> That is all I can think of right now. I had many more questions popping >>> up during this night's bout of insomnia, but they got lost during the >>> day. >> >> How are we going to expose the different states of server roles? They >> can be: >> >> a) available/unavailable (the package providing the role was/was not >> installed on the server) >> b) configured/unconfigured (the installer for the role was/was not >> successfully run on the server, LDAP service entries exist) >> c) enabled/disabled >> >> My preference would be to make server-role commands work on top of >> available services, like this: >> >> # ipa server-role-show $HOSTNAME DNS >> ipa: ERROR: DNS: server role not found >> >> # dnf install freeipa-server-dns >> ... >> >> # ipa server-role-show $HOSTNAME DNS >> Name: DNS >> Configured: False >> Enabled: False >> >> # ipa-dns-install >> ... >> >> # ipa server-role-show $HOSTNAME DNS >> Name: DNS >> Configured: True >> Enabled: True >> >>> >>> Do not be afraid to bring up other questions/remarks/comments. This is >>> my first design documents so I expect them to be plenty. >> >> The CLI commands are a little bit self-inconsistent, see any other >> plugin for how the general layout of arguments should look like. >> > > I have updated the design page[1] according to the comments gathered in this > thread and offline discussion with principal reviewer, e.g. Jan. > > Again comments are welcome. > > [1] http://www.freeipa.org/page/V4/Server_Roles Hi, I wonder if proposed service list->role and ipaConfigString value->server attribute mappings will work for DNSSEC key master. DNS server consist of named-pkcs11 and ipa-dnskeysyncd services. DNSSEC key master adds opendnssec and ipa-ods-exporter services. Can this be represented in the described model? I'm not sure. -- Petr^2 Spacek From pspacek at redhat.com Thu Apr 7 09:09:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 7 Apr 2016 11:09:50 +0200 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> Message-ID: <570623DE.7030709@redhat.com> On 7.4.2016 08:43, Fraser Tweedale wrote: > Hi team, > > I updated the Sub-CAs design page with more detail for the key > replication[1]. This part of the design is nearly complete (a large > patchset is in review over at pki-devel@) but there are various > options about how to authenticate to Custodia. > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > In brief, the options are: > > 1) authenticate as host principal; install binary setuid > root:pkiuser to read host keytab and custodia keys. Huh, I really do not like this. Host keytab on IPA master is one of the most sensitive keys we have. Maybe gssproxy can be used somehow, but I think it would be better to use separate key. > 2) authenticate as host principal; copy host keytab and custodia > keys to location readable by pkiuser. No, really, do not copy host keytab anywhere. > 3) create new principal for pkiuser to use, along with custodia keys > and keytab in location readable by pkiuser. > > I prefer option (1) for reasons outlined in the design page. The > design page goes into quite a bit more detail so please review the > section linked above and get back to me with your thoughts. The only downside of (3) using new keys is: ... This approach requires the creation of new principals, and Kerberos keytabs and Custodia keys for those principals, as part of the installation/upgrade process. Compared with additional SUID binary this seems as safer and easier way to go. FreeIPA installers already create quite a lot of principals and keytabs so this is well understood task. I would do (3). -- Petr^2 Spacek From cheimes at redhat.com Thu Apr 7 10:13:24 2016 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 7 Apr 2016 12:13:24 +0200 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <570623DE.7030709@redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> Message-ID: <570632C4.2010906@redhat.com> On 2016-04-07 11:09, Petr Spacek wrote: > On 7.4.2016 08:43, Fraser Tweedale wrote: >> Hi team, >> >> I updated the Sub-CAs design page with more detail for the key >> replication[1]. This part of the design is nearly complete (a large >> patchset is in review over at pki-devel@) but there are various >> options about how to authenticate to Custodia. >> >> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication >> >> In brief, the options are: >> >> 1) authenticate as host principal; install binary setuid >> root:pkiuser to read host keytab and custodia keys. > > Huh, I really do not like this. Host keytab on IPA master is one of the most > sensitive keys we have. > > Maybe gssproxy can be used somehow, but I think it would be better to use > separate key. > > >> 2) authenticate as host principal; copy host keytab and custodia >> keys to location readable by pkiuser. > > No, really, do not copy host keytab anywhere. > > >> 3) create new principal for pkiuser to use, along with custodia keys >> and keytab in location readable by pkiuser. >> >> I prefer option (1) for reasons outlined in the design page. The >> design page goes into quite a bit more detail so please review the >> section linked above and get back to me with your thoughts. > > The only downside of (3) using new keys is: > ... This approach requires the creation of new principals, and Kerberos > keytabs and Custodia keys for those principals, as part of the > installation/upgrade process. > > Compared with additional SUID binary this seems as safer and easier way to go. > FreeIPA installers already create quite a lot of principals and keytabs so > this is well understood task. > > I would do (3). +1 for (3) A SUID binary feels like a dangerous hack. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jcholast at redhat.com Thu Apr 7 10:29:00 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 7 Apr 2016 12:29:00 +0200 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <570632C4.2010906@redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> Message-ID: <5706366C.4020109@redhat.com> On 7.4.2016 12:13, Christian Heimes wrote: > On 2016-04-07 11:09, Petr Spacek wrote: >> On 7.4.2016 08:43, Fraser Tweedale wrote: >>> Hi team, >>> >>> I updated the Sub-CAs design page with more detail for the key >>> replication[1]. This part of the design is nearly complete (a large >>> patchset is in review over at pki-devel@) but there are various >>> options about how to authenticate to Custodia. >>> >>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication >>> >>> In brief, the options are: >>> >>> 1) authenticate as host principal; install binary setuid >>> root:pkiuser to read host keytab and custodia keys. >> >> Huh, I really do not like this. Host keytab on IPA master is one of the most >> sensitive keys we have. >> >> Maybe gssproxy can be used somehow, but I think it would be better to use >> separate key. >> >> >>> 2) authenticate as host principal; copy host keytab and custodia >>> keys to location readable by pkiuser. >> >> No, really, do not copy host keytab anywhere. >> >> >>> 3) create new principal for pkiuser to use, along with custodia keys >>> and keytab in location readable by pkiuser. >>> >>> I prefer option (1) for reasons outlined in the design page. The >>> design page goes into quite a bit more detail so please review the >>> section linked above and get back to me with your thoughts. >> >> The only downside of (3) using new keys is: >> ... This approach requires the creation of new principals, and Kerberos >> keytabs and Custodia keys for those principals, as part of the >> installation/upgrade process. >> >> Compared with additional SUID binary this seems as safer and easier way to go. >> FreeIPA installers already create quite a lot of principals and keytabs so >> this is well understood task. >> >> I would do (3). > > +1 for (3) > > A SUID binary feels like a dangerous hack. +1 -- Jan Cholasta From ofayans at redhat.com Thu Apr 7 10:35:23 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 7 Apr 2016 12:35:23 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade Message-ID: <570637EB.2000705@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch Type: text/x-patch Size: 2497 bytes Desc: not available URL: From sbose at redhat.com Thu Apr 7 11:53:02 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 7 Apr 2016 13:53:02 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides In-Reply-To: <570279B6.1070504@redhat.com> References: <56FE8B5F.8040803@redhat.com> <570279B6.1070504@redhat.com> Message-ID: <20160407115302.GL4768@p.redhat.com> On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote: > Hi, > > On 1.4.2016 16:53, Tomas Babej wrote: > >Hi, > > > >this extends the user ID overrides with capability to store the user > >certificate. > > > >https://fedorahosted.org/freeipa/ticket/4955 > > The preferred way of managing certificates nowadays is using $OBJ-add-cert > and $OBJ-remove-cert commands, you should add them here as well. > > I would even go as far as not allowing to modify certificates using > idoverrideuser-mod - in user-mod and host-mod, it's there just for backward > compatibility, which is not the case here. But I don't have a strong opinion > on that. > > For consistency with user-find and host-find, the full certificate blob > should not be shown in idoverrideuser-find. You can do that by setting > search_display_attributes attribute on the idoverrideuser class > appropriately. I tested the current patch with my related patches for SSSD and all is working as expected. bye, Sumit > > 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 ssorce at redhat.com Thu Apr 7 12:29:23 2016 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 07 Apr 2016 08:29:23 -0400 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> Message-ID: <1460032163.7463.143.camel@redhat.com> On Thu, 2016-04-07 at 16:43 +1000, Fraser Tweedale wrote: > Hi team, > > I updated the Sub-CAs design page with more detail for the key > replication[1]. This part of the design is nearly complete (a large > patchset is in review over at pki-devel@) but there are various > options about how to authenticate to Custodia. > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > In brief, the options are: > > 1) authenticate as host principal; install binary setuid > root:pkiuser to read host keytab and custodia keys. > > 2) authenticate as host principal; copy host keytab and custodia > keys to location readable by pkiuser. > > 3) create new principal for pkiuser to use, along with custodia keys > and keytab in location readable by pkiuser. > > I prefer option (1) for reasons outlined in the design page. The > design page goes into quite a bit more detail so please review the > section linked above and get back to me with your thoughts. I haven't read the whole design completely yet (sorry, busy with some critical bug), only the Key Replication part. We are moving toward removing access to the HTTP key from even the IPA framework, and I would definitely not want to give access to the host keytab to unprivileged processes. So I lean very heavily on (3). Simo. From ftweedal at redhat.com Thu Apr 7 13:20:16 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 7 Apr 2016 23:20:16 +1000 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <5706366C.4020109@redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> <5706366C.4020109@redhat.com> Message-ID: <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > On 7.4.2016 12:13, Christian Heimes wrote: > >On 2016-04-07 11:09, Petr Spacek wrote: > >>On 7.4.2016 08:43, Fraser Tweedale wrote: > >>>Hi team, > >>> > >>>I updated the Sub-CAs design page with more detail for the key > >>>replication[1]. This part of the design is nearly complete (a large > >>>patchset is in review over at pki-devel@) but there are various > >>>options about how to authenticate to Custodia. > >>> > >>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > >>> > >>>In brief, the options are: > >>> > >>>1) authenticate as host principal; install binary setuid > >>> root:pkiuser to read host keytab and custodia keys. > >> > >>Huh, I really do not like this. Host keytab on IPA master is one of the most > >>sensitive keys we have. > >> > >>Maybe gssproxy can be used somehow, but I think it would be better to use > >>separate key. > >> > >> > >>>2) authenticate as host principal; copy host keytab and custodia > >>> keys to location readable by pkiuser. > >> > >>No, really, do not copy host keytab anywhere. > >> > >> > >>>3) create new principal for pkiuser to use, along with custodia keys > >>> and keytab in location readable by pkiuser. > >>> > >>>I prefer option (1) for reasons outlined in the design page. The > >>>design page goes into quite a bit more detail so please review the > >>>section linked above and get back to me with your thoughts. > >> > >>The only downside of (3) using new keys is: > >>... This approach requires the creation of new principals, and Kerberos > >>keytabs and Custodia keys for those principals, as part of the > >>installation/upgrade process. > >> > >>Compared with additional SUID binary this seems as safer and easier way to go. > >>FreeIPA installers already create quite a lot of principals and keytabs so > >>this is well understood task. > >> > >>I would do (3). > > > >+1 for (3) > > > >A SUID binary feels like a dangerous hack. > > +1 > OK, (3) it is. Thanks all for your input. Now for next question: what should service principal name be? I think `dogtag/example.com at EXAMPLE.COM' but am open to other suggestions, e.g. `pki/...'. Cheers, Fraser From pspacek at redhat.com Thu Apr 7 14:17:58 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 7 Apr 2016 16:17:58 +0200 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> <5706366C.4020109@redhat.com> <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> Message-ID: <57066C16.2000508@redhat.com> On 7.4.2016 15:20, Fraser Tweedale wrote: > On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: >> On 7.4.2016 12:13, Christian Heimes wrote: >>> On 2016-04-07 11:09, Petr Spacek wrote: >>>> On 7.4.2016 08:43, Fraser Tweedale wrote: >>>>> Hi team, >>>>> >>>>> I updated the Sub-CAs design page with more detail for the key >>>>> replication[1]. This part of the design is nearly complete (a large >>>>> patchset is in review over at pki-devel@) but there are various >>>>> options about how to authenticate to Custodia. >>>>> >>>>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication >>>>> >>>>> In brief, the options are: >>>>> >>>>> 1) authenticate as host principal; install binary setuid >>>>> root:pkiuser to read host keytab and custodia keys. >>>> >>>> Huh, I really do not like this. Host keytab on IPA master is one of the most >>>> sensitive keys we have. >>>> >>>> Maybe gssproxy can be used somehow, but I think it would be better to use >>>> separate key. >>>> >>>> >>>>> 2) authenticate as host principal; copy host keytab and custodia >>>>> keys to location readable by pkiuser. >>>> >>>> No, really, do not copy host keytab anywhere. >>>> >>>> >>>>> 3) create new principal for pkiuser to use, along with custodia keys >>>>> and keytab in location readable by pkiuser. >>>>> >>>>> I prefer option (1) for reasons outlined in the design page. The >>>>> design page goes into quite a bit more detail so please review the >>>>> section linked above and get back to me with your thoughts. >>>> >>>> The only downside of (3) using new keys is: >>>> ... This approach requires the creation of new principals, and Kerberos >>>> keytabs and Custodia keys for those principals, as part of the >>>> installation/upgrade process. >>>> >>>> Compared with additional SUID binary this seems as safer and easier way to go. >>>> FreeIPA installers already create quite a lot of principals and keytabs so >>>> this is well understood task. >>>> >>>> I would do (3). >>> >>> +1 for (3) >>> >>> A SUID binary feels like a dangerous hack. >> >> +1 >> > OK, (3) it is. Thanks all for your input. > > Now for next question: what should service principal name be? I > think `dogtag/example.com at EXAMPLE.COM' but am open to other > suggestions, e.g. `pki/...'. Do you plan to attempt to standardize this name in future? I do not expect that. Considering private nature of it, it should be as specific as possible to avoid any potential conflicts with future standards. "dogtag-key-replication" sounds like a good candidate. Before you set the name in stone make sure it does not conflict with anything listed on http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml These names have potential to be used by someone else. -- Petr^2 Spacek From mrniranjan at fedoraproject.org Thu Apr 7 20:12:56 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Fri, 8 Apr 2016 01:42:56 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5704F243.5000006@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> Message-ID: <20160407201256.GA6097@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/06/2016 10:55 AM, Niranjan wrote: > > Greetings, > > > > For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > > a patch, I think this patch is more of a workaround , than a solution. I would > > like to get more inputs on how to use pytest-multihost to execute commands > > on Windows. The method i am using requires cygwin with openssh/bash to be > > installed. > > Wow. I'm surprised the only problem on Windows is the "set -e". > > Regarding the patch: > > - Why is get_winhost_class needed? I don't see it called anywhere. > - Similarly, why is host_type needed? Your patch only sets it. > > If run_command of WinHost and Unix hosts are this similar, I would put > the 'set -e\n' for Unix (and an empty string for Windows) in a class > attribute named e.g. "command_prelude", use it in run_command, and move > run_command from Host to BaseHost. > Would that work, or am I missing something? yes, that would work. But there are few more suggestions, right now test_dir is global and for windows test_dir should be set to ~/$ssh_username/username. So can that also be set ? > > > -- > Petr Viktorin Regards, yiranjan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From placko at redhat.com Fri Apr 8 08:32:25 2016 From: placko at redhat.com (Peter Lacko) Date: Fri, 8 Apr 2016 04:32:25 -0400 (EDT) Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <410669479.43082778.1460104223399.JavaMail.zimbra@redhat.com> Message-ID: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> A non-text attachment was scrubbed... Name: freeipa-placko-0001-Ping-module-tests.patch Type: text/x-patch Size: 2982 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 8 11:13:57 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 8 Apr 2016 13:13:57 +0200 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160407201256.GA6097@mniranja.pnq.csb> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160407201256.GA6097@mniranja.pnq.csb> Message-ID: <57079275.5070108@redhat.com> On 04/07/2016 10:12 PM, Niranjan wrote: > Petr Viktorin wrote: >> On 04/06/2016 10:55 AM, Niranjan wrote: >>> Greetings, >>> >>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed >>> a patch, I think this patch is more of a workaround , than a solution. I would >>> like to get more inputs on how to use pytest-multihost to execute commands >>> on Windows. The method i am using requires cygwin with openssh/bash to be >>> installed. >> >> Wow. I'm surprised the only problem on Windows is the "set -e". >> >> Regarding the patch: >> >> - Why is get_winhost_class needed? I don't see it called anywhere. >> - Similarly, why is host_type needed? Your patch only sets it. >> >> If run_command of WinHost and Unix hosts are this similar, I would put >> the 'set -e\n' for Unix (and an empty string for Windows) in a class >> attribute named e.g. "command_prelude", use it in run_command, and move >> run_command from Host to BaseHost. >> Would that work, or am I missing something? > yes, that would work. OK. Can you write a patch? > But there are few more suggestions, right now > test_dir is global and for windows test_dir should be set to > ~/$ssh_username/username. So can that also be set ? Yes. Add a configuration option to Host (in __init__, from_dict and to_dict), and take the global default if not used. Then you can let Windows hosts default to either a hard-coded path, or to a new global config option like "windows_test_dir". -- Petr Viktorin From ftweedal at redhat.com Fri Apr 8 14:23:39 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 9 Apr 2016 00:23:39 +1000 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals Message-ID: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> Hi all, The attached patch (first of many for long-awaited sub-CAs feature) makes it possible to use CustodiaClient without root privileges, as an arbitrary principal. Cheers, Fraser -------------- next part -------------- From 8e6cab0e47dd4e3152d8bbd84c8675353aa2cb4a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 8 Apr 2016 15:21:19 +1000 Subject: [PATCH] Allow CustodiaClient to be used by arbitrary principals Currently CustodiaClient assumes that the client is the host principal, and it is hard-coded to read the host keytab and server keys. For the Lightweight CAs feature, Dogtag on CA replicas will use CustodiaClient to retrieve signing keys from the originating replica. Because this process runs as 'pkiuser', the host keys cannot be used; instead, each Dogtag replica will have a service principal to use for Custodia authentication. Update CustodiaClient to allow specifying the keytab and Custodia keyfile to use. Avoid hard-coding the GSS-API name; use the name read from the keytab during credential acquisition. Also add an ACI to allow authenticated users to read and search for Custodia server public keys. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- install/updates/20-aci.update | 3 +++ ipapython/secrets/client.py | 17 +++++++++-------- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index 4802ae0458e8b870bf3127764ebabac1a48f7cf2..16e3b7ab9d6cdcc1de0490f42447a17f8b769524 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -136,3 +136,6 @@ add:aci: (target = "ldap:///cn=replication,cn=etc,$SUFFIX")(targetattr = "nsDS5R dn: cn=ipa,cn=etc,$SUFFIX add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia secrets"; allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) + +# Anyone can search Custodia public keys +add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal")(version 3.0; acl "Anyone can search Custodia public keys"; allow(read, search, compare) userdn = "ldap:///all";) diff --git a/ipapython/secrets/client.py b/ipapython/secrets/client.py index 5b671988ddc66eedd9ae1cd4ddec0e1308bc5a93..33172e58095fcfd2469c0ea5ea597fd1a01c2907 100644 --- a/ipapython/secrets/client.py +++ b/ipapython/secrets/client.py @@ -41,16 +41,19 @@ class CustodiaClient(object): return iSecStore(config) - def __init__(self, client, server, realm, ldap_uri=None, auth_type=None): + def __init__(self, client, server, realm, ldap_uri=None, auth_type=None, + keyfile=None, keytab=None): self.client = client - self.creds = None + self.keytab = keytab or paths.KRB5_KEYTAB + self.creds = self.init_creds() self.service_name = gssapi.Name('HTTP@%s' % (server,), gssapi.NameType.hostbased_service) self.server = server - keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys') - self.ikk = IPAKEMKeys({'server_keys': keyfile}) + if keyfile is None: + keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys') + self.ikk = IPAKEMKeys({'server_keys': keyfile, 'ldap_uri': ldap_uri}) self.kemcli = KEMClient(self._server_keys(server, realm), self._client_keys()) @@ -61,11 +64,9 @@ class CustodiaClient(object): requests.packages.urllib3.disable_warnings() def init_creds(self): - name = gssapi.Name('host@%s' % (self.client,), - gssapi.NameType.hostbased_service) - store = {'client_keytab': paths.KRB5_KEYTAB, + store = {'client_keytab': self.keytab, 'ccache': 'MEMORY:Custodia_%s' % b64encode(os.urandom(8))} - return gssapi.Credentials(name=name, store=store, usage='initiate') + return gssapi.Credentials(store=store, usage='initiate') def _auth_header(self): if not self.creds or self.creds.lifetime < 300: -- 2.5.5 From ofayans at redhat.com Fri Apr 8 14:46:09 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 8 Apr 2016 16:46:09 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <567176A2.1000901@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> Message-ID: <5707C431.6070702@redhat.com> Hi all, It's been a while, and now the patch seems to be stable. It does hit one known issue with replica installation occationally [1], but other than that works fine on both domain levels. [1] https://fedorahosted.org/freeipa/ticket/5758 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0013.1-Updated-the-script-creating-test-certificate-chains.patch Type: text/x-patch Size: 2642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0014.3-Actualized-ca-less-tests.patch Type: text/x-patch Size: 44985 bytes Desc: not available URL: From ssorce at redhat.com Fri Apr 8 14:47:19 2016 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Apr 2016 10:47:19 -0400 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> Message-ID: <1460126839.7463.195.camel@redhat.com> On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: > - name = gssapi.Name('host@%s' % (self.client,), > > - gssapi.NameType.hostbased_service) If you remove this then on a serve that has nfs keys in the keytab you may end up acquiring the wrong credentials. You need to pass down what credentials you want to use to initialize the cred store, we canot rely on ordering in the system keytab case. Simo. From mbabinsk at redhat.com Fri Apr 8 15:10:42 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 8 Apr 2016 17:10:42 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling Message-ID: <5707C9F2.8060903@redhat.com> Hi list, I have put together a draft [1] outlining the effort to reimplement the handling of Kerberos principals in both backend and frontend layers of FreeIPA so that we may have multiple aliases per user, host or service and thus implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and https://fedorahosted.org/freeipa/ticket/5413 . Since much of the plumbing was already implemented,[2] the document mainly describes what the patches do. Some parts required by other use cases may be missing so please point these out. I would also be happy if you could correct all factual inacurracies, I did research on this issue a long time ago and my knowledge turned a bit rusty. [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Apr 8 15:13:43 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 8 Apr 2016 17:13:43 +0200 Subject: [Freeipa-devel] [PATCH 0143-0144] different errors/warnings for different LDAP limit type exceeded In-Reply-To: <56FE95B0.90501@redhat.com> References: <56EBCA37.6020306@redhat.com> <56EBF959.3060807@redhat.com> <56EFBC2C.8030300@redhat.com> <56EFDA20.9090005@redhat.com> <56F1608A.4060805@redhat.com> <56F16481.9070304@redhat.com> <56F40464.7000804@redhat.com> <56FE95B0.90501@redhat.com> Message-ID: <5707CAA7.6060602@redhat.com> On 04/01/2016 05:37 PM, Martin Babinsky wrote: > On 03/24/2016 04:14 PM, Martin Babinsky wrote: >> On 03/22/2016 04:28 PM, Rob Crittenden wrote: >>> Martin Babinsky wrote: >>>> On 03/21/2016 12:25 PM, Jan Cholasta wrote: >>>>> On 21.3.2016 10:17, Petr Spacek wrote: >>>>>> On 18.3.2016 13:49, Rob Crittenden wrote: >>>>>>> Martin Babinsky wrote: >>>>>>>> These patches implement behavior agreed upon during discussion of >>>>>>>> https://fedorahosted.org/freeipa/ticket/5677 >>>>>>>> >>>>>>>> However I'm not sure if we want to push them into 4-3 branch (the >>>>>>>> ticket >>>>>>>> is triaged into 4.3.2 milestone) since they modify the framework >>>>>>>> behavior quite a bit. >>>>>>>> >>>>>>>> If there is no need to have it there (CC'ing Milan since he is the >>>>>>>> reporter), I would retriage it into 4.4 milestone. >>>>>>> >>>>>>> >>>>>>> + desc="while getting entries (search base: '{}'," >>>>>>> + "filter: {})".format(base_dn, filter)) >>>>>>> >>>>>>> This is going to expose parts of the DIT in an error message to >>>>>>> users. We have >>>>>>> tried in the past to hide the implementation. I'd propose logging >>>>>>> the >>>>>>> error >>>>>>> and making the exception less verbose. >>>>> >>>>> I agree with Rob here, we shouldn't expose internal stuff in error >>>>> messages for users. >>>>> >>>>> In this particular case, even if we included internal stuff in the >>>>> error >>>>> message, it should be the error message returned by the server rather >>>>> than this ad-hoc message. >>>>> >>>>>> >>>>>> IMHO it actually helps to print the DN. At very least the user can >>>>>> see >>>>>> if the >>>>>> error is happening always with the same DN or if it keeps changing. >>>>>> >>>>>> In other words, for user it is not that important to understand >>>>>> meaning of the >>>>>> DN but it might be important to see if it is the same or not. >>>>> >>>>> I can't imagine a situation where it would actually be useful for the >>>>> user (as opposed to the admin, who has access to logs) to know the >>>>> base >>>>> DN of some arbitrary LDAP search operation. Could you give an example? >>>>> >>>> Right, attaching updated patches. >>> >>> I may have suggested debug logging the detailed error. I was wrong. This >>> should log at the error level so it always appears in the logs. This may >>> be a spurious error and having the user turn on debug logging to capture >>> the reasons would be asking a lot. >>> >>> rob >> That's right, the user would then have to enable debug mode and re-run >> the command. I have changed the log level to error as you suggested. >> >> >> > Bump for review. > Moar bumps. -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Apr 8 15:26:20 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 8 Apr 2016 17:26:20 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <57061A16.5000904@redhat.com> References: <56EAE651.4040603@redhat.com> <56EFB09F.9010200@redhat.com> <57051F25.5090307@redhat.com> <57061A16.5000904@redhat.com> Message-ID: <5707CD9C.3000102@redhat.com> On 04/07/2016 10:28 AM, Petr Spacek wrote: > On 6.4.2016 16:37, Martin Babinsky wrote: >> On 03/21/2016 09:28 AM, Jan Cholasta wrote: >>> On 17.3.2016 18:16, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >>>> design document concerning the concept of Server Roles as a >>>> user-friendly abstraction of the services running on IPA masters. >>>> >>>> The main aim of this feature is to provide a higher level interface to >>>> query and manipulate service-related information stored in dirsrv >>>> backend. >>>> >>>> I have not touched the design much from the post-Devconf session, mainly >>>> because there are some points to clarify and agree upon. >>>> >>>> I have the following points to discuss: >>>> >>>> 1.) the design assumes that there is a distinction between roles such as >>>> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >>>> master, CRL master, etc. Now in the hindsight I think this distinction >>>> is quite artificial and just clutters the interface unnecessarily. We >>>> might implement this kind of hierarchy in the code itself but that is >>>> something the user needs not be aware of. >>> >>> These shouldn't be (sub-)roles at all - they are inherently a >>> one-to-many relationship between the logical services and servers, >>> whereas roles are many-to-many relationship between the logical services >>> and servers. I would rather see them exposed in the global service >>> config, such as: >>> >>> $ ipa dnsconfig-mod --sec-master=ipa12.example.com >>> DNSSEC master: ipa12.example.com >>> >>>> >>>> 2.) I guess the role names should be case insensitive so that users are >>>> not hindered by trying to get the case right. >>> >>> +1 >>> >>>> >>>> 3.) Do we need an internal API call which will add all services >>>> belonging to a role to the corresponding master entry? (basically a >>>> 'server_add_role' type of command). Currently, each service instance >>>> adds its own service entry during service installation so we probably do >>>> not need to duplicate this functionality. >>> >>> +1, we don't need more duplicate code. >>> >>>> >>>> That is all I can think of right now. I had many more questions popping >>>> up during this night's bout of insomnia, but they got lost during the >>>> day. >>> >>> How are we going to expose the different states of server roles? They >>> can be: >>> >>> a) available/unavailable (the package providing the role was/was not >>> installed on the server) >>> b) configured/unconfigured (the installer for the role was/was not >>> successfully run on the server, LDAP service entries exist) >>> c) enabled/disabled >>> >>> My preference would be to make server-role commands work on top of >>> available services, like this: >>> >>> # ipa server-role-show $HOSTNAME DNS >>> ipa: ERROR: DNS: server role not found >>> >>> # dnf install freeipa-server-dns >>> ... >>> >>> # ipa server-role-show $HOSTNAME DNS >>> Name: DNS >>> Configured: False >>> Enabled: False >>> >>> # ipa-dns-install >>> ... >>> >>> # ipa server-role-show $HOSTNAME DNS >>> Name: DNS >>> Configured: True >>> Enabled: True >>> >>>> >>>> Do not be afraid to bring up other questions/remarks/comments. This is >>>> my first design documents so I expect them to be plenty. >>> >>> The CLI commands are a little bit self-inconsistent, see any other >>> plugin for how the general layout of arguments should look like. >>> >> >> I have updated the design page[1] according to the comments gathered in this >> thread and offline discussion with principal reviewer, e.g. Jan. >> >> Again comments are welcome. >> >> [1] http://www.freeipa.org/page/V4/Server_Roles > > Hi, > > I wonder if proposed service list->role and ipaConfigString value->server > attribute mappings will work for DNSSEC key master. > > DNS server consist of named-pkcs11 and ipa-dnskeysyncd services. > DNSSEC key master adds opendnssec and ipa-ods-exporter services. > > Can this be represented in the described model? I'm not sure. > Yes that is something I was not quite sure about whether DNSSec master is more defined by the presence of ipaConfigString or by presence of relevant service entries. We can do both approaches since the mapping between roles/attributes and service entries has to be quite flexible anyway. -- Martin^3 Babinsky From ftweedal at redhat.com Sat Apr 9 00:11:00 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sat, 9 Apr 2016 10:11:00 +1000 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <1460126839.7463.195.camel@redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> Message-ID: <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: > > - name = gssapi.Name('host@%s' % (self.client,), > > > > - gssapi.NameType.hostbased_service) > > If you remove this then on a serve that has nfs keys in the keytab you > may end up acquiring the wrong credentials. > You need to pass down what credentials you want to use to initialize the > cred store, we canot rely on ordering in the system keytab case. > > Simo. > Thanks Simo; updated patch attached. -------------- next part -------------- From cfa2d1d95508c5ea9bb9bf59df6ae0c165f8fbde Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 8 Apr 2016 15:21:19 +1000 Subject: [PATCH] Allow CustodiaClient to be used by arbitrary principals Currently CustodiaClient assumes that the client is the host principal, and it is hard-coded to read the host keytab and server keys. For the Lightweight CAs feature, Dogtag on CA replicas will use CustodiaClient to retrieve signing keys from the originating replica. Because this process runs as 'pkiuser', the host keys cannot be used; instead, each Dogtag replica will have a service principal to use for Custodia authentication. Update CustodiaClient to allow specifying the keytab and Custodia keyfile to use. Avoid hard-coding the service name to find in the keytab. Also add an ACI to allow authenticated users to read and search for Custodia server public keys. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- install/updates/20-aci.update | 3 +++ ipapython/secrets/client.py | 17 ++++++++++------- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index 4802ae0458e8b870bf3127764ebabac1a48f7cf2..16e3b7ab9d6cdcc1de0490f42447a17f8b769524 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -136,3 +136,6 @@ add:aci: (target = "ldap:///cn=replication,cn=etc,$SUFFIX")(targetattr = "nsDS5R dn: cn=ipa,cn=etc,$SUFFIX add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia secrets"; allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) + +# Anyone can search Custodia public keys +add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal")(version 3.0; acl "Anyone can search Custodia public keys"; allow(read, search, compare) userdn = "ldap:///all";) diff --git a/ipapython/secrets/client.py b/ipapython/secrets/client.py index 5b671988ddc66eedd9ae1cd4ddec0e1308bc5a93..a15057ae67c377a782db3642d14384e0bf11b5a2 100644 --- a/ipapython/secrets/client.py +++ b/ipapython/secrets/client.py @@ -41,16 +41,19 @@ class CustodiaClient(object): return iSecStore(config) - def __init__(self, client, server, realm, ldap_uri=None, auth_type=None): - self.client = client - self.creds = None + def __init__(self, client, server, realm, ldap_uri=None, auth_type=None, + client_servicename='host', keyfile=None, keytab=None): + self.client_service = '%s@%s' % (client_servicename, client) + self.keytab = keytab or paths.KRB5_KEYTAB + self.creds = self.init_creds() self.service_name = gssapi.Name('HTTP@%s' % (server,), gssapi.NameType.hostbased_service) self.server = server - keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys') - self.ikk = IPAKEMKeys({'server_keys': keyfile}) + if keyfile is None: + keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys') + self.ikk = IPAKEMKeys({'server_keys': keyfile, 'ldap_uri': ldap_uri}) self.kemcli = KEMClient(self._server_keys(server, realm), self._client_keys()) @@ -61,9 +64,9 @@ class CustodiaClient(object): requests.packages.urllib3.disable_warnings() def init_creds(self): - name = gssapi.Name('host@%s' % (self.client,), + name = gssapi.Name(self.client_service, gssapi.NameType.hostbased_service) - store = {'client_keytab': paths.KRB5_KEYTAB, + store = {'client_keytab': self.keytab, 'ccache': 'MEMORY:Custodia_%s' % b64encode(os.urandom(8))} return gssapi.Credentials(name=name, store=store, usage='initiate') -- 2.5.5 From mrniranjan at fedoraproject.org Sat Apr 9 01:41:10 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Sat, 9 Apr 2016 07:11:10 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <57079275.5070108@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160407201256.GA6097@mniranja.pnq.csb> <57079275.5070108@redhat.com> Message-ID: <20160409014110.GA6126@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/07/2016 10:12 PM, Niranjan wrote: > > Petr Viktorin wrote: > >> On 04/06/2016 10:55 AM, Niranjan wrote: > >>> Greetings, > >>> > >>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>> a patch, I think this patch is more of a workaround , than a solution. I would > >>> like to get more inputs on how to use pytest-multihost to execute commands > >>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>> installed. > >> > >> Wow. I'm surprised the only problem on Windows is the "set -e". > >> > >> Regarding the patch: > >> > >> - Why is get_winhost_class needed? I don't see it called anywhere. > >> - Similarly, why is host_type needed? Your patch only sets it. > >> > >> If run_command of WinHost and Unix hosts are this similar, I would put > >> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >> attribute named e.g. "command_prelude", use it in run_command, and move > >> run_command from Host to BaseHost. > >> Would that work, or am I missing something? > > yes, that would work. > > OK. Can you write a patch? yes, i will come up with a patch, > > > But there are few more suggestions, right now > > test_dir is global and for windows test_dir should be set to > > ~/$ssh_username/username. So can that also be set ? > > Yes. Add a configuration option to Host (in __init__, from_dict and > to_dict), and take the global default if not used. > > Then you can let Windows hosts default to either a hard-coded path, or > to a new global config option like "windows_test_dir". Okay , thanks for this input. > > > -- > Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From pvomacka at redhat.com Mon Apr 11 07:36:51 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Mon, 11 Apr 2016 09:36:51 +0200 Subject: [Freeipa-devel] [PATCH] 0012 webui: Add 'Activate' option to actions menu on stage user detail page Message-ID: <570B5413.40006@redhat.com> Hello, this patch adds 'Activate' option to actions menu on stage user detail page. Ticket: https://fedorahosted.org/freeipa/ticket/5369 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0012-Add-activate-option-to-stage-user-details-page.patch Type: text/x-patch Size: 4203 bytes Desc: not available URL: From pspacek at redhat.com Mon Apr 11 09:05:24 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 11 Apr 2016 11:05:24 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <5707C9F2.8060903@redhat.com> References: <5707C9F2.8060903@redhat.com> Message-ID: <570B68D4.9000905@redhat.com> On 8.4.2016 17:10, Martin Babinsky wrote: > Hi list, > > I have put together a draft [1] outlining the effort to reimplement the > handling of Kerberos principals in both backend and frontend layers of FreeIPA > so that we may have multiple aliases per user, host or service and thus > implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and > https://fedorahosted.org/freeipa/ticket/5413 . > > Since much of the plumbing was already implemented,[2] the document mainly > describes what the patches do. Some parts required by other use cases may be > missing so please point these out. > > I would also be happy if you could correct all factual inacurracies, I did > research on this issue a long time ago and my knowledge turned a bit rusty. > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html I cannot say much about the implementation, but I would appreciate following information: CLI === 1) {user,host,service}-add operate with canonical name, right? This could be made clear so normal user understands the text. 2) Is it possible to change the canonical name? 3) Can Web UI work with aliases without --principal-alias parameter? Upgrade ======= > The backward compatibility with older machines will be kept while the new attributes will be replicated to older master when new host/service/entries will be created on new ones. No special upgrade procedure shall be necessary. It would be good to explicitly mention that old attributes will be still populated => old and new replicas can work in the same topology. Other than that it seems reasonable. -- Petr^2 Spacek From pspacek at redhat.com Mon Apr 11 09:06:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 11 Apr 2016 11:06:02 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <5707CD9C.3000102@redhat.com> References: <56EAE651.4040603@redhat.com> <56EFB09F.9010200@redhat.com> <57051F25.5090307@redhat.com> <57061A16.5000904@redhat.com> <5707CD9C.3000102@redhat.com> Message-ID: <570B68FA.8020608@redhat.com> On 8.4.2016 17:26, Martin Babinsky wrote: > On 04/07/2016 10:28 AM, Petr Spacek wrote: >> On 6.4.2016 16:37, Martin Babinsky wrote: >>> On 03/21/2016 09:28 AM, Jan Cholasta wrote: >>>> On 17.3.2016 18:16, Martin Babinsky wrote: >>>>> Hi list, >>>>> >>>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >>>>> design document concerning the concept of Server Roles as a >>>>> user-friendly abstraction of the services running on IPA masters. >>>>> >>>>> The main aim of this feature is to provide a higher level interface to >>>>> query and manipulate service-related information stored in dirsrv >>>>> backend. >>>>> >>>>> I have not touched the design much from the post-Devconf session, mainly >>>>> because there are some points to clarify and agree upon. >>>>> >>>>> I have the following points to discuss: >>>>> >>>>> 1.) the design assumes that there is a distinction between roles such as >>>>> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >>>>> master, CRL master, etc. Now in the hindsight I think this distinction >>>>> is quite artificial and just clutters the interface unnecessarily. We >>>>> might implement this kind of hierarchy in the code itself but that is >>>>> something the user needs not be aware of. >>>> >>>> These shouldn't be (sub-)roles at all - they are inherently a >>>> one-to-many relationship between the logical services and servers, >>>> whereas roles are many-to-many relationship between the logical services >>>> and servers. I would rather see them exposed in the global service >>>> config, such as: >>>> >>>> $ ipa dnsconfig-mod --sec-master=ipa12.example.com >>>> DNSSEC master: ipa12.example.com >>>> >>>>> >>>>> 2.) I guess the role names should be case insensitive so that users are >>>>> not hindered by trying to get the case right. >>>> >>>> +1 >>>> >>>>> >>>>> 3.) Do we need an internal API call which will add all services >>>>> belonging to a role to the corresponding master entry? (basically a >>>>> 'server_add_role' type of command). Currently, each service instance >>>>> adds its own service entry during service installation so we probably do >>>>> not need to duplicate this functionality. >>>> >>>> +1, we don't need more duplicate code. >>>> >>>>> >>>>> That is all I can think of right now. I had many more questions popping >>>>> up during this night's bout of insomnia, but they got lost during the >>>>> day. >>>> >>>> How are we going to expose the different states of server roles? They >>>> can be: >>>> >>>> a) available/unavailable (the package providing the role was/was not >>>> installed on the server) >>>> b) configured/unconfigured (the installer for the role was/was not >>>> successfully run on the server, LDAP service entries exist) >>>> c) enabled/disabled >>>> >>>> My preference would be to make server-role commands work on top of >>>> available services, like this: >>>> >>>> # ipa server-role-show $HOSTNAME DNS >>>> ipa: ERROR: DNS: server role not found >>>> >>>> # dnf install freeipa-server-dns >>>> ... >>>> >>>> # ipa server-role-show $HOSTNAME DNS >>>> Name: DNS >>>> Configured: False >>>> Enabled: False >>>> >>>> # ipa-dns-install >>>> ... >>>> >>>> # ipa server-role-show $HOSTNAME DNS >>>> Name: DNS >>>> Configured: True >>>> Enabled: True >>>> >>>>> >>>>> Do not be afraid to bring up other questions/remarks/comments. This is >>>>> my first design documents so I expect them to be plenty. >>>> >>>> The CLI commands are a little bit self-inconsistent, see any other >>>> plugin for how the general layout of arguments should look like. >>>> >>> >>> I have updated the design page[1] according to the comments gathered in this >>> thread and offline discussion with principal reviewer, e.g. Jan. >>> >>> Again comments are welcome. >>> >>> [1] http://www.freeipa.org/page/V4/Server_Roles >> >> Hi, >> >> I wonder if proposed service list->role and ipaConfigString value->server >> attribute mappings will work for DNSSEC key master. >> >> DNS server consist of named-pkcs11 and ipa-dnskeysyncd services. >> DNSSEC key master adds opendnssec and ipa-ods-exporter services. >> >> Can this be represented in the described model? I'm not sure. >> > Yes that is something I was not quite sure about whether DNSSec master is more > defined by the presence of ipaConfigString or by presence of relevant service > entries. > > We can do both approaches since the mapping between roles/attributes and > service entries has to be quite flexible anyway. This is up to you as long as we are able to represent it somehow :-) -- Petr^2 Spacek From mbabinsk at redhat.com Mon Apr 11 10:50:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 11 Apr 2016 12:50:36 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <570B68D4.9000905@redhat.com> References: <5707C9F2.8060903@redhat.com> <570B68D4.9000905@redhat.com> Message-ID: <570B817C.5080901@redhat.com> On 04/11/2016 11:05 AM, Petr Spacek wrote: > On 8.4.2016 17:10, Martin Babinsky wrote: >> Hi list, >> >> I have put together a draft [1] outlining the effort to reimplement the >> handling of Kerberos principals in both backend and frontend layers of FreeIPA >> so that we may have multiple aliases per user, host or service and thus >> implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and >> https://fedorahosted.org/freeipa/ticket/5413 . >> >> Since much of the plumbing was already implemented,[2] the document mainly >> describes what the patches do. Some parts required by other use cases may be >> missing so please point these out. >> >> I would also be happy if you could correct all factual inacurracies, I did >> research on this issue a long time ago and my knowledge turned a bit rusty. >> >> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >> [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > > I cannot say much about the implementation, but I would appreciate following > information: > > CLI > === > 1) {user,host,service}-add operate with canonical name, right? This could be > made clear so normal user understands the text. > The *-add commands operate on both, they will set krbCanonicalName attribute and copy the same value to the krbPrincipalName. I will update the design to made this clear. > 2) Is it possible to change the canonical name? For users the canonical name will be changed during 'rename' operation, since the principal is generated from the primary key. I'm not sure about hosts/services since their primary keys are currently immutable. If we make them mutable, then the behavior shall be consistent with the user entries. > > 3) Can Web UI work with aliases without --principal-alias parameter? > Probably not and we would require to add this options to users and services. Hosts already have '--principalname' option currently restricted to single value, we may change it to multi-valued and add it also to other two entities. > > Upgrade > ======= >> The backward compatibility with older machines will be kept while the new attributes will be replicated to older master when new host/service/entries will be created on new ones. No special upgrade procedure shall be necessary. > > It would be good to explicitly mention that old attributes will be still > populated => old and new replicas can work in the same topology. > Ok I will make this more clear. > > Other than that it seems reasonable. > Thank you for your comments. -- Martin^3 Babinsky From simo at redhat.com Mon Apr 11 14:17:18 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 11 Apr 2016 10:17:18 -0400 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <570B817C.5080901@redhat.com> References: <5707C9F2.8060903@redhat.com> <570B68D4.9000905@redhat.com> <570B817C.5080901@redhat.com> Message-ID: <1460384238.7463.238.camel@redhat.com> On Mon, 2016-04-11 at 12:50 +0200, Martin Babinsky wrote: > On 04/11/2016 11:05 AM, Petr Spacek wrote: > > On 8.4.2016 17:10, Martin Babinsky wrote: > >> Hi list, > >> > >> I have put together a draft [1] outlining the effort to reimplement the > >> handling of Kerberos principals in both backend and frontend layers of FreeIPA > >> so that we may have multiple aliases per user, host or service and thus > >> implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and > >> https://fedorahosted.org/freeipa/ticket/5413 . > >> > >> Since much of the plumbing was already implemented,[2] the document mainly > >> describes what the patches do. Some parts required by other use cases may be > >> missing so please point these out. > >> > >> I would also be happy if you could correct all factual inacurracies, I did > >> research on this issue a long time ago and my knowledge turned a bit rusty. > >> > >> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > >> [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > > > > I cannot say much about the implementation, but I would appreciate following > > information: > > > > CLI > > === > > 1) {user,host,service}-add operate with canonical name, right? This could be > > made clear so normal user understands the text. > > > The *-add commands operate on both, they will set krbCanonicalName > attribute and copy the same value to the krbPrincipalName. I will update > the design to made this clear. > > > 2) Is it possible to change the canonical name? > For users the canonical name will be changed during 'rename' operation, > since the principal is generated from the primary key. I'm not sure > about hosts/services since their primary keys are currently immutable. > > If we make them mutable, then the behavior shall be consistent with the > user entries. > > > > > 3) Can Web UI work with aliases without --principal-alias parameter? > > > Probably not and we would require to add this options to users and > services. Hosts already have '--principalname' option currently > restricted to single value, we may change it to multi-valued and add it > also to other two entities. > > > > > Upgrade > > ======= > >> The backward compatibility with older machines will be kept while the new attributes will be replicated to older master when new host/service/entries will be created on new ones. No special upgrade procedure shall be necessary. > > > > It would be good to explicitly mention that old attributes will be still > > populated => old and new replicas can work in the same topology. > > > Ok I will make this more clear. Old attributes should not be populated, we are abandoning them because they can't work, they will simply not be removed from the schema to avoid constraints violations, but they will rapidly be deprecated and not used anymore. We need to assess the impact on keeping older replicas running for long, with old framework and KDC code, but I do not think there will be issues in the general case. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Mon Apr 11 14:29:15 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 11 Apr 2016 16:29:15 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <5707C9F2.8060903@redhat.com> References: <5707C9F2.8060903@redhat.com> Message-ID: <570BB4BB.6020404@redhat.com> On 04/08/2016 05:10 PM, Martin Babinsky wrote: > Hi list, > > I have put together a draft [1] outlining the effort to reimplement > the handling of Kerberos principals in both backend and frontend > layers of FreeIPA so that we may have multiple aliases per user, host > or service and thus implement stuff like > https://fedorahosted.org/freeipa/ticket/3961 and > https://fedorahosted.org/freeipa/ticket/5413 . > > Since much of the plumbing was already implemented,[2] the document > mainly describes what the patches do. Some parts required by other use > cases may be missing so please point these out. > > I would also be happy if you could correct all factual inacurracies, I > did research on this issue a long time ago and my knowledge turned a > bit rusty. > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > [2] > https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > Hi Martin, Currently DS is enforcing that 'krbPrincipalName' and 'krbCanonicalName' are unique. krbPrincipalName is caseExactIA5Match. Is it possible to imagine entries having the same (IgnoreCase) alias: dn: uid=user_one,cn=users,cn=accounts, ... krbCanonicalName: user_one@ krbPrincipalName: user_one@ krbPrincipalName: user_ONE@ dn: uid=user_two,cn=users,cn=accounts, ... krbCanonicalName: user_two@ krbPrincipalName: user_two@ krbPrincipalName: user_TWO@ krbPrincipalName: *user_**One*@ So KDB, searching as case insentive "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will retrieve user_one and user_two ? thanks thierry | ||| -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrogers at redhat.com Mon Apr 11 14:41:06 2016 From: mrogers at redhat.com (Matt Rogers) Date: Mon, 11 Apr 2016 10:41:06 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <1774860181.38986003.1460384578105.JavaMail.zimbra@redhat.com> Message-ID: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> Hi, The attached patch is a part of the authentication indicator enhancements, adding indicator value storage and retrieval for the KDB driver. https://fedorahosted.org/freeipa/ticket/5782 Regards, --- Matt Rogers Red Hat, Inc -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mrogers-0001-ipa_kdb-add-krbPrincipalAuthInd-handling.patch Type: text/x-patch Size: 13039 bytes Desc: not available URL: From simo at redhat.com Mon Apr 11 14:51:20 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 11 Apr 2016 10:51:20 -0400 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <570BB4BB.6020404@redhat.com> References: <5707C9F2.8060903@redhat.com> <570BB4BB.6020404@redhat.com> Message-ID: <1460386280.7463.242.camel@redhat.com> On Mon, 2016-04-11 at 16:29 +0200, thierry bordaz wrote: > > On 04/08/2016 05:10 PM, Martin Babinsky wrote: > > Hi list, > > > > I have put together a draft [1] outlining the effort to reimplement > > the handling of Kerberos principals in both backend and frontend > > layers of FreeIPA so that we may have multiple aliases per user, host > > or service and thus implement stuff like > > https://fedorahosted.org/freeipa/ticket/3961 and > > https://fedorahosted.org/freeipa/ticket/5413 . > > > > Since much of the plumbing was already implemented,[2] the document > > mainly describes what the patches do. Some parts required by other use > > cases may be missing so please point these out. > > > > I would also be happy if you could correct all factual inacurracies, I > > did research on this issue a long time ago and my knowledge turned a > > bit rusty. > > > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > > [2] > > https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > > > Hi Martin, > > Currently DS is enforcing that 'krbPrincipalName' and > 'krbCanonicalName' are unique. > krbPrincipalName is caseExactIA5Match. > Is it possible to imagine entries having the same (IgnoreCase) alias: > > dn: uid=user_one,cn=users,cn=accounts, > ... > krbCanonicalName: user_one@ > krbPrincipalName: user_one@ > krbPrincipalName: user_ONE@ > > dn: uid=user_two,cn=users,cn=accounts, > ... > krbCanonicalName: user_two@ > krbPrincipalName: user_two@ > krbPrincipalName: user_TWO@ > krbPrincipalName: *user_**One*@ > > So KDB, searching as case insentive > "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will > retrieve user_one and user_two ? Yes, but it is an error to have the same alias (differing just by case) on two distinct principals. So this is an error condition not an expected use case. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Mon Apr 11 14:58:11 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 11 Apr 2016 16:58:11 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <1460386280.7463.242.camel@redhat.com> References: <5707C9F2.8060903@redhat.com> <570BB4BB.6020404@redhat.com> <1460386280.7463.242.camel@redhat.com> Message-ID: <570BBB83.70304@redhat.com> On 04/11/2016 04:51 PM, Simo Sorce wrote: > On Mon, 2016-04-11 at 16:29 +0200, thierry bordaz wrote: >> On 04/08/2016 05:10 PM, Martin Babinsky wrote: >>> Hi list, >>> >>> I have put together a draft [1] outlining the effort to reimplement >>> the handling of Kerberos principals in both backend and frontend >>> layers of FreeIPA so that we may have multiple aliases per user, host >>> or service and thus implement stuff like >>> https://fedorahosted.org/freeipa/ticket/3961 and >>> https://fedorahosted.org/freeipa/ticket/5413 . >>> >>> Since much of the plumbing was already implemented,[2] the document >>> mainly describes what the patches do. Some parts required by other use >>> cases may be missing so please point these out. >>> >>> I would also be happy if you could correct all factual inacurracies, I >>> did research on this issue a long time ago and my knowledge turned a >>> bit rusty. >>> >>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>> [2] >>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >>> >> Hi Martin, >> >> Currently DS is enforcing that 'krbPrincipalName' and >> 'krbCanonicalName' are unique. >> krbPrincipalName is caseExactIA5Match. >> Is it possible to imagine entries having the same (IgnoreCase) alias: >> >> dn: uid=user_one,cn=users,cn=accounts, >> ... >> krbCanonicalName: user_one@ >> krbPrincipalName: user_one@ >> krbPrincipalName: user_ONE@ >> >> dn: uid=user_two,cn=users,cn=accounts, >> ... >> krbCanonicalName: user_two@ >> krbPrincipalName: user_two@ >> krbPrincipalName: user_TWO@ >> krbPrincipalName: *user_**One*@ >> >> So KDB, searching as case insentive >> "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will >> retrieve user_one and user_two ? > Yes, but it is an error to have the same alias (differing just by case) > on two distinct principals. So this is an error condition not an > expected use case. > > Simo. > I agree. At uniqueness plugin, this could be prevented if we add the support of matchingRule for uniqueness lookup. thanks thierry From fskola at redhat.com Mon Apr 11 15:06:26 2016 From: fskola at redhat.com (Filip Skola) Date: Mon, 11 Apr 2016 11:06:26 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0009] Refactor test_automember_plugin In-Reply-To: <1691910141.53565378.1460387123472.JavaMail.zimbra@redhat.com> Message-ID: <819699319.53565735.1460387186194.JavaMail.zimbra@redhat.com> Hi, sending the refactored automember plugin test for review. Filip -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0009-Refactor-test_automember_plugin.patch Type: text/x-patch Size: 104169 bytes Desc: not available URL: From ftweedal at redhat.com Tue Apr 12 07:03:21 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 12 Apr 2016 17:03:21 +1000 Subject: [Freeipa-devel] DNs of Custodia keys Message-ID: <20160412070321.GE18277@dhcp-40-8.bne.redhat.com> Hi Simo and Honza et al, I have a design challenge pertaining to DNs for Custodia keys. DNs for Custodia keys for host principals currently take the form: cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX This prevents the creation of Custodia keys for service principals (pursuant to another recent design decision[1] the service principal 'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia client for Dogtag lightweight CA key replication). [1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html Searches for custodia keys use a filter on 'ipaKeyUsage' and 'memberPrincipal' attributes, so the CN is unimportant except for a) uniqueness, and b) ACIs (see below). Based on this, my first attempt to resolve the conflict was to use the service name and host name instead of the just the hostname: cn=sig/host/f23-5.ipa.local at IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local However, this fails during replica install: [2/5]: Generating ipa-custodia keys {'info': "Insufficient 'add' privilege to add the entry 'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n", 'desc': 'Insufficient access'} due to the ACI: dn: cn=ipa,cn=etc,$SUFFIX add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") (version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) The wildcard '*' in the target is not greedy and stops at the first slash '/', so the value captured by the ($dn) macro does not match the bind DN. Proposed solution ----------------- Use a delimiter other than '/' between the key type and service name, e.g. cn={sig,enc}+$SERVICENAME/$HOSTNAME (rule) cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example) Pros: should work with existing ACIs. Cons: continues with an arguably suboptimal design choice. Alternative solution -------------------- Add an 'ipaCustodiaKey' object class, which has 'managedBy' attribute for linking the key to the host that manages it, and 'ipaUniqueId'. Create key entries with autogenerated ipaUniqueId as RDN. Add ACIs: dn: cn=ipa,cn=etc,$SUFFIX add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userattr = "managedby#USERDN";) add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (targetattr = "ipaPublicKey") (version 3.0; acl "IPA server hosts can manage own Custodia secrets"; allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userattr = "managedby#USERDN";) (Retain existing ACIs for backwards compatiblity.) Let me know what you think! Cheers, Fraser From mbabinsk at redhat.com Tue Apr 12 07:31:03 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Apr 2016 09:31:03 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <56EAE651.4040603@redhat.com> References: <56EAE651.4040603@redhat.com> Message-ID: <570CA437.1010900@redhat.com> On 03/17/2016 06:16 PM, Martin Babinsky wrote: > Hi list, > > here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP > design document concerning the concept of Server Roles as a > user-friendly abstraction of the services running on IPA masters. > > The main aim of this feature is to provide a higher level interface to > query and manipulate service-related information stored in dirsrv backend. > > I have not touched the design much from the post-Devconf session, mainly > because there are some points to clarify and agree upon. > > I have the following points to discuss: > > 1.) the design assumes that there is a distinction between roles such as > DNS server, CA, etc. and the more specific sub-roles such as DNSSec key > master, CRL master, etc. Now in the hindsight I think this distinction > is quite artificial and just clutters the interface unnecessarily. We > might implement this kind of hierarchy in the code itself but that is > something the user needs not be aware of. > > 2.) I guess the role names should be case insensitive so that users are > not hindered by trying to get the case right. > > 3.) Do we need an internal API call which will add all services > belonging to a role to the corresponding master entry? (basically a > 'server_add_role' type of command). Currently, each service instance > adds its own service entry during service installation so we probably do > not need to duplicate this functionality. > > That is all I can think of right now. I had many more questions popping > up during this night's bout of insomnia, but they got lost during the day. > > Do not be afraid to bring up other questions/remarks/comments. This is > my first design documents so I expect them to be plenty. > Hi list, We had a discussion with Petr Spacek and Jan Cholasta about the possible utilization of server role implementation for the generation of location specific DNAME records.[1] The thing that would make Petr's life a bit easier is a plugin that would associate a certain role with a set of DNS RRs and would be able to spew out configured RRs for all masters on which the role is enabled. For example, for the implicit "IPA Master" role we would spit out all configured LDAP/Kerberos/Kpasswd SRV records. I have updated the design[2] to include CLI commands that will to this job, although I think it would be enough to just have them in API and to not expose them on the command line. Let me know what you think. [1] http://www.freeipa.org/page/V4/DNS_Location_Mechanism [2] http://www.freeipa.org/page/V4/Server_Roles -- Martin^3 Babinsky From mbasti at redhat.com Tue Apr 12 08:09:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 12 Apr 2016 10:09:54 +0200 Subject: [Freeipa-devel] [PATCH 0452] Add missing pre_common_callback to stageuser-add In-Reply-To: <57029038.4020309@redhat.com> References: <56FCD688.80204@redhat.com> <57029038.4020309@redhat.com> Message-ID: <570CAD52.7060100@redhat.com> On 04.04.2016 18:03, Martin Babinsky wrote: > On 03/31/2016 09:49 AM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5759 >> >> Patch attached. >> >> > ACK. > Pushed to: master: d9fe502e8346022ac7265556782c984a8b36ee85 ipa-4-3: 4ddb373cc373c34952e0fc1119dff8c18ecbe678 From pspacek at redhat.com Tue Apr 12 08:14:18 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Apr 2016 10:14:18 +0200 Subject: [Freeipa-devel] DNs of Custodia keys In-Reply-To: <20160412070321.GE18277@dhcp-40-8.bne.redhat.com> References: <20160412070321.GE18277@dhcp-40-8.bne.redhat.com> Message-ID: <570CAE5A.5060109@redhat.com> On 12.4.2016 09:03, Fraser Tweedale wrote: > Hi Simo and Honza et al, > > I have a design challenge pertaining to DNs for Custodia keys. > DNs for Custodia keys for host principals currently take the form: > > cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX > > This prevents the creation of Custodia keys for service principals > (pursuant to another recent design decision[1] the service principal > 'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia > client for Dogtag lightweight CA key replication). > > [1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html > > Searches for custodia keys use a filter on 'ipaKeyUsage' and > 'memberPrincipal' attributes, so the CN is unimportant except for > a) uniqueness, and b) ACIs (see below). > > Based on this, my first attempt to resolve the conflict was to use > the service name and host name instead of the just the hostname: > > cn=sig/host/f23-5.ipa.local at IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local > > However, this fails during replica install: > > [2/5]: Generating ipa-custodia keys > {'info': "Insufficient 'add' privilege to add the entry > 'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n", > 'desc': 'Insufficient access'} > > due to the ACI: > > dn: cn=ipa,cn=etc,$SUFFIX > add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > The wildcard '*' in the target is not greedy and stops at the first > slash '/', so the value captured by the ($dn) macro does not match > the bind DN. The question is if the * behaves as expected. CCing Ludwig ... Petr^2 Spacek > > > Proposed solution > ----------------- > > Use a delimiter other than '/' between the key type and service > name, e.g. > > cn={sig,enc}+$SERVICENAME/$HOSTNAME (rule) > cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example) > > Pros: should work with existing ACIs. > > Cons: continues with an arguably suboptimal design choice. > > > Alternative solution > -------------------- > > Add an 'ipaCustodiaKey' object class, which has 'managedBy' > attribute for linking the key to the host that manages it, and > 'ipaUniqueId'. > > Create key entries with autogenerated ipaUniqueId as RDN. > > Add ACIs: > > dn: cn=ipa,cn=etc,$SUFFIX > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userattr = "managedby#USERDN";) > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (targetattr = "ipaPublicKey") > (version 3.0; acl "IPA server hosts can manage own Custodia secrets"; > allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userattr = "managedby#USERDN";) > > (Retain existing ACIs for backwards compatiblity.) > > > Let me know what you think! > > Cheers, > Fraser > -- Petr^2 Spacek From pspacek at redhat.com Tue Apr 12 08:15:08 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Apr 2016 10:15:08 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <570BBB83.70304@redhat.com> References: <5707C9F2.8060903@redhat.com> <570BB4BB.6020404@redhat.com> <1460386280.7463.242.camel@redhat.com> <570BBB83.70304@redhat.com> Message-ID: <570CAE8C.2000607@redhat.com> On 11.4.2016 16:58, thierry bordaz wrote: > > > On 04/11/2016 04:51 PM, Simo Sorce wrote: >> On Mon, 2016-04-11 at 16:29 +0200, thierry bordaz wrote: >>> On 04/08/2016 05:10 PM, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> I have put together a draft [1] outlining the effort to reimplement >>>> the handling of Kerberos principals in both backend and frontend >>>> layers of FreeIPA so that we may have multiple aliases per user, host >>>> or service and thus implement stuff like >>>> https://fedorahosted.org/freeipa/ticket/3961 and >>>> https://fedorahosted.org/freeipa/ticket/5413 . >>>> >>>> Since much of the plumbing was already implemented,[2] the document >>>> mainly describes what the patches do. Some parts required by other use >>>> cases may be missing so please point these out. >>>> >>>> I would also be happy if you could correct all factual inacurracies, I >>>> did research on this issue a long time ago and my knowledge turned a >>>> bit rusty. >>>> >>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>>> [2] >>>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >>>> >>> Hi Martin, >>> >>> Currently DS is enforcing that 'krbPrincipalName' and >>> 'krbCanonicalName' are unique. >>> krbPrincipalName is caseExactIA5Match. >>> Is it possible to imagine entries having the same (IgnoreCase) alias: >>> >>> dn: uid=user_one,cn=users,cn=accounts, >>> ... >>> krbCanonicalName: user_one@ >>> krbPrincipalName: user_one@ >>> krbPrincipalName: user_ONE@ >>> >>> dn: uid=user_two,cn=users,cn=accounts, >>> ... >>> krbCanonicalName: user_two@ >>> krbPrincipalName: user_two@ >>> krbPrincipalName: user_TWO@ >>> krbPrincipalName: *user_**One*@ >>> >>> So KDB, searching as case insentive >>> "krbPrincipalName:caseIgnoreIA5Match:=USER_one@" will >>> retrieve user_one and user_two ? >> Yes, but it is an error to have the same alias (differing just by case) >> on two distinct principals. So this is an error condition not an >> expected use case. >> >> Simo. >> > I agree. > At uniqueness plugin, this could be prevented if we add the support of > matchingRule for uniqueness lookup. Sounds like a good idea to me! -- Petr^2 Spacek From pspacek at redhat.com Tue Apr 12 08:45:19 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Apr 2016 10:45:19 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <570CA437.1010900@redhat.com> References: <56EAE651.4040603@redhat.com> <570CA437.1010900@redhat.com> Message-ID: <570CB59F.5030005@redhat.com> On 12.4.2016 09:31, Martin Babinsky wrote: > On 03/17/2016 06:16 PM, Martin Babinsky wrote: >> Hi list, >> >> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >> design document concerning the concept of Server Roles as a >> user-friendly abstraction of the services running on IPA masters. >> >> The main aim of this feature is to provide a higher level interface to >> query and manipulate service-related information stored in dirsrv backend. >> >> I have not touched the design much from the post-Devconf session, mainly >> because there are some points to clarify and agree upon. >> >> I have the following points to discuss: >> >> 1.) the design assumes that there is a distinction between roles such as >> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >> master, CRL master, etc. Now in the hindsight I think this distinction >> is quite artificial and just clutters the interface unnecessarily. We >> might implement this kind of hierarchy in the code itself but that is >> something the user needs not be aware of. >> >> 2.) I guess the role names should be case insensitive so that users are >> not hindered by trying to get the case right. >> >> 3.) Do we need an internal API call which will add all services >> belonging to a role to the corresponding master entry? (basically a >> 'server_add_role' type of command). Currently, each service instance >> adds its own service entry during service installation so we probably do >> not need to duplicate this functionality. >> >> That is all I can think of right now. I had many more questions popping >> up during this night's bout of insomnia, but they got lost during the day. >> >> Do not be afraid to bring up other questions/remarks/comments. This is >> my first design documents so I expect them to be plenty. >> > Hi list, > > We had a discussion with Petr Spacek and Jan Cholasta about the possible > utilization of server role implementation for the generation of location > specific DNAME records.[1] > > The thing that would make Petr's life a bit easier is a plugin that would > associate a certain role with a set of DNS RRs and would be able to spew out > configured RRs for all masters on which the role is enabled. > > For example, for the implicit "IPA Master" role we would spit out all > configured LDAP/Kerberos/Kpasswd SRV records. > > I have updated the design[2] to include CLI commands that will to this job, > although I think it would be enough to just have them in API and to not expose > them on the command line. Let me know what you think. I agree. Even user-visible API can be too much. Can we make this purely internal interface? > [1] http://www.freeipa.org/page/V4/DNS_Location_Mechanism > [2] http://www.freeipa.org/page/V4/Server_Roles > -- Petr^2 Spacek From mrniranjan at fedoraproject.org Tue Apr 12 09:07:01 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Tue, 12 Apr 2016 14:37:01 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5704F243.5000006@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> Message-ID: <20160412090701.GA12547@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/06/2016 10:55 AM, Niranjan wrote: > > Greetings, > > > > For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > > a patch, I think this patch is more of a workaround , than a solution. I would > > like to get more inputs on how to use pytest-multihost to execute commands > > on Windows. The method i am using requires cygwin with openssh/bash to be > > installed. > > Wow. I'm surprised the only problem on Windows is the "set -e". > > Regarding the patch: > > - Why is get_winhost_class needed? I don't see it called anywhere. > - Similarly, why is host_type needed? Your patch only sets it. > > If run_command of WinHost and Unix hosts are this similar, I would put > the 'set -e\n' for Unix (and an empty string for Windows) in a class > attribute named e.g. "command_prelude", use it in run_command, and move > run_command from Host to BaseHost. > Would that work, or am I missing something? How do we detect the host is windows/unix then , we still need host_type to know what the type of host is (unix/windows)? > > > -- > Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From ofayans at redhat.com Tue Apr 12 09:19:59 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 12 Apr 2016 11:19:59 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Fixed failing legacy client tests Message-ID: <570CBDBF.6040305@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0036-Fixed-a-failure-in-legacy_client-tests.patch Type: text/x-patch Size: 966 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 12 10:52:13 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 12 Apr 2016 12:52:13 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: <56C70FAA.4010606@redhat.com> References: <56C70FAA.4010606@redhat.com> Message-ID: <570CD35D.50204@redhat.com> On 19.2.2016 13:50, Petr Viktorin wrote: > Is it time yet? > > This patch switches /usr/bin/ipa to Python 3 for > - the in-tree ./ipa command > - RPMs, when built with_python3 NACK, the change in 'ipa' command broke ipa dnszone-find: # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone not found The same command works when I switch python3->python2 in the 'ipa' command. Sorry. -- Petr^2 Spacek From jcholast at redhat.com Tue Apr 12 10:55:50 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Apr 2016 12:55:50 +0200 Subject: [Freeipa-devel] DNs of Custodia keys In-Reply-To: <20160412070321.GE18277@dhcp-40-8.bne.redhat.com> References: <20160412070321.GE18277@dhcp-40-8.bne.redhat.com> Message-ID: <570CD436.8030500@redhat.com> Hi, On 12.4.2016 09:03, Fraser Tweedale wrote: > Hi Simo and Honza et al, > > I have a design challenge pertaining to DNs for Custodia keys. > DNs for Custodia keys for host principals currently take the form: > > cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX > > This prevents the creation of Custodia keys for service principals > (pursuant to another recent design decision[1] the service principal > 'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia > client for Dogtag lightweight CA key replication). This naming scheme is relevant only to IPA server keys, otherwise the cn can be anything, as long as it does not conflict with existing keys. > > [1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html > > Searches for custodia keys use a filter on 'ipaKeyUsage' and > 'memberPrincipal' attributes, so the CN is unimportant except for > a) uniqueness, and b) ACIs (see below). > > Based on this, my first attempt to resolve the conflict was to use > the service name and host name instead of the just the hostname: > > cn=sig/host/f23-5.ipa.local at IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local > > However, this fails during replica install: > > [2/5]: Generating ipa-custodia keys > {'info': "Insufficient 'add' privilege to add the entry > 'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n", > 'desc': 'Insufficient access'} > > due to the ACI: > > dn: cn=ipa,cn=etc,$SUFFIX > add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > The wildcard '*' in the target is not greedy and stops at the first > slash '/', so the value captured by the ($dn) macro does not match > the bind DN. Again, this is relevant only to IPA server keys, you should add your own ACI for lightweight CAs. > > > Proposed solution > ----------------- > > Use a delimiter other than '/' between the key type and service > name, e.g. > > cn={sig,enc}+$SERVICENAME/$HOSTNAME (rule) > cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example) > > Pros: should work with existing ACIs. > > Cons: continues with an arguably suboptimal design choice. > > > Alternative solution > -------------------- > > Add an 'ipaCustodiaKey' object class, which has 'managedBy' > attribute for linking the key to the host that manages it, and > 'ipaUniqueId'. > > Create key entries with autogenerated ipaUniqueId as RDN. > > Add ACIs: > > dn: cn=ipa,cn=etc,$SUFFIX > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userattr = "managedby#USERDN";) > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (targetattr = "ipaPublicKey") > (version 3.0; acl "IPA server hosts can manage own Custodia secrets"; > allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userattr = "managedby#USERDN";) > > (Retain existing ACIs for backwards compatiblity.) Actually this has been discussed before: > > > Let me know what you think! I think that all you have to do is add a new ACI for your purposes, you don't need to change anything. Honza -- Jan Cholasta From jcholast at redhat.com Tue Apr 12 10:57:41 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Apr 2016 12:57:41 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <570CB59F.5030005@redhat.com> References: <56EAE651.4040603@redhat.com> <570CA437.1010900@redhat.com> <570CB59F.5030005@redhat.com> Message-ID: <570CD4A5.7050502@redhat.com> On 12.4.2016 10:45, Petr Spacek wrote: > On 12.4.2016 09:31, Martin Babinsky wrote: >> On 03/17/2016 06:16 PM, Martin Babinsky wrote: >>> Hi list, >>> >>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >>> design document concerning the concept of Server Roles as a >>> user-friendly abstraction of the services running on IPA masters. >>> >>> The main aim of this feature is to provide a higher level interface to >>> query and manipulate service-related information stored in dirsrv backend. >>> >>> I have not touched the design much from the post-Devconf session, mainly >>> because there are some points to clarify and agree upon. >>> >>> I have the following points to discuss: >>> >>> 1.) the design assumes that there is a distinction between roles such as >>> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >>> master, CRL master, etc. Now in the hindsight I think this distinction >>> is quite artificial and just clutters the interface unnecessarily. We >>> might implement this kind of hierarchy in the code itself but that is >>> something the user needs not be aware of. >>> >>> 2.) I guess the role names should be case insensitive so that users are >>> not hindered by trying to get the case right. >>> >>> 3.) Do we need an internal API call which will add all services >>> belonging to a role to the corresponding master entry? (basically a >>> 'server_add_role' type of command). Currently, each service instance >>> adds its own service entry during service installation so we probably do >>> not need to duplicate this functionality. >>> >>> That is all I can think of right now. I had many more questions popping >>> up during this night's bout of insomnia, but they got lost during the day. >>> >>> Do not be afraid to bring up other questions/remarks/comments. This is >>> my first design documents so I expect them to be plenty. >>> >> Hi list, >> >> We had a discussion with Petr Spacek and Jan Cholasta about the possible >> utilization of server role implementation for the generation of location >> specific DNAME records.[1] >> >> The thing that would make Petr's life a bit easier is a plugin that would >> associate a certain role with a set of DNS RRs and would be able to spew out >> configured RRs for all masters on which the role is enabled. >> >> For example, for the implicit "IPA Master" role we would spit out all >> configured LDAP/Kerberos/Kpasswd SRV records. >> >> I have updated the design[2] to include CLI commands that will to this job, >> although I think it would be enough to just have them in API and to not expose >> them on the command line. Let me know what you think. > > I agree. Even user-visible API can be too much. Can we make this purely > internal interface? +1, these should be commands at all, but rather a new type of plugin. -- Jan Cholasta From jcholast at redhat.com Tue Apr 12 10:58:10 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 12 Apr 2016 12:58:10 +0200 Subject: [Freeipa-devel] [DESIGN] Server Roles In-Reply-To: <570CD4A5.7050502@redhat.com> References: <56EAE651.4040603@redhat.com> <570CA437.1010900@redhat.com> <570CB59F.5030005@redhat.com> <570CD4A5.7050502@redhat.com> Message-ID: <570CD4C2.8050601@redhat.com> On 12.4.2016 12:57, Jan Cholasta wrote: > On 12.4.2016 10:45, Petr Spacek wrote: >> On 12.4.2016 09:31, Martin Babinsky wrote: >>> On 03/17/2016 06:16 PM, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP >>>> design document concerning the concept of Server Roles as a >>>> user-friendly abstraction of the services running on IPA masters. >>>> >>>> The main aim of this feature is to provide a higher level interface to >>>> query and manipulate service-related information stored in dirsrv >>>> backend. >>>> >>>> I have not touched the design much from the post-Devconf session, >>>> mainly >>>> because there are some points to clarify and agree upon. >>>> >>>> I have the following points to discuss: >>>> >>>> 1.) the design assumes that there is a distinction between roles >>>> such as >>>> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key >>>> master, CRL master, etc. Now in the hindsight I think this distinction >>>> is quite artificial and just clutters the interface unnecessarily. We >>>> might implement this kind of hierarchy in the code itself but that is >>>> something the user needs not be aware of. >>>> >>>> 2.) I guess the role names should be case insensitive so that users are >>>> not hindered by trying to get the case right. >>>> >>>> 3.) Do we need an internal API call which will add all services >>>> belonging to a role to the corresponding master entry? (basically a >>>> 'server_add_role' type of command). Currently, each service instance >>>> adds its own service entry during service installation so we >>>> probably do >>>> not need to duplicate this functionality. >>>> >>>> That is all I can think of right now. I had many more questions popping >>>> up during this night's bout of insomnia, but they got lost during >>>> the day. >>>> >>>> Do not be afraid to bring up other questions/remarks/comments. This is >>>> my first design documents so I expect them to be plenty. >>>> >>> Hi list, >>> >>> We had a discussion with Petr Spacek and Jan Cholasta about the possible >>> utilization of server role implementation for the generation of location >>> specific DNAME records.[1] >>> >>> The thing that would make Petr's life a bit easier is a plugin that >>> would >>> associate a certain role with a set of DNS RRs and would be able to >>> spew out >>> configured RRs for all masters on which the role is enabled. >>> >>> For example, for the implicit "IPA Master" role we would spit out all >>> configured LDAP/Kerberos/Kpasswd SRV records. >>> >>> I have updated the design[2] to include CLI commands that will to >>> this job, >>> although I think it would be enough to just have them in API and to >>> not expose >>> them on the command line. Let me know what you think. >> >> I agree. Even user-visible API can be too much. Can we make this purely >> internal interface? > > +1, these should be commands at all, but rather a new type of plugin. ... should *not* be... -- Jan Cholasta From ftweedal at redhat.com Tue Apr 12 11:26:33 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 12 Apr 2016 21:26:33 +1000 Subject: [Freeipa-devel] DNs of Custodia keys In-Reply-To: <570CD436.8030500@redhat.com> References: <20160412070321.GE18277@dhcp-40-8.bne.redhat.com> <570CD436.8030500@redhat.com> Message-ID: <20160412112633.GG18277@dhcp-40-8.bne.redhat.com> On Tue, Apr 12, 2016 at 12:55:50PM +0200, Jan Cholasta wrote: > Hi, > > On 12.4.2016 09:03, Fraser Tweedale wrote: > >Hi Simo and Honza et al, > > > >I have a design challenge pertaining to DNs for Custodia keys. > >DNs for Custodia keys for host principals currently take the form: > > > > cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX > > > >This prevents the creation of Custodia keys for service principals > >(pursuant to another recent design decision[1] the service principal > >'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia > >client for Dogtag lightweight CA key replication). > > This naming scheme is relevant only to IPA server keys, otherwise the cn can > be anything, as long as it does not conflict with existing keys. > > > > >[1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html > > > >Searches for custodia keys use a filter on 'ipaKeyUsage' and > >'memberPrincipal' attributes, so the CN is unimportant except for > >a) uniqueness, and b) ACIs (see below). > > > >Based on this, my first attempt to resolve the conflict was to use > >the service name and host name instead of the just the hostname: > > > > cn=sig/host/f23-5.ipa.local at IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local > > > >However, this fails during replica install: > > > > [2/5]: Generating ipa-custodia keys > > {'info': "Insufficient 'add' privilege to add the entry > > 'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n", > > 'desc': 'Insufficient access'} > > > >due to the ACI: > > > > dn: cn=ipa,cn=etc,$SUFFIX > > add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > > >The wildcard '*' in the target is not greedy and stops at the first > >slash '/', so the value captured by the ($dn) macro does not match > >the bind DN. > > Again, this is relevant only to IPA server keys, you should add your own ACI > for lightweight CAs. > > > > > > >Proposed solution > >----------------- > > > >Use a delimiter other than '/' between the key type and service > >name, e.g. > > > > cn={sig,enc}+$SERVICENAME/$HOSTNAME (rule) > > cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example) > > > >Pros: should work with existing ACIs. > > > >Cons: continues with an arguably suboptimal design choice. > > > > > >Alternative solution > >-------------------- > > > >Add an 'ipaCustodiaKey' object class, which has 'managedBy' > >attribute for linking the key to the host that manages it, and > >'ipaUniqueId'. > > > >Create key entries with autogenerated ipaUniqueId as RDN. > > > >Add ACIs: > > > > dn: cn=ipa,cn=etc,$SUFFIX > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > and userattr = "managedby#USERDN";) > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (targetattr = "ipaPublicKey") > > (version 3.0; acl "IPA server hosts can manage own Custodia secrets"; > > allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > and userattr = "managedby#USERDN";) > > > >(Retain existing ACIs for backwards compatiblity.) > > Actually this has been discussed before: > > Thanks for the link and feedback. Something like the following ACI should do the trick, I think? add:aci: (target = "ldap:///cn=*/dogtag-ipa-custodia/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") (version 3.0; acl "IPA server hosts can manage Custodia secrets for the dogtag-ipa-custodia service on same host"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) Host Custodia keys would keep the existing CN schema and existing ACLs will apply only to them. Cheers, Fraser > > > > > >Let me know what you think! > > I think that all you have to do is add a new ACI for your purposes, you > don't need to change anything. > > Honza > > -- > Jan Cholasta From ssorce at redhat.com Tue Apr 12 11:50:24 2016 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Apr 2016 07:50:24 -0400 Subject: [Freeipa-devel] DNs of Custodia keys In-Reply-To: <20160412112633.GG18277@dhcp-40-8.bne.redhat.com> References: <20160412070321.GE18277@dhcp-40-8.bne.redhat.com> <570CD436.8030500@redhat.com> <20160412112633.GG18277@dhcp-40-8.bne.redhat.com> Message-ID: <1460461824.8657.23.camel@redhat.com> On Tue, 2016-04-12 at 21:26 +1000, Fraser Tweedale wrote: > On Tue, Apr 12, 2016 at 12:55:50PM +0200, Jan Cholasta wrote: > > Hi, > > > > On 12.4.2016 09:03, Fraser Tweedale wrote: > > >Hi Simo and Honza et al, > > > > > >I have a design challenge pertaining to DNs for Custodia keys. > > >DNs for Custodia keys for host principals currently take the form: > > > > > > cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX > > > > > >This prevents the creation of Custodia keys for service principals > > >(pursuant to another recent design decision[1] the service principal > > >'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia > > >client for Dogtag lightweight CA key replication). > > > > This naming scheme is relevant only to IPA server keys, otherwise the cn can > > be anything, as long as it does not conflict with existing keys. > > > > > > > >[1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html > > > > > >Searches for custodia keys use a filter on 'ipaKeyUsage' and > > >'memberPrincipal' attributes, so the CN is unimportant except for > > >a) uniqueness, and b) ACIs (see below). > > > > > >Based on this, my first attempt to resolve the conflict was to use > > >the service name and host name instead of the just the hostname: > > > > > > cn=sig/host/f23-5.ipa.local at IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local > > > > > >However, this fails during replica install: > > > > > > [2/5]: Generating ipa-custodia keys > > > {'info': "Insufficient 'add' privilege to add the entry > > > 'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n", > > > 'desc': 'Insufficient access'} > > > > > >due to the ACI: > > > > > > dn: cn=ipa,cn=etc,$SUFFIX > > > add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > > > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > > and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > > > > >The wildcard '*' in the target is not greedy and stops at the first > > >slash '/', so the value captured by the ($dn) macro does not match > > >the bind DN. > > > > Again, this is relevant only to IPA server keys, you should add your own ACI > > for lightweight CAs. > > > > > > > > > > >Proposed solution > > >----------------- > > > > > >Use a delimiter other than '/' between the key type and service > > >name, e.g. > > > > > > cn={sig,enc}+$SERVICENAME/$HOSTNAME (rule) > > > cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example) > > > > > >Pros: should work with existing ACIs. > > > > > >Cons: continues with an arguably suboptimal design choice. > > > > > > > > >Alternative solution > > >-------------------- > > > > > >Add an 'ipaCustodiaKey' object class, which has 'managedBy' > > >attribute for linking the key to the host that manages it, and > > >'ipaUniqueId'. > > > > > >Create key entries with autogenerated ipaUniqueId as RDN. > > > > > >Add ACIs: > > > > > > dn: cn=ipa,cn=etc,$SUFFIX > > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > > > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > > and userattr = "managedby#USERDN";) > > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (targetattr = "ipaPublicKey") > > > (version 3.0; acl "IPA server hosts can manage own Custodia secrets"; > > > allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > > > and userattr = "managedby#USERDN";) > > > > > >(Retain existing ACIs for backwards compatiblity.) > > > > Actually this has been discussed before: > > > > > Thanks for the link and feedback. > > Something like the following ACI should do the trick, I think? > > add:aci: (target = "ldap:///cn=*/dogtag-ipa-custodia/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (version 3.0; acl "IPA server hosts can manage Custodia secrets for the dogtag-ipa-custodia service on same host"; > allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" > and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > Host Custodia keys would keep the existing CN schema and existing > ACLs will apply only to them. You may also think of adding a subtree specific to subCA keys perhaps. Simo. From ssorce at redhat.com Tue Apr 12 13:31:30 2016 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Apr 2016 09:31:30 -0400 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> Message-ID: <1460467890.8657.25.camel@redhat.com> On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote: > On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: > > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: > > > - name = gssapi.Name('host@%s' % (self.client,), > > > > > > - gssapi.NameType.hostbased_service) > > > > If you remove this then on a serve that has nfs keys in the keytab you > > may end up acquiring the wrong credentials. > > You need to pass down what credentials you want to use to initialize the > > cred store, we canot rely on ordering in the system keytab case. > > > > Simo. > > > Thanks Simo; updated patch attached. Except the ACI the rest looks good to me. For ACI please add a separate patch that follows the naming scheme for subCA keys. Simo. From mbabinsk at redhat.com Tue Apr 12 13:35:28 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Apr 2016 15:35:28 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade In-Reply-To: <570637EB.2000705@redhat.com> References: <570637EB.2000705@redhat.com> Message-ID: <570CF9A0.7070200@redhat.com> On 04/07/2016 12:35 PM, Oleg Fayans wrote: > > > Hi Oleg, since this is a part of replica promotion test suite please add the link to https://fedorahosted.org/freeipa/ticket/5723 to the commit message. The patch cannot be applied cleanly, even 3-way merge fails with: """ git am ../review/ofayans/freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch -3 Applying: Add test if replica is working after domain upgrade error: invalid object 100644 acae5c924594cc73bf262eeab5f843f252723207 for 'ipatests/test_integration/test_replica_promotion.py' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Add test if replica is working after domain upgrade """ I had to fall back to plain 'patch -p1' I have your previous patches 0033-0034 applied. The patch probably needs a rebase. Also I would be more happy if the username for 'testuser' was not hardcoded in the code. You can factor it out as a class member. -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Apr 12 14:15:45 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Apr 2016 16:15:45 +0200 Subject: [Freeipa-devel] [TEST][patch-0033] Added assertion errors to topology tests, track N 5772 In-Reply-To: <570503B4.9010702@redhat.com> References: <56FCF65C.8000709@redhat.com> <56FCF6F3.9040007@redhat.com> <56FD05C3.6010305@redhat.com> <56FD3F17.8000507@redhat.com> <57029A79.8080408@redhat.com> <570503B4.9010702@redhat.com> Message-ID: <570D0311.5040305@redhat.com> On 04/06/2016 02:40 PM, Oleg Fayans wrote: > Hi Martin, > > The updated patches are attached > > On 04/04/2016 06:46 PM, Martin Babinsky wrote: >> On 03/31/2016 05:15 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Thanks for the review. The updated patch(es) are included >>> >>> Testrun output can be found here: >>> >>> http://fpaste.org/347800/59421745/ >>> >>> On 03/31/2016 01:10 PM, Martin Basti wrote: >>>> >>>> >>>> On 31.03.2016 12:07, Oleg Fayans wrote: >>>>> Please, disregard it for a while, it does not pass lint. >>>>> >>>>> On 03/31/2016 12:05 PM, Oleg Fayans wrote: >>>>>> >>>>>> >>>> NACK >>>> >>>> Please send unrelated changes in separate patches. I do not see relation >>>> between changing variable names, adding assertion messages and setting >>>> replication sleep-a-bit wait. >>> >>> Agreed. There are two necessary bugfixes for the testsuite to run. They >>> were put into a separate patch >>> >>>> >>>> IMO to the ticket in the patch only assertion changes are related. >>>> >>>> For the pylint related errors: >>>> assert ('any value', 'in tuple') >>>> is always true. >>>> right syntax is >>>> assert (any test), ('error msg') >>> >>> thank you! >>> >>>> >>>> Martin^2 >>> >>> >>> >> Hi Oleg, >> >> Patch 0033: >> >> 1.) >> First of all, the commit message does not tell much about what the patch >> does, I would prefer something like "Improve reporting of failed tests >> in topology test suite". > > Done > >> >> 2.) Since what you are doing is basically comparing the contents of a >> list of dicts containing expected data with a list of dicts with data >> parsed from test results, why are you not using "assert_deepequal" >> function from 'ipatests/util.py' module? It is also used in e.g. XMLRPC >> tests and it reports the failures fairly well (e.g. redundant keys, >> missing keys, expected value mismatch, container length mismatch etc.) > > Indeed :) Done. > >> >> Patch 034: >> >> I think this is a good use case for 'wait_for_replication' function from >> 'ipatests/test_integration/tasks.py' module. You need to establish LDAP >> connection to the host but this is very easy, see how it's done in >> 'test_simple_replication' suite[1]. >> >> I would prefer this approach (if applicable) instead of using sleep(). > > Implemented. > >> >> In any way, your formatting of assertions is wrong and makes the code >> nearly unreadable. See the attached patch for an example of pep8 >> compliant and pleasant formatting > > Thank you, that looks really way more readable. > >> >> [1] >> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_integration/test_simple_replication.py#n42 >> >> >> >> > Thanks, ACK. -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Apr 12 15:23:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 12 Apr 2016 17:23:36 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Fixed failing legacy client tests In-Reply-To: <570CBDBF.6040305@redhat.com> References: <570CBDBF.6040305@redhat.com> Message-ID: <570D12F8.6010105@redhat.com> On 04/12/2016 11:19 AM, Oleg Fayans wrote: > > > ACK. -- Martin^3 Babinsky From mbasti at redhat.com Tue Apr 12 15:26:27 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 12 Apr 2016 17:26:27 +0200 Subject: [Freeipa-devel] [PATCH 0088-0095] Add --forward-policy option into installers In-Reply-To: <57028A3D.1010204@redhat.com> References: <56E1E3B2.3070907@redhat.com> <20160310211744.GD32482@mail.corp.redhat.com> <56F01891.5030704@redhat.com> <56FD0DBF.7030307@redhat.com> <57028A3D.1010204@redhat.com> Message-ID: <570D13A3.8060802@redhat.com> On 04.04.2016 17:37, Petr Spacek wrote: > On 31.3.2016 13:45, Martin Basti wrote: >> >> On 21.03.2016 16:51, Petr Spacek wrote: >>> On 10.3.2016 22:17, Lukas Slebodnik wrote: >>>> On (10/03/16 22:14), Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> I forgot to send a patches before I leave, so here it is: >>>>> >>>>> Auto-detect default value for --forward-policy option in installers >>>>> >>>>> See >>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>> commit messages, and design page >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>>> >>>>> >>>>> >>>>> I did not have time to test it thoroughly but it LGTM :-D >>>>> >>>>> Please note that this is first part, it does not solve upgrade (yet) and >>>>> warnings in forwardzone-* interface. >>>>> >>>>> This can be solved in another patch set, this can be pushed if it passes >>>>> review. >>>>> >>>> ENOPATH >>> LOL, here it is. >>> >>> >>> >> * Remove function ipapython.ipautil.host_exists() * >> ACK >> >> >> * Extend installers with --forward-policy option * >> 1) >> There is no --forward-policy option in ipa-dns-install >> >> >> * Move automatic empty zone list into ipapython.dnsutil and make it reusable * >> ACK >> >> >> * Add assert_absolute_dnsname() helper to ipapython.dnsutil * >> ACK >> >> >> * Move function is_auto_empty_zone() into ipapython.dnsutil * >> ACK >> >> >> * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * >> ACK >> >> * Add function ipapython.dnsutil.inside_auto_empty_zone() * >> ACK >> >> * Auto-detect default value for --forward-policy option in installers * >> LGTM, but ipa-dns-install is missing option --forward-policy >> >> # ipa-dns-install >> ... >> Unexpected error - see /var/log/ipaserver-install.log for details: >> AttributeError: Values instance has no attribute 'forward_policy' >> >> >> Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK > Thank you very much for review. > > Here is my second attempt :-) > Hello, code works as expected, but it is quite inconsistent with current behavior ipa-server-install --forward-policy should raise error without --setup-dns option Like here: [root at vm-058-134 ~]# ipa-server-install --forwarder=10.2.3.4 Usage: ipa-server-install [options] ipa-server-install: error: You cannot specify a --forwarder option without the --setup-dns option ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information Martin From ftweedal at redhat.com Wed Apr 13 01:15:50 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 13 Apr 2016 11:15:50 +1000 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <1460467890.8657.25.camel@redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> <1460467890.8657.25.camel@redhat.com> Message-ID: <20160413011550.GI18277@dhcp-40-8.bne.redhat.com> On Tue, Apr 12, 2016 at 09:31:30AM -0400, Simo Sorce wrote: > On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote: > > On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: > > > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: > > > > - name = gssapi.Name('host@%s' % (self.client,), > > > > > > > > - gssapi.NameType.hostbased_service) > > > > > > If you remove this then on a serve that has nfs keys in the keytab you > > > may end up acquiring the wrong credentials. > > > You need to pass down what credentials you want to use to initialize the > > > cred store, we canot rely on ordering in the system keytab case. > > > > > > Simo. > > > > > Thanks Simo; updated patch attached. > > Except the ACI the rest looks good to me. > For ACI please add a separate patch that follows the naming scheme for > subCA keys. > The ACI here targets the Custodia server public keys, so the client can search and read them. It should just read: add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") (targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal") (version 3.0; acl "Anyone can search Custodia public keys"; allow(read, search, compare) userdn = "ldap:///all";) I don't mind putting the ACI in a separate patch, but it is necessary to restrict read access on the public keys to only the dogtag-ipa-custodia service principals. Cheers, Fraser From dkupka at redhat.com Wed Apr 13 05:50:06 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 13 Apr 2016 07:50:06 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <5707C9F2.8060903@redhat.com> References: <5707C9F2.8060903@redhat.com> Message-ID: <570DDE0E.5070006@redhat.com> On 08/04/16 17:10, Martin Babinsky wrote: > Hi list, > > I have put together a draft [1] outlining the effort to reimplement the > handling of Kerberos principals in both backend and frontend layers of > FreeIPA so that we may have multiple aliases per user, host or service > and thus implement stuff like > https://fedorahosted.org/freeipa/ticket/3961 and > https://fedorahosted.org/freeipa/ticket/5413 . > > Since much of the plumbing was already implemented,[2] the document > mainly describes what the patches do. Some parts required by other use > cases may be missing so please point these out. > > I would also be happy if you could correct all factual inacurracies, I > did research on this issue a long time ago and my knowledge turned a bit > rusty. > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > [2] > https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > Hi, after reading the designs following thoughts comes to my mind. 1) Just to be sure that I understand the new ticket obtaining process correctly I'd like to summarize. We need to always search all krbPrincipalName values, krbCanonicalName and ipaKrbPrincipalAlias (for backward compatibility). For TGT request case sensitivity of the search and principal in returned ticket depends on canonicalization. When canonicalization is requested the search is case-insensitive and krbCanonicalName is used otherwise case-sensitive search is performed and principal from request is used. When requesting TGS search is always case-sensitive and principal from request is used. In pseudo-code: get_tgt(principal, secret, canonicalization) if canonicalization if principal case-insensitive-in {krbPrincipalName + ipaKrbPrincipalAlias + krbCanonicalName} # verify secret, perform various other checks... return TGT(krbCanonicalName) else if principal case-sensitive-in {krbPrincipalName + ipaKrbPrincipalAlias + krbCanonicalName} # verify secret, perform various other checks... return TGT(principal) get_tgs(service_principal, TGT) if service_principal case-sensitive-in {krbPrincipalName + ipaKrbPrincipalAlias + krbCanonicalName} # verify TGT, perform various other checks... return TGS(service_principal) Do I understand it right? 2) I would like to add following constrains for krb{Canonical,Principal}Name attributes: when user/host/service is created krbCanonicalName is set to the same value as krbPrincipalName krbCanonicalName cannot be modified krbPrincipalName with the same value as krbCanonicalName cannot be removed/modified krbPrincipalName must be case-insensitively unique in whole DB krbPrincipalName attributes can be added and/or removed This will allow us to keep the first krbPrincipalName as RDN for services/hosts and give the flexibility of adding/removing aliases. 'Change of username' use case is also solvable with this approach. When username is changed we add krbPrincipalName with the new username. That will allow user to login with either old or new name. 3) ad CLI: {user,host,service}-add - Can canonicalname be specified? Or will it take principal argument/option value? Can we add {user,host,service}-{add,remove}-principal set of commands for principal manipulation? I really don't want to use --{add,set,del}-attr unless necessary. Will {user,host,service}-{show,find} display krbCanonicalName by default or only with --all option? 4) ad Upgrade: I think it would be worth to check and document what happens during upgrade of multiple replicas. There may be confusing behavior when obtaining tickets. KDC behavior will differ among servers and since autodiscovery is in use we don't know if we are talking to the old or new server. I'm not sure what exactly will happen but I suspect it won't be nice. -- David Kupka From tbabej at redhat.com Wed Apr 13 07:55:18 2016 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 13 Apr 2016 09:55:18 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides In-Reply-To: <20160407115302.GL4768@p.redhat.com> References: <56FE8B5F.8040803@redhat.com> <570279B6.1070504@redhat.com> <20160407115302.GL4768@p.redhat.com> Message-ID: <570DFB66.9040207@redhat.com> On 04/07/2016 01:53 PM, Sumit Bose wrote: > On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote: >> Hi, >> >> On 1.4.2016 16:53, Tomas Babej wrote: >>> Hi, >>> >>> this extends the user ID overrides with capability to store the user >>> certificate. >>> >>> https://fedorahosted.org/freeipa/ticket/4955 >> >> The preferred way of managing certificates nowadays is using $OBJ-add-cert >> and $OBJ-remove-cert commands, you should add them here as well. >> >> I would even go as far as not allowing to modify certificates using >> idoverrideuser-mod - in user-mod and host-mod, it's there just for backward >> compatibility, which is not the case here. But I don't have a strong opinion >> on that. >> >> For consistency with user-find and host-find, the full certificate blob >> should not be shown in idoverrideuser-find. You can do that by setting >> search_display_attributes attribute on the idoverrideuser class >> appropriately. > > I tested the current patch with my related patches for SSSD and all is > working as expected. > > bye, > Sumit > >> >> 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 > Thanks for the reviews, attaching a updated patch that addresses Honza's comments. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0405-2-idviews-Add-user-certificate-attribute-to-user-ID-ov.patch Type: text/x-patch Size: 14406 bytes Desc: not available URL: From ofayans at redhat.com Wed Apr 13 08:30:44 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 13 Apr 2016 10:30:44 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade In-Reply-To: <570CF9A0.7070200@redhat.com> References: <570637EB.2000705@redhat.com> <570CF9A0.7070200@redhat.com> Message-ID: <570E03B4.3080008@redhat.com> Hi Martin, I've updated the patch with regard to your review. Thank you! On 04/12/2016 03:35 PM, Martin Babinsky wrote: > On 04/07/2016 12:35 PM, Oleg Fayans wrote: >> >> >> > Hi Oleg, > > since this is a part of replica promotion test suite please add the link > to https://fedorahosted.org/freeipa/ticket/5723 to the commit message. Done > > The patch cannot be applied cleanly, even 3-way merge fails with: > > """ > git am > ../review/ofayans/freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch > -3 > Applying: Add test if replica is working after domain upgrade > error: invalid object 100644 acae5c924594cc73bf262eeab5f843f252723207 > for 'ipatests/test_integration/test_replica_promotion.py' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0001 Add test if replica is working after domain upgrade > """ > > I had to fall back to plain 'patch -p1' > > I have your previous patches 0033-0034 applied. The patch probably needs > a rebase. Fixed > > Also I would be more happy if the username for 'testuser' was not > hardcoded in the code. You can factor it out as a class member. > Done -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0035.1-Add-test-if-replica-is-working-after-domain-upgrade.patch Type: text/x-patch Size: 2528 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Wed Apr 13 08:53:30 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Wed, 13 Apr 2016 14:23:30 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160412090701.GA12547@mniranja.pnq.csb> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> Message-ID: <20160413085330.GA31535@mniranja.pnq.csb> Niranjan wrote: > Petr Viktorin wrote: > > On 04/06/2016 10:55 AM, Niranjan wrote: > > > Greetings, > > > > > > For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > > > a patch, I think this patch is more of a workaround , than a solution. I would > > > like to get more inputs on how to use pytest-multihost to execute commands > > > on Windows. The method i am using requires cygwin with openssh/bash to be > > > installed. > > > > Wow. I'm surprised the only problem on Windows is the "set -e". > > > > Regarding the patch: > > > > - Why is get_winhost_class needed? I don't see it called anywhere. > > - Similarly, why is host_type needed? Your patch only sets it. > > > > If run_command of WinHost and Unix hosts are this similar, I would put > > the 'set -e\n' for Unix (and an empty string for Windows) in a class > > attribute named e.g. "command_prelude", use it in run_command, and move > > run_command from Host to BaseHost. > > Would that work, or am I missing something? > How do we detect the host is windows/unix then , we still need host_type > to know what the type of host is (unix/windows)? > > > > > > -- > > Petr Viktorin Please review the attached patch. > -- > 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 -------------- From 5b01d7eb1bc3723201b6083a814467f87d865367 Mon Sep 17 00:00:00 2001 From: Niranjan MR Date: Tue, 12 Apr 2016 17:18:10 +0530 Subject: [PATCH] modify run_command to execute on Windows Add global parameter windows_test_dir to specify test directory for Windows Add parameter host_type(per host) to specify the type of host (host_type:windows) move run_command from Host class to BaseHost class Signed-off-by: Niranjan MR --- pytest_multihost/config.py | 3 ++ pytest_multihost/host.py | 87 +++++++++++++++++++++++++--------------------- 2 files changed, 50 insertions(+), 40 deletions(-) diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py index 31045c21e8ee67c1793f154f841375f8df7b365f..58a3a5fbc8dbcdaac35e3fd305f23999d5f5b09f 100644 --- a/pytest_multihost/config.py +++ b/pytest_multihost/config.py @@ -45,6 +45,7 @@ class Config(object): self.ssh_password = kwargs.get('ssh_password') self.ssh_username = kwargs.get('ssh_username', 'root') self.ipv6 = bool(kwargs.get('ipv6', False)) + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') if not self.ssh_password and not self.ssh_key_filename: self.ssh_key_filename = '~/.ssh/id_rsa' @@ -80,6 +81,8 @@ class Config(object): dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') if 'root_password' in dct: dct['ssh_password'] = dct.pop('root_password') + if 'windows_test_dir' in dct: + dct['windows_test_dir'] = dct.pop('windows_test_dir') all_init_args = set(init_args) | set(cls.extra_init_args) extra_args = set(dct) - all_init_args diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py index e6c0db50799b2042e699d66ed9ec5f04f6592d31..828ba81279b563e4c5d2735bc6396480f4152304 100644 --- a/pytest_multihost/host.py +++ b/pytest_multihost/host.py @@ -27,9 +27,13 @@ class BaseHost(object): transport_class = None def __init__(self, domain, hostname, role, ip=None, - external_hostname=None, username=None, password=None): + external_hostname=None, username=None, + password=None, windows_test_dir=None, + host_type=None): self.domain = domain self.role = str(role) + self.host_type = host_type + self.command_prelude = 'set -e\n' if username is None: self.ssh_username = self.config.ssh_username else: @@ -40,6 +44,8 @@ class BaseHost(object): else: self.ssh_key_filename = None self.ssh_password = password + if windows_test_dir is None: + self.windows_test_dir = self.config.windows_test_dir shortname, dot, ext_domain = hostname.partition('.') self.shortname = shortname @@ -118,11 +124,13 @@ class BaseHost(object): username = dct.pop('username', None) password = dct.pop('password', None) + windows_test_dir = dct.pop('windows_test_dir', None) + host_type = dct.pop('host_type', None) check_config_dict_empty(dct, 'host %s' % hostname) return cls(domain, hostname, role, ip, external_hostname, - username, password) + username, password, windows_test_dir, host_type) def to_dict(self): """Export info about this Host to a dict""" @@ -131,6 +139,8 @@ class BaseHost(object): 'ip': self.ip, 'role': self.role, 'external_hostname': self.external_hostname, + 'windows_test_dir': self.windows_test_dir, + 'host_type': self.host_type } @property @@ -199,54 +209,51 @@ class BaseHost(object): be sourced before running the command. :param stdin_text: If given, will be written to the command's stdin :param log_stdout: If false, standard output will not be logged - (but will still be available as cmd.stdout_text) + (but will still be available as cmd.stdout_text) :param raiseonerr: If true, an exception will be raised if the command does not exit with return code 0 :param cwd: The working directory for the command """ - raise NotImplementedError() + command = self.transport.start_shell(argv, log_stdout=log_stdout) + #set working directory + if cwd is None: + if self.host_type == 'windows': + cwd = self.config.windows_test_dir + else: + cwd = self.config.test_dir + command.stdin.write('cd %s\n' % shell_quote(cwd)) + + #set the environment + if set_env: + command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) + + if self.host_type != 'windows': + command.stdin.write(self.command_prelude) + + if isinstance(argv, basestring): + #Run a shell command given as string + command.stdin.write('(') + command.stdin.write(argv) + command.stdin.write(')') + else: + # Run a command given as a popen-style list (no shell expansion) + for arg in argv: + command.stdin.write(shell_quote(arg)) + command.stdin.write(' ') + + command.stdin.write(';exit\n') + if stdin_text: + command.stdin.write(stdin_text) + command.stdin.flush() + + command.wait(raiseonerr=raiseonerr) + return command class Host(BaseHost): """A Unix host""" transport_class = transport.SSHTransport - def run_command(self, argv, set_env=True, stdin_text=None, - log_stdout=True, raiseonerr=True, - cwd=None): - # This will give us a Bash shell - command = self.transport.start_shell(argv, log_stdout=log_stdout) - - # Set working directory - if cwd is None: - cwd = self.config.test_dir - command.stdin.write('cd %s\n' % shell_quote(cwd)) - - # Set the environment - if set_env: - command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) - command.stdin.write('set -e\n') - - if isinstance(argv, basestring): - # Run a shell command given as a string - command.stdin.write('(') - command.stdin.write(argv) - command.stdin.write(')') - else: - # Run a command given as a popen-style list (no shell expansion) - for arg in argv: - command.stdin.write(shell_quote(arg)) - command.stdin.write(' ') - - command.stdin.write(';exit\n') - if stdin_text: - command.stdin.write(stdin_text) - command.stdin.flush() - - command.wait(raiseonerr=raiseonerr) - return command - - class WinHost(BaseHost): """ Representation of a remote Windows host. -- 1.8.3.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From akasurde at redhat.com Wed Apr 13 09:42:01 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 13 Apr 2016 15:12:01 +0530 Subject: [Freeipa-devel] [PATCH] Added fix for notifying user about account expiration in Web UI In-Reply-To: <56F12632.40903@redhat.com> References: <56EC00CC.2080300@redhat.com> <56EC0C2A.3020009@redhat.com> <56F12632.40903@redhat.com> Message-ID: <570E1469.3050500@redhat.com> Ping On 03/22/2016 04:32 PM, Abhijeet Kasurde wrote: > Hi All, > > Please find the updated patches as per review comments. > > On 03/18/2016 07:39 PM, Petr Vobornik wrote: >> On 03/18/2016 02:21 PM, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> Please review these patches. >>> >>> Fixes : https://fedorahosted.org/freeipa/ticket/5077 >>> >>> Thanks, >>> Abhijeet Kasurde >>> >> >> 'invalid' is a default and right now is meant for invalid >> password(not correct, see below). So by reading the patch, it will >> break the case when user sets invalid password. >> >> Better would be to process kinit output in >> rpcserver.py:login_password and set e.g: 'krbprincipal-expired' reason. >> >> Then add it to a list of known errors in ipa.js:login_password:498. >> We should probaly add also 'invalid-password' to the list. >> >> Then do the change as in this patch but only with: >> 'krbprincipal-expired'. >> >> If 'invalid-password' is added to the list of know errors then we >> should change the default error from "The password or username you >> entered is incorrect. " to e.g.: 'Login failed from unknown reason" >> > Thanks Petr for suggestions. > > Thanks, > Abhijeet Kasurde > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Wed Apr 13 10:24:48 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 13 Apr 2016 12:24:48 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <5707C431.6070702@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> <5707C431.6070702@redhat.com> Message-ID: <570E1E70.6060309@redhat.com> Please. disregard my previous patch-0014: it doesn't pass pylint. The newer one does. On 04/08/2016 04:46 PM, Oleg Fayans wrote: > Hi all, > > It's been a while, and now the patch seems to be stable. It does hit one > known issue with replica installation occationally [1], but other than > that works fine on both domain levels. > > [1] https://fedorahosted.org/freeipa/ticket/5758 > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0014.4-Actualized-ca-less-tests.patch Type: text/x-patch Size: 45168 bytes Desc: not available URL: From mbasti at redhat.com Wed Apr 13 11:40:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 Apr 2016 13:40:03 +0200 Subject: [Freeipa-devel] [PATCH 0024] ipa-replica-manage: added --suffix option for certain commands In-Reply-To: <5704FB3C.2050003@redhat.com> References: <56E29266.8000501@redhat.com> <56E6E43B.4050805@redhat.com> <56E7AADC.3060407@redhat.com> <56E7F642.8010109@redhat.com> <56E90C5C.2020703@redhat.com> <56E925D0.2080305@redhat.com> <56E9637B.5080307@redhat.com> <56F2B380.9030504@redhat.com> <1183297765.33667649.1458760420403.JavaMail.zimbra@redhat.com> <56F42D93.5050505@redhat.com> <56FBE818.80805@redhat.com> <5704FB3C.2050003@redhat.com> Message-ID: <570E3013.7030006@redhat.com> On 06.04.2016 14:04, Stanislav Laznicka wrote: > On 03/30/2016 04:52 PM, Martin Basti wrote: >> On 24.03.2016 19:10, Stanislav Laznicka wrote: >>> On 03/23/2016 08:13 PM, Martin Basti wrote: >>>> [...] >>>> Can you please update design >>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 (mainly >>>> the --suffix option)? Also there are missing clean-ruv and list-ruv >>>> commands in design, and fix usage at the bottom. >>>> >>>> 1) >>>> I don't understand this expression >>>> + if dirman_passwd is None or ( >>>> + not dirman_passwd and args[0] in cs_enabled_commands): >>>> >>>> You already tested if subcommand belongs to cs_enabled_commands few >>>> lines above, IMO the 'dirman_password is None' expression is enough. >>> If I understand it well, when empty password is entered, the program >>> continues and uses Kerberos credentials for some operations. E.g. >>> for list-ruv, if empty password is entered, the command would only >>> display RUVs for domain tree but not for the CA tree no matter if CA >>> is set up or not (in the current state of the patch, after get_ruv >>> refactoring). This here is one possible way around this, although >>> the check for non-empty password might probably just as well be in >>> get_ruv_both_suffixes. >> >> ok >>>> 2) >>>> +# tuple of commands that work with ca tree and need Directory Manager >>>> password >>>> +cs_enabled_commands = ("list-ruv", "clean-ruv", "abort-clean-ruv") >>>> >>>> this variable is used only toi detect if dirman passwd is needed, I >>>> suggest to rename it to commands_req_dirman_passwd, or something >>>> better. >>>> >>>> 3) >>>> Q: Do we need is_cs_set() function? >>>> A: Yes! >>>> >>>> I wanted to give you ultimate NACK, but then I checked how get_ruv >>>> code >>>> works and I changed my mind. >>>> >>>> Please write a comment where is_cs_set function is used, why we need >>>> extra function instead of catching an exception, possibly you can >>>> open a >>>> refactoring ticket. >>> After the refactoring changes, is_cs_set should not be needed >>> anymore, removed it. >>>> >>>> Shame: >>>> 1) >>>> + if not test_connection(realm, host, options.nolookup) or\ >>>> Please use parentheses instead of backslash >>>> >>>> 2) >>>> + args[0] in cs_enabled_commands: >>>> >>>> + not dirman_passwd and args[0] in cs_enabled_commands): >>>> >>>> Indentation is not multiplication of 4 >>> Shame on me indeed, fixed it. >>>> >>>> Nitpicks (I don't insist on fixing these): >>>> 1) >>>> + if servers.get('ca', None): >>>> >>>> None is default >>>> >>>> 2) >>>> + for (netloc, rid) in servers['ca']: >>>> parentheses are not needed >>>> >>>> 3) >>>> + print("\t%s: %s" % (netloc, rid)) >>>> Would be nice to use .format() instead of % >>>> >>>> Martin^2 >>>> >>>> >>>> >>>> I changed my mind, ultimate NACK. >>>> Please fix get_ruv function, is_cs_set will not help. In case there >>>> are no RUVs but CA is installed, sys.exit there prevents us from >>>> removing RUVs (or any else operation) on domain suffix, and vice >>>> versa. >>>> I propose to move ticket to 4.4 milestone because I would like to >>>> avoid breaking something in 4.3, as this will hit many places in >>>> ipa-replica-manage. >>>> >>>> Please provide the refactoring of get_ruv as separate patch a put >>>> these patches on top of it. >>>> >>>> Martin2 >>> Did the refactoring. There also seemed to be duplicit code in >>> abort_clean_ruv for some reason, removed it (I hope it does not >>> break anything, but it seemed rather useless). Also had to change >>> the numbers of the patches so that they would apply. >> >> NACK >> >> * ipa-replica-manage refactoring * >> >> 1) >> Instead of: >> - print("Failed to connect to server %s: %s" % (host, e)) >> - sys.exit(1) >> + root_logger.debug("Failed to connect to server {host}: {err}" >> + .format(host=host, err=e)) >> + raise RuntimeError(e) >> >> I expected >> >> - print("Failed to connect to server %s: %s" % (host, e)) >> - sys.exit(1) >> + root_logger.debug(traceback.format_exc()) >> + raise RuntimeError("Failed to connect to server {host}: {err}" >> + .format(host=host, err=e))) > Should be fixed now. >> >> 2) >> - print("No RUV records found.") >> - sys.exit(0) >> >> Here is exit state 0, so we should not raise error. >> >> I think that we should create new nonfatal exception. > Made a new nonfatal error exception, then. This step was a bit > controversial when it comes to get_ruv_both_suffixes because it needs > to catch both this new exception and a RuntimeError exception for both > trees. As the main idea here was not to stop if either tree is missing > (resulting in RuntimeError in get_ruv) or contains no records > (NonFatalError), it is only printed that something bad may have > happened (or it's debug-logged in case of nonfatal errors). In the > end, only NonFatalError exception is raised if no records were found > for whatever reason resulting in the script always returning 0. >> >> 3) >> - print("unable to decode: %s" % ruv) >> + root_logger.debug("unable to decode: %s" % ruv) >> This may break tests, because the logger logs to stderr, leave it as >> print for now >> >> 4) >> - servers = get_ruv(realm, host, dirman_passwd, nolookup) >> + try: >> + servers = get_ruv(realm, host, dirman_passwd, nolookup) >> + except RuntimeError as e: >> + print(e) >> + sys.exit(1) >> >> again we have to print it to stdout for now. > 3), 4) done, although it might be better to log to stderr from patch > number 27 and on since the default behavior is changed anyway. >> >> * abort-clean/list/clean-ruv now work for both suffixes * >> >> - if dirman_passwd is None: >> + if dirman_passwd is None or ( >> + not dirman_passwd and args[0] in >> dirman_passwd_req_commands): >> sys.exit("Directory Manager password required") > Done. >> >> Please fix other patch accordingly. >> Martin^2 > 1) +class NonFatalError(Exception): + pass IMO we should be more specific and call it NoRUVsFound[Exception] 2) Not sure if this i sstill refactoring, it should be separate patch - if dirman_passwd is None: + if dirman_passwd is None or ( + not dirman_passwd and args[0] in dirman_passwd_req_commands): 3) +def get_ruv_both_suffixes I think in case where both suffixes returns RuntimeError we should raise RuntimeError too which results into exit with error code. From tbabej at redhat.com Wed Apr 13 12:13:52 2016 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 13 Apr 2016 14:13:52 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides In-Reply-To: <570DFB66.9040207@redhat.com> References: <56FE8B5F.8040803@redhat.com> <570279B6.1070504@redhat.com> <20160407115302.GL4768@p.redhat.com> <570DFB66.9040207@redhat.com> Message-ID: <570E3800.1060700@redhat.com> On 04/13/2016 09:55 AM, Tomas Babej wrote: > On 04/07/2016 01:53 PM, Sumit Bose wrote: >> On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 1.4.2016 16:53, Tomas Babej wrote: >>>> Hi, >>>> >>>> this extends the user ID overrides with capability to store the user >>>> certificate. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4955 >>> >>> The preferred way of managing certificates nowadays is using $OBJ-add-cert >>> and $OBJ-remove-cert commands, you should add them here as well. >>> >>> I would even go as far as not allowing to modify certificates using >>> idoverrideuser-mod - in user-mod and host-mod, it's there just for backward >>> compatibility, which is not the case here. But I don't have a strong opinion >>> on that. >>> >>> For consistency with user-find and host-find, the full certificate blob >>> should not be shown in idoverrideuser-find. You can do that by setting >>> search_display_attributes attribute on the idoverrideuser class >>> appropriately. >> >> I tested the current patch with my related patches for SSSD and all is >> working as expected. >> >> bye, >> Sumit >> >>> >>> 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 >> > > Thanks for the reviews, > > attaching a updated patch that addresses Honza's comments. > > Tomas > Sending an improved version addressing a couple of additional issues. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0405-3-idviews-Add-user-certificate-attribute-to-user-ID-ov.patch Type: text/x-patch Size: 14551 bytes Desc: not available URL: From pvomacka at redhat.com Wed Apr 13 12:56:48 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 13 Apr 2016 14:56:48 +0200 Subject: [Freeipa-devel] [PATCH] 0013 webui: Add ability to convert users from preserved to staged state Message-ID: <570E4210.1090409@redhat.com> Hello, This patch adds ability to convert users from preserved to staged state. Fixes this ticket: https://fedorahosted.org/freeipa/ticket/5371 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0013-Add-ability-to-convert-users-from-preserved-to-stage.patch Type: text/x-patch Size: 8379 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 13 14:01:45 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 13 Apr 2016 16:01:45 +0200 Subject: [Freeipa-devel] [PATCH 0453 - 0458] host-del: fix updatedns option In-Reply-To: <56FEA235.9010202@redhat.com> References: <56FEA235.9010202@redhat.com> Message-ID: <570E5149.8020205@redhat.com> On 1.4.2016 18:30, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5675 > > Patches attached. NACK, it breaks if the client does not have any corresponding DNS record. [root at vm-033 git]# ipa host-add host.test. --force ---------------------- Added host "host.test" ---------------------- Host name: host.test Principal name: host/host.test at DOM-033.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM Password: False Keytab: False Managed by: host.test [root at vm-033 git]# ipa host-del host.test. --updatedns ipa: ERROR: host.test: host not found I think we already had a ticket to prevent this kind of error, no? -- Petr^2 Spacek From mbasti at redhat.com Wed Apr 13 14:05:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 Apr 2016 16:05:49 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Fixed failing legacy client tests In-Reply-To: <570D12F8.6010105@redhat.com> References: <570CBDBF.6040305@redhat.com> <570D12F8.6010105@redhat.com> Message-ID: <570E523D.7080309@redhat.com> On 12.04.2016 17:23, Martin Babinsky wrote: > On 04/12/2016 11:19 AM, Oleg Fayans wrote: >> >> >> > ACK. > Pushed to: master: 280f1ed85f40a0d123fc891f9ad02a4fff4a363b ipa-4-3: 488dcd3e94a5d6c791baff8cb2f07530072b1d31 From mbabinsk at redhat.com Wed Apr 13 14:26:52 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Apr 2016 16:26:52 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <570DDE0E.5070006@redhat.com> References: <5707C9F2.8060903@redhat.com> <570DDE0E.5070006@redhat.com> Message-ID: <570E572C.9090806@redhat.com> On 04/13/2016 07:50 AM, David Kupka wrote: > On 08/04/16 17:10, Martin Babinsky wrote: >> Hi list, >> >> I have put together a draft [1] outlining the effort to reimplement the >> handling of Kerberos principals in both backend and frontend layers of >> FreeIPA so that we may have multiple aliases per user, host or service >> and thus implement stuff like >> https://fedorahosted.org/freeipa/ticket/3961 and >> https://fedorahosted.org/freeipa/ticket/5413 . >> >> Since much of the plumbing was already implemented,[2] the document >> mainly describes what the patches do. Some parts required by other use >> cases may be missing so please point these out. >> >> I would also be happy if you could correct all factual inacurracies, I >> did research on this issue a long time ago and my knowledge turned a bit >> rusty. >> >> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >> [2] >> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >> > > Hi, > after reading the designs following thoughts comes to my mind. > > 1) Just to be sure that I understand the new ticket obtaining process > correctly I'd like to summarize. > We need to always search all krbPrincipalName values, krbCanonicalName > and ipaKrbPrincipalAlias (for backward compatibility). > For TGT request case sensitivity of the search and principal in returned > ticket depends on canonicalization. When canonicalization is requested > the search is case-insensitive and krbCanonicalName is used otherwise > case-sensitive search is performed and principal from request is used. > When requesting TGS search is always case-sensitive and principal from > request is used. > > In pseudo-code: > > get_tgt(principal, secret, canonicalization) > if canonicalization > if principal case-insensitive-in {krbPrincipalName + > ipaKrbPrincipalAlias + krbCanonicalName} > # verify secret, perform various other checks... > return TGT(krbCanonicalName) > else > if principal case-sensitive-in {krbPrincipalName + > ipaKrbPrincipalAlias + krbCanonicalName} > # verify secret, perform various other checks... > return TGT(principal) > > get_tgs(service_principal, TGT) > if service_principal case-sensitive-in {krbPrincipalName + > ipaKrbPrincipalAlias + krbCanonicalName} > # verify TGT, perform various other checks... > return TGS(service_principal) > > Do I understand it right? > > 2) I would like to add following constrains for > krb{Canonical,Principal}Name attributes: > > when user/host/service is created krbCanonicalName is set to the same > value as krbPrincipalName > krbCanonicalName cannot be modified > krbPrincipalName with the same value as krbCanonicalName cannot be > removed/modified > krbPrincipalName must be case-insensitively unique in whole DB > krbPrincipalName attributes can be added and/or removed > I will definitwly add this constraints into the design. > This will allow us to keep the first krbPrincipalName as RDN for > services/hosts and give the flexibility of adding/removing aliases. > > 'Change of username' use case is also solvable with this approach. When > username is changed we add krbPrincipalName with the new username. That > will allow user to login with either old or new name. > > 3) ad CLI: > {user,host,service}-add - Can canonicalname be specified? Or will it > take principal argument/option value? > Can we add {user,host,service}-{add,remove}-principal set of commands > for principal manipulation? I really don't want to use > --{add,set,del}-attr unless necessary. I have added the commands to the design. > Will {user,host,service}-{show,find} display krbCanonicalName by default > or only with --all option? > IIRC it should be printed out only when '--all' is requested. > 4) ad Upgrade: > I think it would be worth to check and document what happens during > upgrade of multiple replicas. There may be confusing behavior when > obtaining tickets. KDC behavior will differ among servers and since > autodiscovery is in use we don't know if we are talking to the old or > new server. I'm not sure what exactly will happen but I suspect it won't > be nice. > I will test this but I expected that 'kinit -C' will get back TGT with different principal for different replica (old vs. new) for newly added entries (the old entries will behave the same as before). That may not be what we want, but I can not think of any way to amend this. What we forgot to discuss is the handling of krbCanonicalName during MODRDN operation, e.g. when username is changed. Currently the design assumes that when uid changes the MODRDN plugin will change krbCanonicalName attribute to reflect this change, e.g. uid: jsmith->johns krbCanonicalName: jsmith at REALM -> krbCanoncialName: johns at REALM I remember talking with Simo (CC'ed) that this is the desired behavior but I am not sure if this still holds. -- Martin^3 Babinsky From mbasti at redhat.com Wed Apr 13 14:31:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 Apr 2016 16:31:53 +0200 Subject: [Freeipa-devel] [PATCH 0453 - 0458, 0460] host-del: fix updatedns option In-Reply-To: <570E5149.8020205@redhat.com> References: <56FEA235.9010202@redhat.com> <570E5149.8020205@redhat.com> Message-ID: <570E5859.6000701@redhat.com> On 13.04.2016 16:01, Petr Spacek wrote: > On 1.4.2016 18:30, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5675 >> >> Patches attached. > NACK, it breaks if the client does not have any corresponding DNS record. > > [root at vm-033 git]# ipa host-add host.test. --force > ---------------------- > Added host "host.test" > ---------------------- > Host name: host.test > Principal name: host/host.test at DOM-033.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM > Password: False > Keytab: False > Managed by: host.test > > [root at vm-033 git]# ipa host-del host.test. --updatedns > ipa: ERROR: host.test: host not found > > I think we already had a ticket to prevent this kind of error, no? > This will be resolved in https://fedorahosted.org/freeipa/ticket/5627 Patch 460 attached, feel free to review both tickets :) (Patch requires my previous DNS patches) Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0460-host-del-updatedns-print-warnings-instead-of-error.patch Type: text/x-patch Size: 3923 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 13 14:48:43 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 13 Apr 2016 16:48:43 +0200 Subject: [Freeipa-devel] [PATCH 0143-0144] different errors/warnings for different LDAP limit type exceeded In-Reply-To: <5707CAA7.6060602@redhat.com> References: <56EBCA37.6020306@redhat.com> <56EBF959.3060807@redhat.com> <56EFBC2C.8030300@redhat.com> <56EFDA20.9090005@redhat.com> <56F1608A.4060805@redhat.com> <56F16481.9070304@redhat.com> <56F40464.7000804@redhat.com> <56FE95B0.90501@redhat.com> <5707CAA7.6060602@redhat.com> Message-ID: <570E5C4B.4090307@redhat.com> On 8.4.2016 17:13, Martin Babinsky wrote: > On 04/01/2016 05:37 PM, Martin Babinsky wrote: >> On 03/24/2016 04:14 PM, Martin Babinsky wrote: >>> On 03/22/2016 04:28 PM, Rob Crittenden wrote: >>>> Martin Babinsky wrote: >>>>> On 03/21/2016 12:25 PM, Jan Cholasta wrote: >>>>>> On 21.3.2016 10:17, Petr Spacek wrote: >>>>>>> On 18.3.2016 13:49, Rob Crittenden wrote: >>>>>>>> Martin Babinsky wrote: >>>>>>>>> These patches implement behavior agreed upon during discussion of >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5677 >>>>>>>>> >>>>>>>>> However I'm not sure if we want to push them into 4-3 branch (the >>>>>>>>> ticket >>>>>>>>> is triaged into 4.3.2 milestone) since they modify the framework >>>>>>>>> behavior quite a bit. >>>>>>>>> >>>>>>>>> If there is no need to have it there (CC'ing Milan since he is the >>>>>>>>> reporter), I would retriage it into 4.4 milestone. >>>>>>>> >>>>>>>> >>>>>>>> + desc="while getting entries (search base: '{}'," >>>>>>>> + "filter: {})".format(base_dn, filter)) >>>>>>>> >>>>>>>> This is going to expose parts of the DIT in an error message to >>>>>>>> users. We have >>>>>>>> tried in the past to hide the implementation. I'd propose logging >>>>>>>> the >>>>>>>> error >>>>>>>> and making the exception less verbose. >>>>>> >>>>>> I agree with Rob here, we shouldn't expose internal stuff in error >>>>>> messages for users. >>>>>> >>>>>> In this particular case, even if we included internal stuff in the >>>>>> error >>>>>> message, it should be the error message returned by the server rather >>>>>> than this ad-hoc message. >>>>>> >>>>>>> >>>>>>> IMHO it actually helps to print the DN. At very least the user can >>>>>>> see >>>>>>> if the >>>>>>> error is happening always with the same DN or if it keeps changing. >>>>>>> >>>>>>> In other words, for user it is not that important to understand >>>>>>> meaning of the >>>>>>> DN but it might be important to see if it is the same or not. >>>>>> >>>>>> I can't imagine a situation where it would actually be useful for the >>>>>> user (as opposed to the admin, who has access to logs) to know the >>>>>> base >>>>>> DN of some arbitrary LDAP search operation. Could you give an example? >>>>>> >>>>> Right, attaching updated patches. >>>> >>>> I may have suggested debug logging the detailed error. I was wrong. This >>>> should log at the error level so it always appears in the logs. This may >>>> be a spurious error and having the user turn on debug logging to capture >>>> the reasons would be asking a lot. >>>> >>>> rob >>> That's right, the user would then have to enable debug mode and re-run >>> the command. I have changed the log level to error as you suggested. >>> >>> >>> >> Bump for review. >> > Moar bumps. ACK, sorry for the delay! -- Petr^2 Spacek From mbabinsk at redhat.com Wed Apr 13 14:49:11 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 13 Apr 2016 16:49:11 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology Message-ID: <570E5C67.40201@redhat.com> This is a WIP patch which moves the `ipa-replica-manage del` subcommand to the 'server-del' API method and exposes it as CLI command[1]. A CI test suite is also included. There are some issues with the patch I would like to discuss in more detail on the list: 1.) In the original subcommand there was a lot of output (mostly print statements) during all stages of master removal. I have tried to port these as messages to the command which results in quite voluminous response sent back to the frontend. Should we try to reduce the output? 2.) In the original discussion[2] we assumed that the cleanup part would me a separate API method called during server_del postcallback. However since the two objects ended up sharing a lot of state (e.g. topology state from pre-callback, messages) i have merged it to server-del. That makes the code rather unwieldy but I found it difficult to keep the two entities separate without some hacking around framework capabilities 3.) since actions in post-callback require a knowledge about topology state gathered in pre-callback, I had to store some information in the command's context. Sorry about that, if you know about some way to circumvent me, let me know. 4.) The master can not remove itself. I have implemented an ad-hoc forwarding of the request to other master that can do the job. Is this okay? 5.) Since the original behavior of 'chekc_deleted_segments' was kept, the code can sometimes hang waiting for removal of some segments, especially during forced removal in wonky topologies. This can cause gateway timeout in JSON-RPC call and report false positive error back to the user. This makes a large part of 'TestServerDel' suite to fail. How should we handle this? Should we keep the original behavior? 6.) There are some in-place imports of server-side code in some places. I'm not very happy about it and would be glad if we can agree on a way to fix this. [1] https://fedorahosted.org/freeipa/ticket/5588 [2] https://www.redhat.com/archives/freeipa-devel/2016-March/msg00335.html -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-WIP-integration-test-suite-for-server-del.patch Type: text/x-patch Size: 15810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-WIP-server-del-perform-full-master-removal-in-managed-to.patch Type: text/x-patch Size: 24820 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 13 15:05:27 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 13 Apr 2016 17:05:27 +0200 Subject: [Freeipa-devel] [PATCH 0453 - 0458, 0460] host-del: fix updatedns option In-Reply-To: <570E5859.6000701@redhat.com> References: <56FEA235.9010202@redhat.com> <570E5149.8020205@redhat.com> <570E5859.6000701@redhat.com> Message-ID: <570E6037.6020901@redhat.com> On 13.4.2016 16:31, Martin Basti wrote: > > > On 13.04.2016 16:01, Petr Spacek wrote: >> On 1.4.2016 18:30, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5675 >>> >>> Patches attached. >> NACK, it breaks if the client does not have any corresponding DNS record. >> >> [root at vm-033 git]# ipa host-add host.test. --force >> ---------------------- >> Added host "host.test" >> ---------------------- >> Host name: host.test >> Principal name: host/host.test at DOM-033.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >> Password: False >> Keytab: False >> Managed by: host.test >> >> [root at vm-033 git]# ipa host-del host.test. --updatedns >> ipa: ERROR: host.test: host not found >> >> I think we already had a ticket to prevent this kind of error, no? >> > > This will be resolved in https://fedorahosted.org/freeipa/ticket/5627 > > Patch 460 attached, feel free to review both tickets :) > (Patch requires my previous DNS patches) ACK -- Petr^2 Spacek From pspacek at redhat.com Wed Apr 13 15:05:52 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 13 Apr 2016 17:05:52 +0200 Subject: [Freeipa-devel] [PATCH 0453 - 0458] host-del: fix updatedns option In-Reply-To: <570E5149.8020205@redhat.com> References: <56FEA235.9010202@redhat.com> <570E5149.8020205@redhat.com> Message-ID: <570E6050.2020004@redhat.com> On 13.4.2016 16:01, Petr Spacek wrote: > On 1.4.2016 18:30, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5675 >> >> Patches attached. > > NACK, it breaks if the client does not have any corresponding DNS record. > > [root at vm-033 git]# ipa host-add host.test. --force > ---------------------- > Added host "host.test" > ---------------------- > Host name: host.test > Principal name: host/host.test at DOM-033.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM > Password: False > Keytab: False > Managed by: host.test > > [root at vm-033 git]# ipa host-del host.test. --updatedns > ipa: ERROR: host.test: host not found > > I think we already had a ticket to prevent this kind of error, no? ACK as this is solved by separate patch. -- Petr^2 Spacek From rcritten at redhat.com Wed Apr 13 15:10:52 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Apr 2016 11:10:52 -0400 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570E5C67.40201@redhat.com> References: <570E5C67.40201@redhat.com> Message-ID: <570E617C.3060503@redhat.com> Martin Babinsky wrote: > This is a WIP patch which moves the `ipa-replica-manage del` subcommand > to the 'server-del' API method and exposes it as CLI command[1]. A CI > test suite is also included. > > There are some issues with the patch I would like to discuss in more > detail on the list: > > 1.) In the original subcommand there was a lot of output (mostly print > statements) during all stages of master removal. I have tried to port > these as messages to the command which results in quite voluminous > response sent back to the frontend. Should we try to reduce the output? I don't think it applies anymore. These messages were there so the user would know something was happening. If it is an API command there isn't much we can do other than add something to the cli to print "This could take a bit" before making the call. > 2.) In the original discussion[2] we assumed that the cleanup part would > me a separate API method called during server_del postcallback. However > since the two objects ended up sharing a lot of state (e.g. topology > state from pre-callback, messages) i have merged it to server-del. That > makes the code rather unwieldy but I found it difficult to keep the two > entities separate without some hacking around framework capabilities I haven't looked at the code but as a general principal having separate operations has saved our bacon on more than one occasion. > 3.) since actions in post-callback require a knowledge about topology > state gathered in pre-callback, I had to store some information in the > command's context. Sorry about that, if you know about some way to > circumvent me, let me know. Looks like it is the only way since you are extending server_del. Another option would be to drop pre/post and add all this topology stuff directly to server_del execute. > 4.) The master can not remove itself. I have implemented an ad-hoc > forwarding of the request to other master that can do the job. Is this > okay? Assisted suicide? What does this effectively do? Potentially disconnect it from the topology, perhaps to run as standalone for upgrade, integration or other testing (e.g. there might be valid reasons to do this)? If so that seems ok to me, or if too hacky you could just spit out a message directing them to disconnect from another host, but that would be strange in the UI I think. > 5.) Since the original behavior of 'chekc_deleted_segments' was kept, > the code can sometimes hang waiting for removal of some segments, > especially during forced removal in wonky topologies. This can cause > gateway timeout in JSON-RPC call and report false positive error back to > the user. This makes a large part of 'TestServerDel' suite to fail. How > should we handle this? Should we keep the original behavior? Oh to have async calls... I wonder if "I'm still here" messages could be sent. I'm not entirely sure this is possible with the framework but it might be one way to keep long-lived connections alive. > 6.) There are some in-place imports of server-side code in some places. > I'm not very happy about it and would be glad if we can agree on a way > to fix this. Is this to prevent imports on non-servers? You might look at trust for inspiration, it does this. rob > > [1] https://fedorahosted.org/freeipa/ticket/5588 > [2] https://www.redhat.com/archives/freeipa-devel/2016-March/msg00335.html > > > From mbasti at redhat.com Wed Apr 13 15:43:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 Apr 2016 17:43:18 +0200 Subject: [Freeipa-devel] [PATCH 0459] use python-netifaces for detection of the local ip addresses Message-ID: <570E6916.4030301@redhat.com> https://fedorahosted.org/freeipa/ticket/5591 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0459-Use-netifaces-module-instead-of-ip-command.patch Type: text/x-patch Size: 6280 bytes Desc: not available URL: From mbasti at redhat.com Wed Apr 13 15:46:27 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 Apr 2016 17:46:27 +0200 Subject: [Freeipa-devel] [PATCH 0453 - 0458] host-del: fix updatedns option In-Reply-To: <570E6050.2020004@redhat.com> References: <56FEA235.9010202@redhat.com> <570E5149.8020205@redhat.com> <570E6050.2020004@redhat.com> Message-ID: <570E69D3.2060805@redhat.com> On 13.04.2016 17:05, Petr Spacek wrote: > On 13.4.2016 16:01, Petr Spacek wrote: >> On 1.4.2016 18:30, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5675 >>> >>> Patches attached. >> NACK, it breaks if the client does not have any corresponding DNS record. >> >> [root at vm-033 git]# ipa host-add host.test. --force >> ---------------------- >> Added host "host.test" >> ---------------------- >> Host name: host.test >> Principal name: host/host.test at DOM-033.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >> Password: False >> Keytab: False >> Managed by: host.test >> >> [root at vm-033 git]# ipa host-del host.test. --updatedns >> ipa: ERROR: host.test: host not found >> >> I think we already had a ticket to prevent this kind of error, no? > ACK as this is solved by separate patch. > pushed to master: * 40e3a0bf63c766fc281517c9d192907376c2d353 host_del: fix removal of host records * 9a0f92be0dc1dc22827c918b5808b1ccb4e4b409 host_del: replace dns-record find command with show * bea066c33647c16a7b18deb1392838acb831ac88 host_del: remove unneeded dnszone-show command call * 1e70d6b914656d670f9afed26ccd5f93e3aa54d5 host_del: split removing A/AAAA and PTR records to separate functions * e8c8134eee159fa6eb7c8f2156c328798abdda80 host_del: remove only A, AAAA, SSHFP, PTR records * 54e3859595e1f5f2e669b8af20afdac1187d8cd7 host_del: update help for --updatedns option From mbasti at redhat.com Wed Apr 13 15:50:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 Apr 2016 17:50:16 +0200 Subject: [Freeipa-devel] [PATCH 0453 - 0458, 0460] host-del: fix updatedns option In-Reply-To: <570E6037.6020901@redhat.com> References: <56FEA235.9010202@redhat.com> <570E5149.8020205@redhat.com> <570E5859.6000701@redhat.com> <570E6037.6020901@redhat.com> Message-ID: <570E6AB8.8000104@redhat.com> On 13.04.2016 17:05, Petr Spacek wrote: > On 13.4.2016 16:31, Martin Basti wrote: >> >> On 13.04.2016 16:01, Petr Spacek wrote: >>> On 1.4.2016 18:30, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5675 >>>> >>>> Patches attached. >>> NACK, it breaks if the client does not have any corresponding DNS record. >>> >>> [root at vm-033 git]# ipa host-add host.test. --force >>> ---------------------- >>> Added host "host.test" >>> ---------------------- >>> Host name: host.test >>> Principal name: host/host.test at DOM-033.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>> Password: False >>> Keytab: False >>> Managed by: host.test >>> >>> [root at vm-033 git]# ipa host-del host.test. --updatedns >>> ipa: ERROR: host.test: host not found >>> >>> I think we already had a ticket to prevent this kind of error, no? >>> >> This will be resolved in https://fedorahosted.org/freeipa/ticket/5627 >> >> Patch 460 attached, feel free to review both tickets :) >> (Patch requires my previous DNS patches) > ACK > Pushed to master: b23ad42269c606f234f4f8c545e3c763e648f551 From mbasti at redhat.com Wed Apr 13 15:53:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 13 Apr 2016 17:53:13 +0200 Subject: [Freeipa-devel] [PATCH 0143-0144] different errors/warnings for different LDAP limit type exceeded In-Reply-To: <570E5C4B.4090307@redhat.com> References: <56EBCA37.6020306@redhat.com> <56EBF959.3060807@redhat.com> <56EFBC2C.8030300@redhat.com> <56EFDA20.9090005@redhat.com> <56F1608A.4060805@redhat.com> <56F16481.9070304@redhat.com> <56F40464.7000804@redhat.com> <56FE95B0.90501@redhat.com> <5707CAA7.6060602@redhat.com> <570E5C4B.4090307@redhat.com> Message-ID: <570E6B69.4040003@redhat.com> On 13.04.2016 16:48, Petr Spacek wrote: > On 8.4.2016 17:13, Martin Babinsky wrote: >> On 04/01/2016 05:37 PM, Martin Babinsky wrote: >>> On 03/24/2016 04:14 PM, Martin Babinsky wrote: >>>> On 03/22/2016 04:28 PM, Rob Crittenden wrote: >>>>> Martin Babinsky wrote: >>>>>> On 03/21/2016 12:25 PM, Jan Cholasta wrote: >>>>>>> On 21.3.2016 10:17, Petr Spacek wrote: >>>>>>>> On 18.3.2016 13:49, Rob Crittenden wrote: >>>>>>>>> Martin Babinsky wrote: >>>>>>>>>> These patches implement behavior agreed upon during discussion of >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5677 >>>>>>>>>> >>>>>>>>>> However I'm not sure if we want to push them into 4-3 branch (the >>>>>>>>>> ticket >>>>>>>>>> is triaged into 4.3.2 milestone) since they modify the framework >>>>>>>>>> behavior quite a bit. >>>>>>>>>> >>>>>>>>>> If there is no need to have it there (CC'ing Milan since he is the >>>>>>>>>> reporter), I would retriage it into 4.4 milestone. >>>>>>>>> >>>>>>>>> + desc="while getting entries (search base: '{}'," >>>>>>>>> + "filter: {})".format(base_dn, filter)) >>>>>>>>> >>>>>>>>> This is going to expose parts of the DIT in an error message to >>>>>>>>> users. We have >>>>>>>>> tried in the past to hide the implementation. I'd propose logging >>>>>>>>> the >>>>>>>>> error >>>>>>>>> and making the exception less verbose. >>>>>>> I agree with Rob here, we shouldn't expose internal stuff in error >>>>>>> messages for users. >>>>>>> >>>>>>> In this particular case, even if we included internal stuff in the >>>>>>> error >>>>>>> message, it should be the error message returned by the server rather >>>>>>> than this ad-hoc message. >>>>>>> >>>>>>>> IMHO it actually helps to print the DN. At very least the user can >>>>>>>> see >>>>>>>> if the >>>>>>>> error is happening always with the same DN or if it keeps changing. >>>>>>>> >>>>>>>> In other words, for user it is not that important to understand >>>>>>>> meaning of the >>>>>>>> DN but it might be important to see if it is the same or not. >>>>>>> I can't imagine a situation where it would actually be useful for the >>>>>>> user (as opposed to the admin, who has access to logs) to know the >>>>>>> base >>>>>>> DN of some arbitrary LDAP search operation. Could you give an example? >>>>>>> >>>>>> Right, attaching updated patches. >>>>> I may have suggested debug logging the detailed error. I was wrong. This >>>>> should log at the error level so it always appears in the logs. This may >>>>> be a spurious error and having the user turn on debug logging to capture >>>>> the reasons would be asking a lot. >>>>> >>>>> rob >>>> That's right, the user would then have to enable debug mode and re-run >>>> the command. I have changed the log level to error as you suggested. >>>> >>>> >>>> >>> Bump for review. >>> >> Moar bumps. > ACK, sorry for the delay! > pushed to master: * 1f0959735f9828a09439f17f1468dcd3dfb914db differentiate between limit types when LDAP search exceeds configured limits * 62bb478e112cd4677e681f4750c5f5e5c9221607 specify type of exceeded limit when warning about truncated search results From jcholast at redhat.com Thu Apr 14 06:14:57 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 Apr 2016 08:14:57 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5704CF86.3000709@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> Message-ID: <570F3561.5090403@redhat.com> On 6.4.2016 10:57, Petr Spacek wrote: > On 6.4.2016 10:50, Jan Cholasta wrote: >> On 4.4.2016 13:51, Petr Spacek wrote: >>> On 4.4.2016 13:39, Martin Basti wrote: >>>> >>>> >>>> On 31.03.2016 09:58, Petr Spacek wrote: >>>>> On 26.2.2016 15:37, Petr Spacek wrote: >>>>>> On 25.2.2016 16:46, Simo Sorce wrote: >>>>>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>>>>> Variant C >>>>>>>>>> --------- >>>>>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>>>>> the first >>>>>>>>>> round ... >>>>>>>>>> >>>>>>>>>> We would retain >>>>>>>>>> [first step - no change from variant A] >>>>>>>>>> * create locations >>>>>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>>>>> manually >>>>>>>>>> input (server, weight) tuples >>>>>>>>>> >>>>>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>>>>> from all >>>>>>>>>> other locations. >>>>>>>>>> >>>>>>>>>> Additional storage complexity: 0 >>>>>>>>>> >>>>>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>>>>> only as >>>>>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>>>>> >>>>>>>>>> This might be sufficient for the first run and would allow us to >>>>>>>>>> gather some >>>>>>>>>> feedback from the field. >>>>>>>>>> >>>>>>>>>> Now I'm inclined to this variant :-) >>>>>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>>>>> >>>>>>>>> To recap: >>>>>>>>> - define a location with the list of servers (perhaps location is a >>>>>>>>> property of server objects so you can have only one location per server, >>>>>>>>> and if you remove the server it is automatically removed from the >>>>>>>>> location w/o additional work or referential integrity necessary), if >>>>>>>>> weight is not defined (default) then they all have the same weight. >>>>>>>> Agreed. >>>>>>>> >>>>>>>> >>>>>>>>> - Allow to specify backup locations in the location object, priorities >>>>>>>>> are calculated automatically and all backup locations have same weight. >>>>>>>> Hmm, weights have to be inherited form the original location in all >>>>>>>> cases. Did >>>>>>>> you mean that all backup locations have the same *priority*? >>>>>>> Yes, sorry. >>>>>>> >>>>>>>> Anyway, explicit configuration of backup locations is introducing API and >>>>>>>> schema for variant A and that is what I'm questioning above. It is hard to >>>>>>>> make it extensible so we do not have headache in future when somebody >>>>>>>> decides >>>>>>>> that more flexibility is needed OR that link-based approach is better. >>>>>>> I think no matter we do we'll need to allow admins to override backup >>>>>>> locations, in future if we can calculate them automatically admins will >>>>>>> simply not set any backup location explicitly (or set some special value >>>>>>> like "autogenerate" and the system will do it for them. >>>>>>> >>>>>>> Forcing admins to mentally calculate weights to force the system to >>>>>>> autogenerate the configuration they want would be a bad experience, I >>>>>>> personally would find it very annoying. >>>>>>> >>>>>>>> In other words, for doing what you propose above we would have to design >>>>>>>> complete schema and API for variant A anyway to make sure we do not lock >>>>>>>> ourselves, so we are not getting any saving by doing so. >>>>>>> A seemed much more complicated to me, as you wanted to define a ful >>>>>>> matrix for weights of servers when they are served as backups and all >>>>>>> that. >>>>>>> >>>>>>>>> - Define a *default* location, which is the backup for any other >>>>>>>>> location but always with lower priority to any other explicitly defined >>>>>>>>> backup locations. >>>>>>>> I would rather *always* use the default location as backup for all other >>>>>>>> locations. It does not require any API or schema (as it equals to "all >>>>>>>> servers" except "servers in this location" which can be easily calculated >>>>>>>> on fly). >>>>>>> We can start with this, but it works well only in a stellar topology >>>>>>> where you have a central location all other location connect to. >>>>>>> As soon as you have a super-stellar topology where you have hub location >>>>>>> to which regional locations connect to, then this is wasteful. >>>>>>> >>>>>>>> This can be later on extended in whatever direction we want without any >>>>>>>> upgrade/migration problem. >>>>>>>> >>>>>>>> More importantly, all the schema and API will be common for all other >>>>>>>> variants >>>>>>>> anyway so we can start doing so and see how much time is left when it is >>>>>>>> done. >>>>>>> I am ok with this for the first step. >>>>>>> After all location is mostly about the "normal" case where clients want >>>>>>> to reach the local servers, the backup part is only an additional >>>>>>> feature we can keep simple for now. It's a degraded mode of operation >>>>>>> anyway so it is probably ok to have just one default backup location as >>>>>>> a starting point. >>>>>> Okay, now we are in agreement. I will think about minimal schema and API >>>>>> over >>>>>> the weekend. >>>>> Well, it took longer than one weekend. >>>>> >>>>> There was couple of changes in the design document: >>>>> * ?Feature Management: CLI proposal >>>>> * ?Feature Management: web UI - idea with topology graph replaced original >>>>> complicated table >>>>> * Feature Management: described necessary configuration outside of IPA DNS >>>>> * Version 1 parts which were moved into separate document: >>>>> V4/DNS_Location_Mechanism_with_per_client_override >>>>> * ?Assumptions: removed misleading reference to DHCP, clarified role of DNS >>>>> views >>>>> * Assumptions: removed misleading mention of 'different networks' and added >>>>> summary explaining how Location is defined >>>>> * Implementation: high-level outline added >>>>> >>>>> Current version: >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>> >>>>> Full diff: >>>>> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >>>>> >>>>> >>>>> >>>>> Practical usage is described in section How to test: >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >>>>> >>>>> >>>>> I will think about LDAP schema after we agree on CLI. >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>> >>>>>>>>> - Weights for backup location servers are the same as the weight defined >>>>>>>>> within the backup location itself, so no additional weights are defined >>>>>>>>> for backups. >>>>>>>> Yes, that was somehow implied in the variant A. Sorry for not >>>>>>>> mentioning it. >>>>>>>> Weight is always relative number for servers inside one location. >>>>>>> Ok it looked a lot more complex from your description. >>>>>>> >>>>>>> Simo. >>>> >>>> Design review: >>>> >>>> 1) >>>> You missed warning when there is no backup DNS server in location >>> >>> Thanks, added. >>> >>> >>>> 2) >>>> "Number of IPA DNS servers <= number of configured IPA locations" I dont >>>> understand >>>> >>>> You need at least one DNS server per location, thus DNS servers >= locations >>> >>> Good catch, fixed. >>> >>> >>>> 3) >>>> Design (Version 1: DNAME per client) Link to design doesn't work for me >>> >>> Oh, my wiki-fu was weak. Fixed. >>> >>> >>>> CLI looks good to me. Maybe we should explicitly write in design that >>>> priorities of the SRV records will be set statically (What values? 0 - servers >>>> in location, 100 - backup?) >>> >>> I've added a note about static priorities. Particular values are just an >>> implementation detail so I would not clutter feature management section with >>> that. >> >> If server can be only in one location, why bother with >> location-{add,mod,remove}-member and not use server-mod: >> >> server-mod --location= [--location-weight=0..65535] >> >> ? This is the natural way to model one-to-many relationships in the API, >> consistent with existing stuff. > > I originally wanted to have location-add-member command so (external) DNS > servers and IPA servers can be assigned to a location using the same command: > location-add-member LOCATION_NAME --ipa-server= > location-add-member LOCATION_NAME --advertising-server= > > Should I split this between > server-mod --location= [--location-weight=0..65535] > and > dnsserver-mod --type=external --advertise-location=... Let's not get ahead of ourselves. This will need a proper design when it is to be implemented rather than something quickly thrown together right now. > > I do not like splitting server-to-location assignment management between two > commands very much. Current proposal in design page was inspired by > group-add-member command which has --users and --groups options which seemed > philosophically similar to me. The --users and --groups options of group-add-member both translate to the member attribute of the group, they are both multivalue and the command does not need to perform additional checks on the target entries. On the other hand, the --ipa-server and --weight options of location-add-member translate to different attributes of the server, they are single value (if --ipa-server was multivalue you would have to do multiple mods on multiple server entries, if --weight was multivalue the command would be just insane), and the command needs to check if the target server has location already set. If you handle this in server-mod, all you have to do is add two new params to the server plugin and it will just work. > > Anyway, I'm open to suggestions how to handle this. -- Jan Cholasta From jcholast at redhat.com Thu Apr 14 06:24:31 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 Apr 2016 08:24:31 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570E617C.3060503@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> Message-ID: <570F379F.4000101@redhat.com> On 13.4.2016 17:10, Rob Crittenden wrote: > Martin Babinsky wrote: >> This is a WIP patch which moves the `ipa-replica-manage del` subcommand >> to the 'server-del' API method and exposes it as CLI command[1]. A CI >> test suite is also included. >> >> There are some issues with the patch I would like to discuss in more >> detail on the list: >> >> 1.) In the original subcommand there was a lot of output (mostly print >> statements) during all stages of master removal. I have tried to port >> these as messages to the command which results in quite voluminous >> response sent back to the frontend. Should we try to reduce the output? > > I don't think it applies anymore. These messages were there so the user > would know something was happening. If it is an API command there isn't > much we can do other than add something to the cli to print "This could > take a bit" before making the call. +1 > >> 2.) In the original discussion[2] we assumed that the cleanup part would >> me a separate API method called during server_del postcallback. However >> since the two objects ended up sharing a lot of state (e.g. topology >> state from pre-callback, messages) i have merged it to server-del. That >> makes the code rather unwieldy but I found it difficult to keep the two >> entities separate without some hacking around framework capabilities > > I haven't looked at the code but as a general principal having separate > operations has saved our bacon on more than one occasion. The patch adds a force option, which allows you to re-run server-del even if the master entry does not exist anymore, so I think we are safe. > >> 3.) since actions in post-callback require a knowledge about topology >> state gathered in pre-callback, I had to store some information in the >> command's context. Sorry about that, if you know about some way to >> circumvent me, let me know. > > Looks like it is the only way since you are extending server_del. > Another option would be to drop pre/post and add all this topology stuff > directly to server_del execute. > >> 4.) The master can not remove itself. I have implemented an ad-hoc >> forwarding of the request to other master that can do the job. Is this >> okay? Why can't the master remove itself? > > Assisted suicide? > > What does this effectively do? Potentially disconnect it from the > topology, perhaps to run as standalone for upgrade, integration or other > testing (e.g. there might be valid reasons to do this)? If so that seems > ok to me, or if too hacky you could just spit out a message directing > them to disconnect from another host, but that would be strange in the > UI I think. > >> 5.) Since the original behavior of 'chekc_deleted_segments' was kept, >> the code can sometimes hang waiting for removal of some segments, >> especially during forced removal in wonky topologies. This can cause >> gateway timeout in JSON-RPC call and report false positive error back to >> the user. This makes a large part of 'TestServerDel' suite to fail. How >> should we handle this? Should we keep the original behavior? > > Oh to have async calls... > > I wonder if "I'm still here" messages could be sent. I'm not entirely > sure this is possible with the framework but it might be one way to keep > long-lived connections alive. Impossible, everything is synchronous. > >> 6.) There are some in-place imports of server-side code in some places. >> I'm not very happy about it and would be glad if we can agree on a way >> to fix this. > > Is this to prevent imports on non-servers? You might look at trust for > inspiration, it does this. I wouldn't worry about this, I'm going to move most plugin code to ipaserver as part of the thin client feature anyway ;-) Honza -- Jan Cholasta From ftweedal at redhat.com Thu Apr 14 06:33:00 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 14 Apr 2016 16:33:00 +1000 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <20160413011550.GI18277@dhcp-40-8.bne.redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> <1460467890.8657.25.camel@redhat.com> <20160413011550.GI18277@dhcp-40-8.bne.redhat.com> Message-ID: <20160414063300.GN18277@dhcp-40-8.bne.redhat.com> On Wed, Apr 13, 2016 at 11:15:50AM +1000, Fraser Tweedale wrote: > On Tue, Apr 12, 2016 at 09:31:30AM -0400, Simo Sorce wrote: > > On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote: > > > On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: > > > > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: > > > > > - name = gssapi.Name('host@%s' % (self.client,), > > > > > > > > > > - gssapi.NameType.hostbased_service) > > > > > > > > If you remove this then on a serve that has nfs keys in the keytab you > > > > may end up acquiring the wrong credentials. > > > > You need to pass down what credentials you want to use to initialize the > > > > cred store, we canot rely on ordering in the system keytab case. > > > > > > > > Simo. > > > > > > > Thanks Simo; updated patch attached. > > > > Except the ACI the rest looks good to me. > > For ACI please add a separate patch that follows the naming scheme for > > subCA keys. > > > The ACI here targets the Custodia server public keys, so the client > can search and read them. It should just read: > > add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal") > (version 3.0; acl "Anyone can search Custodia public keys"; > allow(read, search, compare) userdn = "ldap:///all";) > > I don't mind putting the ACI in a separate patch, but it is > necessary to restrict read access on the public keys to only the > dogtag-ipa-custodia service principals. > Updated patches attached. ACI was split into new patch and simplified (removed ($dn) macro). Cheers, Fraser -------------- next part -------------- From 1f1193b3a4e786c63bde4fa0abe3640c16481633 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 8 Apr 2016 15:21:19 +1000 Subject: [PATCH] Allow CustodiaClient to be used by arbitrary principals Currently CustodiaClient assumes that the client is the host principal, and it is hard-coded to read the host keytab and server keys. For the Lightweight CAs feature, Dogtag on CA replicas will use CustodiaClient to retrieve signing keys from the originating replica. Because this process runs as 'pkiuser', the host keys cannot be used; instead, each Dogtag replica will have a service principal to use for Custodia authentication. Update CustodiaClient to allow specifying the keytab and Custodia keyfile to use. Avoid hard-coding the service name to find in the keytab. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipapython/secrets/client.py | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/ipapython/secrets/client.py b/ipapython/secrets/client.py index 5b671988ddc66eedd9ae1cd4ddec0e1308bc5a93..a15057ae67c377a782db3642d14384e0bf11b5a2 100644 --- a/ipapython/secrets/client.py +++ b/ipapython/secrets/client.py @@ -41,16 +41,19 @@ class CustodiaClient(object): return iSecStore(config) - def __init__(self, client, server, realm, ldap_uri=None, auth_type=None): - self.client = client - self.creds = None + def __init__(self, client, server, realm, ldap_uri=None, auth_type=None, + client_servicename='host', keyfile=None, keytab=None): + self.client_service = '%s@%s' % (client_servicename, client) + self.keytab = keytab or paths.KRB5_KEYTAB + self.creds = self.init_creds() self.service_name = gssapi.Name('HTTP@%s' % (server,), gssapi.NameType.hostbased_service) self.server = server - keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys') - self.ikk = IPAKEMKeys({'server_keys': keyfile}) + if keyfile is None: + keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys') + self.ikk = IPAKEMKeys({'server_keys': keyfile, 'ldap_uri': ldap_uri}) self.kemcli = KEMClient(self._server_keys(server, realm), self._client_keys()) @@ -61,9 +64,9 @@ class CustodiaClient(object): requests.packages.urllib3.disable_warnings() def init_creds(self): - name = gssapi.Name('host@%s' % (self.client,), + name = gssapi.Name(self.client_service, gssapi.NameType.hostbased_service) - store = {'client_keytab': paths.KRB5_KEYTAB, + store = {'client_keytab': self.keytab, 'ccache': 'MEMORY:Custodia_%s' % b64encode(os.urandom(8))} return gssapi.Credentials(name=name, store=store, usage='initiate') -- 2.5.5 -------------- next part -------------- From 234e6334dafb27224b89fed86968df3016b27474 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 13 Apr 2016 14:51:16 +1000 Subject: [PATCH] Allow all principals to read Custodia keys Add an ACI to allow all authenticated principals to read and search for Custodia server public keys. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- install/updates/20-aci.update | 3 +++ 1 file changed, 3 insertions(+) diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index 4802ae0458e8b870bf3127764ebabac1a48f7cf2..f4d20cba3b2449042c841477f64beff416c71862 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -136,3 +136,6 @@ add:aci: (target = "ldap:///cn=replication,cn=etc,$SUFFIX")(targetattr = "nsDS5R dn: cn=ipa,cn=etc,$SUFFIX add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia secrets"; allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) + +# Anyone can search Custodia public keys +add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal")(version 3.0; acl "Anyone can search Custodia public keys"; allow(read, search, compare) userdn = "ldap:///all";) -- 2.5.5 From jcholast at redhat.com Thu Apr 14 06:42:04 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 Apr 2016 08:42:04 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570E5C67.40201@redhat.com> References: <570E5C67.40201@redhat.com> Message-ID: <570F3BBC.7000800@redhat.com> Hi, On 13.4.2016 16:49, Martin Babinsky wrote: > This is a WIP patch which moves the `ipa-replica-manage del` subcommand > to the 'server-del' API method and exposes it as CLI command[1]. A CI > test suite is also included. > `server-del` now accepts the following options: > * `--cleanup`: perform a cleanup after an already deleted master I would prefer if this was actually called --force, for reasons explained in the design thread: . > * `--force-removal`: force master removal, i.e. ignore topology errors So, this is actually the all-powerful --force option we always try to avoid, but with a different name (and not very good one - if you are removing something, what other than removal would you need to force?). Could you split this into separate options? Honza -- Jan Cholasta From ftweedal at redhat.com Thu Apr 14 06:39:37 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 14 Apr 2016 16:39:37 +1000 Subject: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication Message-ID: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> Hi all, The attached patches configure lightweight CA key replication on IPA CAs, on upgrade and installation. Patches 0051..0052 from my other mail are also needed for the system to work, but this patchset does not depend on them and can be reviewed independently. There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 - it just puts the necessary principals/keys/configuration in place. Cheers, Fraser -------------- next part -------------- From aa91bd3c6773d42c864a8f34eabad8b90bb01f8b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Apr 2016 12:42:35 +1000 Subject: [PATCH 53/54] Optionally add service name to Custodia key DNs Lightweight CAs support introduces new service principals for Dogtag, with Custodia keys. The current Custodia key creation uses a DN that contains only they key type and the hostname, so keys for multiple services on the same host cannot be created. Add the 'generate_keys' method to generate keys for a host or an arbitrary service. When a service name is given, include the service name in the DN. This change does not affect searching because all searching is done using the ipaKeyUsage and memberPrincipal attributes. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipapython/secrets/kem.py | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py index 1025ed7980f055c82c602634e8845fa490cf0514..533121779241d30e19fef4c050bb69c55d29ec22 100644 --- a/ipapython/secrets/kem.py +++ b/ipapython/secrets/kem.py @@ -105,10 +105,11 @@ class KEMLdap(iSecLdap): encoding=serialization.Encoding.DER, format=serialization.PublicFormat.SubjectPublicKeyInfo) - def set_key(self, usage, host, principal, key): + def set_key(self, usage, servicename, host, principal, key): public_key = self._format_public_key(key) conn = self.connect() - name = '%s/%s' % (KEY_USAGE_MAP[usage], host) + service_segment = '~' + servicename if servicename else '' + name = '%s%s/%s' % (KEY_USAGE_MAP[usage], service_segment, host) dn = 'cn=%s,%s' % (name, self.keysbase) try: mods = [('objectClass', ['nsContainer', @@ -170,15 +171,18 @@ class IPAKEMKeys(KEMKeysStore): return conn.get_key(usage, kid) def generate_server_keys(self): - principal = 'host/%s@%s' % (self.host, self.realm) + self.generate_keys() + + def generate_keys(self, servicename=None): + principal = '%s/%s@%s' % (servicename or 'host', self.host, self.realm) # Neutralize the key with read if any self._server_keys = None # Generate private key and store it pubkeys = newServerKeys(self.config['server_keys'], principal) # Store public key in LDAP ldapconn = KEMLdap(self.ldap_uri) - ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) - ldapconn.set_key(KEY_USAGE_ENC, self.host, principal, pubkeys[1]) + ldapconn.set_key(KEY_USAGE_SIG, servicename, self.host, principal, pubkeys[0]) + ldapconn.set_key(KEY_USAGE_ENC, servicename, self.host, principal, pubkeys[1]) @property def server_keys(self): -- 2.5.5 -------------- next part -------------- From cf452abcf309ce3cded3eeef70b07f108d9eb92d Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Apr 2016 16:47:33 +1000 Subject: [PATCH 54/54] Setup lightweight CA key retrieval on install/upgrade To configure Dogtag lightweight CA key replication on installation and upgrade: - add the 'dogtag-ipa-custodia/$HOSTNAME' service principal - create Custodia keys - retrieve keytab - configure the IPACustodiaKeyRetriever in CS.cfg Part of: https://fedorahosted.org/freeipa/ticket/4559 --- install/tools/ipa-ca-install | 4 ++++ ipaserver/install/cainstance.py | 43 +++++++++++++++++++++++++++++++++++++ ipaserver/install/server/install.py | 8 ++++++- ipaserver/install/server/upgrade.py | 6 +++++- 4 files changed, 59 insertions(+), 2 deletions(-) diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install index 1bc5def03bf687a1e4f9fb38a54363b5429c8fc4..0af5b39116b4649423ed2a51579e2adc767d802b 100755 --- a/install/tools/ipa-ca-install +++ b/install/tools/ipa-ca-install @@ -226,6 +226,10 @@ def install_master(safe_options, options): ca.install_check(True, None, options) ca.install(True, None, options) + CA = cainstance.CAInstance( + api.env.realm, certs.NSS_DIR, host_name=api.env.host) + CA.setup_lightweight_ca_key_retrieval() + def install(safe_options, options, filename): options.promote = False diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index a21f7d2671461dfb99797d39fc7ee5706317241f..08d0ec661a5b0a95cfc4f8ac8ccc1476d86e6ea0 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -59,6 +59,7 @@ from ipapython.certdb import get_ca_nickname from ipapython.dn import DN from ipapython.ipa_log_manager import log_mgr,\ standard_logging_setup, root_logger +from ipapython.secrets.kem import IPAKEMKeys from ipaserver.install import certs from ipaserver.install import dsinstance @@ -66,6 +67,7 @@ from ipaserver.install import installutils from ipaserver.install import ldapupdate from ipaserver.install import replication from ipaserver.install import service +from ipaserver.install import sysupgrade from ipaserver.install.dogtaginstance import (export_kra_agent_pem, DogtagInstance) from ipaserver.plugins import ldap2 @@ -1356,11 +1358,52 @@ class CAInstance(DogtagInstance): self.step("updating IPA configuration", update_ipa_conf) self.step("Restart HTTP server to pick up changes", self.__restart_http_instance) + self.step("Configure lightweight CA key retrieval", + self.setup_lightweight_ca_key_retrieval) self.step("enabling CA instance", self.__enable_instance) self.start_creation(runtime=210) + def setup_lightweight_ca_key_retrieval(self): + if sysupgrade.get_upgrade_state('dogtag', 'setup_lwca_key_retrieval'): + return + + root_logger.info('[Set up lightweight CA key retrieval]') + + service = 'dogtag-ipa-custodia' + principal = '{}/{}@{}'.format(service, api.env.host, self.realm) + pent = pwd.getpwnam(constants.PKI_USER) + + root_logger.info('Creating principal') + installutils.kadmin_addprinc(principal) + self.suffix = ipautil.realm_to_suffix(self.realm) + if not self.admin_conn: + self.ldap_connect() + self.move_service(principal) + + root_logger.info('Retrieving keytab') + keytab = os.path.join(paths.PKI_TOMCAT, 'dogtag-ipa-custodia.keytab') + installutils.create_keytab(keytab, principal) + os.chmod(keytab, 0o600) + os.chown(keytab, pent.pw_uid, pent.pw_gid) + + root_logger.info('Creating Custodia keys') + keyfile = os.path.join(paths.PKI_TOMCAT, 'dogtag-ipa-custodia.keys') + keystore = IPAKEMKeys({'server_keys': keyfile}) + keystore.generate_keys(service) + os.chmod(keyfile, 0o600) + os.chown(keyfile, pent.pw_uid, pent.pw_gid) + + root_logger.info('Configuring key retriever') + installutils.set_directive( + paths.CA_CS_CFG_PATH, + 'features.authority.keyRetrieverClass', + 'com.netscape.ca.IPACustodiaKeyRetriever', + quotes=False, separator='=') + + sysupgrade.set_upgrade_state('dogtag', 'setup_lwca_key_retieval', True) + def replica_ca_install_check(config): if not config.setup_ca: diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py index f01022c4c3a056513db47f70727aa48157a8c6f2..d9fcd7e6098c1bdd7647c300695f583f43bde9e5 100644 --- a/ipaserver/install/server/install.py +++ b/ipaserver/install/server/install.py @@ -892,7 +892,8 @@ def install(installer): ca.install_step_0(False, None, options) # Now put the CA cert where other instances exepct it - ca_instance = cainstance.CAInstance(realm_name, certs.NSS_DIR) + ca_instance = cainstance.CAInstance( + realm_name, certs.NSS_DIR, host_name=host_name) ca_instance.publish_ca_cert(CACERT) else: # Put the CA cert where other instances expect it @@ -922,6 +923,11 @@ def install(installer): # generated ds.add_cert_to_service() + if setup_ca: + # CA was configured before Kerberos; + # add Custodia client princ and keys now + ca_instance.setup_lightweight_ca_key_retrieval() + memcache = memcacheinstance.MemcacheInstance() memcache.create_instance('MEMCACHE', host_name, dm_password, ipautil.realm_to_suffix(realm_name)) diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index 3e60cfd3630c359268cf16219527088b5c63ba86..cc003c7146d547b5778f4d5d8d1c4f7eedc69ec7 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1463,7 +1463,8 @@ def upgrade_configuration(): if subject_base: sub_dict['SUBJECT_BASE'] = subject_base - ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) + ca = cainstance.CAInstance( + api.env.realm, certs.NSS_DIR, host_name=api.env.host) with installutils.stopped_service('pki-tomcatd', 'pki-tomcat'): # Dogtag must be stopped to be able to backup CS.cfg config @@ -1658,6 +1659,9 @@ def upgrade_configuration(): ca_import_included_profiles(ca) add_default_caacl(ca) + if ca.is_configured(): + ca.setup_lightweight_ca_key_retrieval() + set_sssd_domain_option('ipa_server_mode', 'True') if ds_running and not ds.is_running(): -- 2.5.5 From jcholast at redhat.com Thu Apr 14 06:56:40 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 Apr 2016 08:56:40 +0200 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <57066C16.2000508@redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> <5706366C.4020109@redhat.com> <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> <57066C16.2000508@redhat.com> Message-ID: <570F3F28.3020801@redhat.com> On 7.4.2016 16:17, Petr Spacek wrote: > On 7.4.2016 15:20, Fraser Tweedale wrote: >> On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: >>> On 7.4.2016 12:13, Christian Heimes wrote: >>>> On 2016-04-07 11:09, Petr Spacek wrote: >>>>> On 7.4.2016 08:43, Fraser Tweedale wrote: >>>>>> Hi team, >>>>>> >>>>>> I updated the Sub-CAs design page with more detail for the key >>>>>> replication[1]. This part of the design is nearly complete (a large >>>>>> patchset is in review over at pki-devel@) but there are various >>>>>> options about how to authenticate to Custodia. >>>>>> >>>>>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication >>>>>> >>>>>> In brief, the options are: >>>>>> >>>>>> 1) authenticate as host principal; install binary setuid >>>>>> root:pkiuser to read host keytab and custodia keys. >>>>> >>>>> Huh, I really do not like this. Host keytab on IPA master is one of the most >>>>> sensitive keys we have. >>>>> >>>>> Maybe gssproxy can be used somehow, but I think it would be better to use >>>>> separate key. >>>>> >>>>> >>>>>> 2) authenticate as host principal; copy host keytab and custodia >>>>>> keys to location readable by pkiuser. >>>>> >>>>> No, really, do not copy host keytab anywhere. >>>>> >>>>> >>>>>> 3) create new principal for pkiuser to use, along with custodia keys >>>>>> and keytab in location readable by pkiuser. >>>>>> >>>>>> I prefer option (1) for reasons outlined in the design page. The >>>>>> design page goes into quite a bit more detail so please review the >>>>>> section linked above and get back to me with your thoughts. >>>>> >>>>> The only downside of (3) using new keys is: >>>>> ... This approach requires the creation of new principals, and Kerberos >>>>> keytabs and Custodia keys for those principals, as part of the >>>>> installation/upgrade process. >>>>> >>>>> Compared with additional SUID binary this seems as safer and easier way to go. >>>>> FreeIPA installers already create quite a lot of principals and keytabs so >>>>> this is well understood task. >>>>> >>>>> I would do (3). >>>> >>>> +1 for (3) >>>> >>>> A SUID binary feels like a dangerous hack. >>> >>> +1 >>> >> OK, (3) it is. Thanks all for your input. >> >> Now for next question: what should service principal name be? I >> think `dogtag/example.com at EXAMPLE.COM' but am open to other >> suggestions, e.g. `pki/...'. > > Do you plan to attempt to standardize this name in future? I do not expect that. > > Considering private nature of it, it should be as specific as possible to > avoid any potential conflicts with future standards. "dogtag-key-replication" > sounds like a good candidate. IMO it shouldn't be *that* specific, considering we want to switch Dogtag from SSL to GSSAPI authentication to DS, which will probably use the same principal name. I think "ipa-pki/..." or "dogtag/..." should be fine. > > Before you set the name in stone make sure it does not conflict with anything > listed on > http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > These names have potential to be used by someone else. -- Jan Cholasta From pvomacka at redhat.com Thu Apr 14 07:39:40 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 14 Apr 2016 09:39:40 +0200 Subject: [Freeipa-devel] [PATCH] 0014 webui: Update delete dialog on active user details page Message-ID: <570F493C.6060800@redhat.com> Hi, The attached patch fixes this ticket: https://fedorahosted.org/freeipa/ticket/5370 . It adds radio button to choose whether you want to preserve or delete user when performing delete action from details page. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0014-Update-the-delete-dialog-on-details-user-page.patch Type: text/x-patch Size: 6317 bytes Desc: not available URL: From ldoudova at redhat.com Thu Apr 14 08:43:22 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 14 Apr 2016 10:43:22 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0011] WebUI: Creating user without private group In-Reply-To: <57029C43.7000309@redhat.com> References: <56CF0AD6.4060505@redhat.com> <56DD9E73.1020609@redhat.com> <56DEBE89.70808@redhat.com> <56DEC2DF.3000801@redhat.com> <56E1B5CC.7070208@redhat.com> <56EBD74C.40709@redhat.com> <56FCFF33.7060801@redhat.com> <56FD314C.4080809@redhat.com> <56FE6ACE.1050705@redhat.com> <57029C43.7000309@redhat.com> Message-ID: <570F582A.109@redhat.com> On 04/04/2016 06:54 PM, Martin Basti wrote: > > > On 01.04.2016 14:34, Pavel Vomacka wrote: >> >> >> On 03/31/2016 04:16 PM, Lenka Doudova wrote: >>> >>> >>> On 03/31/2016 12:42 PM, Pavel Vomacka wrote: >>>> >>>> >>>> On 03/18/2016 11:24 AM, Lenka Doudova wrote: >>>>> >>>>> >>>>> On 03/10/2016 06:58 PM, Petr Vobornik wrote: >>>>>> On 03/08/2016 01:17 PM, Lenka Doudova wrote: >>>>>>> >>>>>>> >>>>>>> On 03/08/2016 12:59 PM, Petr Vobornik wrote: >>>>>>>> On 03/07/2016 04:29 PM, Pavel Vomacka wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/25/2016 03:08 PM, Lenka Doudova wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> here's a patch for webUI tests that provides test for >>>>>>>>>> creating user >>>>>>>>>> without private group. >>>>>>>>>> Related to ticket https://fedorahosted.org/freeipa/ticket/4986 >>>>>>>>>> >>>>>>>>>> Since the option to specify GID when creating a user is not >>>>>>>>>> available >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5505 the test creates >>>>>>>>>> a new >>>>>>>>>> posix group, makes it a default user group instead of >>>>>>>>>> 'ipausers' and >>>>>>>>>> then attemps to create the user without private group. Returning >>>>>>>>>> default user group value to 'ipausers' is provided even for >>>>>>>>>> cases when >>>>>>>>>> the test fails so it would not block other tests from performing >>>>>>>>>> properly. >>>>>>>>>> >>>>>>>>>> Lenka >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> ACK, works well. >>>>>>>>> >>>>>>>>> Pavel^3 Vomacka >>>>>>>>> >>>>>>>> >>>>>>>> NACK, don't use naked except, specify at least 'Exception' >>>>>>>> + except: >>>>>>>> >>>>>>> >>>>>>> Thanks, patch fixed according to Petr's review attached. >>>>>>> >>>>>>> Lenka >>>>>> >>>>>> Ticket 5505 was pushed. So the workaround can be removed. Do you >>>>>> prefer to do it in this patch? >>>>>> >>>>>> Also, maybe it would be good to test both cases and check if the >>>>>> error is actually the right one. >>>>> >>>>> Hi, >>>>> >>>>> attaching patch fixed according to recently pushed changes. >>>>> >>>>> Lenka >>>> Hi, >>>> >>>> NACK, >>>> >>>> 1) The data definition for user3 (user.DATA3) is not used anywhere. >>>> And the definition is actually the same as definition of user4. So, >>>> I think that it could be removed. >>>> >>>> 2) This is just a detail, but I would rather use 'combobox_input' >>>> or 'combobox_textbox' as parameter name because the parameter >>>> actually doesn't represent the value of combobox. >>>> >>>> Otherwise it works as expected. >>>> >>>> -- >>>> Pavel^3 Vomacka >>>> >>> Hi, >>> >>> thanks for comments, updated patch attached. >>> >>> Lenka >>> >>> >> Thank you, ACK. >> >> -- >> Pavel^3 Vomacka >> >> >> > Ticket is in closed milestone, this patch cannot be attached to closed > milestone, please create a new ticket/or post the proper ticket. > > Hi, new ticket has been created for this issue. Patch with modified commit message to refer to the new ticket attached. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0011.5-WebUI-Test-creating-user-without-private-group.patch Type: text/x-patch Size: 7091 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Apr 14 08:48:15 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 14 Apr 2016 10:48:15 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570F3BBC.7000800@redhat.com> References: <570E5C67.40201@redhat.com> <570F3BBC.7000800@redhat.com> Message-ID: <570F594F.6080007@redhat.com> On 04/14/2016 08:42 AM, Jan Cholasta wrote: > Hi, > > On 13.4.2016 16:49, Martin Babinsky wrote: >> This is a WIP patch which moves the `ipa-replica-manage del` subcommand >> to the 'server-del' API method and exposes it as CLI command[1]. A CI >> test suite is also included. > >> `server-del` now accepts the following options: >> * `--cleanup`: perform a cleanup after an already deleted master > > I would prefer if this was actually called --force, for reasons > explained in the design thread: > . > >> * `--force-removal`: force master removal, i.e. ignore topology errors > > So, this is actually the all-powerful --force option we always try to > avoid, but with a different name (and not very good one - if you are > removing something, what other than removal would you need to force?). > > Could you split this into separate options? > There are actually two checks that we need to pass/bypass before we can remove the master entry and run all the cleanup shenanigans: 1.) the topology is not disconnected already or is not being disconnected by the action 2.) the action does leave at least one CA/DNS server, does not remove DNSSec keymaster and we can promote other master to CA renewal master So IIUC we would need three options actually: * one that bypasses topology checks ('--ignore-topology-disconnect') * one that bypasses the check for remaining services ('--ignore-last-services?') * one that will cleanup leftovers only, ignoring NotFound error ('--cleanup'), this one is already there > Honza > -- Martin^3 Babinsky From mbabinsk at redhat.com Thu Apr 14 08:59:55 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 14 Apr 2016 10:59:55 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570F379F.4000101@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> Message-ID: <570F5C0B.5010706@redhat.com> On 04/14/2016 08:24 AM, Jan Cholasta wrote: > On 13.4.2016 17:10, Rob Crittenden wrote: >> Martin Babinsky wrote: >>> This is a WIP patch which moves the `ipa-replica-manage del` subcommand >>> to the 'server-del' API method and exposes it as CLI command[1]. A CI >>> test suite is also included. >>> >>> There are some issues with the patch I would like to discuss in more >>> detail on the list: >>> >>> 1.) In the original subcommand there was a lot of output (mostly print >>> statements) during all stages of master removal. I have tried to port >>> these as messages to the command which results in quite voluminous >>> response sent back to the frontend. Should we try to reduce the output? >> >> I don't think it applies anymore. These messages were there so the user >> would know something was happening. If it is an API command there isn't >> much we can do other than add something to the cli to print "This could >> take a bit" before making the call. > > +1 > This is already implemented in PoC. So I guess we may reduce the output only to the following: In CLI print: "Removing {server} from replication topology, " "please wait... The adding info messages: "checking topology connectivity" | "skipping topology connectivity check" "checking remaining services" | "skipping check for remaining services" "performing cleanup" "Deleted server {server}" >> >>> 2.) In the original discussion[2] we assumed that the cleanup part would >>> me a separate API method called during server_del postcallback. However >>> since the two objects ended up sharing a lot of state (e.g. topology >>> state from pre-callback, messages) i have merged it to server-del. That >>> makes the code rather unwieldy but I found it difficult to keep the two >>> entities separate without some hacking around framework capabilities >> >> I haven't looked at the code but as a general principal having separate >> operations has saved our bacon on more than one occasion. > > The patch adds a force option, which allows you to re-run server-del > even if the master entry does not exist anymore, so I think we are safe. > >> >>> 3.) since actions in post-callback require a knowledge about topology >>> state gathered in pre-callback, I had to store some information in the >>> command's context. Sorry about that, if you know about some way to >>> circumvent me, let me know. >> >> Looks like it is the only way since you are extending server_del. >> Another option would be to drop pre/post and add all this topology stuff >> directly to server_del execute. >> >>> 4.) The master can not remove itself. I have implemented an ad-hoc >>> forwarding of the request to other master that can do the job. Is this >>> okay? > > Why can't the master remove itself? > Because it removes its own replication agreements hence any changes in DIT (like removed principals, s4u2 proxy targets etc.) won't replicate to other masters. >> >> Assisted suicide? >> >> What does this effectively do? Potentially disconnect it from the >> topology, perhaps to run as standalone for upgrade, integration or other >> testing (e.g. there might be valid reasons to do this)? If so that seems >> ok to me, or if too hacky you could just spit out a message directing >> them to disconnect from another host, but that would be strange in the >> UI I think. >> >>> 5.) Since the original behavior of 'chekc_deleted_segments' was kept, >>> the code can sometimes hang waiting for removal of some segments, >>> especially during forced removal in wonky topologies. This can cause >>> gateway timeout in JSON-RPC call and report false positive error back to >>> the user. This makes a large part of 'TestServerDel' suite to fail. How >>> should we handle this? Should we keep the original behavior? >> >> Oh to have async calls... >> >> I wonder if "I'm still here" messages could be sent. I'm not entirely >> sure this is possible with the framework but it might be one way to keep >> long-lived connections alive. > > Impossible, everything is synchronous. > >> >>> 6.) There are some in-place imports of server-side code in some places. >>> I'm not very happy about it and would be glad if we can agree on a way >>> to fix this. >> >> Is this to prevent imports on non-servers? You might look at trust for >> inspiration, it does this. > > I wouldn't worry about this, I'm going to move most plugin code to > ipaserver as part of the thin client feature anyway ;-) > > Honza > -- Martin^3 Babinsky From mbabinsk at redhat.com Thu Apr 14 09:10:28 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 14 Apr 2016 11:10:28 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570E617C.3060503@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> Message-ID: <570F5E84.9050000@redhat.com> On 04/13/2016 05:10 PM, Rob Crittenden wrote: > Martin Babinsky wrote: >> This is a WIP patch which moves the `ipa-replica-manage del` subcommand >> to the 'server-del' API method and exposes it as CLI command[1]. A CI >> test suite is also included. >> >> There are some issues with the patch I would like to discuss in more >> detail on the list: >> >> 1.) In the original subcommand there was a lot of output (mostly print >> statements) during all stages of master removal. I have tried to port >> these as messages to the command which results in quite voluminous >> response sent back to the frontend. Should we try to reduce the output? > > I don't think it applies anymore. These messages were there so the user > would know something was happening. If it is an API command there isn't > much we can do other than add something to the cli to print "This could > take a bit" before making the call. > >> 2.) In the original discussion[2] we assumed that the cleanup part would >> me a separate API method called during server_del postcallback. However >> since the two objects ended up sharing a lot of state (e.g. topology >> state from pre-callback, messages) i have merged it to server-del. That >> makes the code rather unwieldy but I found it difficult to keep the two >> entities separate without some hacking around framework capabilities > > I haven't looked at the code but as a general principal having separate > operations has saved our bacon on more than one occasion. > >> 3.) since actions in post-callback require a knowledge about topology >> state gathered in pre-callback, I had to store some information in the >> command's context. Sorry about that, if you know about some way to >> circumvent me, let me know. > > Looks like it is the only way since you are extending server_del. > Another option would be to drop pre/post and add all this topology stuff > directly to server_del execute. > >> 4.) The master can not remove itself. I have implemented an ad-hoc >> forwarding of the request to other master that can do the job. Is this >> okay? > > Assisted suicide? > > What does this effectively do? Potentially disconnect it from the > topology, perhaps to run as standalone for upgrade, integration or other > testing (e.g. there might be valid reasons to do this)? If so that seems > ok to me, or if too hacky you could just spit out a message directing > them to disconnect from another host, but that would be strange in the > UI I think. > One of the use-cases for this feature is to run server-del as a part of uninstallation of domain-level 1 master. In this case, you cannot run the command on the host and some other master has to put our host down so you would have to forward the request somewhere else anyway. Other case I was thinking about was running the command from a client machine that talks primarily to a server that should be removed. In this case the user can either get some 'I cannot kill myself, talk to someone else' response, or the server could forward the request elsewhere and then return the result. >> 5.) Since the original behavior of 'chekc_deleted_segments' was kept, >> the code can sometimes hang waiting for removal of some segments, >> especially during forced removal in wonky topologies. This can cause >> gateway timeout in JSON-RPC call and report false positive error back to >> the user. This makes a large part of 'TestServerDel' suite to fail. How >> should we handle this? Should we keep the original behavior? > > Oh to have async calls... > > I wonder if "I'm still here" messages could be sent. I'm not entirely > sure this is possible with the framework but it might be one way to keep > long-lived connections alive. > >> 6.) There are some in-place imports of server-side code in some places. >> I'm not very happy about it and would be glad if we can agree on a way >> to fix this. > > Is this to prevent imports on non-servers? You might look at trust for > inspiration, it does this. > > rob > >> >> [1] https://fedorahosted.org/freeipa/ticket/5588 >> [2] >> https://www.redhat.com/archives/freeipa-devel/2016-March/msg00335.html >> >> >> > -- Martin^3 Babinsky From cheimes at redhat.com Thu Apr 14 09:16:01 2016 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 14 Apr 2016 11:16:01 +0200 Subject: [Freeipa-devel] Check if server is fully installed and ready Message-ID: <570F5FD1.4050600@redhat.com> Hi, while I was working on my Ansible playbook I ran into an issue. It is hard to detect if a FreeIPA server instance is fully installed and all its services are ready to handle requests. It's even harder to check it remotely. I have figured out some heuristics to detect that a sever is *not* fully installed (e.g. /etc/ipa/default.conf is missing or http://ipa-ca.ipa.example/ipa/crl/MasterCRL.bin returns 404). The presence of these resources is no guarantee that all FreeIPA services fully up and running. Two days ago on IRC Jan came up with the same problem with containers. He ran into a problem related to containers and DNS updates. Since I'm no longer alone with the problem and my own workarounds are not completely stable, I like to address the problem in FreeIPA directly. Now you might wonder why it is so hard to check if FreeIPA is ready or why nobody ran into the issue before. Let's start with the second question. A typical admin first installs a FreeIPA server on one machine. It takes a couple of seconds until he notices that the installer has finished. The admin ssh-es into another machine, sudo -s and then runs ipa-client-install with some arguments. It takes a couple of seconds, maybe even a minute. With containers and automation tools it's more like milliseconds. Now for the first question. Under some conditions a FreeIPA service might be started but not yet ready to serve requests or aren't fully operation yet. For example ticket https://fedorahosted.org/freeipa/ticket/5813 is an example of a problem with ipa-kra-install, 389-DS restarts and bind-dyndb-ldap. Proposal 1) A new boolean attribute ipaReady=TRUE/FALSE in cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX tracks whether or not an FreeIPA instance is ready to handle requests. 2) A new HTTP route http[s]://$FQDN/ipa/ready is added. The route does not need authentication. When ipaReady=TRUE the route simple returns 200 OK with some text like READY. When the attribute is not present or FALSE, it returns an error to the client (412, 408?). 3) All ipa install and upgrade commands set the attribute to FALSE before any tasks. 4) A final step in all ipa install and upgrade commands checks that all services have been started and are ready to handle requests. Eventually the ipaReady attribute is set to true. 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 lkrispen at redhat.com Thu Apr 14 09:46:26 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 14 Apr 2016 11:46:26 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570F5C0B.5010706@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> Message-ID: <570F66F2.7050407@redhat.com> On 04/14/2016 10:59 AM, Martin Babinsky wrote: > On 04/14/2016 08:24 AM, Jan Cholasta wrote: >> On 13.4.2016 17:10, Rob Crittenden wrote: >>> Martin Babinsky wrote: >>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>> subcommand >>>> to the 'server-del' API method and exposes it as CLI command[1]. A CI >>>> test suite is also included. >>>> >>>> There are some issues with the patch I would like to discuss in more >>>> detail on the list: >>>> >>>> 1.) In the original subcommand there was a lot of output (mostly print >>>> statements) during all stages of master removal. I have tried to port >>>> these as messages to the command which results in quite voluminous >>>> response sent back to the frontend. Should we try to reduce the >>>> output? >>> >>> I don't think it applies anymore. These messages were there so the user >>> would know something was happening. If it is an API command there isn't >>> much we can do other than add something to the cli to print "This could >>> take a bit" before making the call. >> >> +1 >> > This is already implemented in PoC. So I guess we may reduce the > output only to the following: > > > In CLI print: > "Removing {server} from replication topology, " > "please wait... > > The adding info messages: > > "checking topology connectivity" | "skipping topology connectivity check" > "checking remaining services" | "skipping check for remaining services" > "performing cleanup" > "Deleted server {server}" > > >>> >>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>> would >>>> me a separate API method called during server_del postcallback. >>>> However >>>> since the two objects ended up sharing a lot of state (e.g. topology >>>> state from pre-callback, messages) i have merged it to server-del. >>>> That >>>> makes the code rather unwieldy but I found it difficult to keep the >>>> two >>>> entities separate without some hacking around framework capabilities >>> >>> I haven't looked at the code but as a general principal having separate >>> operations has saved our bacon on more than one occasion. >> >> The patch adds a force option, which allows you to re-run server-del >> even if the master entry does not exist anymore, so I think we are safe. >> >>> >>>> 3.) since actions in post-callback require a knowledge about topology >>>> state gathered in pre-callback, I had to store some information in the >>>> command's context. Sorry about that, if you know about some way to >>>> circumvent me, let me know. >>> >>> Looks like it is the only way since you are extending server_del. >>> Another option would be to drop pre/post and add all this topology >>> stuff >>> directly to server_del execute. >>> >>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>> forwarding of the request to other master that can do the job. Is this >>>> okay? >> >> Why can't the master remove itself? >> > Because it removes its own replication agreements hence any changes in > DIT (like removed principals, s4u2 proxy targets etc.) won't replicate > to other masters. It shouldn't remove replication agreements, in fact this should be prevented by the topology plugin. The removal of the agreements will be triggered by removing the master entry >>> >>> Assisted suicide? >>> >>> What does this effectively do? Potentially disconnect it from the >>> topology, perhaps to run as standalone for upgrade, integration or >>> other >>> testing (e.g. there might be valid reasons to do this)? If so that >>> seems >>> ok to me, or if too hacky you could just spit out a message directing >>> them to disconnect from another host, but that would be strange in the >>> UI I think. >>> >>>> 5.) Since the original behavior of 'chekc_deleted_segments' was kept, >>>> the code can sometimes hang waiting for removal of some segments, >>>> especially during forced removal in wonky topologies. This can cause >>>> gateway timeout in JSON-RPC call and report false positive error >>>> back to >>>> the user. This makes a large part of 'TestServerDel' suite to fail. >>>> How >>>> should we handle this? Should we keep the original behavior? >>> >>> Oh to have async calls... >>> >>> I wonder if "I'm still here" messages could be sent. I'm not entirely >>> sure this is possible with the framework but it might be one way to >>> keep >>> long-lived connections alive. >> >> Impossible, everything is synchronous. >> >>> >>>> 6.) There are some in-place imports of server-side code in some >>>> places. >>>> I'm not very happy about it and would be glad if we can agree on a way >>>> to fix this. >>> >>> Is this to prevent imports on non-servers? You might look at trust for >>> inspiration, it does this. >> >> I wouldn't worry about this, I'm going to move most plugin code to >> ipaserver as part of the thin client feature anyway ;-) >> >> Honza >> > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From mbabinsk at redhat.com Thu Apr 14 10:23:44 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 14 Apr 2016 12:23:44 +0200 Subject: [Freeipa-devel] Check if server is fully installed and ready In-Reply-To: <570F5FD1.4050600@redhat.com> References: <570F5FD1.4050600@redhat.com> Message-ID: <570F6FB0.1020008@redhat.com> On 04/14/2016 11:16 AM, Christian Heimes wrote: > Hi, > > while I was working on my Ansible playbook I ran into an issue. It is > hard to detect if a FreeIPA server instance is fully installed and all > its services are ready to handle requests. It's even harder to check it > remotely. I have figured out some heuristics to detect that a sever is > *not* fully installed (e.g. /etc/ipa/default.conf is missing or > http://ipa-ca.ipa.example/ipa/crl/MasterCRL.bin returns 404). The > presence of these resources is no guarantee that all FreeIPA services > fully up and running. > > Two days ago on IRC Jan came up with the same problem with containers. > He ran into a problem related to containers and DNS updates. Since I'm > no longer alone with the problem and my own workarounds are not > completely stable, I like to address the problem in FreeIPA directly. > Now you might wonder why it is so hard to check if FreeIPA is ready or > why nobody ran into the issue before. > > Let's start with the second question. A typical admin first installs a > FreeIPA server on one machine. It takes a couple of seconds until he > notices that the installer has finished. The admin ssh-es into another > machine, sudo -s and then runs ipa-client-install with some arguments. > It takes a couple of seconds, maybe even a minute. With containers and > automation tools it's more like milliseconds. > > Now for the first question. Under some conditions a FreeIPA service > might be started but not yet ready to serve requests or aren't fully > operation yet. For example ticket > https://fedorahosted.org/freeipa/ticket/5813 is an example of a problem > with ipa-kra-install, 389-DS restarts and bind-dyndb-ldap. > > > Proposal > > 1) A new boolean attribute ipaReady=TRUE/FALSE in > cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX tracks whether or not an > FreeIPA instance is ready to handle requests. > Each service entry in the service container contains 'ipaConfigString=enabledService' attribute that *should* tell that the service is enabled and running. When the Server Roles[1] feature you could check whether the role that interests you (in this case implicit "IPA Master" role) is enabled (which means that all component services are marked as enabled, read the linked design for more info). However the fact that something is marked as enabled/ready in LDAP backend does not reflect the real status of systemd service on local system it just tells you that someone (typically installer) marked this service as enabled. For that we would need a daemon that would synchronize the state of local services with the state of LDAP backend and even then things may not be 100% guaranteed. > 2) A new HTTP route http[s]://$FQDN/ipa/ready is added. The route does > not need authentication. When ipaReady=TRUE the route simple returns 200 > OK with some text like READY. When the attribute is not present or > FALSE, it returns an error to the client (412, 408?). > > 3) All ipa install and upgrade commands set the attribute to FALSE > before any tasks. > Installers already mark the corresponding service as enabled when finished succesfully. > 4) A final step in all ipa install and upgrade commands checks that all > services have been started and are ready to handle requests. Eventually > the ipaReady attribute is set to true. > This is basically what ipactl status does. > Christian > > > http://www.freeipa.org/page/V4/Server_Roles -- Martin^3 Babinsky From pvomacka at redhat.com Thu Apr 14 11:03:32 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 14 Apr 2016 13:03:32 +0200 Subject: [Freeipa-devel] [PATCH] 0015, 16 webui: Add 'Skip overlap check' checkbox to the dns adder dialogs Message-ID: <570F7904.6000908@redhat.com> Hello, The first patch (0015) adds the checkbox to the dns zone adder dialog. The second patch (0016) adds the 'skip overlap check' checkbox to the dns forward zone adder dialog. This patch requires the previous one. The patch 0016 might not be used in case that the dns forward zone dialog shouldn't contain that checkbox. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0015-Add-skip-overlap-check-checkbox-into-add-zone-dialog.patch Type: text/x-patch Size: 2865 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0016-Add-skip-overlap-check-checkbox-to-the-add-dns-forwa.patch Type: text/x-patch Size: 1101 bytes Desc: not available URL: From dkupka at redhat.com Thu Apr 14 11:39:17 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 14 Apr 2016 13:39:17 +0200 Subject: [Freeipa-devel] [PATCH 0459] use python-netifaces for detection of the local ip addresses In-Reply-To: <570E6916.4030301@redhat.com> References: <570E6916.4030301@redhat.com> Message-ID: <570F8165.7070105@redhat.com> On 13/04/16 17:43, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5591 > > Patch attached. > > Hi, two nitpicks: 1) python-netifaces is missing in BuildRequires. 2) iproute package is no longer needed in Requires. Otherwise it works, ACK when freeipa.spec.in is fixed. -- David Kupka From mbasti at redhat.com Thu Apr 14 11:55:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 Apr 2016 13:55:37 +0200 Subject: [Freeipa-devel] [PATCH 0459] use python-netifaces for detection of the local ip addresses In-Reply-To: <570F8165.7070105@redhat.com> References: <570E6916.4030301@redhat.com> <570F8165.7070105@redhat.com> Message-ID: <570F8539.3010902@redhat.com> On 14.04.2016 13:39, David Kupka wrote: > On 13/04/16 17:43, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5591 >> >> Patch attached. >> >> > Hi, > two nitpicks: > 1) python-netifaces is missing in BuildRequires. > 2) iproute package is no longer needed in Requires. > > Otherwise it works, ACK when freeipa.spec.in is fixed. > Thanks, updated Pushed to master: 70fd78928cb874006f218ae4e7aca00e0babf99a From mbasti at redhat.com Thu Apr 14 12:03:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 Apr 2016 14:03:40 +0200 Subject: [Freeipa-devel] [PATCH] 0015, 16 webui: Add 'Skip overlap check' checkbox to the dns adder dialogs In-Reply-To: <570F7904.6000908@redhat.com> References: <570F7904.6000908@redhat.com> Message-ID: <570F871C.1070209@redhat.com> On 14.04.2016 13:03, Pavel Vomacka wrote: > Hello, > > The first patch (0015) adds the checkbox to the dns zone adder dialog. > > The second patch (0016) adds the 'skip overlap check' checkbox to the > dns forward zone adder dialog. This patch requires the previous one. > The patch 0016 might not be used in case that the dns forward zone > dialog shouldn't contain that checkbox. > > -- > Pavel^3 Vomacka > > Can we add hint to webUI what 'skip overlap check' means? Maybe description from ipa dns[forward]zone-add --help. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu Apr 14 12:04:36 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 14 Apr 2016 14:04:36 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade In-Reply-To: <570E03B4.3080008@redhat.com> References: <570637EB.2000705@redhat.com> <570CF9A0.7070200@redhat.com> <570E03B4.3080008@redhat.com> Message-ID: <570F8754.4080503@redhat.com> The new version disables a falsely failing pylint check for ldap_connect method in a master host instance. On 04/13/2016 10:30 AM, Oleg Fayans wrote: > Hi Martin, > > I've updated the patch with regard to your review. Thank you! > > On 04/12/2016 03:35 PM, Martin Babinsky wrote: >> On 04/07/2016 12:35 PM, Oleg Fayans wrote: >>> >>> >>> >> Hi Oleg, >> >> since this is a part of replica promotion test suite please add the link >> to https://fedorahosted.org/freeipa/ticket/5723 to the commit message. > > Done > >> >> The patch cannot be applied cleanly, even 3-way merge fails with: >> >> """ >> git am >> ../review/ofayans/freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch >> -3 >> Applying: Add test if replica is working after domain upgrade >> error: invalid object 100644 acae5c924594cc73bf262eeab5f843f252723207 >> for 'ipatests/test_integration/test_replica_promotion.py' >> fatal: git-write-tree: error building trees >> Repository lacks necessary blobs to fall back on 3-way merge. >> Cannot fall back to three-way merge. >> Patch failed at 0001 Add test if replica is working after domain upgrade >> """ >> >> I had to fall back to plain 'patch -p1' >> >> I have your previous patches 0033-0034 applied. The patch probably needs >> a rebase. > > Fixed > >> >> Also I would be more happy if the username for 'testuser' was not >> hardcoded in the code. You can factor it out as a class member. >> > > Done > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0035.2-Add-test-if-replica-is-working-after-domain-upgrade.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: From jpazdziora at redhat.com Thu Apr 14 12:05:05 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 14 Apr 2016 14:05:05 +0200 Subject: [Freeipa-devel] Check if server is fully installed and ready In-Reply-To: <570F5FD1.4050600@redhat.com> References: <570F5FD1.4050600@redhat.com> Message-ID: <20160414120504.GF3241@redhat.com> On Thu, Apr 14, 2016 at 11:16:01AM +0200, Christian Heimes wrote: > > Two days ago on IRC Jan came up with the same problem with containers. > He ran into a problem related to containers and DNS updates. Since I'm My issue was mostly PEBKAC. In container environments that I use, the IP address of the IPA server itself can change with new start, so the fact that SSSD couldn't talk to IPA was actually correct -- at that time, my client it was trying to talk to the IPA server on IP address that was no longer valid. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Thu Apr 14 12:17:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 Apr 2016 14:17:57 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade In-Reply-To: <570F8754.4080503@redhat.com> References: <570637EB.2000705@redhat.com> <570CF9A0.7070200@redhat.com> <570E03B4.3080008@redhat.com> <570F8754.4080503@redhat.com> Message-ID: <570F8A75.8060002@redhat.com> On 14.04.2016 14:04, Oleg Fayans wrote: > The new version disables a falsely failing pylint check for ldap_connect > method in a master host instance. > > On 04/13/2016 10:30 AM, Oleg Fayans wrote: >> Hi Martin, >> >> I've updated the patch with regard to your review. Thank you! >> >> On 04/12/2016 03:35 PM, Martin Babinsky wrote: >>> On 04/07/2016 12:35 PM, Oleg Fayans wrote: >>>> >>>> >>> Hi Oleg, >>> >>> since this is a part of replica promotion test suite please add the link >>> to https://fedorahosted.org/freeipa/ticket/5723 to the commit message. >> Done >> >>> The patch cannot be applied cleanly, even 3-way merge fails with: >>> >>> """ >>> git am >>> ../review/ofayans/freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch >>> -3 >>> Applying: Add test if replica is working after domain upgrade >>> error: invalid object 100644 acae5c924594cc73bf262eeab5f843f252723207 >>> for 'ipatests/test_integration/test_replica_promotion.py' >>> fatal: git-write-tree: error building trees >>> Repository lacks necessary blobs to fall back on 3-way merge. >>> Cannot fall back to three-way merge. >>> Patch failed at 0001 Add test if replica is working after domain upgrade >>> """ >>> >>> I had to fall back to plain 'patch -p1' >>> >>> I have your previous patches 0033-0034 applied. The patch probably needs >>> a rebase. >> Fixed >> >>> Also I would be more happy if the username for 'testuser' was not >>> hardcoded in the code. You can factor it out as a class member. >>> >> Done >> >> >> > > I suggest to put missing member here: diff --git a/pylint_plugins.py b/pylint_plugins.py index c3042f4..7a421ab 100644 --- a/pylint_plugins.py +++ b/pylint_plugins.py @@ -230,6 +230,7 @@ ipa_class_members = { {'transport': ['put_file']}, 'put_file_contents', 'get_file_contents', + 'ldap_connect', ]}, 'replicas', 'clients', instead of disabling the check locally (untested) Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Thu Apr 14 14:30:40 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 14 Apr 2016 10:30:40 -0400 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> Message-ID: <1460644240.17408.6.camel@redhat.com> On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > Hi, > > The attached patch is a part of the authentication indicator > enhancements, > adding indicator value storage and retrieval for the KDB driver. > > https://fedorahosted.org/freeipa/ticket/5782 This patch is part of the authentication indicators work and is parallel to my patches (also on this list). My patches cause the OTP/RADIUS process to insert indicators in tickets. This patch allows us to define required indicators for a service principal. After this patch is merged, we will need CLI and UI to expose the manipulation of this attribute. A similar patch was already merged upstream. This patch matches the behavior and schema of upstream in our own KDB module with one exception: we do not store indicators in krbExtraData in parallel. From npmccallum at redhat.com Thu Apr 14 14:32:15 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 14 Apr 2016 10:32:15 -0400 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> Message-ID: <1460644335.17408.8.camel@redhat.com> On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > Hi, > > The attached patch is a part of the authentication indicator > enhancements, > adding indicator value storage and retrieval for the KDB driver. > > https://fedorahosted.org/freeipa/ticket/5782 Can you add some whitespace in next_attr()? The density of the code there hurts readability. From mbasti at redhat.com Thu Apr 14 15:16:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 Apr 2016 17:16:33 +0200 Subject: [Freeipa-devel] [PATCH 0439] Do not do extra search for ipasshpubkey In-Reply-To: <56EF9937.5030100@redhat.com> References: <56E804A4.4000505@redhat.com> <56EBF37F.4090101@redhat.com> <56EF9937.5030100@redhat.com> Message-ID: <570FB451.60409@redhat.com> On 21.03.2016 07:48, Jan Cholasta wrote: > On 18.3.2016 13:24, Martin Babinsky wrote: >> On 03/15/2016 01:48 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/3376 >>> >>> Patch attached. >>> >>> >> ACK but fix the 'behavioar' typo in the commit message before pushing. > > 1) You are breaking the default_attributes contract by declaring > ipasshpubkey as default attribute and then removing it from the > result. This is a hack, which makes the code less readable ("If > ipasshpubkey is in default_attributes, why am I not getting it in the > result?") and requires every developer to remember to remove > ipasshpubkey themselves if they are using user/host objects in their > code and want the same behavior as user/host commands. Please keep the > change isolated in the relevant commands. > > 2) Don't add ipasshpubkey to search_attributes, we don't want > user-find and friends to search inside ipasshpubkey. > Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0439.2-Do-not-do-extra-search-for-ipasshpubkey-to-generate-.patch Type: text/x-patch Size: 18746 bytes Desc: not available URL: From mbasti at redhat.com Thu Apr 14 15:47:05 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 14 Apr 2016 17:47:05 +0200 Subject: [Freeipa-devel] [PATCH 0461] Limit max username lenght to 255 in config-mod Message-ID: <570FBB79.5010704@redhat.com> https://fedorahosted.org/freeipa/ticket/5774 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0461-Limit-max-username-length-to-255-in-config-mod.patch Type: text/x-patch Size: 894 bytes Desc: not available URL: From mrogers at redhat.com Thu Apr 14 16:59:55 2016 From: mrogers at redhat.com (Matt Rogers) Date: Thu, 14 Apr 2016 12:59:55 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <1460644335.17408.8.camel@redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> Message-ID: <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Nathaniel McCallum" > To: "Matt Rogers" , freeipa-devel at redhat.com > Sent: Thursday, April 14, 2016 10:32:15 AM > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > Hi, > > > > The attached patch is a part of the authentication indicator > > enhancements, > > adding indicator value storage and retrieval for the KDB driver. > > > > https://fedorahosted.org/freeipa/ticket/5782 > > Can you add some whitespace in next_attr()? The density of the code > there hurts readability. > Sure, I've attached the revised patch. -- Matt Rogers Red Hat, Inc -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mrogers-0001-ipa_kdb-add-krbPrincipalAuthInd-handling.patch Type: text/x-patch Size: 13070 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 15 08:18:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 15 Apr 2016 10:18:39 +0200 Subject: [Freeipa-devel] [TESTS][PATCH 0011] WebUI: Creating user without private group In-Reply-To: <570F582A.109@redhat.com> References: <56CF0AD6.4060505@redhat.com> <56DD9E73.1020609@redhat.com> <56DEBE89.70808@redhat.com> <56DEC2DF.3000801@redhat.com> <56E1B5CC.7070208@redhat.com> <56EBD74C.40709@redhat.com> <56FCFF33.7060801@redhat.com> <56FD314C.4080809@redhat.com> <56FE6ACE.1050705@redhat.com> <57029C43.7000309@redhat.com> <570F582A.109@redhat.com> Message-ID: <5710A3DF.4030703@redhat.com> On 14.04.2016 10:43, Lenka Doudova wrote: > > > On 04/04/2016 06:54 PM, Martin Basti wrote: >> >> >> On 01.04.2016 14:34, Pavel Vomacka wrote: >>> >>> >>> On 03/31/2016 04:16 PM, Lenka Doudova wrote: >>>> >>>> >>>> On 03/31/2016 12:42 PM, Pavel Vomacka wrote: >>>>> >>>>> >>>>> On 03/18/2016 11:24 AM, Lenka Doudova wrote: >>>>>> >>>>>> >>>>>> On 03/10/2016 06:58 PM, Petr Vobornik wrote: >>>>>>> On 03/08/2016 01:17 PM, Lenka Doudova wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 03/08/2016 12:59 PM, Petr Vobornik wrote: >>>>>>>>> On 03/07/2016 04:29 PM, Pavel Vomacka wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/25/2016 03:08 PM, Lenka Doudova wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> here's a patch for webUI tests that provides test for >>>>>>>>>>> creating user >>>>>>>>>>> without private group. >>>>>>>>>>> Related to ticket https://fedorahosted.org/freeipa/ticket/4986 >>>>>>>>>>> >>>>>>>>>>> Since the option to specify GID when creating a user is not >>>>>>>>>>> available >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5505 the test >>>>>>>>>>> creates a new >>>>>>>>>>> posix group, makes it a default user group instead of >>>>>>>>>>> 'ipausers' and >>>>>>>>>>> then attemps to create the user without private group. >>>>>>>>>>> Returning >>>>>>>>>>> default user group value to 'ipausers' is provided even for >>>>>>>>>>> cases when >>>>>>>>>>> the test fails so it would not block other tests from >>>>>>>>>>> performing >>>>>>>>>>> properly. >>>>>>>>>>> >>>>>>>>>>> Lenka >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> ACK, works well. >>>>>>>>>> >>>>>>>>>> Pavel^3 Vomacka >>>>>>>>>> >>>>>>>>> >>>>>>>>> NACK, don't use naked except, specify at least 'Exception' >>>>>>>>> + except: >>>>>>>>> >>>>>>>> >>>>>>>> Thanks, patch fixed according to Petr's review attached. >>>>>>>> >>>>>>>> Lenka >>>>>>> >>>>>>> Ticket 5505 was pushed. So the workaround can be removed. Do you >>>>>>> prefer to do it in this patch? >>>>>>> >>>>>>> Also, maybe it would be good to test both cases and check if the >>>>>>> error is actually the right one. >>>>>> >>>>>> Hi, >>>>>> >>>>>> attaching patch fixed according to recently pushed changes. >>>>>> >>>>>> Lenka >>>>> Hi, >>>>> >>>>> NACK, >>>>> >>>>> 1) The data definition for user3 (user.DATA3) is not used >>>>> anywhere. And the definition is actually the same as definition of >>>>> user4. So, I think that it could be removed. >>>>> >>>>> 2) This is just a detail, but I would rather use 'combobox_input' >>>>> or 'combobox_textbox' as parameter name because the parameter >>>>> actually doesn't represent the value of combobox. >>>>> >>>>> Otherwise it works as expected. >>>>> >>>>> -- >>>>> Pavel^3 Vomacka >>>>> >>>> Hi, >>>> >>>> thanks for comments, updated patch attached. >>>> >>>> Lenka >>>> >>>> >>> Thank you, ACK. >>> >>> -- >>> Pavel^3 Vomacka >>> >>> >>> >> Ticket is in closed milestone, this patch cannot be attached to >> closed milestone, please create a new ticket/or post the proper ticket. >> >> > Hi, > > new ticket has been created for this issue. Patch with modified commit > message to refer to the new ticket attached. > Lenka > > Pushed to: master: 6468a398504d8e4aae94488047f2dafe5b895e1d ipa-4-3: bd0ab0a8ec175ebbe619b32451b3371a86e8a96a -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Fri Apr 15 11:18:24 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 15 Apr 2016 13:18:24 +0200 Subject: [Freeipa-devel] [PATCH 0461] Limit max username lenght to 255 in config-mod In-Reply-To: <570FBB79.5010704@redhat.com> References: <570FBB79.5010704@redhat.com> Message-ID: <5710CE00.30409@redhat.com> On 14/04/16 17:47, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5774 > > Patch attached. > > Hi, works for me, ACK. FYI: While trying this I've hit related issue (https://fedorahosted.org/freeipa/ticket/5822) but I believe the impact is minimal. -- David Kupka From ofayans at redhat.com Fri Apr 15 11:23:05 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 15 Apr 2016 13:23:05 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade In-Reply-To: <570F8A75.8060002@redhat.com> References: <570637EB.2000705@redhat.com> <570CF9A0.7070200@redhat.com> <570E03B4.3080008@redhat.com> <570F8754.4080503@redhat.com> <570F8A75.8060002@redhat.com> Message-ID: <5710CF19.3090603@redhat.com> Hi Martin & Martin, The updated patches are included. both apply cleanly and pass pylint On 04/14/2016 02:17 PM, Martin Basti wrote: > > > On 14.04.2016 14:04, Oleg Fayans wrote: >> The new version disables a falsely failing pylint check for ldap_connect >> method in a master host instance. >> >> On 04/13/2016 10:30 AM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> I've updated the patch with regard to your review. Thank you! >>> >>> On 04/12/2016 03:35 PM, Martin Babinsky wrote: >>>> On 04/07/2016 12:35 PM, Oleg Fayans wrote: >>>>> >>>>> >>>> Hi Oleg, >>>> >>>> since this is a part of replica promotion test suite please add the link >>>> to https://fedorahosted.org/freeipa/ticket/5723 to the commit message. >>> Done >>> >>>> The patch cannot be applied cleanly, even 3-way merge fails with: >>>> >>>> """ >>>> git am >>>> ../review/ofayans/freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch >>>> -3 >>>> Applying: Add test if replica is working after domain upgrade >>>> error: invalid object 100644 acae5c924594cc73bf262eeab5f843f252723207 >>>> for 'ipatests/test_integration/test_replica_promotion.py' >>>> fatal: git-write-tree: error building trees >>>> Repository lacks necessary blobs to fall back on 3-way merge. >>>> Cannot fall back to three-way merge. >>>> Patch failed at 0001 Add test if replica is working after domain upgrade >>>> """ >>>> >>>> I had to fall back to plain 'patch -p1' >>>> >>>> I have your previous patches 0033-0034 applied. The patch probably needs >>>> a rebase. >>> Fixed >>> >>>> Also I would be more happy if the username for 'testuser' was not >>>> hardcoded in the code. You can factor it out as a class member. >>>> >>> Done >>> >>> >>> >> >> > > I suggest to put missing member here: > > diff --git a/pylint_plugins.py b/pylint_plugins.py > index c3042f4..7a421ab 100644 > --- a/pylint_plugins.py > +++ b/pylint_plugins.py > @@ -230,6 +230,7 @@ ipa_class_members = { > {'transport': ['put_file']}, > 'put_file_contents', > 'get_file_contents', > + 'ldap_connect', > ]}, > 'replicas', > 'clients', > > instead of disabling the check locally (untested) > > Martin^2 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0035.3-Add-test-if-replica-is-working-after-domain-upgrade.patch Type: text/x-patch Size: 2528 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0037-disabled-check-for-ldap_connect-in-pylint.patch Type: text/x-patch Size: 713 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 15 11:25:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 15 Apr 2016 13:25:42 +0200 Subject: [Freeipa-devel] [PATCH 0461] Limit max username lenght to 255 in config-mod In-Reply-To: <5710CE00.30409@redhat.com> References: <570FBB79.5010704@redhat.com> <5710CE00.30409@redhat.com> Message-ID: <5710CFB6.8020307@redhat.com> On 15.04.2016 13:18, David Kupka wrote: > On 14/04/16 17:47, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5774 >> >> Patch attached. >> >> > > Hi, > works for me, ACK. > > FYI: While trying this I've hit related issue > (https://fedorahosted.org/freeipa/ticket/5822) but I believe the > impact is minimal. Pushed to master: 93871bf017e1bc5f2c176aa3419278d49fcc003b From akasurde at redhat.com Fri Apr 15 11:43:39 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Fri, 15 Apr 2016 17:13:39 +0530 Subject: [Freeipa-devel] [PATCH] Added description related to 'status' in ipactl man page Message-ID: <5710D3EB.7040500@redhat.com> Hi All, Please review these patches. Fixes: https://fedorahosted.org/freeipa/ticket/5768 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0007-1-Added-description-related-to-status-in-ipactl-man-pa.patch Type: text/x-patch Size: 912 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0007-1-Added-description-related-to-status-in-ipactl-man-pa-4-2.patch Type: text/x-patch Size: 912 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0007-1-Added-description-related-to-status-in-ipactl-man-pa-4-3.patch Type: text/x-patch Size: 912 bytes Desc: not available URL: From slaznick at redhat.com Fri Apr 15 12:30:05 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 15 Apr 2016 14:30:05 +0200 Subject: [Freeipa-devel] [PATCH 0024] ipa-replica-manage: added --suffix option for certain commands In-Reply-To: <570E3013.7030006@redhat.com> References: <56E29266.8000501@redhat.com> <56E6E43B.4050805@redhat.com> <56E7AADC.3060407@redhat.com> <56E7F642.8010109@redhat.com> <56E90C5C.2020703@redhat.com> <56E925D0.2080305@redhat.com> <56E9637B.5080307@redhat.com> <56F2B380.9030504@redhat.com> <1183297765.33667649.1458760420403.JavaMail.zimbra@redhat.com> <56F42D93.5050505@redhat.com> <56FBE818.80805@redhat.com> <5704FB3C.2050003@redhat.com> <570E3013.7030006@redhat.com> Message-ID: <5710DECD.5040103@redhat.com> On 04/13/2016 01:40 PM, Martin Basti wrote: > > > On 06.04.2016 14:04, Stanislav Laznicka wrote: >> On 03/30/2016 04:52 PM, Martin Basti wrote: >>> On 24.03.2016 19:10, Stanislav Laznicka wrote: >>>> On 03/23/2016 08:13 PM, Martin Basti wrote: >>>>> [...] >>>>> Can you please update design >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 >>>>> (mainly >>>>> the --suffix option)? Also there are missing clean-ruv and list-ruv >>>>> commands in design, and fix usage at the bottom. >>>>> >>>>> 1) >>>>> I don't understand this expression >>>>> + if dirman_passwd is None or ( >>>>> + not dirman_passwd and args[0] in >>>>> cs_enabled_commands): >>>>> >>>>> You already tested if subcommand belongs to cs_enabled_commands few >>>>> lines above, IMO the 'dirman_password is None' expression is enough. >>>> If I understand it well, when empty password is entered, the >>>> program continues and uses Kerberos credentials for some >>>> operations. E.g. for list-ruv, if empty password is entered, the >>>> command would only display RUVs for domain tree but not for the CA >>>> tree no matter if CA is set up or not (in the current state of the >>>> patch, after get_ruv refactoring). This here is one possible way >>>> around this, although the check for non-empty password might >>>> probably just as well be in get_ruv_both_suffixes. >>> >>> ok >>>>> 2) >>>>> +# tuple of commands that work with ca tree and need Directory >>>>> Manager >>>>> password >>>>> +cs_enabled_commands = ("list-ruv", "clean-ruv", "abort-clean-ruv") >>>>> >>>>> this variable is used only toi detect if dirman passwd is needed, I >>>>> suggest to rename it to commands_req_dirman_passwd, or something >>>>> better. >>>>> >>>>> 3) >>>>> Q: Do we need is_cs_set() function? >>>>> A: Yes! >>>>> >>>>> I wanted to give you ultimate NACK, but then I checked how get_ruv >>>>> code >>>>> works and I changed my mind. >>>>> >>>>> Please write a comment where is_cs_set function is used, why we need >>>>> extra function instead of catching an exception, possibly you can >>>>> open a >>>>> refactoring ticket. >>>> After the refactoring changes, is_cs_set should not be needed >>>> anymore, removed it. >>>>> >>>>> Shame: >>>>> 1) >>>>> + if not test_connection(realm, host, options.nolookup) or\ >>>>> Please use parentheses instead of backslash >>>>> >>>>> 2) >>>>> + args[0] in cs_enabled_commands: >>>>> >>>>> + not dirman_passwd and args[0] in >>>>> cs_enabled_commands): >>>>> >>>>> Indentation is not multiplication of 4 >>>> Shame on me indeed, fixed it. >>>>> >>>>> Nitpicks (I don't insist on fixing these): >>>>> 1) >>>>> + if servers.get('ca', None): >>>>> >>>>> None is default >>>>> >>>>> 2) >>>>> + for (netloc, rid) in servers['ca']: >>>>> parentheses are not needed >>>>> >>>>> 3) >>>>> + print("\t%s: %s" % (netloc, rid)) >>>>> Would be nice to use .format() instead of % >>>>> >>>>> Martin^2 >>>>> >>>>> >>>>> >>>>> I changed my mind, ultimate NACK. >>>>> Please fix get_ruv function, is_cs_set will not help. In case >>>>> there are no RUVs but CA is installed, sys.exit there prevents us >>>>> from removing RUVs (or any else operation) on domain suffix, and >>>>> vice versa. >>>>> I propose to move ticket to 4.4 milestone because I would like to >>>>> avoid breaking something in 4.3, as this will hit many places in >>>>> ipa-replica-manage. >>>>> >>>>> Please provide the refactoring of get_ruv as separate patch a put >>>>> these patches on top of it. >>>>> >>>>> Martin2 >>>> Did the refactoring. There also seemed to be duplicit code in >>>> abort_clean_ruv for some reason, removed it (I hope it does not >>>> break anything, but it seemed rather useless). Also had to change >>>> the numbers of the patches so that they would apply. >>> >>> NACK >>> >>> * ipa-replica-manage refactoring * >>> >>> 1) >>> Instead of: >>> - print("Failed to connect to server %s: %s" % (host, e)) >>> - sys.exit(1) >>> + root_logger.debug("Failed to connect to server {host}: {err}" >>> + .format(host=host, err=e)) >>> + raise RuntimeError(e) >>> >>> I expected >>> >>> - print("Failed to connect to server %s: %s" % (host, e)) >>> - sys.exit(1) >>> + root_logger.debug(traceback.format_exc()) >>> + raise RuntimeError("Failed to connect to server {host}: {err}" >>> + .format(host=host, err=e))) >> Should be fixed now. >>> >>> 2) >>> - print("No RUV records found.") >>> - sys.exit(0) >>> >>> Here is exit state 0, so we should not raise error. >>> >>> I think that we should create new nonfatal exception. >> Made a new nonfatal error exception, then. This step was a bit >> controversial when it comes to get_ruv_both_suffixes because it needs >> to catch both this new exception and a RuntimeError exception for >> both trees. As the main idea here was not to stop if either tree is >> missing (resulting in RuntimeError in get_ruv) or contains no records >> (NonFatalError), it is only printed that something bad may have >> happened (or it's debug-logged in case of nonfatal errors). In the >> end, only NonFatalError exception is raised if no records were found >> for whatever reason resulting in the script always returning 0. >>> >>> 3) >>> - print("unable to decode: %s" % ruv) >>> + root_logger.debug("unable to decode: %s" % ruv) >>> This may break tests, because the logger logs to stderr, leave it as >>> print for now >>> >>> 4) >>> - servers = get_ruv(realm, host, dirman_passwd, nolookup) >>> + try: >>> + servers = get_ruv(realm, host, dirman_passwd, nolookup) >>> + except RuntimeError as e: >>> + print(e) >>> + sys.exit(1) >>> >>> again we have to print it to stdout for now. >> 3), 4) done, although it might be better to log to stderr from patch >> number 27 and on since the default behavior is changed anyway. >>> >>> * abort-clean/list/clean-ruv now work for both suffixes * >>> >>> - if dirman_passwd is None: >>> + if dirman_passwd is None or ( >>> + not dirman_passwd and args[0] in >>> dirman_passwd_req_commands): >>> sys.exit("Directory Manager password required") >> Done. >>> >>> Please fix other patch accordingly. >>> Martin^2 >> > > 1) > +class NonFatalError(Exception): > + pass > > IMO we should be more specific and call it NoRUVsFound[Exception] > > 2) > Not sure if this i sstill refactoring, it should be separate patch > - if dirman_passwd is None: > + if dirman_passwd is None or ( > + not dirman_passwd and args[0] in > dirman_passwd_req_commands): > > 3) > +def get_ruv_both_suffixes > > I think in case where both suffixes returns RuntimeError we should > raise RuntimeError too which results into exit with error code. > Please see the latest patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0026-3-replica-manage-fail-nicely-when-DM-psswd-required.patch Type: text/x-patch Size: 1592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0027-3-ipa-replica-manage-refactoring.patch Type: text/x-patch Size: 5164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0028-3-abort-clean-list-clean-ruv-now-work-for-both-suffixe.patch Type: text/x-patch Size: 9626 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0029-3-Moved-password-check-from-clean_dangling_ruv.patch Type: text/x-patch Size: 1827 bytes Desc: not available URL: From pvoborni at redhat.com Fri Apr 15 13:03:01 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Apr 2016 15:03:01 +0200 Subject: [Freeipa-devel] [PATCH 0461] Limit max username lenght to 255 in config-mod In-Reply-To: <5710CFB6.8020307@redhat.com> References: <570FBB79.5010704@redhat.com> <5710CE00.30409@redhat.com> <5710CFB6.8020307@redhat.com> Message-ID: <5710E685.8080005@redhat.com> On 04/15/2016 01:25 PM, Martin Basti wrote: > > > On 15.04.2016 13:18, David Kupka wrote: >> On 14/04/16 17:47, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5774 >>> >>> Patch attached. >>> >>> >> >> Hi, >> works for me, ACK. >> >> FYI: While trying this I've hit related issue >> (https://fedorahosted.org/freeipa/ticket/5822) but I believe the >> impact is minimal. > > Pushed to master: 93871bf017e1bc5f2c176aa3419278d49fcc003b > API.txt and version was not updated: -option: Int('ipamaxusernamelength', attribute=True, autofill=False, cli_name='maxusername', minvalue=1, multivalue=False, required=False) +option: Int('ipamaxusernamelength', attribute=True, autofill=False, cli_name='maxusername', maxvalue=255, minvalue=1, multivalue=False, required=False) -- Petr Vobornik From mbabinsk at redhat.com Fri Apr 15 13:35:30 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 15 Apr 2016 15:35:30 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade In-Reply-To: <5710CF19.3090603@redhat.com> References: <570637EB.2000705@redhat.com> <570CF9A0.7070200@redhat.com> <570E03B4.3080008@redhat.com> <570F8754.4080503@redhat.com> <570F8A75.8060002@redhat.com> <5710CF19.3090603@redhat.com> Message-ID: <5710EE22.3020702@redhat.com> On 04/15/2016 01:23 PM, Oleg Fayans wrote: > Hi Martin & Martin, > > The updated patches are included. both apply cleanly and pass pylint > > On 04/14/2016 02:17 PM, Martin Basti wrote: >> >> >> On 14.04.2016 14:04, Oleg Fayans wrote: >>> The new version disables a falsely failing pylint check for ldap_connect >>> method in a master host instance. >>> >>> On 04/13/2016 10:30 AM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> I've updated the patch with regard to your review. Thank you! >>>> >>>> On 04/12/2016 03:35 PM, Martin Babinsky wrote: >>>>> On 04/07/2016 12:35 PM, Oleg Fayans wrote: >>>>>> >>>>>> >>>>> Hi Oleg, >>>>> >>>>> since this is a part of replica promotion test suite please add the link >>>>> to https://fedorahosted.org/freeipa/ticket/5723 to the commit message. >>>> Done >>>> >>>>> The patch cannot be applied cleanly, even 3-way merge fails with: >>>>> >>>>> """ >>>>> git am >>>>> ../review/ofayans/freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch >>>>> -3 >>>>> Applying: Add test if replica is working after domain upgrade >>>>> error: invalid object 100644 acae5c924594cc73bf262eeab5f843f252723207 >>>>> for 'ipatests/test_integration/test_replica_promotion.py' >>>>> fatal: git-write-tree: error building trees >>>>> Repository lacks necessary blobs to fall back on 3-way merge. >>>>> Cannot fall back to three-way merge. >>>>> Patch failed at 0001 Add test if replica is working after domain upgrade >>>>> """ >>>>> >>>>> I had to fall back to plain 'patch -p1' >>>>> >>>>> I have your previous patches 0033-0034 applied. The patch probably needs >>>>> a rebase. >>>> Fixed >>>> >>>>> Also I would be more happy if the username for 'testuser' was not >>>>> hardcoded in the code. You can factor it out as a class member. >>>>> >>>> Done >>>> >>>> >>>> >>> >>> >> >> I suggest to put missing member here: >> >> diff --git a/pylint_plugins.py b/pylint_plugins.py >> index c3042f4..7a421ab 100644 >> --- a/pylint_plugins.py >> +++ b/pylint_plugins.py >> @@ -230,6 +230,7 @@ ipa_class_members = { >> {'transport': ['put_file']}, >> 'put_file_contents', >> 'get_file_contents', >> + 'ldap_connect', >> ]}, >> 'replicas', >> 'clients', >> >> instead of disabling the check locally (untested) >> >> Martin^2 > ACK, but I think it would be good idea to merge the patches before pushing. -- Martin^3 Babinsky From mbasti at redhat.com Fri Apr 15 13:42:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 15 Apr 2016 15:42:03 +0200 Subject: [Freeipa-devel] [PATCH 0461] Limit max username lenght to 255 in config-mod In-Reply-To: <5710E685.8080005@redhat.com> References: <570FBB79.5010704@redhat.com> <5710CE00.30409@redhat.com> <5710CFB6.8020307@redhat.com> <5710E685.8080005@redhat.com> Message-ID: <5710EFAB.8060507@redhat.com> On 15.04.2016 15:03, Petr Vobornik wrote: > On 04/15/2016 01:25 PM, Martin Basti wrote: >> >> On 15.04.2016 13:18, David Kupka wrote: >>> On 14/04/16 17:47, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5774 >>>> >>>> Patch attached. >>>> >>>> >>> Hi, >>> works for me, ACK. >>> >>> FYI: While trying this I've hit related issue >>> (https://fedorahosted.org/freeipa/ticket/5822) but I believe the >>> impact is minimal. >> Pushed to master: 93871bf017e1bc5f2c176aa3419278d49fcc003b >> > API.txt and version was not updated: > > -option: Int('ipamaxusernamelength', attribute=True, autofill=False, > cli_name='maxusername', minvalue=1, multivalue=False, required=False) > +option: Int('ipamaxusernamelength', attribute=True, autofill=False, > cli_name='maxusername', maxvalue=255, minvalue=1, multivalue=False, > required=False) > Sorry. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0462-Increase-API-version-for-ipamaxusernamelength-attrib.patch Type: text/x-patch Size: 2309 bytes Desc: not available URL: From pvoborni at redhat.com Fri Apr 15 13:42:55 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Apr 2016 15:42:55 +0200 Subject: [Freeipa-devel] [PATCH] 0009 webui: Show certificates in useful format In-Reply-To: <56FBAE6A.6040008@redhat.com> References: <56E7FEA8.3010404@redhat.com> <56E99E3A.3040200@redhat.com> <56FA4E21.3040504@redhat.com> <56FBAE6A.6040008@redhat.com> Message-ID: <5710EFDF.9080508@redhat.com> On 03/30/2016 12:46 PM, Pavel Vomacka wrote: > > > On 03/29/2016 11:42 AM, Pavel Vomacka wrote: >> >> >> On 03/16/2016 06:56 PM, Petr Vobornik wrote: >>> On 03/15/2016 01:23 PM, Pavel Vomacka wrote: >>>> Hello, >>>> >>>> patch for https://fedorahosted.org/freeipa/ticket/5311 is attached. >>>> >>>> -- >>>> Pavel^3 Vomacka >>>> >>> >>> Not tested, but can we avoid using
s with "white-space: pre" and >>> therefore use only IPA.cert.pem_cert_format(text). >>> >>> Also, it should be displayed in monospaced, so probably add: >>> >>> .certificate-widget .certificate { >>> font-family: monospace; >>> overflow-x: auto; >>> white-space: pre; >>> } >> Fixed. >>> >>> >>> Probably as a separate patch or ticket: we can add "download" button which >>> would offer the certificate in form of data uri[1] with 'download' attribute >>> of 'a' element [2]. So user will get pem encoded file without any hassle. >>> >>> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/data_URIs >>> [2] https://developer.mozilla.org/en/docs/Web/HTML/Element/a >> The download button is really good idea. There is attached another patch which >> adds this button. If we need new ticket let me know and I will file it. >> >> -- >> Pavel^3 Vomacka >> >> > Self NACK, css parts should be moved to less files. Attaching new patches. > patch 9-3: ACK patch 10-2: 1. Use @font-family-base variable (defined in variable.less) for the font-family value + a { + font-family: 'Open Sans', Helvetica, Arial, sans-serif; + float: right; + } 2. Wouldn't it be better to put the download button next to the show button? Or maybe in the actions menu which is planned in the next patches? -- Petr Vobornik From pvoborni at redhat.com Fri Apr 15 13:46:08 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Apr 2016 15:46:08 +0200 Subject: [Freeipa-devel] [PATCH] 0008 Add X-Frame-Options and frame-ancestors options In-Reply-To: <56E28DEF.9020309@redhat.com> References: <56E1B319.9020204@redhat.com> <1457632943.8257.335.camel@redhat.com> <56E1BAEA.805@redhat.com> <1457634175.8257.336.camel@redhat.com> <56E280F0.6070203@redhat.com> <56E28DEF.9020309@redhat.com> Message-ID: <5710F0A0.4080809@redhat.com> On 03/11/2016 10:20 AM, Pavel Vomacka wrote: > > > On 03/11/2016 09:25 AM, Petr Vobornik wrote: >> On 03/10/2016 07:22 PM, Simo Sorce wrote: >>> On Thu, 2016-03-10 at 19:20 +0100, Pavel Vomacka wrote: >>>> >>>> On 03/10/2016 07:02 PM, Simo Sorce wrote: >>>>> On Thu, 2016-03-10 at 18:47 +0100, Pavel Vomacka wrote: >>>>>> Hi, >>>>>> >>>>>> These two options allow preventing clickjacking attacks. They don't >>>>>> allow open FreeIPA in frame, iframe or object element. >>>>> Will these apply to the whole server or just to /ipa ? >>>>> >>>> Yes, you are right, these apply to whole server. In this new patch they >>>> are applied only on /ipa. >>>> >>>> -- >>>> Pavel^3 Vomacka >>> >>> Thanks, >>> LGTM >>> >>> Simo. >>> >> >> VERSION in a header needs to incremented so that the config file is >> correctly processed during upgrade. >> > VERSION incremented. > > ACK pushed to master: * 6eb174c5e72e4a4b60cbd61a666fbe90d01e46bb Add X-Frame-Options and frame-ancestors options ipa-4-3: * d98345bc157a89c7d029a2c433ce0e2c6d5089ff Add X-Frame-Options and frame-ancestors options -- Petr Vobornik From mbasti at redhat.com Fri Apr 15 13:46:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 15 Apr 2016 15:46:16 +0200 Subject: [Freeipa-devel] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade In-Reply-To: <5710EE22.3020702@redhat.com> References: <570637EB.2000705@redhat.com> <570CF9A0.7070200@redhat.com> <570E03B4.3080008@redhat.com> <570F8754.4080503@redhat.com> <570F8A75.8060002@redhat.com> <5710CF19.3090603@redhat.com> <5710EE22.3020702@redhat.com> Message-ID: <5710F0A8.7080501@redhat.com> On 15.04.2016 15:35, Martin Babinsky wrote: > On 04/15/2016 01:23 PM, Oleg Fayans wrote: >> Hi Martin & Martin, >> >> The updated patches are included. both apply cleanly and pass pylint >> >> On 04/14/2016 02:17 PM, Martin Basti wrote: >>> >>> >>> On 14.04.2016 14:04, Oleg Fayans wrote: >>>> The new version disables a falsely failing pylint check for >>>> ldap_connect >>>> method in a master host instance. >>>> >>>> On 04/13/2016 10:30 AM, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> I've updated the patch with regard to your review. Thank you! >>>>> >>>>> On 04/12/2016 03:35 PM, Martin Babinsky wrote: >>>>>> On 04/07/2016 12:35 PM, Oleg Fayans wrote: >>>>>>> >>>>>>> >>>>>> Hi Oleg, >>>>>> >>>>>> since this is a part of replica promotion test suite please add >>>>>> the link >>>>>> to https://fedorahosted.org/freeipa/ticket/5723 to the commit >>>>>> message. >>>>> Done >>>>> >>>>>> The patch cannot be applied cleanly, even 3-way merge fails with: >>>>>> >>>>>> """ >>>>>> git am >>>>>> ../review/ofayans/freeipa-ofayans-0035-Add-test-if-replica-is-working-after-domain-upgrade.patch >>>>>> >>>>>> -3 >>>>>> Applying: Add test if replica is working after domain upgrade >>>>>> error: invalid object 100644 >>>>>> acae5c924594cc73bf262eeab5f843f252723207 >>>>>> for 'ipatests/test_integration/test_replica_promotion.py' >>>>>> fatal: git-write-tree: error building trees >>>>>> Repository lacks necessary blobs to fall back on 3-way merge. >>>>>> Cannot fall back to three-way merge. >>>>>> Patch failed at 0001 Add test if replica is working after domain >>>>>> upgrade >>>>>> """ >>>>>> >>>>>> I had to fall back to plain 'patch -p1' >>>>>> >>>>>> I have your previous patches 0033-0034 applied. The patch >>>>>> probably needs >>>>>> a rebase. >>>>> Fixed >>>>> >>>>>> Also I would be more happy if the username for 'testuser' was not >>>>>> hardcoded in the code. You can factor it out as a class member. >>>>>> >>>>> Done >>>>> >>>>> >>>>> >>>> >>>> >>> >>> I suggest to put missing member here: >>> >>> diff --git a/pylint_plugins.py b/pylint_plugins.py >>> index c3042f4..7a421ab 100644 >>> --- a/pylint_plugins.py >>> +++ b/pylint_plugins.py >>> @@ -230,6 +230,7 @@ ipa_class_members = { >>> {'transport': ['put_file']}, >>> 'put_file_contents', >>> 'get_file_contents', >>> + 'ldap_connect', >>> ]}, >>> 'replicas', >>> 'clients', >>> >>> instead of disabling the check locally (untested) >>> >>> Martin^2 >> > ACK, but I think it would be good idea to merge the patches before > pushing. > Merged and pushed to: ipa-4-3: 2abdfdd0e1ce23b36e8519cae10adcf299b3a99c master: c06117279212ec3f76762c633c0215c6d8a377e8 From pvoborni at redhat.com Fri Apr 15 14:43:05 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Apr 2016 16:43:05 +0200 Subject: [Freeipa-devel] [PATCH] 0012 webui: Add 'Activate' option to actions menu on stage user detail page In-Reply-To: <570B5413.40006@redhat.com> References: <570B5413.40006@redhat.com> Message-ID: <5710FDF9.9030200@redhat.com> On 04/11/2016 09:36 AM, Pavel Vomacka wrote: > Hello, > > this patch adds 'Activate' option to actions menu on stage user detail > page. > > Ticket: https://fedorahosted.org/freeipa/ticket/5369 > > -- > Pavel^3 Vomacka > ACK pushed to master: * d01f7e85560039543b01f3f923c670936e11e31c Add activate option to stage user details page -- Petr Vobornik From mbabinsk at redhat.com Fri Apr 15 15:19:57 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 15 Apr 2016 17:19:57 +0200 Subject: [Freeipa-devel] [PATCH 0145] replica-prepare: do not add PTR records if there is no IPA managed reverse zone Message-ID: <5711069D.30503@redhat.com> https://fedorahosted.org/freeipa/ticket/5740 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0145-replica-prepare-do-not-add-PTR-records-if-there-is-n.patch Type: text/x-patch Size: 1504 bytes Desc: not available URL: From pvoborni at redhat.com Fri Apr 15 15:59:25 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Apr 2016 17:59:25 +0200 Subject: [Freeipa-devel] [PATCH] Added fix for notifying user about account expiration in Web UI In-Reply-To: <570E1469.3050500@redhat.com> References: <56EC00CC.2080300@redhat.com> <56EC0C2A.3020009@redhat.com> <56F12632.40903@redhat.com> <570E1469.3050500@redhat.com> Message-ID: <57110FDD.8060107@redhat.com> On 04/13/2016 11:42 AM, Abhijeet Kasurde wrote: > Ping > > On 03/22/2016 04:32 PM, Abhijeet Kasurde wrote: >> Hi All, >> >> Please find the updated patches as per review comments. >> >> On 03/18/2016 07:39 PM, Petr Vobornik wrote: >>> On 03/18/2016 02:21 PM, Abhijeet Kasurde wrote: >>>> Hi All, >>>> >>>> Please review these patches. >>>> >>>> Fixes : https://fedorahosted.org/freeipa/ticket/5077 >>>> >>>> Thanks, >>>> Abhijeet Kasurde >>>> >>> >>> 'invalid' is a default and right now is meant for invalid password(not >>> correct, see below). So by reading the patch, it will break the case when >>> user sets invalid password. >>> >>> Better would be to process kinit output in rpcserver.py:login_password and >>> set e.g: 'krbprincipal-expired' reason. >>> >>> Then add it to a list of known errors in ipa.js:login_password:498. We should >>> probaly add also 'invalid-password' to the list. >>> >>> Then do the change as in this patch but only with: 'krbprincipal-expired'. >>> >>> If 'invalid-password' is added to the list of know errors then we should >>> change the default error from "The password or username you entered is >>> incorrect. " to e.g.: 'Login failed from unknown reason" >>> >> Thanks Petr for suggestions. >> >> Thanks, >> Abhijeet Kasurde >> ACK pushed to master: * 2a20c746336f85c4a9bd095db242de11f0015903 Added fix for notifying user about Kerberos principal expiration in WebUI -- Petr Vobornik From pvoborni at redhat.com Fri Apr 15 16:44:04 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 15 Apr 2016 18:44:04 +0200 Subject: [Freeipa-devel] [PATCH] 0013 webui: Add ability to convert users from preserved to staged state In-Reply-To: <570E4210.1090409@redhat.com> References: <570E4210.1090409@redhat.com> Message-ID: <57111A54.5070005@redhat.com> On 04/13/2016 02:56 PM, Pavel Vomacka wrote: > Hello, > > This patch adds ability to convert users from preserved to staged state. > > Fixes this ticket: https://fedorahosted.org/freeipa/ticket/5371 > > -- > Pavel^3 Vomacka > > The patch requires rebase. -- Petr Vobornik From mkosek at redhat.com Mon Apr 18 08:31:23 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 Apr 2016 10:31:23 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <5707C9F2.8060903@redhat.com> References: <5707C9F2.8060903@redhat.com> Message-ID: <57149B5B.1050909@redhat.com> On 04/08/2016 05:10 PM, Martin Babinsky wrote: > Hi list, > > I have put together a draft [1] outlining the effort to reimplement the > handling of Kerberos principals in both backend and frontend layers of FreeIPA > so that we may have multiple aliases per user, host or service and thus > implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and > https://fedorahosted.org/freeipa/ticket/5413 . > > Since much of the plumbing was already implemented,[2] the document mainly > describes what the patches do. Some parts required by other use cases may be > missing so please point these out. > > I would also be happy if you could correct all factual inacurracies, I did > research on this issue a long time ago and my knowledge turned a bit rusty. > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also see that you are using the Kerberos attributes in the raw name ("--krbprincipalname"). This is not consistent with the CLI form when they are used in other commands: ... Str('krbprincipalname?', validate_principal, cli_name='principal', label=_('Kerberos principal'), default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm), autofill=True, flags=['no_update'], normalizer=lambda value: normalize_principal(value), ), DateTime('krbprincipalexpiration?', cli_name='principal_expiration', label=_('Kerberos principal expiration'), ), ... IMO, it should be rather "--principal" and "--principal-alias". Martin From pspacek at redhat.com Mon Apr 18 08:55:07 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Apr 2016 10:55:07 +0200 Subject: [Freeipa-devel] [PATCH] Added description related to 'status' in ipactl man page In-Reply-To: <5710D3EB.7040500@redhat.com> References: <5710D3EB.7040500@redhat.com> Message-ID: <5714A0EB.8050102@redhat.com> On 15.4.2016 13:43, Abhijeet Kasurde wrote: > Hi All, > > Please review these patches. > > Fixes: https://fedorahosted.org/freeipa/ticket/5768 LGTM -- Petr^2 Spacek From mrniranjan at fedoraproject.org Mon Apr 18 10:39:22 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Mon, 18 Apr 2016 16:09:22 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160413085330.GA31535@mniranja.pnq.csb> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> Message-ID: <20160418103922.GA25347@mniranja.pnq.csb> Niranjan wrote: > Niranjan wrote: > > Petr Viktorin wrote: > > > On 04/06/2016 10:55 AM, Niranjan wrote: > > > > Greetings, > > > > > > > > For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > > > > a patch, I think this patch is more of a workaround , than a solution. I would > > > > like to get more inputs on how to use pytest-multihost to execute commands > > > > on Windows. The method i am using requires cygwin with openssh/bash to be > > > > installed. > > > > > > Wow. I'm surprised the only problem on Windows is the "set -e". > > > > > > Regarding the patch: > > > > > > - Why is get_winhost_class needed? I don't see it called anywhere. > > > - Similarly, why is host_type needed? Your patch only sets it. > > > > > > If run_command of WinHost and Unix hosts are this similar, I would put > > > the 'set -e\n' for Unix (and an empty string for Windows) in a class > > > attribute named e.g. "command_prelude", use it in run_command, and move > > > run_command from Host to BaseHost. > > > Would that work, or am I missing something? > > How do we detect the host is windows/unix then , we still need host_type > > to know what the type of host is (unix/windows)? > > > > > > > > > -- > > > Petr Viktorin > Please review the attached patch. > > > > > -- > > 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 > Could you please review this patch > From 5b01d7eb1bc3723201b6083a814467f87d865367 Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] modify run_command to execute on Windows > > Add global parameter windows_test_dir to specify test directory > for Windows > Add parameter host_type(per host) to specify the type of host > (host_type:windows) > move run_command from Host class to BaseHost class > > Signed-off-by: Niranjan MR > --- > pytest_multihost/config.py | 3 ++ > pytest_multihost/host.py | 87 +++++++++++++++++++++++++--------------------- > 2 files changed, 50 insertions(+), 40 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c21e8ee67c1793f154f841375f8df7b365f..58a3a5fbc8dbcdaac35e3fd305f23999d5f5b09f 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db50799b2042e699d66ed9ec5f04f6592d31..828ba81279b563e4c5d2735bc6396480f4152304 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -27,9 +27,13 @@ class BaseHost(object): > transport_class = None > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, > + password=None, windows_test_dir=None, > + host_type=None): > self.domain = domain > self.role = str(role) > + self.host_type = host_type > + self.command_prelude = 'set -e\n' > if username is None: > self.ssh_username = self.config.ssh_username > else: > @@ -40,6 +44,8 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if windows_test_dir is None: > + self.windows_test_dir = self.config.windows_test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -118,11 +124,13 @@ class BaseHost(object): > > username = dct.pop('username', None) > password = dct.pop('password', None) > + windows_test_dir = dct.pop('windows_test_dir', None) > + host_type = dct.pop('host_type', None) > > check_config_dict_empty(dct, 'host %s' % hostname) > > return cls(domain, hostname, role, ip, external_hostname, > - username, password) > + username, password, windows_test_dir, host_type) > > def to_dict(self): > """Export info about this Host to a dict""" > @@ -131,6 +139,8 @@ class BaseHost(object): > 'ip': self.ip, > 'role': self.role, > 'external_hostname': self.external_hostname, > + 'windows_test_dir': self.windows_test_dir, > + 'host_type': self.host_type > } > > @property > @@ -199,54 +209,51 @@ class BaseHost(object): > be sourced before running the command. > :param stdin_text: If given, will be written to the command's stdin > :param log_stdout: If false, standard output will not be logged > - (but will still be available as cmd.stdout_text) > + (but will still be available as cmd.stdout_text) > :param raiseonerr: If true, an exception will be raised if the command > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > + command = self.transport.start_shell(argv, log_stdout=log_stdout) > + #set working directory > + if cwd is None: > + if self.host_type == 'windows': > + cwd = self.config.windows_test_dir > + else: > + cwd = self.config.test_dir > + command.stdin.write('cd %s\n' % shell_quote(cwd)) > + > + #set the environment > + if set_env: > + command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > + > + if self.host_type != 'windows': > + command.stdin.write(self.command_prelude) > + > + if isinstance(argv, basestring): > + #Run a shell command given as string > + command.stdin.write('(') > + command.stdin.write(argv) > + command.stdin.write(')') > + else: > + # Run a command given as a popen-style list (no shell expansion) > + for arg in argv: > + command.stdin.write(shell_quote(arg)) > + command.stdin.write(' ') > + > + command.stdin.write(';exit\n') > + if stdin_text: > + command.stdin.write(stdin_text) > + command.stdin.flush() > + > + command.wait(raiseonerr=raiseonerr) > + return command > > > class Host(BaseHost): > """A Unix host""" > transport_class = transport.SSHTransport > > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > - command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > - # Set working directory > - if cwd is None: > - cwd = self.config.test_dir > - command.stdin.write('cd %s\n' % shell_quote(cwd)) > - > - # Set the environment > - if set_env: > - command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > - > - if isinstance(argv, basestring): > - # Run a shell command given as a string > - command.stdin.write('(') > - command.stdin.write(argv) > - command.stdin.write(')') > - else: > - # Run a command given as a popen-style list (no shell expansion) > - for arg in argv: > - command.stdin.write(shell_quote(arg)) > - command.stdin.write(' ') > - > - command.stdin.write(';exit\n') > - if stdin_text: > - command.stdin.write(stdin_text) > - command.stdin.flush() > - > - command.wait(raiseonerr=raiseonerr) > - return command > - > - > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > -- > 1.8.3.1 > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From pspacek at redhat.com Mon Apr 18 12:50:17 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Apr 2016 14:50:17 +0200 Subject: [Freeipa-devel] Check if server is fully installed and ready In-Reply-To: <570F6FB0.1020008@redhat.com> References: <570F5FD1.4050600@redhat.com> <570F6FB0.1020008@redhat.com> Message-ID: <5714D809.8070403@redhat.com> On 14.4.2016 12:23, Martin Babinsky wrote: > On 04/14/2016 11:16 AM, Christian Heimes wrote: >> Hi, >> >> while I was working on my Ansible playbook I ran into an issue. It is >> hard to detect if a FreeIPA server instance is fully installed and all >> its services are ready to handle requests. It's even harder to check it >> remotely. I have figured out some heuristics to detect that a sever is >> *not* fully installed (e.g. /etc/ipa/default.conf is missing or >> http://ipa-ca.ipa.example/ipa/crl/MasterCRL.bin returns 404). The >> presence of these resources is no guarantee that all FreeIPA services >> fully up and running. >> >> Two days ago on IRC Jan came up with the same problem with containers. >> He ran into a problem related to containers and DNS updates. Since I'm >> no longer alone with the problem and my own workarounds are not >> completely stable, I like to address the problem in FreeIPA directly. >> Now you might wonder why it is so hard to check if FreeIPA is ready or >> why nobody ran into the issue before. >> >> Let's start with the second question. A typical admin first installs a >> FreeIPA server on one machine. It takes a couple of seconds until he >> notices that the installer has finished. The admin ssh-es into another >> machine, sudo -s and then runs ipa-client-install with some arguments. >> It takes a couple of seconds, maybe even a minute. With containers and >> automation tools it's more like milliseconds. >> >> Now for the first question. Under some conditions a FreeIPA service >> might be started but not yet ready to serve requests or aren't fully >> operation yet. For example ticket >> https://fedorahosted.org/freeipa/ticket/5813 is an example of a problem >> with ipa-kra-install, 389-DS restarts and bind-dyndb-ldap. >> >> >> Proposal >> >> 1) A new boolean attribute ipaReady=TRUE/FALSE in >> cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX tracks whether or not an >> FreeIPA instance is ready to handle requests. >> > > Each service entry in the service container contains > 'ipaConfigString=enabledService' attribute that *should* tell that the service > is enabled and running. > > When the Server Roles[1] feature you could check whether the role that > interests you (in this case implicit "IPA Master" role) is enabled (which > means that all component services are marked as enabled, read the linked > design for more info). > > However the fact that something is marked as enabled/ready in LDAP backend > does not reflect the real status of systemd service on local system it just > tells you that someone (typically installer) marked this service as enabled. > > For that we would need a daemon that would synchronize the state of local > services with the state of LDAP backend and even then things may not be 100% > guaranteed. We can use systemd's feature 'notify' to inform systemd that service is actually running and accepting requests (compare this with 'process is running'). See man sd_notify I have a bind-dyndb-ldap ticket for this but it did not get sufficient priority up until now: https://fedorahosted.org/bind-dyndb-ldap/ticket/150 The very same thing can be done with all other services. When this is implemented for all services, it will be very easy to add systemd unit like 'ipa-ready' which can be used either for local check or to trigger a file generation somewhere so you can read the file over HTTP or so. Petr^2 Spacek > >> 2) A new HTTP route http[s]://$FQDN/ipa/ready is added. The route does >> not need authentication. When ipaReady=TRUE the route simple returns 200 >> OK with some text like READY. When the attribute is not present or >> FALSE, it returns an error to the client (412, 408?). >> > >> 3) All ipa install and upgrade commands set the attribute to FALSE >> before any tasks. >> > Installers already mark the corresponding service as enabled when finished > succesfully. >> 4) A final step in all ipa install and upgrade commands checks that all >> services have been started and are ready to handle requests. Eventually >> the ipaReady attribute is set to true. >> > This is basically what ipactl status does. >> Christian >> >> >> > http://www.freeipa.org/page/V4/Server_Roles > -- Petr^2 Spacek From pspacek at redhat.com Mon Apr 18 13:22:55 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Apr 2016 15:22:55 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5704CF86.3000709@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> Message-ID: <5714DFAF.2060303@redhat.com> On 6.4.2016 10:57, Petr Spacek wrote: > On 6.4.2016 10:50, Jan Cholasta wrote: >> On 4.4.2016 13:51, Petr Spacek wrote: >>> On 4.4.2016 13:39, Martin Basti wrote: >>>> >>>> >>>> On 31.03.2016 09:58, Petr Spacek wrote: >>>>> On 26.2.2016 15:37, Petr Spacek wrote: >>>>>> On 25.2.2016 16:46, Simo Sorce wrote: >>>>>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>>>>> Variant C >>>>>>>>>> --------- >>>>>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>>>>> the first >>>>>>>>>> round ... >>>>>>>>>> >>>>>>>>>> We would retain >>>>>>>>>> [first step - no change from variant A] >>>>>>>>>> * create locations >>>>>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>>>>> manually >>>>>>>>>> input (server, weight) tuples >>>>>>>>>> >>>>>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>>>>> from all >>>>>>>>>> other locations. >>>>>>>>>> >>>>>>>>>> Additional storage complexity: 0 >>>>>>>>>> >>>>>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>>>>> only as >>>>>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>>>>> >>>>>>>>>> This might be sufficient for the first run and would allow us to >>>>>>>>>> gather some >>>>>>>>>> feedback from the field. >>>>>>>>>> >>>>>>>>>> Now I'm inclined to this variant :-) >>>>>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>>>>> >>>>>>>>> To recap: >>>>>>>>> - define a location with the list of servers (perhaps location is a >>>>>>>>> property of server objects so you can have only one location per server, >>>>>>>>> and if you remove the server it is automatically removed from the >>>>>>>>> location w/o additional work or referential integrity necessary), if >>>>>>>>> weight is not defined (default) then they all have the same weight. >>>>>>>> Agreed. >>>>>>>> >>>>>>>> >>>>>>>>> - Allow to specify backup locations in the location object, priorities >>>>>>>>> are calculated automatically and all backup locations have same weight. >>>>>>>> Hmm, weights have to be inherited form the original location in all >>>>>>>> cases. Did >>>>>>>> you mean that all backup locations have the same *priority*? >>>>>>> Yes, sorry. >>>>>>> >>>>>>>> Anyway, explicit configuration of backup locations is introducing API and >>>>>>>> schema for variant A and that is what I'm questioning above. It is hard to >>>>>>>> make it extensible so we do not have headache in future when somebody >>>>>>>> decides >>>>>>>> that more flexibility is needed OR that link-based approach is better. >>>>>>> I think no matter we do we'll need to allow admins to override backup >>>>>>> locations, in future if we can calculate them automatically admins will >>>>>>> simply not set any backup location explicitly (or set some special value >>>>>>> like "autogenerate" and the system will do it for them. >>>>>>> >>>>>>> Forcing admins to mentally calculate weights to force the system to >>>>>>> autogenerate the configuration they want would be a bad experience, I >>>>>>> personally would find it very annoying. >>>>>>> >>>>>>>> In other words, for doing what you propose above we would have to design >>>>>>>> complete schema and API for variant A anyway to make sure we do not lock >>>>>>>> ourselves, so we are not getting any saving by doing so. >>>>>>> A seemed much more complicated to me, as you wanted to define a ful >>>>>>> matrix for weights of servers when they are served as backups and all >>>>>>> that. >>>>>>> >>>>>>>>> - Define a *default* location, which is the backup for any other >>>>>>>>> location but always with lower priority to any other explicitly defined >>>>>>>>> backup locations. >>>>>>>> I would rather *always* use the default location as backup for all other >>>>>>>> locations. It does not require any API or schema (as it equals to "all >>>>>>>> servers" except "servers in this location" which can be easily calculated >>>>>>>> on fly). >>>>>>> We can start with this, but it works well only in a stellar topology >>>>>>> where you have a central location all other location connect to. >>>>>>> As soon as you have a super-stellar topology where you have hub location >>>>>>> to which regional locations connect to, then this is wasteful. >>>>>>> >>>>>>>> This can be later on extended in whatever direction we want without any >>>>>>>> upgrade/migration problem. >>>>>>>> >>>>>>>> More importantly, all the schema and API will be common for all other >>>>>>>> variants >>>>>>>> anyway so we can start doing so and see how much time is left when it is >>>>>>>> done. >>>>>>> I am ok with this for the first step. >>>>>>> After all location is mostly about the "normal" case where clients want >>>>>>> to reach the local servers, the backup part is only an additional >>>>>>> feature we can keep simple for now. It's a degraded mode of operation >>>>>>> anyway so it is probably ok to have just one default backup location as >>>>>>> a starting point. >>>>>> Okay, now we are in agreement. I will think about minimal schema and API >>>>>> over >>>>>> the weekend. >>>>> Well, it took longer than one weekend. >>>>> >>>>> There was couple of changes in the design document: >>>>> * ?Feature Management: CLI proposal >>>>> * ?Feature Management: web UI - idea with topology graph replaced original >>>>> complicated table >>>>> * Feature Management: described necessary configuration outside of IPA DNS >>>>> * Version 1 parts which were moved into separate document: >>>>> V4/DNS_Location_Mechanism_with_per_client_override >>>>> * ?Assumptions: removed misleading reference to DHCP, clarified role of DNS >>>>> views >>>>> * Assumptions: removed misleading mention of 'different networks' and added >>>>> summary explaining how Location is defined >>>>> * Implementation: high-level outline added >>>>> >>>>> Current version: >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>> >>>>> Full diff: >>>>> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >>>>> >>>>> >>>>> >>>>> Practical usage is described in section How to test: >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >>>>> >>>>> >>>>> I will think about LDAP schema after we agree on CLI. >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>> >>>>>>>>> - Weights for backup location servers are the same as the weight defined >>>>>>>>> within the backup location itself, so no additional weights are defined >>>>>>>>> for backups. >>>>>>>> Yes, that was somehow implied in the variant A. Sorry for not >>>>>>>> mentioning it. >>>>>>>> Weight is always relative number for servers inside one location. >>>>>>> Ok it looked a lot more complex from your description. >>>>>>> >>>>>>> Simo. >>>> >>>> Design review: >>>> >>>> 1) >>>> You missed warning when there is no backup DNS server in location >>> >>> Thanks, added. >>> >>> >>>> 2) >>>> "Number of IPA DNS servers <= number of configured IPA locations" I dont >>>> understand >>>> >>>> You need at least one DNS server per location, thus DNS servers >= locations >>> >>> Good catch, fixed. >>> >>> >>>> 3) >>>> Design (Version 1: DNAME per client) Link to design doesn't work for me >>> >>> Oh, my wiki-fu was weak. Fixed. >>> >>> >>>> CLI looks good to me. Maybe we should explicitly write in design that >>>> priorities of the SRV records will be set statically (What values? 0 - servers >>>> in location, 100 - backup?) >>> >>> I've added a note about static priorities. Particular values are just an >>> implementation detail so I would not clutter feature management section with >>> that. >> >> If server can be only in one location, why bother with >> location-{add,mod,remove}-member and not use server-mod: >> >> server-mod --location= [--location-weight=0..65535] >> >> ? This is the natural way to model one-to-many relationships in the API, >> consistent with existing stuff. > > I originally wanted to have location-add-member command so (external) DNS > servers and IPA servers can be assigned to a location using the same command: > location-add-member LOCATION_NAME --ipa-server= > location-add-member LOCATION_NAME --advertising-server= > > Should I split this between > server-mod --location= [--location-weight=0..65535] > and > dnsserver-mod --type=external --advertise-location=... > > I do not like splitting server-to-location assignment management between two > commands very much. Current proposal in design page was inspired by > group-add-member command which has --users and --groups options which seemed > philosophically similar to me. > > Anyway, I'm open to suggestions how to handle this. Honza and me are playing with idea that Server Roles can be re-used for Locations, too. The rough idea is that 'the advertising' server will have a role like 'DNS Location XYZ DNS server' and that the member server will have role like 'IPA master in location XYZ'. (Pick your own names, these are just examples.) Obvious advantage is consistency in the user interface, which is something we really need. The question is how where to put equivalent of --weight option. This would make location-add-member command unnecessary. -- Petr^2 Spacek From mbasti at redhat.com Mon Apr 18 14:42:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 18 Apr 2016 16:42:23 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5714DFAF.2060303@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> Message-ID: <5714F24F.70203@redhat.com> On 18.04.2016 15:22, Petr Spacek wrote: > On 6.4.2016 10:57, Petr Spacek wrote: >> On 6.4.2016 10:50, Jan Cholasta wrote: >>> On 4.4.2016 13:51, Petr Spacek wrote: >>>> On 4.4.2016 13:39, Martin Basti wrote: >>>>> >>>>> On 31.03.2016 09:58, Petr Spacek wrote: >>>>>> On 26.2.2016 15:37, Petr Spacek wrote: >>>>>>> On 25.2.2016 16:46, Simo Sorce wrote: >>>>>>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>>>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>>>>>> Variant C >>>>>>>>>>> --------- >>>>>>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>>>>>> the first >>>>>>>>>>> round ... >>>>>>>>>>> >>>>>>>>>>> We would retain >>>>>>>>>>> [first step - no change from variant A] >>>>>>>>>>> * create locations >>>>>>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>>>>>> manually >>>>>>>>>>> input (server, weight) tuples >>>>>>>>>>> >>>>>>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>>>>>> from all >>>>>>>>>>> other locations. >>>>>>>>>>> >>>>>>>>>>> Additional storage complexity: 0 >>>>>>>>>>> >>>>>>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>>>>>> only as >>>>>>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>>>>>> >>>>>>>>>>> This might be sufficient for the first run and would allow us to >>>>>>>>>>> gather some >>>>>>>>>>> feedback from the field. >>>>>>>>>>> >>>>>>>>>>> Now I'm inclined to this variant :-) >>>>>>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>>>>>> >>>>>>>>>> To recap: >>>>>>>>>> - define a location with the list of servers (perhaps location is a >>>>>>>>>> property of server objects so you can have only one location per server, >>>>>>>>>> and if you remove the server it is automatically removed from the >>>>>>>>>> location w/o additional work or referential integrity necessary), if >>>>>>>>>> weight is not defined (default) then they all have the same weight. >>>>>>>>> Agreed. >>>>>>>>> >>>>>>>>> >>>>>>>>>> - Allow to specify backup locations in the location object, priorities >>>>>>>>>> are calculated automatically and all backup locations have same weight. >>>>>>>>> Hmm, weights have to be inherited form the original location in all >>>>>>>>> cases. Did >>>>>>>>> you mean that all backup locations have the same *priority*? >>>>>>>> Yes, sorry. >>>>>>>> >>>>>>>>> Anyway, explicit configuration of backup locations is introducing API and >>>>>>>>> schema for variant A and that is what I'm questioning above. It is hard to >>>>>>>>> make it extensible so we do not have headache in future when somebody >>>>>>>>> decides >>>>>>>>> that more flexibility is needed OR that link-based approach is better. >>>>>>>> I think no matter we do we'll need to allow admins to override backup >>>>>>>> locations, in future if we can calculate them automatically admins will >>>>>>>> simply not set any backup location explicitly (or set some special value >>>>>>>> like "autogenerate" and the system will do it for them. >>>>>>>> >>>>>>>> Forcing admins to mentally calculate weights to force the system to >>>>>>>> autogenerate the configuration they want would be a bad experience, I >>>>>>>> personally would find it very annoying. >>>>>>>> >>>>>>>>> In other words, for doing what you propose above we would have to design >>>>>>>>> complete schema and API for variant A anyway to make sure we do not lock >>>>>>>>> ourselves, so we are not getting any saving by doing so. >>>>>>>> A seemed much more complicated to me, as you wanted to define a ful >>>>>>>> matrix for weights of servers when they are served as backups and all >>>>>>>> that. >>>>>>>> >>>>>>>>>> - Define a *default* location, which is the backup for any other >>>>>>>>>> location but always with lower priority to any other explicitly defined >>>>>>>>>> backup locations. >>>>>>>>> I would rather *always* use the default location as backup for all other >>>>>>>>> locations. It does not require any API or schema (as it equals to "all >>>>>>>>> servers" except "servers in this location" which can be easily calculated >>>>>>>>> on fly). >>>>>>>> We can start with this, but it works well only in a stellar topology >>>>>>>> where you have a central location all other location connect to. >>>>>>>> As soon as you have a super-stellar topology where you have hub location >>>>>>>> to which regional locations connect to, then this is wasteful. >>>>>>>> >>>>>>>>> This can be later on extended in whatever direction we want without any >>>>>>>>> upgrade/migration problem. >>>>>>>>> >>>>>>>>> More importantly, all the schema and API will be common for all other >>>>>>>>> variants >>>>>>>>> anyway so we can start doing so and see how much time is left when it is >>>>>>>>> done. >>>>>>>> I am ok with this for the first step. >>>>>>>> After all location is mostly about the "normal" case where clients want >>>>>>>> to reach the local servers, the backup part is only an additional >>>>>>>> feature we can keep simple for now. It's a degraded mode of operation >>>>>>>> anyway so it is probably ok to have just one default backup location as >>>>>>>> a starting point. >>>>>>> Okay, now we are in agreement. I will think about minimal schema and API >>>>>>> over >>>>>>> the weekend. >>>>>> Well, it took longer than one weekend. >>>>>> >>>>>> There was couple of changes in the design document: >>>>>> * ?Feature Management: CLI proposal >>>>>> * ?Feature Management: web UI - idea with topology graph replaced original >>>>>> complicated table >>>>>> * Feature Management: described necessary configuration outside of IPA DNS >>>>>> * Version 1 parts which were moved into separate document: >>>>>> V4/DNS_Location_Mechanism_with_per_client_override >>>>>> * ?Assumptions: removed misleading reference to DHCP, clarified role of DNS >>>>>> views >>>>>> * Assumptions: removed misleading mention of 'different networks' and added >>>>>> summary explaining how Location is defined >>>>>> * Implementation: high-level outline added >>>>>> >>>>>> Current version: >>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>> >>>>>> Full diff: >>>>>> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >>>>>> >>>>>> >>>>>> >>>>>> Practical usage is described in section How to test: >>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >>>>>> >>>>>> >>>>>> I will think about LDAP schema after we agree on CLI. >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>> >>>>>>>>>> - Weights for backup location servers are the same as the weight defined >>>>>>>>>> within the backup location itself, so no additional weights are defined >>>>>>>>>> for backups. >>>>>>>>> Yes, that was somehow implied in the variant A. Sorry for not >>>>>>>>> mentioning it. >>>>>>>>> Weight is always relative number for servers inside one location. >>>>>>>> Ok it looked a lot more complex from your description. >>>>>>>> >>>>>>>> Simo. >>>>> Design review: >>>>> >>>>> 1) >>>>> You missed warning when there is no backup DNS server in location >>>> Thanks, added. >>>> >>>> >>>>> 2) >>>>> "Number of IPA DNS servers <= number of configured IPA locations" I dont >>>>> understand >>>>> >>>>> You need at least one DNS server per location, thus DNS servers >= locations >>>> Good catch, fixed. >>>> >>>> >>>>> 3) >>>>> Design (Version 1: DNAME per client) Link to design doesn't work for me >>>> Oh, my wiki-fu was weak. Fixed. >>>> >>>> >>>>> CLI looks good to me. Maybe we should explicitly write in design that >>>>> priorities of the SRV records will be set statically (What values? 0 - servers >>>>> in location, 100 - backup?) >>>> I've added a note about static priorities. Particular values are just an >>>> implementation detail so I would not clutter feature management section with >>>> that. >>> If server can be only in one location, why bother with >>> location-{add,mod,remove}-member and not use server-mod: >>> >>> server-mod --location= [--location-weight=0..65535] >>> >>> ? This is the natural way to model one-to-many relationships in the API, >>> consistent with existing stuff. >> I originally wanted to have location-add-member command so (external) DNS >> servers and IPA servers can be assigned to a location using the same command: >> location-add-member LOCATION_NAME --ipa-server= >> location-add-member LOCATION_NAME --advertising-server= >> >> Should I split this between >> server-mod --location= [--location-weight=0..65535] >> and >> dnsserver-mod --type=external --advertise-location=... >> >> I do not like splitting server-to-location assignment management between two >> commands very much. Current proposal in design page was inspired by >> group-add-member command which has --users and --groups options which seemed >> philosophically similar to me. >> >> Anyway, I'm open to suggestions how to handle this. > Honza and me are playing with idea that Server Roles can be re-used for > Locations, too. > > The rough idea is that 'the advertising' server will have a role like 'DNS > Location XYZ DNS server' and that the member server will have role like 'IPA > master in location XYZ'. > > (Pick your own names, these are just examples.) > > Obvious advantage is consistency in the user interface, which is something we > really need. > > The question is how where to put equivalent of --weight option. > > This would make location-add-member command unnecessary. > Today I found out that I misunderstood how non-IPA SRV records will work with the DNS locations feature. I expected that other SRV record stored in IPA domain will be copied unchanged to locations, only for IPA services SRV records will be altered with priorities. However, DNS locations *will not* handle other SRV than IPA ones, what effectively means that custom user SRV records will disappear on hosts thats belong to a location. Example: domain: ipa.test server: server.ipa.test custom SRV record in IPA domain: _userservice._udp SRV record: 0 100 123 server.ipa.test. The record above will not be accessible from clients that connect to server with enabled locations. I think that users may have own services on IPA server with custom SRV records, and I don't consider this behavior as user-friendly and blocker for deployment of this feature. NACK to design from me. We should fix this. Martin^2 From pviktori at redhat.com Mon Apr 18 15:00:43 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 18 Apr 2016 17:00:43 +0200 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160418103922.GA25347@mniranja.pnq.csb> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> Message-ID: <5714F69B.2090602@redhat.com> On 04/18/2016 12:39 PM, Niranjan wrote: > Niranjan wrote: >> Niranjan wrote: >>> Petr Viktorin wrote: >>>> On 04/06/2016 10:55 AM, Niranjan wrote: >>>>> Greetings, >>>>> >>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed >>>>> a patch, I think this patch is more of a workaround , than a solution. I would >>>>> like to get more inputs on how to use pytest-multihost to execute commands >>>>> on Windows. The method i am using requires cygwin with openssh/bash to be >>>>> installed. >>>> >>>> Wow. I'm surprised the only problem on Windows is the "set -e". >>>> >>>> Regarding the patch: >>>> >>>> - Why is get_winhost_class needed? I don't see it called anywhere. >>>> - Similarly, why is host_type needed? Your patch only sets it. >>>> >>>> If run_command of WinHost and Unix hosts are this similar, I would put >>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class >>>> attribute named e.g. "command_prelude", use it in run_command, and move >>>> run_command from Host to BaseHost. >>>> Would that work, or am I missing something? >>> How do we detect the host is windows/unix then , we still need host_type >>> to know what the type of host is (unix/windows)? >>>> >>>> >>>> -- >>>> Petr Viktorin >> Please review the attached patch. Sorry for the delay. The information about whether the host is Unix or Windows is available: the class is either Host or WinHost, so I don't think an extra host_type is necessary. I'd be open to adding host_type as *configuration* (and corresponding attribute) if it also selected the actual Host class. Currently to use WinHost you need to write custom code. I modified the patch so BaseHost takes test_dir as an argument, and sets it as self.test_dir, so that users don't need to choose between self.config.windows_test_dir/self.config.test_dir themselves. (Unfortunately I don't have Windows to test on; I hope the change is correct.) Would this approach work for you? -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-modify-run_command-to-execute-on-Windows.patch Type: text/x-patch Size: 4787 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Mon Apr 18 15:25:00 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Mon, 18 Apr 2016 20:55:00 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5714F69B.2090602@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> Message-ID: <20160418152500.GA5191@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/18/2016 12:39 PM, Niranjan wrote: > > Niranjan wrote: > >> Niranjan wrote: > >>> Petr Viktorin wrote: > >>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>> Greetings, > >>>>> > >>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>> installed. > >>>> > >>>> Wow. I'm surprised the only problem on Windows is the "set -e". > >>>> > >>>> Regarding the patch: > >>>> > >>>> - Why is get_winhost_class needed? I don't see it called anywhere. > >>>> - Similarly, why is host_type needed? Your patch only sets it. > >>>> > >>>> If run_command of WinHost and Unix hosts are this similar, I would put > >>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >>>> attribute named e.g. "command_prelude", use it in run_command, and move > >>>> run_command from Host to BaseHost. > >>>> Would that work, or am I missing something? > >>> How do we detect the host is windows/unix then , we still need host_type > >>> to know what the type of host is (unix/windows)? > >>>> > >>>> > >>>> -- > >>>> Petr Viktorin > >> Please review the attached patch. > > Sorry for the delay. > > The information about whether the host is Unix or Windows is available: > the class is either Host or WinHost, so I don't think an extra host_type > is necessary. > I'd be open to adding host_type as *configuration* (and corresponding > attribute) if it also selected the actual Host class. Currently to use > WinHost you need to write custom code. > > I modified the patch so BaseHost takes test_dir as an argument, and sets > it as self.test_dir, so that users don't need to choose between > self.config.windows_test_dir/self.config.test_dir themselves. > (Unfortunately I don't have Windows to test on; I hope the change is > correct.) Would this approach work for you? I am testing the patch with windows AD , Will update with my observations > > -- > Petr Viktorin > > From f4e8290beb21eeee7aba60f1caf7e69b472e1e8e Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] modify run_command to execute on Windows > > Add global parameter windows_test_dir to specify test directory > for Windows > Windows hosts (WinHost) use this directory by default. > test_dir can now be set individually for each host. > Move run_command from Host class to BaseHost class > > Signed-off-by: Petr Viktorin > --- > pytest_multihost/config.py | 3 +++ > pytest_multihost/host.py | 41 ++++++++++++++++++++++------------------- > 2 files changed, 25 insertions(+), 19 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c2..58a3a5f 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db5..f82ff33 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -25,9 +25,11 @@ class BaseHost(object): > See README for an overview of the core classes. > """ > transport_class = None > + command_prelude = '' > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, password=None, > + test_dir=None): > self.domain = domain > self.role = str(role) > if username is None: > @@ -40,6 +42,10 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if test_dir is None: > + self.test_dir = domain.config.test_dir > + else: > + self.test_dir = test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -78,7 +84,7 @@ class BaseHost(object): > self.host_key = None > self.ssh_port = 22 > > - self.env_sh_path = os.path.join(domain.config.test_dir, 'env.sh') > + self.env_sh_path = os.path.join(self.test_dir, 'env.sh') > > self.log_collectors = [] > > @@ -204,28 +210,18 @@ class BaseHost(object): > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > - > - > -class Host(BaseHost): > - """A Unix host""" > - transport_class = transport.SSHTransport > - > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > # Set working directory > if cwd is None: > - cwd = self.config.test_dir > + cwd = self.test_dir > command.stdin.write('cd %s\n' % shell_quote(cwd)) > > # Set the environment > if set_env: > command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > + > + if self.command_prelude: > + command.stdin.write(self.command_prelude) > > if isinstance(argv, basestring): > # Run a shell command given as a string > @@ -247,11 +243,18 @@ class Host(BaseHost): > return command > > > +class Host(BaseHost): > + """A Unix host""" > + transport_class = transport.SSHTransport > + command_prelude = 'set -e\n' > + > + > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > - > - This is a stub; Windows hosts can't currently be interacted with. > """ > > - pass > + def __init__(self, domain, hostname, role, **kwargs): > + # Set test_dir to the Windows directory, if not given explicitly > + kwargs.setdefault('test_dir', domain.config.windows_test_dir) > + super(WinHost, self).__init__(domain, hostname, role, **kwargs) > -- > 2.5.5 > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From pspacek at redhat.com Mon Apr 18 15:44:31 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Apr 2016 17:44:31 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5714F24F.70203@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> Message-ID: <571500DF.20204@redhat.com> On 18.4.2016 16:42, Martin Basti wrote: > > > On 18.04.2016 15:22, Petr Spacek wrote: >> On 6.4.2016 10:57, Petr Spacek wrote: >>> On 6.4.2016 10:50, Jan Cholasta wrote: >>>> On 4.4.2016 13:51, Petr Spacek wrote: >>>>> On 4.4.2016 13:39, Martin Basti wrote: >>>>>> >>>>>> On 31.03.2016 09:58, Petr Spacek wrote: >>>>>>> On 26.2.2016 15:37, Petr Spacek wrote: >>>>>>>> On 25.2.2016 16:46, Simo Sorce wrote: >>>>>>>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>>>>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>>>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>>>>>>> Variant C >>>>>>>>>>>> --------- >>>>>>>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>>>>>>> the first >>>>>>>>>>>> round ... >>>>>>>>>>>> >>>>>>>>>>>> We would retain >>>>>>>>>>>> [first step - no change from variant A] >>>>>>>>>>>> * create locations >>>>>>>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>>>>>>> manually >>>>>>>>>>>> input (server, weight) tuples >>>>>>>>>>>> >>>>>>>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>>>>>>> from all >>>>>>>>>>>> other locations. >>>>>>>>>>>> >>>>>>>>>>>> Additional storage complexity: 0 >>>>>>>>>>>> >>>>>>>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>>>>>>> only as >>>>>>>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>>>>>>> >>>>>>>>>>>> This might be sufficient for the first run and would allow us to >>>>>>>>>>>> gather some >>>>>>>>>>>> feedback from the field. >>>>>>>>>>>> >>>>>>>>>>>> Now I'm inclined to this variant :-) >>>>>>>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>>>>>>> >>>>>>>>>>> To recap: >>>>>>>>>>> - define a location with the list of servers (perhaps location is a >>>>>>>>>>> property of server objects so you can have only one location per >>>>>>>>>>> server, >>>>>>>>>>> and if you remove the server it is automatically removed from the >>>>>>>>>>> location w/o additional work or referential integrity necessary), if >>>>>>>>>>> weight is not defined (default) then they all have the same weight. >>>>>>>>>> Agreed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> - Allow to specify backup locations in the location object, priorities >>>>>>>>>>> are calculated automatically and all backup locations have same >>>>>>>>>>> weight. >>>>>>>>>> Hmm, weights have to be inherited form the original location in all >>>>>>>>>> cases. Did >>>>>>>>>> you mean that all backup locations have the same *priority*? >>>>>>>>> Yes, sorry. >>>>>>>>> >>>>>>>>>> Anyway, explicit configuration of backup locations is introducing >>>>>>>>>> API and >>>>>>>>>> schema for variant A and that is what I'm questioning above. It is >>>>>>>>>> hard to >>>>>>>>>> make it extensible so we do not have headache in future when somebody >>>>>>>>>> decides >>>>>>>>>> that more flexibility is needed OR that link-based approach is better. >>>>>>>>> I think no matter we do we'll need to allow admins to override backup >>>>>>>>> locations, in future if we can calculate them automatically admins will >>>>>>>>> simply not set any backup location explicitly (or set some special value >>>>>>>>> like "autogenerate" and the system will do it for them. >>>>>>>>> >>>>>>>>> Forcing admins to mentally calculate weights to force the system to >>>>>>>>> autogenerate the configuration they want would be a bad experience, I >>>>>>>>> personally would find it very annoying. >>>>>>>>> >>>>>>>>>> In other words, for doing what you propose above we would have to >>>>>>>>>> design >>>>>>>>>> complete schema and API for variant A anyway to make sure we do not >>>>>>>>>> lock >>>>>>>>>> ourselves, so we are not getting any saving by doing so. >>>>>>>>> A seemed much more complicated to me, as you wanted to define a ful >>>>>>>>> matrix for weights of servers when they are served as backups and all >>>>>>>>> that. >>>>>>>>> >>>>>>>>>>> - Define a *default* location, which is the backup for any other >>>>>>>>>>> location but always with lower priority to any other explicitly >>>>>>>>>>> defined >>>>>>>>>>> backup locations. >>>>>>>>>> I would rather *always* use the default location as backup for all >>>>>>>>>> other >>>>>>>>>> locations. It does not require any API or schema (as it equals to "all >>>>>>>>>> servers" except "servers in this location" which can be easily >>>>>>>>>> calculated >>>>>>>>>> on fly). >>>>>>>>> We can start with this, but it works well only in a stellar topology >>>>>>>>> where you have a central location all other location connect to. >>>>>>>>> As soon as you have a super-stellar topology where you have hub location >>>>>>>>> to which regional locations connect to, then this is wasteful. >>>>>>>>> >>>>>>>>>> This can be later on extended in whatever direction we want without any >>>>>>>>>> upgrade/migration problem. >>>>>>>>>> >>>>>>>>>> More importantly, all the schema and API will be common for all other >>>>>>>>>> variants >>>>>>>>>> anyway so we can start doing so and see how much time is left when >>>>>>>>>> it is >>>>>>>>>> done. >>>>>>>>> I am ok with this for the first step. >>>>>>>>> After all location is mostly about the "normal" case where clients want >>>>>>>>> to reach the local servers, the backup part is only an additional >>>>>>>>> feature we can keep simple for now. It's a degraded mode of operation >>>>>>>>> anyway so it is probably ok to have just one default backup location as >>>>>>>>> a starting point. >>>>>>>> Okay, now we are in agreement. I will think about minimal schema and API >>>>>>>> over >>>>>>>> the weekend. >>>>>>> Well, it took longer than one weekend. >>>>>>> >>>>>>> There was couple of changes in the design document: >>>>>>> * ?Feature Management: CLI proposal >>>>>>> * ?Feature Management: web UI - idea with topology graph replaced original >>>>>>> complicated table >>>>>>> * Feature Management: described necessary configuration outside of IPA DNS >>>>>>> * Version 1 parts which were moved into separate document: >>>>>>> V4/DNS_Location_Mechanism_with_per_client_override >>>>>>> * ?Assumptions: removed misleading reference to DHCP, clarified role of >>>>>>> DNS >>>>>>> views >>>>>>> * Assumptions: removed misleading mention of 'different networks' and >>>>>>> added >>>>>>> summary explaining how Location is defined >>>>>>> * Implementation: high-level outline added >>>>>>> >>>>>>> Current version: >>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>> >>>>>>> Full diff: >>>>>>> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Practical usage is described in section How to test: >>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >>>>>>> >>>>>>> >>>>>>> I will think about LDAP schema after we agree on CLI. >>>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>> >>>>>>>>>>> - Weights for backup location servers are the same as the weight >>>>>>>>>>> defined >>>>>>>>>>> within the backup location itself, so no additional weights are >>>>>>>>>>> defined >>>>>>>>>>> for backups. >>>>>>>>>> Yes, that was somehow implied in the variant A. Sorry for not >>>>>>>>>> mentioning it. >>>>>>>>>> Weight is always relative number for servers inside one location. >>>>>>>>> Ok it looked a lot more complex from your description. >>>>>>>>> >>>>>>>>> Simo. >>>>>> Design review: >>>>>> >>>>>> 1) >>>>>> You missed warning when there is no backup DNS server in location >>>>> Thanks, added. >>>>> >>>>> >>>>>> 2) >>>>>> "Number of IPA DNS servers <= number of configured IPA locations" I dont >>>>>> understand >>>>>> >>>>>> You need at least one DNS server per location, thus DNS servers >= >>>>>> locations >>>>> Good catch, fixed. >>>>> >>>>> >>>>>> 3) >>>>>> Design (Version 1: DNAME per client) Link to design doesn't work for me >>>>> Oh, my wiki-fu was weak. Fixed. >>>>> >>>>> >>>>>> CLI looks good to me. Maybe we should explicitly write in design that >>>>>> priorities of the SRV records will be set statically (What values? 0 - >>>>>> servers >>>>>> in location, 100 - backup?) >>>>> I've added a note about static priorities. Particular values are just an >>>>> implementation detail so I would not clutter feature management section with >>>>> that. >>>> If server can be only in one location, why bother with >>>> location-{add,mod,remove}-member and not use server-mod: >>>> >>>> server-mod --location= [--location-weight=0..65535] >>>> >>>> ? This is the natural way to model one-to-many relationships in the API, >>>> consistent with existing stuff. >>> I originally wanted to have location-add-member command so (external) DNS >>> servers and IPA servers can be assigned to a location using the same command: >>> location-add-member LOCATION_NAME --ipa-server= >>> location-add-member LOCATION_NAME --advertising-server= >>> >>> Should I split this between >>> server-mod --location= [--location-weight=0..65535] >>> and >>> dnsserver-mod --type=external --advertise-location=... >>> >>> I do not like splitting server-to-location assignment management between two >>> commands very much. Current proposal in design page was inspired by >>> group-add-member command which has --users and --groups options which seemed >>> philosophically similar to me. >>> >>> Anyway, I'm open to suggestions how to handle this. >> Honza and me are playing with idea that Server Roles can be re-used for >> Locations, too. >> >> The rough idea is that 'the advertising' server will have a role like 'DNS >> Location XYZ DNS server' and that the member server will have role like 'IPA >> master in location XYZ'. >> >> (Pick your own names, these are just examples.) >> >> Obvious advantage is consistency in the user interface, which is something we >> really need. >> >> The question is how where to put equivalent of --weight option. >> >> This would make location-add-member command unnecessary. >> > Today I found out that I misunderstood how non-IPA SRV records will work with > the DNS locations feature. > > I expected that other SRV record stored in IPA domain will be copied unchanged > to locations, only for IPA services SRV records will be altered with priorities. > > However, DNS locations *will not* handle other SRV than IPA ones, what > effectively means that custom user SRV records will disappear on hosts thats > belong to a location. Yes, thank you for pointing this out explicitly. I've tried to capture all I know about this to the design page: http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_2:_DNAME_per_sub-tree.29 Copy follows so we can discuss it quickly: === Interaction with hand-made records === Side-effect of DNAME-redirecting _udp and _tcp subdomains is that all original names under these subdomains will become occluded/invisible to clients (see [https://tools.ietf.org/html/rfc6672#section-2.4 RFC 6672 section 2.4]). This effectively means that hand-made records in the IPA DNS domain will become invisible. E.g. following record will disappear when DNS locations are configured and enabled on IPA domain ipa.example: _userservice._udp.ipa.example. SRV record: 0 100 123 own-server.somewhere.example This behavior is in fact necessary for seamless upgrade of replicas which do not understand the new template LDAP entries in DNS tree. Old replicas will ignore the template entries and use original sub-tree (and ignore _locations sub-tree). New replicas will understand the entry, generate DNAME records and thus occlude old names and use only new ones (in _locations sub-tree). Note: This would be unnecessary if IPA used standard DNS update protocol against standard DNS server with non-replicated zones because we would not need to play DNAME tricks. In that case we could instead update records on each server separately. With current LDAP schema we cannot do that without adding non-replicated part of LDAP tree to each DNS server. * If we added non-replicated sub-tree to each IPA DNS server we would have another set of problems because hand-made entries would not be replicated among IPA servers. Handling of hand-made records adds some interesting questions: * How to find hand-made records? ** Blacklist on name-level or record-data level? What record fields should we compare? * How to handle collisions with IPA-generated records? ** Ignore hand-made records? ** Add hand-made records? ** Replace IPA generated ones with hand-made ones? * What triggers hand-made record synchronization? ** Should the user or IPA framework call ''ipa dnslocation-fix-records'' after each hand-made change to DNS records? ** How is this synchronization supposed to work with DNS update protocol? Currently we do not have means to trigger an action when a records is changed in LDAP. * How it affects interaction with older IPA DNS servers (see above)? There are several options: {{clarify|reason=What to do with hand-made records?}} * For first version, document that enabling DNS location will hide hand-made records in IPA domain. * Add non-replicated sub-trees for IPA records and somehow solve replication of hand-made records. ** What is the proper granularity? Create 20 backends so we can filter on name-level? * Do 'something' which prevents replication of IPA-generated DNS records among servers while still using one LDAP suffix. ** With this in place we can mark IPA-generated records as non-replicable while still replicating hand-made records as usual. (An object class like idnsRecordDoNotReplicate?) This would mean that we can drop whole _locations sub-tree and each server will hold only its own copy of DNS records. * Find, filter and copy hand-made records from main tree into the _locations sub-trees. This means that every hand-made record needs to be copied and synchronized N-times where N = number of IPA locations. My favorite option for the first version is 'document that enabling DNS location will hide hand-made records in IPA domain.' The feature is disabled by default and needs additional configuration anyway so simply upgrading should not break anything. I'm eager to hear opinions and answers to questions above. Petr^2 Spacek > Example: > domain: ipa.test > server: server.ipa.test > custom SRV record in IPA domain: _userservice._udp SRV record: 0 100 123 > server.ipa.test. > > The record above will not be accessible from clients that connect to server > with enabled locations. I think that users may have own services on IPA server > with custom SRV records, and I don't consider this behavior as user-friendly > and blocker for deployment of this feature. > > NACK to design from me. We should fix this. -- Petr^2 Spacek From mrniranjan at fedoraproject.org Mon Apr 18 16:27:12 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Mon, 18 Apr 2016 21:57:12 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5714F69B.2090602@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> Message-ID: <20160418162712.GA8902@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/18/2016 12:39 PM, Niranjan wrote: > > Niranjan wrote: > >> Niranjan wrote: > >>> Petr Viktorin wrote: > >>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>> Greetings, > >>>>> > >>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>> installed. > >>>> > >>>> Wow. I'm surprised the only problem on Windows is the "set -e". > >>>> > >>>> Regarding the patch: > >>>> > >>>> - Why is get_winhost_class needed? I don't see it called anywhere. > >>>> - Similarly, why is host_type needed? Your patch only sets it. > >>>> > >>>> If run_command of WinHost and Unix hosts are this similar, I would put > >>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >>>> attribute named e.g. "command_prelude", use it in run_command, and move > >>>> run_command from Host to BaseHost. > >>>> Would that work, or am I missing something? > >>> How do we detect the host is windows/unix then , we still need host_type > >>> to know what the type of host is (unix/windows)? > >>>> > >>>> > >>>> -- > >>>> Petr Viktorin > >> Please review the attached patch. > > Sorry for the delay. > > The information about whether the host is Unix or Windows is available: > the class is either Host or WinHost, so I don't think an extra host_type > is necessary. > I'd be open to adding host_type as *configuration* (and corresponding > attribute) if it also selected the actual Host class. Currently to use > WinHost you need to write custom code. > > I modified the patch so BaseHost takes test_dir as an argument, and sets > it as self.test_dir, so that users don't need to choose between > self.config.windows_test_dir/self.config.test_dir themselves. > (Unfortunately I don't have Windows to test on; I hope the change is > correct.) Would this approach work for you? > > -- > Petr Viktorin > > From f4e8290beb21eeee7aba60f1caf7e69b472e1e8e Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] modify run_command to execute on Windows > > Add global parameter windows_test_dir to specify test directory > for Windows > Windows hosts (WinHost) use this directory by default. > test_dir can now be set individually for each host. > Move run_command from Host class to BaseHost class > > Signed-off-by: Petr Viktorin > --- > pytest_multihost/config.py | 3 +++ > pytest_multihost/host.py | 41 ++++++++++++++++++++++------------------- > 2 files changed, 25 insertions(+), 19 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c2..58a3a5f 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db5..f82ff33 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -25,9 +25,11 @@ class BaseHost(object): > See README for an overview of the core classes. > """ > transport_class = None > + command_prelude = '' > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, password=None, > + test_dir=None): > self.domain = domain > self.role = str(role) > if username is None: > @@ -40,6 +42,10 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if test_dir is None: > + self.test_dir = domain.config.test_dir > + else: > + self.test_dir = test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -78,7 +84,7 @@ class BaseHost(object): > self.host_key = None > self.ssh_port = 22 > > - self.env_sh_path = os.path.join(domain.config.test_dir, 'env.sh') > + self.env_sh_path = os.path.join(self.test_dir, 'env.sh') > > self.log_collectors = [] > > @@ -204,28 +210,18 @@ class BaseHost(object): > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > - > - > -class Host(BaseHost): > - """A Unix host""" > - transport_class = transport.SSHTransport > - > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > # Set working directory > if cwd is None: > - cwd = self.config.test_dir > + cwd = self.test_dir > command.stdin.write('cd %s\n' % shell_quote(cwd)) > > # Set the environment > if set_env: > command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > + > + if self.command_prelude: > + command.stdin.write(self.command_prelude) > > if isinstance(argv, basestring): > # Run a shell command given as a string > @@ -247,11 +243,18 @@ class Host(BaseHost): > return command > > > +class Host(BaseHost): > + """A Unix host""" > + transport_class = transport.SSHTransport > + command_prelude = 'set -e\n' > + > + > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > - > - This is a stub; Windows hosts can't currently be interacted with. > """ > > - pass > + def __init__(self, domain, hostname, role, **kwargs): > + # Set test_dir to the Windows directory, if not given explicitly > + kwargs.setdefault('test_dir', domain.config.windows_test_dir) > + super(WinHost, self).__init__(domain, hostname, role, **kwargs) > -- > 2.5.5 > I tried with the following multihost config: mhc2.yaml: windows_test_dir: '/home/Administrator' domains: - name: winpki1.testpki.test type: sssd hosts: - name: WIN-Q8VKBEJ7H39 ip: 192.168.122.62 role: master username: 'Administrator' password: 'helloworld' - name: client1 ip: 192.168.122.61 external_hostname: client1.example.test role: client username: 'root' password: 'helloworld' test1.py: from pytest_multihost import make_multihost_fixture from sssd.testlib.common.qe_class import QeConfig import pytest @pytest.fixture(scope='session') def session_multihost(request): mh = make_multihost_fixture( request, descriptions= [ { 'type': 'sssd', 'hosts': { 'master':1, 'client':1 } }, ], config_class=QeConfig) mh.domain = mh.config.domains[0] [mh.master] = mh.domain.hosts_by_role('master') [mh.client] = mh.domain.hosts_by_role('client') return mh @pytest.fixture() def multihost(session_multihost, request): return session_multihost def test_1(multihost): print("i am in test1") print(dir(multihost.master)) print("test_dir =", multihost.master.test_dir) multihost.master.command_prelude = '' output = multihost.master.run_command('date', set_env=False,raiseonerr=False) print(output.stdout_text) def test_2(multihost): print("i am in test2") print(dir(multihost.master)) output = multihost.client.run_command('date',raiseonerr=False) The output is as follows: '__weakref__', 'add_log_collector', 'collect_log', 'command_prelude', 'config', 'dnf_install', 'dnf_uninstall', 'domain', 'env_sh_path', 'external_hostname', 'from_dict', 'get_distro', 'get_file_contents', 'gethostname', 'host_key', 'hostname', 'ip', 'log', 'log_collectors', 'logger_name', 'netbios', 'put_file_contents', 'remove_log_collector', 'reset_connection', 'role', 'run_command', 'shortname', 'ssh_key_filename', 'ssh_password', 'ssh_port', 'ssh_username', 'test_dir', 'to_dict', 'transport', 'transport_class', 'yum_install', 'yum_uninstall'] ('test_dir =', '/root/multihost_tests') 2016-04-18 21:50:10,406 - sssd.testlib.common.qe_class.QeHost.WIN-Q8VKBEJ7H39.ParamikoTransport - DEBUG - Authenticating with password using user Administrator 2016-04-18 21:50:13,779 - sssd.testlib.common.qe_class.QeHost.WIN-Q8VKBEJ7H39.ParamikoTransport - INFO - RUN date 2016-04-18 21:50:13,779 - sssd.testlib.common.qe_class.QeHost.WIN-Q8VKBEJ7H39.cmd1 - DEBUG - RUN date 2016-04-18 21:50:14,917 - sssd.testlib.common.qe_class.QeHost.WIN-Q8VKBEJ7H39.cmd1 - DEBUG - -bash: line 1: cd: /root/multihost_tests: No such file or directory 2016-04-18 21:50:15,507 - sssd.testlib.common.qe_class.QeHost.WIN-Q8VKBEJ7H39.cmd1 - DEBUG - Mon Apr 18 21:46:33 IST 2016 2016-04-18 21:50:15,541 - sssd.testlib.common.qe_class.QeHost.WIN-Q8VKBEJ7H39.cmd1 - DEBUG - TERM environment variable not set. 2016-04-18 21:50:15,543 - sssd.testlib.common.qe_class.QeHost.WIN-Q8VKBEJ7H39.cmd1 - DEBUG - Exit code: 0 Mon Apr 18 21:46:33 IST 2016 PASSED test1.py::test_2 i am in test2 ['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_transport', 'add_log_collector', 'collect_log', 'command_prelude', 'config', 'dnf_install', 'dnf_uninstall', 'domain', 'env_sh_path', 'external_hostname', 'from_dict', 'get_distro', 'get_file_contents', 'gethostname', 'host_key', 'hostname', 'ip', 'log', 'log_collectors', 'logger_name', 'netbios', 'put_file_contents', 'remove_log_collector', 'reset_connection', 'role', 'run_command', 'shortname', 'ssh_key_filename', 'ssh_password', 'ssh_port', 'ssh_username', 'test_dir', 'to_dict', 'transport', 'transport_class', 'yum_install', 'yum_uninstall'] 2016-04-18 21:50:15,611 - sssd.testlib.common.qe_class.QeHost.client1.ParamikoTransport - DEBUG - Authenticating with password using user root 2016-04-18 21:50:15,776 - sssd.testlib.common.qe_class.QeHost.client1.ParamikoTransport - INFO - RUN date 2016-04-18 21:50:15,776 - sssd.testlib.common.qe_class.QeHost.client1.cmd1 - DEBUG - RUN date 2016-04-18 21:50:15,796 - sssd.testlib.common.qe_class.QeHost.client1.cmd1 - DEBUG - -bash: line 1: cd: /root/multihost_tests: No such file or directory 2016-04-18 21:50:15,796 - sssd.testlib.common.qe_class.QeHost.client1.cmd1 - DEBUG - -bash: line 2: /root/multihost_tests/env.sh: No such file or directory 2016-04-18 21:50:15,797 - sssd.testlib.common.qe_class.QeHost.client1.cmd1 - DEBUG - Mon Apr 18 21:50:15 IST 2016 2016-04-18 21:50:15,798 - sssd.testlib.common.qe_class.QeHost.client1.cmd1 - DEBUG - Exit code: 0 test_1 is where i execute "date" command on windows. I see that test_dir still points to /root/multihost_tests, i am wondering should it point to /home/Administrator. Do we need to override WinHost ?, We override Host class using qe_class.py . i am attaching the qe_class.py Could you have a look at the above. Regards Niranjan -------------- next part -------------- from pytest_multihost import make_multihost_fixture import pytest_multihost.config import pytest_multihost.host import logging import pytest class QeConfig(pytest_multihost.config.Config): """ QeConfig subclass of multihost plugin to extend functionality """ extra_init_args = { 'directory_manager', 'directory_password', 'rootdn', 'rootdn_pwd',} def __init__(self, **kwargs): self.log = self.get_logger('%s.%s' % (__name__, type(self).__name__)) pytest_multihost.config.Config.__init__(self, **kwargs) def get_domain_class(self): """ return custom domain class. This is needed to fully extend the config for custom multihost plugin extensions. :param None: :return None: """ return QeDomain def get_logger(self, name): """ Override get_logger to set logging level :param str name: :return obj log: """ log = logging.getLogger(name) log.propagate = False if not log.handlers: # set log Level log.setLevel(logging.DEBUG) handler = logging.StreamHandler() handler.setLevel(logging.DEBUG) # set formatter formatter = logging.Formatter( '%(asctime)s - %(name)s - %(levelname)s - %(message)s') handler.setFormatter(formatter) log.addHandler(handler) return log class QeDomain(pytest_multihost.config.Domain): """ QeDomain subclass of multihost plugin domain class. """ def __init__(self, config, name, domain_type): """ Subclass of pytest_multihost.config.Domain :param obj config: config config :param str name: Name :param str domain_type: :return None: """ self.type = str(domain_type) self.config = config self.name = str(name) self.hosts = [] def get_host_class(self, host_dict): """ return custom host class. This is needed to fully extend the config for custom multihost plugin extensions. """ return QeHost class QeHost(pytest_multihost.host.Host): """ QeHost subclass of multihost plugin host class. This extends functionality of the host class for SSSD QE purposes. Here we add support functions that will be very widely used across tests and must be run on any or all hosts in the environment. """ @classmethod def get_distro(self): """ Return contents of /etc/redhatrelease """ cmd = self.run_command( ['cat', '/etc/redhat-release'], raiseonerr=False) if cmd.returncode != 0: distro = 'unknown Distro' else: distro = cmd.stdout_text.strip() return distro @classmethod def gethostname(self): """ Return system hostname """ if self.host_type != 'windows': cmd = self.run_command(['hostname'], raiseonerr=False) else: cmd = self.run_command(['hostname', '-A'], set_env=False, raiseonerr=False) return cmd.stdout_text.strip() @classmethod def yum_install(self, package): """ Install packages through yum """ cmd = self.run_command(['yum', '-y', 'install', package], raiseonerr=False) return cmd @classmethod def dnf_install(self, package): """ Install packges through dnf """ cmd = self.run_command(['dnf', '-y', 'install', package], raiseonerr=False) return cmd @classmethod def yum_uninstall(self, package): """ Uninstall packages through yum """ cmd = self.run_command(['yum', '-y', 'remove', package], raiseonerr=False) return cmd @classmethod def dnf_uninstall(self, package): """ Uninstall packages through dnf """ cmd = self.run_command(['dnf', '-y', 'remove', package], raiseonerr=False) return cmd @pytest.yield_fixture(scope="session", autouse=True) def session_multihost(request): """ Mulithost plugin fixture for session scope """ mh = make_multihost_fixture(request, descriptions=[ { 'type': 'sssd', 'hosts': { 'master': pytest.num_masters, 'replica': pytest.num_replicas, 'client': pytest.num_clients, 'other': pytest.num_others, } }, ], config_class=QeConfig) mh.domain = mh.config.domains[0] mh.master = mh.domain.hosts_by_role('master') mh.replicas = mh.domain.hosts_by_role('replica') mh.clients = mh.domain.hosts_by_role('client') mh.others = mh.domain.hosts_by_role('other') yield mh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From amarecek at redhat.com Mon Apr 18 16:44:45 2016 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Mon, 18 Apr 2016 12:44:45 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0009] Refactor test_automember_plugin In-Reply-To: <819699319.53565735.1460387186194.JavaMail.zimbra@redhat.com> References: <819699319.53565735.1460387186194.JavaMail.zimbra@redhat.com> Message-ID: <157401724.2956692.1460997885639.JavaMail.zimbra@redhat.com> Hello, it looks good, thanks! ACK. Target: master ----- Original Message ----- > From: "Filip Skola" > To: freeipa-devel at redhat.com > Cc: "Milan Kub?k" , "Ale? Mare?ek" > Sent: Monday, April 11, 2016 5:06:26 PM > Subject: [PATCH 0009] Refactor test_automember_plugin > > Hi, > > sending the refactored automember plugin test for review. > > Filip > From pspacek at redhat.com Mon Apr 18 17:21:48 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Apr 2016 19:21:48 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <571500DF.20204@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> <571500DF.20204@redhat.com> Message-ID: <571517AC.5010201@redhat.com> On 18.4.2016 17:44, Petr Spacek wrote: > On 18.4.2016 16:42, Martin Basti wrote: >> >> >> On 18.04.2016 15:22, Petr Spacek wrote: >>> On 6.4.2016 10:57, Petr Spacek wrote: >>>> On 6.4.2016 10:50, Jan Cholasta wrote: >>>>> On 4.4.2016 13:51, Petr Spacek wrote: >>>>>> On 4.4.2016 13:39, Martin Basti wrote: >>>>>>> >>>>>>> On 31.03.2016 09:58, Petr Spacek wrote: >>>>>>>> On 26.2.2016 15:37, Petr Spacek wrote: >>>>>>>>> On 25.2.2016 16:46, Simo Sorce wrote: >>>>>>>>>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >>>>>>>>>>> On 25.2.2016 15:28, Simo Sorce wrote: >>>>>>>>>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>>>>>>>>>>> Variant C >>>>>>>>>>>>> --------- >>>>>>>>>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>>>>>>>>>>> the first >>>>>>>>>>>>> round ... >>>>>>>>>>>>> >>>>>>>>>>>>> We would retain >>>>>>>>>>>>> [first step - no change from variant A] >>>>>>>>>>>>> * create locations >>>>>>>>>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>>>>>>>>>>> ++ specify weights for the 'main' servers in given location, i.e. >>>>>>>>>>>>> manually >>>>>>>>>>>>> input (server, weight) tuples >>>>>>>>>>>>> >>>>>>>>>>>>> Then, backups would be auto-generated set of all remaining servers >>>>>>>>>>>>> from all >>>>>>>>>>>>> other locations. >>>>>>>>>>>>> >>>>>>>>>>>>> Additional storage complexity: 0 >>>>>>>>>>>>> >>>>>>>>>>>>> This covers the scenario "always prefer local servers and use remote >>>>>>>>>>>>> only as >>>>>>>>>>>>> fallback" easily. It does not cover any other scenario. >>>>>>>>>>>>> >>>>>>>>>>>>> This might be sufficient for the first run and would allow us to >>>>>>>>>>>>> gather some >>>>>>>>>>>>> feedback from the field. >>>>>>>>>>>>> >>>>>>>>>>>>> Now I'm inclined to this variant :-) >>>>>>>>>>>> To be honest, this is all I always had in mind, for the first step. >>>>>>>>>>>> >>>>>>>>>>>> To recap: >>>>>>>>>>>> - define a location with the list of servers (perhaps location is a >>>>>>>>>>>> property of server objects so you can have only one location per >>>>>>>>>>>> server, >>>>>>>>>>>> and if you remove the server it is automatically removed from the >>>>>>>>>>>> location w/o additional work or referential integrity necessary), if >>>>>>>>>>>> weight is not defined (default) then they all have the same weight. >>>>>>>>>>> Agreed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> - Allow to specify backup locations in the location object, priorities >>>>>>>>>>>> are calculated automatically and all backup locations have same >>>>>>>>>>>> weight. >>>>>>>>>>> Hmm, weights have to be inherited form the original location in all >>>>>>>>>>> cases. Did >>>>>>>>>>> you mean that all backup locations have the same *priority*? >>>>>>>>>> Yes, sorry. >>>>>>>>>> >>>>>>>>>>> Anyway, explicit configuration of backup locations is introducing >>>>>>>>>>> API and >>>>>>>>>>> schema for variant A and that is what I'm questioning above. It is >>>>>>>>>>> hard to >>>>>>>>>>> make it extensible so we do not have headache in future when somebody >>>>>>>>>>> decides >>>>>>>>>>> that more flexibility is needed OR that link-based approach is better. >>>>>>>>>> I think no matter we do we'll need to allow admins to override backup >>>>>>>>>> locations, in future if we can calculate them automatically admins will >>>>>>>>>> simply not set any backup location explicitly (or set some special value >>>>>>>>>> like "autogenerate" and the system will do it for them. >>>>>>>>>> >>>>>>>>>> Forcing admins to mentally calculate weights to force the system to >>>>>>>>>> autogenerate the configuration they want would be a bad experience, I >>>>>>>>>> personally would find it very annoying. >>>>>>>>>> >>>>>>>>>>> In other words, for doing what you propose above we would have to >>>>>>>>>>> design >>>>>>>>>>> complete schema and API for variant A anyway to make sure we do not >>>>>>>>>>> lock >>>>>>>>>>> ourselves, so we are not getting any saving by doing so. >>>>>>>>>> A seemed much more complicated to me, as you wanted to define a ful >>>>>>>>>> matrix for weights of servers when they are served as backups and all >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>>>> - Define a *default* location, which is the backup for any other >>>>>>>>>>>> location but always with lower priority to any other explicitly >>>>>>>>>>>> defined >>>>>>>>>>>> backup locations. >>>>>>>>>>> I would rather *always* use the default location as backup for all >>>>>>>>>>> other >>>>>>>>>>> locations. It does not require any API or schema (as it equals to "all >>>>>>>>>>> servers" except "servers in this location" which can be easily >>>>>>>>>>> calculated >>>>>>>>>>> on fly). >>>>>>>>>> We can start with this, but it works well only in a stellar topology >>>>>>>>>> where you have a central location all other location connect to. >>>>>>>>>> As soon as you have a super-stellar topology where you have hub location >>>>>>>>>> to which regional locations connect to, then this is wasteful. >>>>>>>>>> >>>>>>>>>>> This can be later on extended in whatever direction we want without any >>>>>>>>>>> upgrade/migration problem. >>>>>>>>>>> >>>>>>>>>>> More importantly, all the schema and API will be common for all other >>>>>>>>>>> variants >>>>>>>>>>> anyway so we can start doing so and see how much time is left when >>>>>>>>>>> it is >>>>>>>>>>> done. >>>>>>>>>> I am ok with this for the first step. >>>>>>>>>> After all location is mostly about the "normal" case where clients want >>>>>>>>>> to reach the local servers, the backup part is only an additional >>>>>>>>>> feature we can keep simple for now. It's a degraded mode of operation >>>>>>>>>> anyway so it is probably ok to have just one default backup location as >>>>>>>>>> a starting point. >>>>>>>>> Okay, now we are in agreement. I will think about minimal schema and API >>>>>>>>> over >>>>>>>>> the weekend. >>>>>>>> Well, it took longer than one weekend. >>>>>>>> >>>>>>>> There was couple of changes in the design document: >>>>>>>> * ?Feature Management: CLI proposal >>>>>>>> * ?Feature Management: web UI - idea with topology graph replaced original >>>>>>>> complicated table >>>>>>>> * Feature Management: described necessary configuration outside of IPA DNS >>>>>>>> * Version 1 parts which were moved into separate document: >>>>>>>> V4/DNS_Location_Mechanism_with_per_client_override >>>>>>>> * ?Assumptions: removed misleading reference to DHCP, clarified role of >>>>>>>> DNS >>>>>>>> views >>>>>>>> * Assumptions: removed misleading mention of 'different networks' and >>>>>>>> added >>>>>>>> summary explaining how Location is defined >>>>>>>> * Implementation: high-level outline added >>>>>>>> >>>>>>>> Current version: >>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>>> >>>>>>>> Full diff: >>>>>>>> http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Practical usage is described in section How to test: >>>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test >>>>>>>> >>>>>>>> >>>>>>>> I will think about LDAP schema after we agree on CLI. >>>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>> >>>>>>>>> Petr^2 Spacek >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> - Weights for backup location servers are the same as the weight >>>>>>>>>>>> defined >>>>>>>>>>>> within the backup location itself, so no additional weights are >>>>>>>>>>>> defined >>>>>>>>>>>> for backups. >>>>>>>>>>> Yes, that was somehow implied in the variant A. Sorry for not >>>>>>>>>>> mentioning it. >>>>>>>>>>> Weight is always relative number for servers inside one location. >>>>>>>>>> Ok it looked a lot more complex from your description. >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>> Design review: >>>>>>> >>>>>>> 1) >>>>>>> You missed warning when there is no backup DNS server in location >>>>>> Thanks, added. >>>>>> >>>>>> >>>>>>> 2) >>>>>>> "Number of IPA DNS servers <= number of configured IPA locations" I dont >>>>>>> understand >>>>>>> >>>>>>> You need at least one DNS server per location, thus DNS servers >= >>>>>>> locations >>>>>> Good catch, fixed. >>>>>> >>>>>> >>>>>>> 3) >>>>>>> Design (Version 1: DNAME per client) Link to design doesn't work for me >>>>>> Oh, my wiki-fu was weak. Fixed. >>>>>> >>>>>> >>>>>>> CLI looks good to me. Maybe we should explicitly write in design that >>>>>>> priorities of the SRV records will be set statically (What values? 0 - >>>>>>> servers >>>>>>> in location, 100 - backup?) >>>>>> I've added a note about static priorities. Particular values are just an >>>>>> implementation detail so I would not clutter feature management section with >>>>>> that. >>>>> If server can be only in one location, why bother with >>>>> location-{add,mod,remove}-member and not use server-mod: >>>>> >>>>> server-mod --location= [--location-weight=0..65535] >>>>> >>>>> ? This is the natural way to model one-to-many relationships in the API, >>>>> consistent with existing stuff. >>>> I originally wanted to have location-add-member command so (external) DNS >>>> servers and IPA servers can be assigned to a location using the same command: >>>> location-add-member LOCATION_NAME --ipa-server= >>>> location-add-member LOCATION_NAME --advertising-server= >>>> >>>> Should I split this between >>>> server-mod --location= [--location-weight=0..65535] >>>> and >>>> dnsserver-mod --type=external --advertise-location=... >>>> >>>> I do not like splitting server-to-location assignment management between two >>>> commands very much. Current proposal in design page was inspired by >>>> group-add-member command which has --users and --groups options which seemed >>>> philosophically similar to me. >>>> >>>> Anyway, I'm open to suggestions how to handle this. >>> Honza and me are playing with idea that Server Roles can be re-used for >>> Locations, too. >>> >>> The rough idea is that 'the advertising' server will have a role like 'DNS >>> Location XYZ DNS server' and that the member server will have role like 'IPA >>> master in location XYZ'. >>> >>> (Pick your own names, these are just examples.) >>> >>> Obvious advantage is consistency in the user interface, which is something we >>> really need. >>> >>> The question is how where to put equivalent of --weight option. >>> >>> This would make location-add-member command unnecessary. >>> >> Today I found out that I misunderstood how non-IPA SRV records will work with >> the DNS locations feature. >> >> I expected that other SRV record stored in IPA domain will be copied unchanged >> to locations, only for IPA services SRV records will be altered with priorities. >> >> However, DNS locations *will not* handle other SRV than IPA ones, what >> effectively means that custom user SRV records will disappear on hosts thats >> belong to a location. > > Yes, thank you for pointing this out explicitly. > > I've tried to capture all I know about this to the design page: > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_2:_DNAME_per_sub-tree.29 > > Copy follows so we can discuss it quickly: > > === Interaction with hand-made records === > Side-effect of DNAME-redirecting _udp and _tcp subdomains is > that all original names under these subdomains will become occluded/invisible > to clients (see [https://tools.ietf.org/html/rfc6672#section-2.4 RFC 6672 > section 2.4]). > > This effectively means that hand-made records in the IPA DNS domain will > become invisible. E.g. following record will disappear when DNS locations are > configured and enabled on IPA domain ipa.example: > > _userservice._udp.ipa.example. SRV record: 0 100 123 > own-server.somewhere.example > > This behavior is in fact necessary for seamless upgrade of replicas which do > not understand the new template LDAP entries in DNS tree. Old replicas will > ignore the template entries and use original sub-tree (and ignore > _locations sub-tree). New replicas will understand the entry, > generate DNAME records and thus occlude old names and use only new ones (in > _locations sub-tree). > > Note: This would be unnecessary if IPA used standard DNS update protocol > against standard DNS server with non-replicated zones because we would not > need to play DNAME tricks. In that case we could instead update records on > each server separately. With current LDAP schema we cannot do that without > adding non-replicated part of LDAP tree to each DNS server. > * If we added non-replicated sub-tree to each IPA DNS server we would have > another set of problems because hand-made entries would not be replicated > among IPA servers. > > Handling of hand-made records adds some interesting questions: > * How to find hand-made records? > ** Blacklist on name-level or record-data level? What record fields should we > compare? > * How to handle collisions with IPA-generated records? > ** Ignore hand-made records? > ** Add hand-made records? > ** Replace IPA generated ones with hand-made ones? > * What triggers hand-made record synchronization? > ** Should the user or IPA framework call ''ipa dnslocation-fix-records'' after > each hand-made change to DNS records? > ** How is this synchronization supposed to work with DNS update protocol? > Currently we do not have means to trigger an action when a records is changed > in LDAP. > * How it affects interaction with older IPA DNS servers (see above)? > > There are several options: > {{clarify|reason=What to do with hand-made records?}} > * For first version, document that enabling DNS location will hide hand-made > records in IPA domain. > * Add non-replicated sub-trees for IPA records and somehow solve replication > of hand-made records. > ** What is the proper granularity? Create 20 backends so we can filter on > name-level? > * Do 'something' which prevents replication of IPA-generated DNS records among > servers while still using one LDAP suffix. > ** With this in place we can mark IPA-generated records as non-replicable > while still replicating hand-made records as usual. (An object class like > idnsRecordDoNotReplicate?) This would mean that we can drop whole > _locations sub-tree and each server will hold only its own copy of > DNS records. > * Find, filter and copy hand-made records from main tree into the > _locations sub-trees. This means that every hand-made record needs to > be copied and synchronized N-times where N = number of IPA locations. > > > My favorite option for the first version is 'document that enabling DNS > location will hide hand-made records in IPA domain.' > > The feature is disabled by default and needs additional configuration anyway > so simply upgrading should not break anything. > > > I'm eager to hear opinions and answers to questions above. Yet another option: Replace DNAME with CNAMEs on *each* IPA-managed named. This would mean some changes in https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator In particular idnsTemplateObject would have to somehow replace all other attributes on given entry (as CNAME cannot coexist with anything else) + we would have to somehow solve the problem with servers where template is present but substitution is not configured. I will dream about that over night. Petr^2 Spacek > > Petr^2 Spacek > > >> Example: >> domain: ipa.test >> server: server.ipa.test >> custom SRV record in IPA domain: _userservice._udp SRV record: 0 100 123 >> server.ipa.test. >> >> The record above will not be accessible from clients that connect to server >> with enabled locations. I think that users may have own services on IPA server >> with custom SRV records, and I don't consider this behavior as user-friendly >> and blocker for deployment of this feature. >> >> NACK to design from me. We should fix this. > > > -- Petr^2 Spacek From simo at redhat.com Mon Apr 18 19:33:24 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 18 Apr 2016 15:33:24 -0400 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <571500DF.20204@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> <571500DF.20204@redhat.com> Message-ID: <1461008004.30315.15.camel@redhat.com> On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote: > * Find, filter and copy hand-made records from main tree into the > _locations sub-trees. This means that every hand-made record > needs to be copied and synchronized N-times where N = number of IPA > locations. This ^^ seem the one that provides the best semantics for admins and the least unexpected results. > My favorite option for the first version is 'document that enabling > DNS location will hide hand-made records in IPA domain.' I do not think this is acceptable, sorry. > The feature is disabled by default and needs additional configuration > anyway so simply upgrading should not break anything. It is also useless this way. > I'm eager to hear opinions and answers to questions above. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Apr 18 19:42:28 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 18 Apr 2016 15:42:28 -0400 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <570DDE0E.5070006@redhat.com> References: <5707C9F2.8060903@redhat.com> <570DDE0E.5070006@redhat.com> Message-ID: <1461008548.30315.23.camel@redhat.com> On Wed, 2016-04-13 at 07:50 +0200, David Kupka wrote: > On 08/04/16 17:10, Martin Babinsky wrote: > > Hi list, > > > > I have put together a draft [1] outlining the effort to reimplement the > > handling of Kerberos principals in both backend and frontend layers of > > FreeIPA so that we may have multiple aliases per user, host or service > > and thus implement stuff like > > https://fedorahosted.org/freeipa/ticket/3961 and > > https://fedorahosted.org/freeipa/ticket/5413 . > > > > Since much of the plumbing was already implemented,[2] the document > > mainly describes what the patches do. Some parts required by other use > > cases may be missing so please point these out. > > > > I would also be happy if you could correct all factual inacurracies, I > > did research on this issue a long time ago and my knowledge turned a bit > > rusty. > > > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > > [2] > > https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > > > > Hi, > after reading the designs following thoughts comes to my mind. > > 1) Just to be sure that I understand the new ticket obtaining process > correctly I'd like to summarize. > We need to always search all krbPrincipalName values, krbCanonicalName > and ipaKrbPrincipalAlias (for backward compatibility). > For TGT request case sensitivity of the search and principal in returned > ticket depends on canonicalization. When canonicalization is requested > the search is case-insensitive and krbCanonicalName is used otherwise > case-sensitive search is performed and principal from request is used. Yes. > When requesting TGS search is always case-sensitive and principal from > request is used. No, this sounds wrong to me, I think we want a case-insensitve search for TGS requests. > In pseudo-code: > > get_tgt(principal, secret, canonicalization) > if canonicalization > if principal case-insensitive-in {krbPrincipalName + > ipaKrbPrincipalAlias + krbCanonicalName} > # verify secret, perform various other checks... > return TGT(krbCanonicalName) > else > if principal case-sensitive-in {krbPrincipalName + > ipaKrbPrincipalAlias + krbCanonicalName} > # verify secret, perform various other checks... > return TGT(principal) > > get_tgs(service_principal, TGT) > if service_principal case-sensitive-in {krbPrincipalName + > ipaKrbPrincipalAlias + krbCanonicalName} > # verify TGT, perform various other checks... > return TGS(service_principal) > > Do I understand it right? I do not think the TGS part is right. A case insensitive search in TGS would allow to match upper case service or host names which are sometime mistakenly used, especially in Windows born software, given that the AD KDC is case insensitive. > 2) I would like to add following constrains for > krb{Canonical,Principal}Name attributes: > > when user/host/service is created krbCanonicalName is set to the same > value as krbPrincipalName > krbCanonicalName cannot be modified > krbPrincipalName with the same value as krbCanonicalName cannot be > removed/modified > krbPrincipalName must be case-insensitively unique in whole DB > krbPrincipalName attributes can be added and/or removed +1 > This will allow us to keep the first krbPrincipalName as RDN for > services/hosts and give the flexibility of adding/removing aliases. > > 'Change of username' use case is also solvable with this approach. When > username is changed we add krbPrincipalName with the new username. That > will allow user to login with either old or new name. -1 for users a rename means we change the principal and the canonical name and we do not retain any old principal name. > 3) ad CLI: > {user,host,service}-add - Can canonicalname be specified? Or will it > take principal argument/option value? > Can we add {user,host,service}-{add,remove}-principal set of commands > for principal manipulation? I really don't want to use > --{add,set,del}-attr unless necessary. > Will {user,host,service}-{show,find} display krbCanonicalName by default > or only with --all option? > > 4) ad Upgrade: > I think it would be worth to check and document what happens during > upgrade of multiple replicas. There may be confusing behavior when > obtaining tickets. KDC behavior will differ among servers and since > autodiscovery is in use we don't know if we are talking to the old or > new server. I'm not sure what exactly will happen but I suspect it won't > be nice. Yes, this is a problematic point, I am wondering if we should have a way to tell if all KDCs are at a specific level before allowing to turn on this behavior, but then we need to make it conditional and this all starts to sound a lot like a new domain level. OTOH only alias resolution fails on older KDCs, so that may be ok in some cases. Are there any strong opinions? Should we make this change optional and activate it only when enough features come up that demand a new domain level ? We can always generate the canonicalName now to be ready, but prevent adding aliases until a new domain level is created ? Any other idea ? Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Apr 18 19:44:08 2016 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 18 Apr 2016 15:44:08 -0400 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <20160414063300.GN18277@dhcp-40-8.bne.redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> <1460467890.8657.25.camel@redhat.com> <20160413011550.GI18277@dhcp-40-8.bne.redhat.com> <20160414063300.GN18277@dhcp-40-8.bne.redhat.com> Message-ID: <1461008648.30315.24.camel@redhat.com> On Thu, 2016-04-14 at 16:33 +1000, Fraser Tweedale wrote: > On Wed, Apr 13, 2016 at 11:15:50AM +1000, Fraser Tweedale wrote: > > On Tue, Apr 12, 2016 at 09:31:30AM -0400, Simo Sorce wrote: > > > On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote: > > > > On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: > > > > > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: > > > > > > - name = gssapi.Name('host@%s' % (self.client,), > > > > > > > > > > > > - gssapi.NameType.hostbased_service) > > > > > > > > > > If you remove this then on a serve that has nfs keys in the keytab you > > > > > may end up acquiring the wrong credentials. > > > > > You need to pass down what credentials you want to use to initialize the > > > > > cred store, we canot rely on ordering in the system keytab case. > > > > > > > > > > Simo. > > > > > > > > > Thanks Simo; updated patch attached. > > > > > > Except the ACI the rest looks good to me. > > > For ACI please add a separate patch that follows the naming scheme for > > > subCA keys. > > > > > The ACI here targets the Custodia server public keys, so the client > > can search and read them. It should just read: > > > > add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > (targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal") > > (version 3.0; acl "Anyone can search Custodia public keys"; > > allow(read, search, compare) userdn = "ldap:///all";) > > > > I don't mind putting the ACI in a separate patch, but it is > > necessary to restrict read access on the public keys to only the > > dogtag-ipa-custodia service principals. > > > Updated patches attached. ACI was split into new patch and > simplified (removed ($dn) macro). Ack on the custodia patch. However do we really need to allow *anyone* to look up these keys ? I know they are "public" keys, but still ... I think I would prefer a stricter ACI. Simo. From jcholast at redhat.com Tue Apr 19 05:48:27 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Apr 2016 07:48:27 +0200 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <570F3F28.3020801@redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> <5706366C.4020109@redhat.com> <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> <57066C16.2000508@redhat.com> <570F3F28.3020801@redhat.com> Message-ID: <5715C6AB.50909@redhat.com> On 14.4.2016 08:56, Jan Cholasta wrote: > On 7.4.2016 16:17, Petr Spacek wrote: >> On 7.4.2016 15:20, Fraser Tweedale wrote: >>> On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: >>>> On 7.4.2016 12:13, Christian Heimes wrote: >>>>> On 2016-04-07 11:09, Petr Spacek wrote: >>>>>> On 7.4.2016 08:43, Fraser Tweedale wrote: >>>>>>> Hi team, >>>>>>> >>>>>>> I updated the Sub-CAs design page with more detail for the key >>>>>>> replication[1]. This part of the design is nearly complete (a large >>>>>>> patchset is in review over at pki-devel@) but there are various >>>>>>> options about how to authenticate to Custodia. >>>>>>> >>>>>>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication >>>>>>> >>>>>>> In brief, the options are: >>>>>>> >>>>>>> 1) authenticate as host principal; install binary setuid >>>>>>> root:pkiuser to read host keytab and custodia keys. >>>>>> >>>>>> Huh, I really do not like this. Host keytab on IPA master is one >>>>>> of the most >>>>>> sensitive keys we have. >>>>>> >>>>>> Maybe gssproxy can be used somehow, but I think it would be better >>>>>> to use >>>>>> separate key. >>>>>> >>>>>> >>>>>>> 2) authenticate as host principal; copy host keytab and custodia >>>>>>> keys to location readable by pkiuser. >>>>>> >>>>>> No, really, do not copy host keytab anywhere. >>>>>> >>>>>> >>>>>>> 3) create new principal for pkiuser to use, along with custodia keys >>>>>>> and keytab in location readable by pkiuser. >>>>>>> >>>>>>> I prefer option (1) for reasons outlined in the design page. The >>>>>>> design page goes into quite a bit more detail so please review the >>>>>>> section linked above and get back to me with your thoughts. >>>>>> >>>>>> The only downside of (3) using new keys is: >>>>>> ... This approach requires the creation of new principals, and >>>>>> Kerberos >>>>>> keytabs and Custodia keys for those principals, as part of the >>>>>> installation/upgrade process. >>>>>> >>>>>> Compared with additional SUID binary this seems as safer and >>>>>> easier way to go. >>>>>> FreeIPA installers already create quite a lot of principals and >>>>>> keytabs so >>>>>> this is well understood task. >>>>>> >>>>>> I would do (3). >>>>> >>>>> +1 for (3) >>>>> >>>>> A SUID binary feels like a dangerous hack. >>>> >>>> +1 >>>> >>> OK, (3) it is. Thanks all for your input. >>> >>> Now for next question: what should service principal name be? I >>> think `dogtag/example.com at EXAMPLE.COM' but am open to other >>> suggestions, e.g. `pki/...'. >> >> Do you plan to attempt to standardize this name in future? I do not >> expect that. >> >> Considering private nature of it, it should be as specific as possible to >> avoid any potential conflicts with future standards. >> "dogtag-key-replication" >> sounds like a good candidate. > > IMO it shouldn't be *that* specific, considering we want to switch > Dogtag from SSL to GSSAPI authentication to DS, which will probably use > the same principal name. I think "ipa-pki/..." or "dogtag/..." should be > fine. (Forgot to CC Fraser.) > >> >> Before you set the name in stone make sure it does not conflict with >> anything >> listed on >> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml >> >> >> These names have potential to be used by someone else. > -- Jan Cholasta From jcholast at redhat.com Tue Apr 19 06:20:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 19 Apr 2016 08:20:07 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides In-Reply-To: <570E3800.1060700@redhat.com> References: <56FE8B5F.8040803@redhat.com> <570279B6.1070504@redhat.com> <20160407115302.GL4768@p.redhat.com> <570DFB66.9040207@redhat.com> <570E3800.1060700@redhat.com> Message-ID: <5715CE17.8090503@redhat.com> On 13.4.2016 14:13, Tomas Babej wrote: > On 04/13/2016 09:55 AM, Tomas Babej wrote: >> On 04/07/2016 01:53 PM, Sumit Bose wrote: >>> On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 1.4.2016 16:53, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> this extends the user ID overrides with capability to store the user >>>>> certificate. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4955 >>>> >>>> The preferred way of managing certificates nowadays is using $OBJ-add-cert >>>> and $OBJ-remove-cert commands, you should add them here as well. >>>> >>>> I would even go as far as not allowing to modify certificates using >>>> idoverrideuser-mod - in user-mod and host-mod, it's there just for backward >>>> compatibility, which is not the case here. But I don't have a strong opinion >>>> on that. >>>> >>>> For consistency with user-find and host-find, the full certificate blob >>>> should not be shown in idoverrideuser-find. You can do that by setting >>>> search_display_attributes attribute on the idoverrideuser class >>>> appropriately. >>> >>> I tested the current patch with my related patches for SSSD and all is >>> working as expected. >>> >>> bye, >>> Sumit >>> >>>> >>>> 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 >>> >> >> Thanks for the reviews, >> >> attaching a updated patch that addresses Honza's comments. >> >> Tomas >> > > Sending an improved version addressing a couple of additional issues. 1) This bit in idoverrideuser_add.pre_callback() is redundant, as the certificate will always be DER here already: # Normalize the certificate to DER format certs = options.get('usercertificate', []) certs_der = [x509.normalize_certificate(c) for c in certs] entry_attrs['usercertificate'] = certs_der 2) You need to call convert_usercertificate_pre() in idoverrideuser_mod.pre_callback() and convert_usercertificate_post() in idoverrideuser_{mod,find,show}.post_callback() as well. Honza -- Jan Cholasta From dkupka at redhat.com Tue Apr 19 08:11:47 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 19 Apr 2016 10:11:47 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <1461008548.30315.23.camel@redhat.com> References: <5707C9F2.8060903@redhat.com> <570DDE0E.5070006@redhat.com> <1461008548.30315.23.camel@redhat.com> Message-ID: <5715E843.2020707@redhat.com> On 18/04/16 21:42, Simo Sorce wrote: > On Wed, 2016-04-13 at 07:50 +0200, David Kupka wrote: >> On 08/04/16 17:10, Martin Babinsky wrote: >>> Hi list, >>> >>> I have put together a draft [1] outlining the effort to reimplement the >>> handling of Kerberos principals in both backend and frontend layers of >>> FreeIPA so that we may have multiple aliases per user, host or service >>> and thus implement stuff like >>> https://fedorahosted.org/freeipa/ticket/3961 and >>> https://fedorahosted.org/freeipa/ticket/5413 . >>> >>> Since much of the plumbing was already implemented,[2] the document >>> mainly describes what the patches do. Some parts required by other use >>> cases may be missing so please point these out. >>> >>> I would also be happy if you could correct all factual inacurracies, I >>> did research on this issue a long time ago and my knowledge turned a bit >>> rusty. >>> >>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>> [2] >>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >>> >> >> Hi, >> after reading the designs following thoughts comes to my mind. >> >> 1) Just to be sure that I understand the new ticket obtaining process >> correctly I'd like to summarize. >> We need to always search all krbPrincipalName values, krbCanonicalName >> and ipaKrbPrincipalAlias (for backward compatibility). >> For TGT request case sensitivity of the search and principal in returned >> ticket depends on canonicalization. When canonicalization is requested >> the search is case-insensitive and krbCanonicalName is used otherwise >> case-sensitive search is performed and principal from request is used. > > Yes. > >> When requesting TGS search is always case-sensitive and principal from >> request is used. > > No, this sounds wrong to me, I think we want a case-insensitve search > for TGS requests. > >> In pseudo-code: >> >> get_tgt(principal, secret, canonicalization) >> if canonicalization >> if principal case-insensitive-in {krbPrincipalName + >> ipaKrbPrincipalAlias + krbCanonicalName} >> # verify secret, perform various other checks... >> return TGT(krbCanonicalName) >> else >> if principal case-sensitive-in {krbPrincipalName + >> ipaKrbPrincipalAlias + krbCanonicalName} >> # verify secret, perform various other checks... >> return TGT(principal) >> >> get_tgs(service_principal, TGT) >> if service_principal case-sensitive-in {krbPrincipalName + >> ipaKrbPrincipalAlias + krbCanonicalName} >> # verify TGT, perform various other checks... >> return TGS(service_principal) >> >> Do I understand it right? > > I do not think the TGS part is right. > A case insensitive search in TGS would allow to match upper case service > or host names which are sometime mistakenly used, especially in Windows > born software, given that the AD KDC is case insensitive. > Ok, thanks for correcting me. >> 2) I would like to add following constrains for >> krb{Canonical,Principal}Name attributes: >> >> when user/host/service is created krbCanonicalName is set to the same >> value as krbPrincipalName >> krbCanonicalName cannot be modified >> krbPrincipalName with the same value as krbCanonicalName cannot be >> removed/modified >> krbPrincipalName must be case-insensitively unique in whole DB >> krbPrincipalName attributes can be added and/or removed > > +1 > >> This will allow us to keep the first krbPrincipalName as RDN for >> services/hosts and give the flexibility of adding/removing aliases. >> >> 'Change of username' use case is also solvable with this approach. When >> username is changed we add krbPrincipalName with the new username. That >> will allow user to login with either old or new name. > > -1 for users a rename means we change the principal and the canonical > name and we do not retain any old principal name. > But this is inconsistent with the constrains above, especially "krbCanonicalName cannot be modified". We have the following options: 1) Do not allow rename for hosts and services but allow it for users. 2) Allow renaming of all objects. 3) Do not allow renaming of anything. I don't like 1) because it is inconsistent. User renaming is nice feature so we probably don't want 3). Which leaves us with different set of constrains: there always needs to be krbPrincipalName with the same value as krbCanonicalName krbPrincipalName must be case-insensitively unique in whole DB krbPrincipalName attributes can be added and/or removed Is this what we want? Is it wise to allow renaming of hosts and services? Is there a use case? Is there any potential danger? >> 3) ad CLI: >> {user,host,service}-add - Can canonicalname be specified? Or will it >> take principal argument/option value? >> Can we add {user,host,service}-{add,remove}-principal set of commands >> for principal manipulation? I really don't want to use >> --{add,set,del}-attr unless necessary. >> Will {user,host,service}-{show,find} display krbCanonicalName by default >> or only with --all option? >> >> 4) ad Upgrade: >> I think it would be worth to check and document what happens during >> upgrade of multiple replicas. There may be confusing behavior when >> obtaining tickets. KDC behavior will differ among servers and since >> autodiscovery is in use we don't know if we are talking to the old or >> new server. I'm not sure what exactly will happen but I suspect it won't >> be nice. > > Yes, this is a problematic point, I am wondering if we should have a way > to tell if all KDCs are at a specific level before allowing to turn on > this behavior, but then we need to make it conditional and this all > starts to sound a lot like a new domain level. > OTOH only alias resolution fails on older KDCs, so that may be ok in > some cases. > > Are there any strong opinions? > Should we make this change optional and activate it only when enough > features come up that demand a new domain level ? > We can always generate the canonicalName now to be ready, but prevent > adding aliases until a new domain level is created ? > Any other idea ? I would not go for a new domain level, it will just add a lot of 'if' statements all over the code. I believe it will be enough to document that canonicalization and other new features can be used only after all replicas in topology are upgraded. > > Simo. > -- David Kupka From mbasti at redhat.com Tue Apr 19 08:36:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Apr 2016 10:36:07 +0200 Subject: [Freeipa-devel] [PATCH 0009] Refactor test_automember_plugin In-Reply-To: <157401724.2956692.1460997885639.JavaMail.zimbra@redhat.com> References: <819699319.53565735.1460387186194.JavaMail.zimbra@redhat.com> <157401724.2956692.1460997885639.JavaMail.zimbra@redhat.com> Message-ID: <5715EDF7.2010207@redhat.com> On 18.04.2016 18:44, Ale? Mare?ek wrote: > Hello, > it looks good, thanks! > > ACK. > > > Target: master > > ----- Original Message ----- >> From: "Filip Skola" >> To: freeipa-devel at redhat.com >> Cc: "Milan Kub?k" , "Ale? Mare?ek" >> Sent: Monday, April 11, 2016 5:06:26 PM >> Subject: [PATCH 0009] Refactor test_automember_plugin >> >> Hi, >> >> sending the refactored automember plugin test for review. >> >> Filip >> Pushed to master: 5dfaeca7cedec4e692a51b653e0c303e3bcb981d From pspacek at redhat.com Tue Apr 19 09:11:58 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 19 Apr 2016 11:11:58 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1461008004.30315.15.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> <571500DF.20204@redhat.com> <1461008004.30315.15.camel@redhat.com> Message-ID: <5715F65E.2030403@redhat.com> On 18.4.2016 21:33, Simo Sorce wrote: > On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote: >> * Find, filter and copy hand-made records from main tree into the >> _locations sub-trees. This means that every hand-made record >> needs to be copied and synchronized N-times where N = number of IPA >> locations. > > This ^^ seem the one that provides the best semantics for admins and the > least unexpected results. > >> My favorite option for the first version is 'document that enabling >> DNS location will hide hand-made records in IPA domain.' > > I do not think this is acceptable, sorry. > >> The feature is disabled by default and needs additional configuration >> anyway so simply upgrading should not break anything. > > It is also useless this way. > >> I'm eager to hear opinions and answers to questions above. > > HTH, Well it does not help because you did not answer the questions listed in the design page. Anyway, here is third version of the design. It avoids copying user-made records (basically 2 DNAMEs were replaced with bunch of CNAMEs): http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29 It seems like a good middle ground: http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals This required changes in RecordGenerator design, too: https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator Also, CLI was updated to follow Honza's recommendations from previous e-mails: http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CLI Please review. -- Petr^2 Spacek From ofayans at redhat.com Tue Apr 19 09:13:25 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 19 Apr 2016 11:13:25 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <570E1E70.6060309@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> <5707C431.6070702@redhat.com> <570E1E70.6060309@redhat.com> Message-ID: <5715F6B5.3070003@redhat.com> OK, that one, though passing lint, did not actually work. I gave up my attempts to define method decorators inside the class. Now it passes lint AND works :) On 04/13/2016 12:24 PM, Oleg Fayans wrote: > Please. disregard my previous patch-0014: it doesn't pass pylint. The > newer one does. > > On 04/08/2016 04:46 PM, Oleg Fayans wrote: >> Hi all, >> >> It's been a while, and now the patch seems to be stable. It does hit one >> known issue with replica installation occationally [1], but other than >> that works fine on both domain levels. >> >> [1] https://fedorahosted.org/freeipa/ticket/5758 >> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0014.5-Actualized-ca-less-tests.patch Type: text/x-patch Size: 46091 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Apr 19 10:37:45 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 Apr 2016 12:37:45 +0200 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <5715E843.2020707@redhat.com> References: <5707C9F2.8060903@redhat.com> <570DDE0E.5070006@redhat.com> <1461008548.30315.23.camel@redhat.com> <5715E843.2020707@redhat.com> Message-ID: <57160A79.9050106@redhat.com> On 04/19/2016 10:11 AM, David Kupka wrote: > On 18/04/16 21:42, Simo Sorce wrote: >> On Wed, 2016-04-13 at 07:50 +0200, David Kupka wrote: >>> On 08/04/16 17:10, Martin Babinsky wrote: >>>> Hi list, >>>> >>>> I have put together a draft [1] outlining the effort to reimplement the >>>> handling of Kerberos principals in both backend and frontend layers of >>>> FreeIPA so that we may have multiple aliases per user, host or service >>>> and thus implement stuff like >>>> https://fedorahosted.org/freeipa/ticket/3961 and >>>> https://fedorahosted.org/freeipa/ticket/5413 . >>>> >>>> Since much of the plumbing was already implemented,[2] the document >>>> mainly describes what the patches do. Some parts required by other use >>>> cases may be missing so please point these out. >>>> >>>> I would also be happy if you could correct all factual inacurracies, I >>>> did research on this issue a long time ago and my knowledge turned a >>>> bit >>>> rusty. >>>> >>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases >>>> [2] >>>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html >>>> >>>> >>> >>> Hi, >>> after reading the designs following thoughts comes to my mind. >>> >>> 1) Just to be sure that I understand the new ticket obtaining process >>> correctly I'd like to summarize. >>> We need to always search all krbPrincipalName values, krbCanonicalName >>> and ipaKrbPrincipalAlias (for backward compatibility). >>> For TGT request case sensitivity of the search and principal in returned >>> ticket depends on canonicalization. When canonicalization is requested >>> the search is case-insensitive and krbCanonicalName is used otherwise >>> case-sensitive search is performed and principal from request is used. >> >> Yes. >> >>> When requesting TGS search is always case-sensitive and principal from >>> request is used. >> >> No, this sounds wrong to me, I think we want a case-insensitve search >> for TGS requests. >> >>> In pseudo-code: >>> >>> get_tgt(principal, secret, canonicalization) >>> if canonicalization >>> if principal case-insensitive-in {krbPrincipalName + >>> ipaKrbPrincipalAlias + krbCanonicalName} >>> # verify secret, perform various other checks... >>> return TGT(krbCanonicalName) >>> else >>> if principal case-sensitive-in {krbPrincipalName + >>> ipaKrbPrincipalAlias + krbCanonicalName} >>> # verify secret, perform various other checks... >>> return TGT(principal) >>> >>> get_tgs(service_principal, TGT) >>> if service_principal case-sensitive-in {krbPrincipalName + >>> ipaKrbPrincipalAlias + krbCanonicalName} >>> # verify TGT, perform various other checks... >>> return TGS(service_principal) >>> >>> Do I understand it right? >> >> I do not think the TGS part is right. >> A case insensitive search in TGS would allow to match upper case service >> or host names which are sometime mistakenly used, especially in Windows >> born software, given that the AD KDC is case insensitive. >> > > Ok, thanks for correcting me. > >>> 2) I would like to add following constrains for >>> krb{Canonical,Principal}Name attributes: >>> >>> when user/host/service is created krbCanonicalName is set to the same >>> value as krbPrincipalName >>> krbCanonicalName cannot be modified >>> krbPrincipalName with the same value as krbCanonicalName cannot be >>> removed/modified >>> krbPrincipalName must be case-insensitively unique in whole DB >>> krbPrincipalName attributes can be added and/or removed >> >> +1 >> >>> This will allow us to keep the first krbPrincipalName as RDN for >>> services/hosts and give the flexibility of adding/removing aliases. >>> >>> 'Change of username' use case is also solvable with this approach. When >>> username is changed we add krbPrincipalName with the new username. That >>> will allow user to login with either old or new name. >> >> -1 for users a rename means we change the principal and the canonical >> name and we do not retain any old principal name. >> > > But this is inconsistent with the constrains above, especially > "krbCanonicalName cannot be modified". We have the following options: > > 1) Do not allow rename for hosts and services but allow it for users. > 2) Allow renaming of all objects. > 3) Do not allow renaming of anything. > We already support renaming of user entries and the MODRDN plugin handles the rename of krbPrincipalName attribute. In this case we need to retain this behavior to be backwards compatible. Moreover, we would *have* to rename krbCanonicalName for the same reason. The question remains what to do if there are already some other aliases in place and the user is renamed. I will investigate this further. > I don't like 1) because it is inconsistent. User renaming is nice > feature so we probably don't want 3). Which leaves us with different set > of constrains: > > there always needs to be krbPrincipalName with the same value as > krbCanonicalName > krbPrincipalName must be case-insensitively unique in whole DB > krbPrincipalName attributes can be added and/or removed > > Is this what we want? Is it wise to allow renaming of hosts and > services? Is there a use case? Is there any potential danger? > For now I'do go with option 1.). It kind of preserves the current status quo (users have --rename but services/hosts do not) and I'm afraid that allowing rename operation on hosts/services will open a Pandora's box. >>> 3) ad CLI: >>> {user,host,service}-add - Can canonicalname be specified? Or will it >>> take principal argument/option value? >>> Can we add {user,host,service}-{add,remove}-principal set of commands >>> for principal manipulation? I really don't want to use >>> --{add,set,del}-attr unless necessary. >>> Will {user,host,service}-{show,find} display krbCanonicalName by default >>> or only with --all option? >>> >>> 4) ad Upgrade: >>> I think it would be worth to check and document what happens during >>> upgrade of multiple replicas. There may be confusing behavior when >>> obtaining tickets. KDC behavior will differ among servers and since >>> autodiscovery is in use we don't know if we are talking to the old or >>> new server. I'm not sure what exactly will happen but I suspect it won't >>> be nice. >> >> Yes, this is a problematic point, I am wondering if we should have a way >> to tell if all KDCs are at a specific level before allowing to turn on >> this behavior, but then we need to make it conditional and this all >> starts to sound a lot like a new domain level. >> OTOH only alias resolution fails on older KDCs, so that may be ok in >> some cases. >> >> Are there any strong opinions? >> Should we make this change optional and activate it only when enough >> features come up that demand a new domain level ? >> We can always generate the canonicalName now to be ready, but prevent >> adding aliases until a new domain level is created ? >> Any other idea ? > > I would not go for a new domain level, it will just add a lot of 'if' > statements all over the code. I believe it will be enough to document > that canonicalization and other new features can be used only after all > replicas in topology are upgraded. > + 1 just look how much work was required (and still is) to fully support domain level 1. >> >> Simo. >> > > -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Apr 19 10:42:55 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 Apr 2016 12:42:55 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570F66F2.7050407@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> Message-ID: <57160BAF.4020702@redhat.com> On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: > > On 04/14/2016 10:59 AM, Martin Babinsky wrote: >> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>> Martin Babinsky wrote: >>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>> subcommand >>>>> to the 'server-del' API method and exposes it as CLI command[1]. A CI >>>>> test suite is also included. >>>>> >>>>> There are some issues with the patch I would like to discuss in more >>>>> detail on the list: >>>>> >>>>> 1.) In the original subcommand there was a lot of output (mostly print >>>>> statements) during all stages of master removal. I have tried to port >>>>> these as messages to the command which results in quite voluminous >>>>> response sent back to the frontend. Should we try to reduce the >>>>> output? >>>> >>>> I don't think it applies anymore. These messages were there so the user >>>> would know something was happening. If it is an API command there isn't >>>> much we can do other than add something to the cli to print "This could >>>> take a bit" before making the call. >>> >>> +1 >>> >> This is already implemented in PoC. So I guess we may reduce the >> output only to the following: >> >> >> In CLI print: >> "Removing {server} from replication topology, " >> "please wait... >> >> The adding info messages: >> >> "checking topology connectivity" | "skipping topology connectivity check" >> "checking remaining services" | "skipping check for remaining services" >> "performing cleanup" >> "Deleted server {server}" >> >> >>>> >>>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>>> would >>>>> me a separate API method called during server_del postcallback. >>>>> However >>>>> since the two objects ended up sharing a lot of state (e.g. topology >>>>> state from pre-callback, messages) i have merged it to server-del. >>>>> That >>>>> makes the code rather unwieldy but I found it difficult to keep the >>>>> two >>>>> entities separate without some hacking around framework capabilities >>>> >>>> I haven't looked at the code but as a general principal having separate >>>> operations has saved our bacon on more than one occasion. >>> >>> The patch adds a force option, which allows you to re-run server-del >>> even if the master entry does not exist anymore, so I think we are safe. >>> >>>> >>>>> 3.) since actions in post-callback require a knowledge about topology >>>>> state gathered in pre-callback, I had to store some information in the >>>>> command's context. Sorry about that, if you know about some way to >>>>> circumvent me, let me know. >>>> >>>> Looks like it is the only way since you are extending server_del. >>>> Another option would be to drop pre/post and add all this topology >>>> stuff >>>> directly to server_del execute. >>>> >>>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>>> forwarding of the request to other master that can do the job. Is this >>>>> okay? >>> >>> Why can't the master remove itself? >>> >> Because it removes its own replication agreements hence any changes in >> DIT (like removed principals, s4u2 proxy targets etc.) won't replicate >> to other masters. > It shouldn't remove replication agreements, in fact this should be > prevented by the topology plugin. > The removal of the agreements will be triggered by removing the master > entry That is true, but there is a plenty of cleanup code that is executed *after* the master entry is removed and these changes would not replicate if the agreements were removed by topology plugin in the meanwhile. >>>> >>>> Assisted suicide? >>>> >>>> What does this effectively do? Potentially disconnect it from the >>>> topology, perhaps to run as standalone for upgrade, integration or >>>> other >>>> testing (e.g. there might be valid reasons to do this)? If so that >>>> seems >>>> ok to me, or if too hacky you could just spit out a message directing >>>> them to disconnect from another host, but that would be strange in the >>>> UI I think. >>>> >>>>> 5.) Since the original behavior of 'chekc_deleted_segments' was kept, >>>>> the code can sometimes hang waiting for removal of some segments, >>>>> especially during forced removal in wonky topologies. This can cause >>>>> gateway timeout in JSON-RPC call and report false positive error >>>>> back to >>>>> the user. This makes a large part of 'TestServerDel' suite to fail. >>>>> How >>>>> should we handle this? Should we keep the original behavior? >>>> >>>> Oh to have async calls... >>>> >>>> I wonder if "I'm still here" messages could be sent. I'm not entirely >>>> sure this is possible with the framework but it might be one way to >>>> keep >>>> long-lived connections alive. >>> >>> Impossible, everything is synchronous. >>> >>>> >>>>> 6.) There are some in-place imports of server-side code in some >>>>> places. >>>>> I'm not very happy about it and would be glad if we can agree on a way >>>>> to fix this. >>>> >>>> Is this to prevent imports on non-servers? You might look at trust for >>>> inspiration, it does this. >>> >>> I wouldn't worry about this, I'm going to move most plugin code to >>> ipaserver as part of the thin client feature anyway ;-) >>> >>> Honza >>> >> >> > -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Apr 19 11:49:03 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 19 Apr 2016 13:49:03 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <570F594F.6080007@redhat.com> References: <570E5C67.40201@redhat.com> <570F3BBC.7000800@redhat.com> <570F594F.6080007@redhat.com> Message-ID: <57161B2F.5060406@redhat.com> On 04/14/2016 10:48 AM, Martin Babinsky wrote: > On 04/14/2016 08:42 AM, Jan Cholasta wrote: >> Hi, >> >> On 13.4.2016 16:49, Martin Babinsky wrote: >>> This is a WIP patch which moves the `ipa-replica-manage del` subcommand >>> to the 'server-del' API method and exposes it as CLI command[1]. A CI >>> test suite is also included. >> >>> `server-del` now accepts the following options: >>> * `--cleanup`: perform a cleanup after an already deleted master >> >> I would prefer if this was actually called --force, for reasons >> explained in the design thread: >> . >> >>> * `--force-removal`: force master removal, i.e. ignore topology errors >> >> So, this is actually the all-powerful --force option we always try to >> avoid, but with a different name (and not very good one - if you are >> removing something, what other than removal would you need to force?). >> >> Could you split this into separate options? >> > There are actually two checks that we need to pass/bypass before we can > remove the master entry and run all the cleanup shenanigans: > > 1.) the topology is not disconnected already or is not being > disconnected by the action > > 2.) the action does leave at least one CA/DNS server, does not remove > DNSSec keymaster and we can promote other master to CA renewal master > > So IIUC we would need three options actually: > > * one that bypasses topology checks ('--ignore-topology-disconnect') > * one that bypasses the check for remaining services > ('--ignore-last-services?') > * one that will cleanup leftovers only, ignoring NotFound error > ('--cleanup'), this one is already there Actually '--force' should replace '--cleanup' as it does basically the same job. What about the remaining two proposed options? > >> Honza >> > > -- Martin^3 Babinsky From cheimes at redhat.com Tue Apr 19 12:01:35 2016 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 19 Apr 2016 14:01:35 +0200 Subject: [Freeipa-devel] V4/Sub-CAs review Message-ID: <57161E1F.6020001@redhat.com> Hi Fraser, I'm the reviewer for your Sub-CAs and RFC 2818 designs. Let's start with Sub-CAs first. http://www.freeipa.org/page/V4/Sub-CAs In general the design is well written -- accurate as usual. I didn't want to ACK the design with a simple LGTM, so I put myself in the position of a customer and potential user of Sub-CAs. From the end-users perspective couple of points in the design doc are either unclear or are not addressed details. 1) How can I restrict a Sub-CA to a specific key usage or DNS suffix? The design doc mentions a comment from the puppet community or the possibility to use a SubCA for short-lived certs for VPN authentication. As a customer I would like to restrict the KU, EKU and maybe name constraints, e.g. a SubCA for hosts should be limited to EKU "TLS webserver auth". Would it be possible to use a custom profile to generate a SubCA and let users select the profile in ipa ca-add? 2) What is the relationship between Sub-CAs and profiles? From the design doc it is unclear how cert profiles and Sub-CAs interact. The certificate profile doc has http://www.freeipa.org/page/V4/Certificate_Profiles#Schema_2, but that's too technical. I'm not even sure I fully understand the meaning of the schema and how memberCa affects profiles. 3) How can I make FreeIPA use a specific Sub-CA in a cert request? IMO a 1:n relationship between CAs and profiles would make sense. That way ipa cert-request --profile-id=caVPNCert could automatically select the VPN Sub-CA. 4) Where is the private key of a Sub-CAs stored locally and how is it secured? Customers will like to know where Dogtag keeps its crown jewels and how they are secured. 5) What is the backup and export strategy for a Sub-CA private key? Similar to 4), customers want/should to backup private keys securely. 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 mrniranjan at fedoraproject.org Tue Apr 19 14:05:56 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Tue, 19 Apr 2016 19:35:56 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5714F69B.2090602@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> Message-ID: <20160419140556.GA7154@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/18/2016 12:39 PM, Niranjan wrote: > > Niranjan wrote: > >> Niranjan wrote: > >>> Petr Viktorin wrote: > >>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>> Greetings, > >>>>> > >>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>> installed. > >>>> > >>>> Wow. I'm surprised the only problem on Windows is the "set -e". > >>>> > >>>> Regarding the patch: > >>>> > >>>> - Why is get_winhost_class needed? I don't see it called anywhere. > >>>> - Similarly, why is host_type needed? Your patch only sets it. > >>>> > >>>> If run_command of WinHost and Unix hosts are this similar, I would put > >>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >>>> attribute named e.g. "command_prelude", use it in run_command, and move > >>>> run_command from Host to BaseHost. > >>>> Would that work, or am I missing something? > >>> How do we detect the host is windows/unix then , we still need host_type > >>> to know what the type of host is (unix/windows)? > >>>> > >>>> > >>>> -- > >>>> Petr Viktorin > >> Please review the attached patch. > > Sorry for the delay. > > The information about whether the host is Unix or Windows is available: > the class is either Host or WinHost, so I don't think an extra host_type > is necessary. Sorry, but i still not sure how to invoke WinHost, did you mean in the file where i override the host class and WinHost class ? > I'd be open to adding host_type as *configuration* (and corresponding > attribute) if it also selected the actual Host class. Currently to use > WinHost you need to write custom code. Can you show any example code. > > I modified the patch so BaseHost takes test_dir as an argument, and sets > it as self.test_dir, so that users don't need to choose between > self.config.windows_test_dir/self.config.test_dir themselves. > (Unfortunately I don't have Windows to test on; I hope the change is > correct.) Would this approach work for you? > > -- > Petr Viktorin > > From f4e8290beb21eeee7aba60f1caf7e69b472e1e8e Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] modify run_command to execute on Windows > > Add global parameter windows_test_dir to specify test directory > for Windows > Windows hosts (WinHost) use this directory by default. > test_dir can now be set individually for each host. > Move run_command from Host class to BaseHost class > > Signed-off-by: Petr Viktorin > --- > pytest_multihost/config.py | 3 +++ > pytest_multihost/host.py | 41 ++++++++++++++++++++++------------------- > 2 files changed, 25 insertions(+), 19 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c2..58a3a5f 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db5..f82ff33 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -25,9 +25,11 @@ class BaseHost(object): > See README for an overview of the core classes. > """ > transport_class = None > + command_prelude = '' > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, password=None, > + test_dir=None): > self.domain = domain > self.role = str(role) > if username is None: > @@ -40,6 +42,10 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if test_dir is None: > + self.test_dir = domain.config.test_dir > + else: > + self.test_dir = test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -78,7 +84,7 @@ class BaseHost(object): > self.host_key = None > self.ssh_port = 22 > > - self.env_sh_path = os.path.join(domain.config.test_dir, 'env.sh') > + self.env_sh_path = os.path.join(self.test_dir, 'env.sh') > > self.log_collectors = [] > > @@ -204,28 +210,18 @@ class BaseHost(object): > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > - > - > -class Host(BaseHost): > - """A Unix host""" > - transport_class = transport.SSHTransport > - > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > # Set working directory > if cwd is None: > - cwd = self.config.test_dir > + cwd = self.test_dir > command.stdin.write('cd %s\n' % shell_quote(cwd)) > > # Set the environment > if set_env: > command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > + > + if self.command_prelude: > + command.stdin.write(self.command_prelude) > > if isinstance(argv, basestring): > # Run a shell command given as a string > @@ -247,11 +243,18 @@ class Host(BaseHost): > return command > > > +class Host(BaseHost): > + """A Unix host""" > + transport_class = transport.SSHTransport > + command_prelude = 'set -e\n' > + > + > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > - > - This is a stub; Windows hosts can't currently be interacted with. > """ > > - pass > + def __init__(self, domain, hostname, role, **kwargs): > + # Set test_dir to the Windows directory, if not given explicitly > + kwargs.setdefault('test_dir', domain.config.windows_test_dir) > + super(WinHost, self).__init__(domain, hostname, role, **kwargs) > -- > 2.5.5 > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From cheimes at redhat.com Tue Apr 19 14:14:01 2016 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 19 Apr 2016 16:14:01 +0200 Subject: [Freeipa-devel] V4/RFC 2818 review Message-ID: <57163D29.8030400@redhat.com> Hi Fraser, and now to the review of your design doc for RFC 2818-compliant subject alternative names in certs, http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance 1) RFC 2818 vs. RFC 6125 First I like to address a more general topic. Your design mentions RFC 6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname verification and we should follow the rules in RFC 6125, whenever 2818 lacks specification or there is a conflict between both RFCs. I can tell you some horror stories from Python's ssl module related to both RFCs. https://tools.ietf.org/html/rfc2818, HTTP Over TLS https://tools.ietf.org/html/rfc6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) As far as I'm familiar with RFC 6125, your proposal doesn't conflict with the more modern RFC. It also makes sense to name the design after the RFC, which has deprecated CN. I still like to check your design against RFC 6125. Fraser, do you agree? 2) SAN validation in ipa cert-request In the paragraph "ipa cert-request changes" you write that the plugin "[...] ensure that one element of the DNS names list matches the principal name". Shouldn't the plugin validate *all* DNS names and verify that the principal is allowed to request a cert for all fields in SAN? 3) Should FreeIPA deprecate cert request without SAN or at least warn the user? IMHO it makes sense to deprecate CN only cert requests. 4) update "Issue New Certificate for Host" dialog and documentation The web UI has an update "Issue New Certificate for Host" dialog which explains how to create a CSR with certutil. This dialog should be updated to explain how to add a SAN DNS field. The option for SAN DNS is '-8 fqdn' or '--extSAN dns:fqdn', e.g. Create a CSR with subject CN=,O=, for example: # certutil -R -d -a -g -s 'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' 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 Tue Apr 19 15:06:15 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Apr 2016 11:06:15 -0400 Subject: [Freeipa-devel] V4/RFC 2818 review In-Reply-To: <57163D29.8030400@redhat.com> References: <57163D29.8030400@redhat.com> Message-ID: <57164967.2020800@redhat.com> Christian Heimes wrote: > Hi Fraser, > > and now to the review of your design doc for RFC 2818-compliant subject > alternative names in certs, > http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > > 1) RFC 2818 vs. RFC 6125 > > First I like to address a more general topic. Your design mentions RFC > 6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > verification and we should follow the rules in RFC 6125, whenever 2818 > lacks specification or there is a conflict between both RFCs. I can tell > you some horror stories from Python's ssl module related to both RFCs. > > https://tools.ietf.org/html/rfc2818, HTTP Over TLS > > https://tools.ietf.org/html/rfc6125, Representation and Verification of > Domain-Based Application Service Identity within Internet Public Key > Infrastructure Using X.509 (PKIX) Certificates in the Context of > Transport Layer Security (TLS) > > As far as I'm familiar with RFC 6125, your proposal doesn't conflict > with the more modern RFC. It also makes sense to name the design after > the RFC, which has deprecated CN. I still like to check your design > against RFC 6125. > > Fraser, do you agree? > > > 2) SAN validation in ipa cert-request > > In the paragraph "ipa cert-request changes" you write that the plugin > "[...] ensure that one element of the DNS names list matches the > principal name". Shouldn't the plugin validate *all* DNS names and > verify that the principal is allowed to request a cert for all fields in > SAN? Are there plans for any other SAN types? IP address or other oddball types like MS UPN? > > 3) Should FreeIPA deprecate cert request without SAN or at least warn > the user? > > IMHO it makes sense to deprecate CN only cert requests. I'd mark it as deprecated over at least a major release in order to handle older versions that may still make requests without a SAN. > > 4) update "Issue New Certificate for Host" dialog and documentation > > The web UI has an update "Issue New Certificate for Host" dialog which > explains how to create a CSR with certutil. This dialog should be > updated to explain how to add a SAN DNS field. The option for SAN DNS is > '-8 fqdn' or '--extSAN dns:fqdn', e.g. > > Create a CSR with subject CN=,O=, for example: > # certutil -R -d -a -g -s > 'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' rob From mbasti at redhat.com Tue Apr 19 15:11:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 19 Apr 2016 17:11:42 +0200 Subject: [Freeipa-devel] [PATCH 0145] replica-prepare: do not add PTR records if there is no IPA managed reverse zone In-Reply-To: <5711069D.30503@redhat.com> References: <5711069D.30503@redhat.com> Message-ID: <57164AAE.7090708@redhat.com> On 15.04.2016 17:19, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5740 > > > ACK Pushed to: master: 6baed5be75e1de92b22b86536c532e43edfba530 ipa-4-3: 192a8e38b2169e1cbf32e2016046e67763e10bda -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Apr 19 16:50:47 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 19 Apr 2016 12:50:47 -0400 Subject: [Freeipa-devel] [DESIGN] Kerberos principal alias handling In-Reply-To: <57160A79.9050106@redhat.com> References: <5707C9F2.8060903@redhat.com> <570DDE0E.5070006@redhat.com> <1461008548.30315.23.camel@redhat.com> <5715E843.2020707@redhat.com> <57160A79.9050106@redhat.com> Message-ID: <1461084647.30315.39.camel@redhat.com> On Tue, 2016-04-19 at 12:37 +0200, Martin Babinsky wrote: > On 04/19/2016 10:11 AM, David Kupka wrote: > > On 18/04/16 21:42, Simo Sorce wrote: > >> On Wed, 2016-04-13 at 07:50 +0200, David Kupka wrote: > >>> On 08/04/16 17:10, Martin Babinsky wrote: > >>>> Hi list, > >>>> > >>>> I have put together a draft [1] outlining the effort to reimplement the > >>>> handling of Kerberos principals in both backend and frontend layers of > >>>> FreeIPA so that we may have multiple aliases per user, host or service > >>>> and thus implement stuff like > >>>> https://fedorahosted.org/freeipa/ticket/3961 and > >>>> https://fedorahosted.org/freeipa/ticket/5413 . > >>>> > >>>> Since much of the plumbing was already implemented,[2] the document > >>>> mainly describes what the patches do. Some parts required by other use > >>>> cases may be missing so please point these out. > >>>> > >>>> I would also be happy if you could correct all factual inacurracies, I > >>>> did research on this issue a long time ago and my knowledge turned a > >>>> bit > >>>> rusty. > >>>> > >>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > >>>> [2] > >>>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html > >>>> > >>>> > >>> > >>> Hi, > >>> after reading the designs following thoughts comes to my mind. > >>> > >>> 1) Just to be sure that I understand the new ticket obtaining process > >>> correctly I'd like to summarize. > >>> We need to always search all krbPrincipalName values, krbCanonicalName > >>> and ipaKrbPrincipalAlias (for backward compatibility). > >>> For TGT request case sensitivity of the search and principal in returned > >>> ticket depends on canonicalization. When canonicalization is requested > >>> the search is case-insensitive and krbCanonicalName is used otherwise > >>> case-sensitive search is performed and principal from request is used. > >> > >> Yes. > >> > >>> When requesting TGS search is always case-sensitive and principal from > >>> request is used. > >> > >> No, this sounds wrong to me, I think we want a case-insensitve search > >> for TGS requests. > >> > >>> In pseudo-code: > >>> > >>> get_tgt(principal, secret, canonicalization) > >>> if canonicalization > >>> if principal case-insensitive-in {krbPrincipalName + > >>> ipaKrbPrincipalAlias + krbCanonicalName} > >>> # verify secret, perform various other checks... > >>> return TGT(krbCanonicalName) > >>> else > >>> if principal case-sensitive-in {krbPrincipalName + > >>> ipaKrbPrincipalAlias + krbCanonicalName} > >>> # verify secret, perform various other checks... > >>> return TGT(principal) > >>> > >>> get_tgs(service_principal, TGT) > >>> if service_principal case-sensitive-in {krbPrincipalName + > >>> ipaKrbPrincipalAlias + krbCanonicalName} > >>> # verify TGT, perform various other checks... > >>> return TGS(service_principal) > >>> > >>> Do I understand it right? > >> > >> I do not think the TGS part is right. > >> A case insensitive search in TGS would allow to match upper case service > >> or host names which are sometime mistakenly used, especially in Windows > >> born software, given that the AD KDC is case insensitive. > >> > > > > Ok, thanks for correcting me. > > > >>> 2) I would like to add following constrains for > >>> krb{Canonical,Principal}Name attributes: > >>> > >>> when user/host/service is created krbCanonicalName is set to the same > >>> value as krbPrincipalName > >>> krbCanonicalName cannot be modified > >>> krbPrincipalName with the same value as krbCanonicalName cannot be > >>> removed/modified > >>> krbPrincipalName must be case-insensitively unique in whole DB > >>> krbPrincipalName attributes can be added and/or removed > >> > >> +1 > >> > >>> This will allow us to keep the first krbPrincipalName as RDN for > >>> services/hosts and give the flexibility of adding/removing aliases. > >>> > >>> 'Change of username' use case is also solvable with this approach. When > >>> username is changed we add krbPrincipalName with the new username. That > >>> will allow user to login with either old or new name. > >> > >> -1 for users a rename means we change the principal and the canonical > >> name and we do not retain any old principal name. > >> > > > > But this is inconsistent with the constrains above, especially > > "krbCanonicalName cannot be modified". We have the following options: > > > > 1) Do not allow rename for hosts and services but allow it for users. Yep, this is what we had for a long time, I see no reason for changing, no any inconsistency. > > 2) Allow renaming of all objects. > > 3) Do not allow renaming of anything. > > > We already support renaming of user entries and the MODRDN plugin > handles the rename of krbPrincipalName attribute. In this case we need > to retain this behavior to be backwards compatible. Moreover, we would > *have* to rename krbCanonicalName for the same reason. The question > remains what to do if there are already some other aliases in place and > the user is renamed. I will investigate this further. Aliases should be preserve, the only gotcha is if someone is renaming a user to a name that is already on the entry as an alias. We need to allow that and not fail the operation in that case, IMO. > > I don't like 1) because it is inconsistent. User renaming is nice > > feature so we probably don't want 3). Which leaves us with different set > > of constrains: > > > > there always needs to be krbPrincipalName with the same value as > > krbCanonicalName > > krbPrincipalName must be case-insensitively unique in whole DB > > krbPrincipalName attributes can be added and/or removed > > > > Is this what we want? Is it wise to allow renaming of hosts and > > services? Is there a use case? Is there any potential danger? > > > For now I'do go with option 1.). It kind of preserves the current status > quo (users have --rename but services/hosts do not) and I'm afraid that > allowing rename operation on hosts/services will open a Pandora's box. Renaming of services makes little sense, you'd have to download a keytab again anyway, in most cases. And host and services are generally tied to the hostname anyway. If there is huge demand for something like this we may allow it, but in general I'd say we keep the status quo. > >>> 3) ad CLI: > >>> {user,host,service}-add - Can canonicalname be specified? Or will it > >>> take principal argument/option value? > >>> Can we add {user,host,service}-{add,remove}-principal set of commands > >>> for principal manipulation? I really don't want to use > >>> --{add,set,del}-attr unless necessary. > >>> Will {user,host,service}-{show,find} display krbCanonicalName by default > >>> or only with --all option? > >>> > >>> 4) ad Upgrade: > >>> I think it would be worth to check and document what happens during > >>> upgrade of multiple replicas. There may be confusing behavior when > >>> obtaining tickets. KDC behavior will differ among servers and since > >>> autodiscovery is in use we don't know if we are talking to the old or > >>> new server. I'm not sure what exactly will happen but I suspect it won't > >>> be nice. > >> > >> Yes, this is a problematic point, I am wondering if we should have a way > >> to tell if all KDCs are at a specific level before allowing to turn on > >> this behavior, but then we need to make it conditional and this all > >> starts to sound a lot like a new domain level. > >> OTOH only alias resolution fails on older KDCs, so that may be ok in > >> some cases. > >> > >> Are there any strong opinions? > >> Should we make this change optional and activate it only when enough > >> features come up that demand a new domain level ? > >> We can always generate the canonicalName now to be ready, but prevent > >> adding aliases until a new domain level is created ? > >> Any other idea ? > > > > I would not go for a new domain level, it will just add a lot of 'if' > > statements all over the code. I believe it will be enough to document > > that canonicalization and other new features can be used only after all > > replicas in topology are upgraded. > > > + 1 just look how much work was required (and still is) to fully support > domain level 1. So here I disagree with the reasoning, it doesn't really matter if it is inconvenient for *us*. What matters is what is most usable and convenient for admins and reduces confusion and possible misbehavior. We may not need to use a domain level, but, unless we have a clear path to make sure mixed domain (with old and new servers) work properly we may not have any other option actually. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Apr 19 17:17:35 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 19 Apr 2016 13:17:35 -0400 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5715F65E.2030403@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> <571500DF.20204@redhat.com> <1461008004.30315.15.camel@redhat.com> <5715F65E.2030403@redhat.com> Message-ID: <1461086255.30315.46.camel@redhat.com> On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote: > On 18.4.2016 21:33, Simo Sorce wrote: > > On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote: > >> * Find, filter and copy hand-made records from main tree into the > >> _locations sub-trees. This means that every hand-made record > >> needs to be copied and synchronized N-times where N = number of IPA > >> locations. > > > > This ^^ seem the one that provides the best semantics for admins and the > > least unexpected results. > > > >> My favorite option for the first version is 'document that enabling > >> DNS location will hide hand-made records in IPA domain.' > > > > I do not think this is acceptable, sorry. > > > >> The feature is disabled by default and needs additional configuration > >> anyway so simply upgrading should not break anything. > > > > It is also useless this way. > > > >> I'm eager to hear opinions and answers to questions above. > > > > HTH, > > Well it does not help because you did not answer the questions listed in the > design page. > > Anyway, here is third version of the design. It avoids copying user-made > records (basically 2 DNAMEs were replaced with bunch of CNAMEs): > > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29 > > It seems like a good middle ground: > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals It does seem like a decent middle ground. And I guess an admin would be able to add custom templates if he wants to have specific services forwarded to the location specific subtree ? > This required changes in RecordGenerator design, too: > https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator I do not see where you specify the specific record names you forward to the location trees here? > Also, CLI was updated to follow Honza's recommendations from previous e-mails: > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CLI Thanks for updating all designs in concert. Simo. -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Wed Apr 20 01:32:41 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 20 Apr 2016 11:32:41 +1000 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <5715C6AB.50909@redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> <5706366C.4020109@redhat.com> <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> <57066C16.2000508@redhat.com> <570F3F28.3020801@redhat.com> <5715C6AB.50909@redhat.com> Message-ID: <20160420013241.GB18277@dhcp-40-8.bne.redhat.com> On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote: > On 14.4.2016 08:56, Jan Cholasta wrote: > >On 7.4.2016 16:17, Petr Spacek wrote: > >>On 7.4.2016 15:20, Fraser Tweedale wrote: > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > >>>>On 7.4.2016 12:13, Christian Heimes wrote: > >>>>>On 2016-04-07 11:09, Petr Spacek wrote: > >>>>>>On 7.4.2016 08:43, Fraser Tweedale wrote: > >>>>>>>Hi team, > >>>>>>> > >>>>>>>I updated the Sub-CAs design page with more detail for the key > >>>>>>>replication[1]. This part of the design is nearly complete (a large > >>>>>>>patchset is in review over at pki-devel@) but there are various > >>>>>>>options about how to authenticate to Custodia. > >>>>>>> > >>>>>>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > >>>>>>> > >>>>>>>In brief, the options are: > >>>>>>> > >>>>>>>1) authenticate as host principal; install binary setuid > >>>>>>> root:pkiuser to read host keytab and custodia keys. > >>>>>> > >>>>>>Huh, I really do not like this. Host keytab on IPA master is one > >>>>>>of the most > >>>>>>sensitive keys we have. > >>>>>> > >>>>>>Maybe gssproxy can be used somehow, but I think it would be better > >>>>>>to use > >>>>>>separate key. > >>>>>> > >>>>>> > >>>>>>>2) authenticate as host principal; copy host keytab and custodia > >>>>>>> keys to location readable by pkiuser. > >>>>>> > >>>>>>No, really, do not copy host keytab anywhere. > >>>>>> > >>>>>> > >>>>>>>3) create new principal for pkiuser to use, along with custodia keys > >>>>>>> and keytab in location readable by pkiuser. > >>>>>>> > >>>>>>>I prefer option (1) for reasons outlined in the design page. The > >>>>>>>design page goes into quite a bit more detail so please review the > >>>>>>>section linked above and get back to me with your thoughts. > >>>>>> > >>>>>>The only downside of (3) using new keys is: > >>>>>>... This approach requires the creation of new principals, and > >>>>>>Kerberos > >>>>>>keytabs and Custodia keys for those principals, as part of the > >>>>>>installation/upgrade process. > >>>>>> > >>>>>>Compared with additional SUID binary this seems as safer and > >>>>>>easier way to go. > >>>>>>FreeIPA installers already create quite a lot of principals and > >>>>>>keytabs so > >>>>>>this is well understood task. > >>>>>> > >>>>>>I would do (3). > >>>>> > >>>>>+1 for (3) > >>>>> > >>>>>A SUID binary feels like a dangerous hack. > >>>> > >>>>+1 > >>>> > >>>OK, (3) it is. Thanks all for your input. > >>> > >>>Now for next question: what should service principal name be? I > >>>think `dogtag/example.com at EXAMPLE.COM' but am open to other > >>>suggestions, e.g. `pki/...'. > >> > >>Do you plan to attempt to standardize this name in future? I do not > >>expect that. > >> > >>Considering private nature of it, it should be as specific as possible to > >>avoid any potential conflicts with future standards. > >>"dogtag-key-replication" > >>sounds like a good candidate. > > > >IMO it shouldn't be *that* specific, considering we want to switch > >Dogtag from SSL to GSSAPI authentication to DS, which will probably use > >the same principal name. I think "ipa-pki/..." or "dogtag/..." should be > >fine. > > (Forgot to CC Fraser.) > What is HTTP client support like for principal names with service part /= "HTTP"? For communication from IPA framework to Dogtag, we will need a way to force the client to use an alternative service name. As for the actual service name, I will use "dogtag/..." Cheers, Fraser > > > >> > >>Before you set the name in stone make sure it does not conflict with > >>anything > >>listed on > >>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > >> > >> > >>These names have potential to be used by someone else. > > > > -- > Jan Cholasta From simo at redhat.com Wed Apr 20 01:57:52 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 19 Apr 2016 21:57:52 -0400 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <20160420013241.GB18277@dhcp-40-8.bne.redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> <5706366C.4020109@redhat.com> <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> <57066C16.2000508@redhat.com> <570F3F28.3020801@redhat.com> <5715C6AB.50909@redhat.com> <20160420013241.GB18277@dhcp-40-8.bne.redhat.com> Message-ID: <1461117472.30315.64.camel@redhat.com> On Wed, 2016-04-20 at 11:32 +1000, Fraser Tweedale wrote: > On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote: > > On 14.4.2016 08:56, Jan Cholasta wrote: > > >On 7.4.2016 16:17, Petr Spacek wrote: > > >>On 7.4.2016 15:20, Fraser Tweedale wrote: > > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > > >>>>On 7.4.2016 12:13, Christian Heimes wrote: > > >>>>>On 2016-04-07 11:09, Petr Spacek wrote: > > >>>>>>On 7.4.2016 08:43, Fraser Tweedale wrote: > > >>>>>>>Hi team, > > >>>>>>> > > >>>>>>>I updated the Sub-CAs design page with more detail for the key > > >>>>>>>replication[1]. This part of the design is nearly complete (a large > > >>>>>>>patchset is in review over at pki-devel@) but there are various > > >>>>>>>options about how to authenticate to Custodia. > > >>>>>>> > > >>>>>>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > >>>>>>> > > >>>>>>>In brief, the options are: > > >>>>>>> > > >>>>>>>1) authenticate as host principal; install binary setuid > > >>>>>>> root:pkiuser to read host keytab and custodia keys. > > >>>>>> > > >>>>>>Huh, I really do not like this. Host keytab on IPA master is one > > >>>>>>of the most > > >>>>>>sensitive keys we have. > > >>>>>> > > >>>>>>Maybe gssproxy can be used somehow, but I think it would be better > > >>>>>>to use > > >>>>>>separate key. > > >>>>>> > > >>>>>> > > >>>>>>>2) authenticate as host principal; copy host keytab and custodia > > >>>>>>> keys to location readable by pkiuser. > > >>>>>> > > >>>>>>No, really, do not copy host keytab anywhere. > > >>>>>> > > >>>>>> > > >>>>>>>3) create new principal for pkiuser to use, along with custodia keys > > >>>>>>> and keytab in location readable by pkiuser. > > >>>>>>> > > >>>>>>>I prefer option (1) for reasons outlined in the design page. The > > >>>>>>>design page goes into quite a bit more detail so please review the > > >>>>>>>section linked above and get back to me with your thoughts. > > >>>>>> > > >>>>>>The only downside of (3) using new keys is: > > >>>>>>... This approach requires the creation of new principals, and > > >>>>>>Kerberos > > >>>>>>keytabs and Custodia keys for those principals, as part of the > > >>>>>>installation/upgrade process. > > >>>>>> > > >>>>>>Compared with additional SUID binary this seems as safer and > > >>>>>>easier way to go. > > >>>>>>FreeIPA installers already create quite a lot of principals and > > >>>>>>keytabs so > > >>>>>>this is well understood task. > > >>>>>> > > >>>>>>I would do (3). > > >>>>> > > >>>>>+1 for (3) > > >>>>> > > >>>>>A SUID binary feels like a dangerous hack. > > >>>> > > >>>>+1 > > >>>> > > >>>OK, (3) it is. Thanks all for your input. > > >>> > > >>>Now for next question: what should service principal name be? I > > >>>think `dogtag/example.com at EXAMPLE.COM' but am open to other > > >>>suggestions, e.g. `pki/...'. > > >> > > >>Do you plan to attempt to standardize this name in future? I do not > > >>expect that. > > >> > > >>Considering private nature of it, it should be as specific as possible to > > >>avoid any potential conflicts with future standards. > > >>"dogtag-key-replication" > > >>sounds like a good candidate. > > > > > >IMO it shouldn't be *that* specific, considering we want to switch > > >Dogtag from SSL to GSSAPI authentication to DS, which will probably use > > >the same principal name. I think "ipa-pki/..." or "dogtag/..." should be > > >fine. > > > > (Forgot to CC Fraser.) > > > What is HTTP client support like for principal names with service > part /= "HTTP"? As a target ? None, in which case are you going to use the dogtag keytab for the acceptor though ? > For communication from IPA framework to Dogtag, > we will need a way to force the client to use an alternative service > name. Our pbox design says differently. We'll just interpose gssproxy and we'll be able to safely share the HTTP key for all services. > As for the actual service name, I will use "dogtag/..." Good to use as a client. Simo. > Cheers, > Fraser > > > > > > >> > > >>Before you set the name in stone make sure it does not conflict with > > >>anything > > >>listed on > > >>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > >> > > >> > > >>These names have potential to be used by someone else. > > > > > > > -- > > Jan Cholasta > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Apr 20 02:00:36 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 19 Apr 2016 22:00:36 -0400 Subject: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia In-Reply-To: <1461117472.30315.64.camel@redhat.com> References: <20160407064329.GN18277@dhcp-40-8.bne.redhat.com> <570623DE.7030709@redhat.com> <570632C4.2010906@redhat.com> <5706366C.4020109@redhat.com> <20160407132016.GO18277@dhcp-40-8.bne.redhat.com> <57066C16.2000508@redhat.com> <570F3F28.3020801@redhat.com> <5715C6AB.50909@redhat.com> <20160420013241.GB18277@dhcp-40-8.bne.redhat.com> <1461117472.30315.64.camel@redhat.com> Message-ID: <1461117636.30315.66.camel@redhat.com> On Tue, 2016-04-19 at 21:57 -0400, Simo Sorce wrote: > On Wed, 2016-04-20 at 11:32 +1000, Fraser Tweedale wrote: > > On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote: > > > On 14.4.2016 08:56, Jan Cholasta wrote: > > > >On 7.4.2016 16:17, Petr Spacek wrote: > > > >>On 7.4.2016 15:20, Fraser Tweedale wrote: > > > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > > > >>>>On 7.4.2016 12:13, Christian Heimes wrote: > > > >>>>>On 2016-04-07 11:09, Petr Spacek wrote: > > > >>>>>>On 7.4.2016 08:43, Fraser Tweedale wrote: > > > >>>>>>>Hi team, > > > >>>>>>> > > > >>>>>>>I updated the Sub-CAs design page with more detail for the key > > > >>>>>>>replication[1]. This part of the design is nearly complete (a large > > > >>>>>>>patchset is in review over at pki-devel@) but there are various > > > >>>>>>>options about how to authenticate to Custodia. > > > >>>>>>> > > > >>>>>>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > > >>>>>>> > > > >>>>>>>In brief, the options are: > > > >>>>>>> > > > >>>>>>>1) authenticate as host principal; install binary setuid > > > >>>>>>> root:pkiuser to read host keytab and custodia keys. > > > >>>>>> > > > >>>>>>Huh, I really do not like this. Host keytab on IPA master is one > > > >>>>>>of the most > > > >>>>>>sensitive keys we have. > > > >>>>>> > > > >>>>>>Maybe gssproxy can be used somehow, but I think it would be better > > > >>>>>>to use > > > >>>>>>separate key. > > > >>>>>> > > > >>>>>> > > > >>>>>>>2) authenticate as host principal; copy host keytab and custodia > > > >>>>>>> keys to location readable by pkiuser. > > > >>>>>> > > > >>>>>>No, really, do not copy host keytab anywhere. > > > >>>>>> > > > >>>>>> > > > >>>>>>>3) create new principal for pkiuser to use, along with custodia keys > > > >>>>>>> and keytab in location readable by pkiuser. > > > >>>>>>> > > > >>>>>>>I prefer option (1) for reasons outlined in the design page. The > > > >>>>>>>design page goes into quite a bit more detail so please review the > > > >>>>>>>section linked above and get back to me with your thoughts. > > > >>>>>> > > > >>>>>>The only downside of (3) using new keys is: > > > >>>>>>... This approach requires the creation of new principals, and > > > >>>>>>Kerberos > > > >>>>>>keytabs and Custodia keys for those principals, as part of the > > > >>>>>>installation/upgrade process. > > > >>>>>> > > > >>>>>>Compared with additional SUID binary this seems as safer and > > > >>>>>>easier way to go. > > > >>>>>>FreeIPA installers already create quite a lot of principals and > > > >>>>>>keytabs so > > > >>>>>>this is well understood task. > > > >>>>>> > > > >>>>>>I would do (3). > > > >>>>> > > > >>>>>+1 for (3) > > > >>>>> > > > >>>>>A SUID binary feels like a dangerous hack. > > > >>>> > > > >>>>+1 > > > >>>> > > > >>>OK, (3) it is. Thanks all for your input. > > > >>> > > > >>>Now for next question: what should service principal name be? I > > > >>>think `dogtag/example.com at EXAMPLE.COM' but am open to other > > > >>>suggestions, e.g. `pki/...'. > > > >> > > > >>Do you plan to attempt to standardize this name in future? I do not > > > >>expect that. > > > >> > > > >>Considering private nature of it, it should be as specific as possible to > > > >>avoid any potential conflicts with future standards. > > > >>"dogtag-key-replication" > > > >>sounds like a good candidate. > > > > > > > >IMO it shouldn't be *that* specific, considering we want to switch > > > >Dogtag from SSL to GSSAPI authentication to DS, which will probably use > > > >the same principal name. I think "ipa-pki/..." or "dogtag/..." should be > > > >fine. > > > > > > (Forgot to CC Fraser.) > > > > > What is HTTP client support like for principal names with service > > part /= "HTTP"? > > As a target ? > None, in which case are you going to use the dogtag keytab for the > acceptor though ? > > > For communication from IPA framework to Dogtag, > > we will need a way to force the client to use an alternative service > > name. > > Our pbox design says differently. > We'll just interpose gssproxy and we'll be able to safely share the HTTP > key for all services. Ah this is not finalized yet, but attached find an initial draft. > > As for the actual service name, I will use "dogtag/..." > > Good to use as a client. > > Simo. > > > Cheers, > > Fraser > > > > > > > > > >> > > > >>Before you set the name in stone make sure it does not conflict with > > > >>anything > > > >>listed on > > > >>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > > >> > > > >> > > > >>These names have potential to be used by someone else. > > > > > > > > > > -- > > > Jan Cholasta > > > > -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: P-Box-option-1.pdf Type: application/pdf Size: 55944 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Wed Apr 20 04:11:43 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Wed, 20 Apr 2016 09:41:43 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5714F69B.2090602@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> Message-ID: <20160420041143.GA4140@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/18/2016 12:39 PM, Niranjan wrote: > > Niranjan wrote: > >> Niranjan wrote: > >>> Petr Viktorin wrote: > >>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>> Greetings, > >>>>> > >>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>> installed. > >>>> > >>>> Wow. I'm surprised the only problem on Windows is the "set -e". > >>>> > >>>> Regarding the patch: > >>>> > >>>> - Why is get_winhost_class needed? I don't see it called anywhere. > >>>> - Similarly, why is host_type needed? Your patch only sets it. > >>>> > >>>> If run_command of WinHost and Unix hosts are this similar, I would put > >>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >>>> attribute named e.g. "command_prelude", use it in run_command, and move > >>>> run_command from Host to BaseHost. > >>>> Would that work, or am I missing something? > >>> How do we detect the host is windows/unix then , we still need host_type > >>> to know what the type of host is (unix/windows)? > >>>> > >>>> > >>>> -- > >>>> Petr Viktorin > >> Please review the attached patch. > > Sorry for the delay. > > The information about whether the host is Unix or Windows is available: > the class is either Host or WinHost, so I don't think an extra host_type > is necessary. > I'd be open to adding host_type as *configuration* (and corresponding > attribute) if it also selected the actual Host class. Currently to use > WinHost you need to write custom code. I would like to have host_type available. We would like to add more functions in classes that override Host/WinHost class , which can be then called depending upon the host_type. > > I modified the patch so BaseHost takes test_dir as an argument, and sets > it as self.test_dir, so that users don't need to choose between > self.config.windows_test_dir/self.config.test_dir themselves. > (Unfortunately I don't have Windows to test on; I hope the change is > correct.) Would this approach work for you? > > -- > Petr Viktorin > > From f4e8290beb21eeee7aba60f1caf7e69b472e1e8e Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] modify run_command to execute on Windows > > Add global parameter windows_test_dir to specify test directory > for Windows > Windows hosts (WinHost) use this directory by default. > test_dir can now be set individually for each host. > Move run_command from Host class to BaseHost class > > Signed-off-by: Petr Viktorin > --- > pytest_multihost/config.py | 3 +++ > pytest_multihost/host.py | 41 ++++++++++++++++++++++------------------- > 2 files changed, 25 insertions(+), 19 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c2..58a3a5f 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db5..f82ff33 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -25,9 +25,11 @@ class BaseHost(object): > See README for an overview of the core classes. > """ > transport_class = None > + command_prelude = '' > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, password=None, > + test_dir=None): > self.domain = domain > self.role = str(role) > if username is None: > @@ -40,6 +42,10 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if test_dir is None: > + self.test_dir = domain.config.test_dir > + else: > + self.test_dir = test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -78,7 +84,7 @@ class BaseHost(object): > self.host_key = None > self.ssh_port = 22 > > - self.env_sh_path = os.path.join(domain.config.test_dir, 'env.sh') > + self.env_sh_path = os.path.join(self.test_dir, 'env.sh') > > self.log_collectors = [] > > @@ -204,28 +210,18 @@ class BaseHost(object): > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > - > - > -class Host(BaseHost): > - """A Unix host""" > - transport_class = transport.SSHTransport > - > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > # Set working directory > if cwd is None: > - cwd = self.config.test_dir > + cwd = self.test_dir > command.stdin.write('cd %s\n' % shell_quote(cwd)) > > # Set the environment > if set_env: > command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > + > + if self.command_prelude: > + command.stdin.write(self.command_prelude) > > if isinstance(argv, basestring): > # Run a shell command given as a string > @@ -247,11 +243,18 @@ class Host(BaseHost): > return command > > > +class Host(BaseHost): > + """A Unix host""" > + transport_class = transport.SSHTransport > + command_prelude = 'set -e\n' > + > + > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > - > - This is a stub; Windows hosts can't currently be interacted with. > """ > > - pass > + def __init__(self, domain, hostname, role, **kwargs): > + # Set test_dir to the Windows directory, if not given explicitly > + kwargs.setdefault('test_dir', domain.config.windows_test_dir) > + super(WinHost, self).__init__(domain, hostname, role, **kwargs) > -- > 2.5.5 > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From akasurde at redhat.com Wed Apr 20 05:52:44 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 20 Apr 2016 11:22:44 +0530 Subject: [Freeipa-devel] [PATCH] Added fix for notifying user about locked user account in WebUI Message-ID: <5717192C.1010708@redhat.com> Hi All, Please review this patch. Fixes : https://fedorahosted.org/freeipa/ticket/5076 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0008-Added-fix-for-notifying-user-about-locked-user-accou.patch Type: text/x-patch Size: 5261 bytes Desc: not available URL: From ftweedal at redhat.com Wed Apr 20 06:22:54 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 20 Apr 2016 16:22:54 +1000 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <1461008648.30315.24.camel@redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> <1460467890.8657.25.camel@redhat.com> <20160413011550.GI18277@dhcp-40-8.bne.redhat.com> <20160414063300.GN18277@dhcp-40-8.bne.redhat.com> <1461008648.30315.24.camel@redhat.com> Message-ID: <20160420062254.GE18277@dhcp-40-8.bne.redhat.com> On Mon, Apr 18, 2016 at 03:44:08PM -0400, Simo Sorce wrote: > On Thu, 2016-04-14 at 16:33 +1000, Fraser Tweedale wrote: > > On Wed, Apr 13, 2016 at 11:15:50AM +1000, Fraser Tweedale wrote: > > > On Tue, Apr 12, 2016 at 09:31:30AM -0400, Simo Sorce wrote: > > > > On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote: > > > > > On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: > > > > > > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: > > > > > > > - name = gssapi.Name('host@%s' % (self.client,), > > > > > > > > > > > > > > - gssapi.NameType.hostbased_service) > > > > > > > > > > > > If you remove this then on a serve that has nfs keys in the keytab you > > > > > > may end up acquiring the wrong credentials. > > > > > > You need to pass down what credentials you want to use to initialize the > > > > > > cred store, we canot rely on ordering in the system keytab case. > > > > > > > > > > > > Simo. > > > > > > > > > > > Thanks Simo; updated patch attached. > > > > > > > > Except the ACI the rest looks good to me. > > > > For ACI please add a separate patch that follows the naming scheme for > > > > subCA keys. > > > > > > > The ACI here targets the Custodia server public keys, so the client > > > can search and read them. It should just read: > > > > > > add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") > > > (targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal") > > > (version 3.0; acl "Anyone can search Custodia public keys"; > > > allow(read, search, compare) userdn = "ldap:///all";) > > > > > > I don't mind putting the ACI in a separate patch, but it is > > > necessary to restrict read access on the public keys to only the > > > dogtag-ipa-custodia service principals. > > > > > Updated patches attached. ACI was split into new patch and > > simplified (removed ($dn) macro). > > Ack on the custodia patch. > However do we really need to allow *anyone* to look up these keys ? > I know they are "public" keys, but still ... I think I would prefer a > stricter ACI. > OK, I rescind the ACI patch (0052) and will include a more specific ACI in a new version of the patch that adds the principal. 0051 is good to merge now :) Thanks for the review, Simo. Fraser From dkupka at redhat.com Wed Apr 20 08:35:34 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 20 Apr 2016 10:35:34 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <5715F6B5.3070003@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> <5707C431.6070702@redhat.com> <570E1E70.6060309@redhat.com> <5715F6B5.3070003@redhat.com> Message-ID: <57173F56.5020308@redhat.com> On 19/04/16 11:13, Oleg Fayans wrote: > OK, that one, though passing lint, did not actually work. I gave up my > attempts to define method decorators inside the class. Now it passes > lint AND works:) > Hi Oleg! 1) Current commit message is useless. Please use it to describe what is the point of the patch. 2) $ git show -U0 | pep8 --diff ./ipatests/test_integration/test_caless.py:66:1: E302 expected 2 blank lines, found 1 ./ipatests/test_integration/test_caless.py:74:1: E302 expected 2 blank lines, found 1 ./ipatests/test_integration/test_caless.py:820:5: E303 too many blank lines (2) ./ipatests/test_integration/test_caless.py:825:80: E501 line too long (80 > 79 characters) ./ipatests/test_integration/test_caless.py:1035:44: E225 missing whitespace around operator 3) Isn't there a way to do this with pytest's fixtures? > +def server_install_teardown(func): > + def wrapped(*args): > + try: > + func(*args) > + finally: > + args[0].uninstall_server() > + return wrapped > + > +def replica_install_teardown(func): > + def wrapped(*args): > + try: > + func(*args) > + finally: > + # Uninstall replica > + replica = args[0].replicas[0] > + tasks.kinit_admin(args[0].master) > + args[0].uninstall_server(replica) > + args[0].master.run_command(['ipa-replica-manage', 'del', > + replica.hostname, '--force'], > + raiseonerr=False) > + args[0].master.run_command(['ipa', 'host-del', > + replica.hostname], > + raiseonerr=False) > + return wrapped > + 4) Is it necessary to create the $TEST_DIR in the test? Isn't it created by the framework? > + host.transport.mkdir_recursive(host.config.test_dir) 5) I don't think the comment match the code. > > + # Remove CA cert in /etc/pki/nssdb, in case of failed (un)install > + for host in cls.get_all_hosts(): > + cls.uninstall_server(host) > + > super(CALessBase, cls).uninstall(mh) 6) No! Create list with one element, iterate that list and append every item to the other list. Maybe there's better way (Hint: append). I've seen this on multiple places. > if unattended: > args.extend(['-U']) 7) Why don't you (extend and) use ipatests.test_integaration.tasks.(un)install_{master,replica}? This could be done pretty much all over the code. > host.run_command(['ipa-server-install', '--uninstall', '-U']) 8) Use ipaplatform.paths for certutil and other binaries. If the binary is not there feel free to add it. I've seen this on multiple places. > + host.run_command(['certutil', '-d', paths.NSS_DB_DIR, '-D', > + '-n', 'External CA cert'], > + raiseonerr=False) > + # A workaround forhttps://fedorahosted.org/freeipa/ticket/4639 > + result = host.run_command(['certutil', '-L', '-d', > + paths.HTTPD_ALIAS_DIR]) > + for rawcert in result.stdout_text.split('\n')[4: -1]: > + cert = rawcert.split(' ')[0] > + host.run_command(['certutil', '-D', '-d', paths.HTTPD_ALIAS_DIR, > + '-n', cert]) > 9) certmonger is system service. You can check if is is .enabled() and .running(). And IIUC the comment is negation of what the code does. > > # Verify certmonger was not started > result = host.run_command(['getcert', 'list'], raiseonerr=False) > - assert result > 0 > - assert ('Please verify that the certmonger service has been ' > - 'started.' in result.stdout_text), result.stdout_text > + assert result.returncode == 0 10) What is the point of calling uninstall_server() when it will be called in the finally block of server_install_teardown anyway? > + @server_install_teardown > def test_revoked_http(self): > "IPA server install with revoked HTTP certificate" > > if result.returncode == 0: > + self.uninstall_server() > raise nose.SkipTest( > "Known CA-less installation defect, see " > +"https://fedorahosted.org/freeipa/ticket/4270") > > assert result.returncode > 0 > Nitpick) Do not mix fixing typos/grammar/spelling/style with functional changes. > - def test_incorect_http_pin(self): > + @pytest.mark.xfail(reason='freeipa ticket 5378') > + def test_incorrect_http_pin(self): > "Install new HTTP certificate with incorrect PKCS#12 password" -- David Kupka From dkupka at redhat.com Wed Apr 20 09:55:03 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 20 Apr 2016 11:55:03 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <57173F56.5020308@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> <5707C431.6070702@redhat.com> <570E1E70.6060309@redhat.com> <5715F6B5.3070003@redhat.com> <57173F56.5020308@redhat.com> Message-ID: <571751F7.7030504@redhat.com> On 20/04/16 10:35, David Kupka wrote: > On 19/04/16 11:13, Oleg Fayans wrote: >> OK, that one, though passing lint, did not actually work. I gave up my >> attempts to define method decorators inside the class. Now it passes >> lint AND works:) >> > > Hi Oleg! > > 1) Current commit message is useless. Please use it to describe what is > the point of the patch. > > 2) $ git show -U0 | pep8 --diff > ./ipatests/test_integration/test_caless.py:66:1: E302 expected 2 blank > lines, found 1 > ./ipatests/test_integration/test_caless.py:74:1: E302 expected 2 blank > lines, found 1 > ./ipatests/test_integration/test_caless.py:820:5: E303 too many blank > lines (2) > ./ipatests/test_integration/test_caless.py:825:80: E501 line too long > (80 > 79 characters) > ./ipatests/test_integration/test_caless.py:1035:44: E225 missing > whitespace around operator > > > 3) Isn't there a way to do this with pytest's fixtures? > >> +def server_install_teardown(func): >> + def wrapped(*args): >> + try: >> + func(*args) >> + finally: >> + args[0].uninstall_server() >> + return wrapped >> + >> +def replica_install_teardown(func): >> + def wrapped(*args): >> + try: >> + func(*args) >> + finally: >> + # Uninstall replica >> + replica = args[0].replicas[0] >> + tasks.kinit_admin(args[0].master) >> + args[0].uninstall_server(replica) >> + args[0].master.run_command(['ipa-replica-manage', 'del', >> + replica.hostname, '--force'], >> + raiseonerr=False) >> + args[0].master.run_command(['ipa', 'host-del', >> + replica.hostname], >> + raiseonerr=False) >> + return wrapped >> + > > 4) Is it necessary to create the $TEST_DIR in the test? Isn't it created > by the framework? > >> + host.transport.mkdir_recursive(host.config.test_dir) > > > 5) I don't think the comment match the code. > >> >> + # Remove CA cert in /etc/pki/nssdb, in case of failed >> (un)install >> + for host in cls.get_all_hosts(): >> + cls.uninstall_server(host) >> + >> super(CALessBase, cls).uninstall(mh) > > > 6) No! Create list with one element, iterate that list and append every > item to the other list. Maybe there's better way (Hint: append). > I've seen this on multiple places. > >> if unattended: >> args.extend(['-U']) > > 7) Why don't you (extend and) use > ipatests.test_integaration.tasks.(un)install_{master,replica}? > This could be done pretty much all over the code. > >> host.run_command(['ipa-server-install', '--uninstall', '-U']) > > 8) Use ipaplatform.paths for certutil and other binaries. If the binary > is not there feel free to add it. > I've seen this on multiple places. > >> + host.run_command(['certutil', '-d', paths.NSS_DB_DIR, '-D', >> + '-n', 'External CA cert'], >> + raiseonerr=False) >> + # A workaround forhttps://fedorahosted.org/freeipa/ticket/4639 >> + result = host.run_command(['certutil', '-L', '-d', >> + paths.HTTPD_ALIAS_DIR]) >> + for rawcert in result.stdout_text.split('\n')[4: -1]: >> + cert = rawcert.split(' ')[0] >> + host.run_command(['certutil', '-D', '-d', >> paths.HTTPD_ALIAS_DIR, >> + '-n', cert]) >> > > 9) certmonger is system service. You can check if is is .enabled() and > .running(). And IIUC the comment is negation of what the code does. > >> >> # Verify certmonger was not started >> result = host.run_command(['getcert', 'list'], >> raiseonerr=False) >> - assert result > 0 >> - assert ('Please verify that the certmonger service has >> been ' >> - 'started.' in result.stdout_text), >> result.stdout_text >> + assert result.returncode == 0 > > 10) What is the point of calling uninstall_server() when it will be > called in the finally block of server_install_teardown anyway? > >> + @server_install_teardown >> def test_revoked_http(self): >> "IPA server install with revoked HTTP certificate" >> >> if result.returncode == 0: >> + self.uninstall_server() >> raise nose.SkipTest( >> "Known CA-less installation defect, see " >> +"https://fedorahosted.org/freeipa/ticket/4270") >> >> assert result.returncode > 0 >> > > Nitpick) Do not mix fixing typos/grammar/spelling/style with functional > changes. > >> - def test_incorect_http_pin(self): >> + @pytest.mark.xfail(reason='freeipa ticket 5378') >> + def test_incorrect_http_pin(self): >> "Install new HTTP certificate with incorrect PKCS#12 password" > > I forget to mention the most important problem: 0) It does not work. ============================= test session starts ============================== platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: multihost, sourceorder collected 88 items test_integration/test_caless.py F..xFF.FFFFxFFx.FFF.FFxF.FF.EEExEEEEsEExEEExEEsEExEEEEFEEEEEEEExxEEEEEEEEEEEEExxEEEEEEEE -- David Kupka From ofayans at redhat.com Wed Apr 20 10:01:10 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 20 Apr 2016 12:01:10 +0200 Subject: [Freeipa-devel] [PATCH] ca-less tests updated In-Reply-To: <571751F7.7030504@redhat.com> References: <56337745.109@redhat.com> <563B091B.3010501@redhat.com> <563B6A96.8090606@redhat.com> <563BABEC.8080304@redhat.com> <563C5B1A.1090803@redhat.com> <563C5E6D.4060307@redhat.com> <563CA575.1030808@redhat.com> <567176A2.1000901@redhat.com> <5707C431.6070702@redhat.com> <570E1E70.6060309@redhat.com> <5715F6B5.3070003@redhat.com> <57173F56.5020308@redhat.com> <571751F7.7030504@redhat.com> Message-ID: <57175366.7030403@redhat.com> Hi David, On 04/20/2016 11:55 AM, David Kupka wrote: > On 20/04/16 10:35, David Kupka wrote: >> On 19/04/16 11:13, Oleg Fayans wrote: >>> OK, that one, though passing lint, did not actually work. I gave up my >>> attempts to define method decorators inside the class. Now it passes >>> lint AND works:) >>> >> >> Hi Oleg! >> >> 1) Current commit message is useless. Please use it to describe what is >> the point of the patch. >> >> 2) $ git show -U0 | pep8 --diff >> ./ipatests/test_integration/test_caless.py:66:1: E302 expected 2 blank >> lines, found 1 >> ./ipatests/test_integration/test_caless.py:74:1: E302 expected 2 blank >> lines, found 1 >> ./ipatests/test_integration/test_caless.py:820:5: E303 too many blank >> lines (2) >> ./ipatests/test_integration/test_caless.py:825:80: E501 line too long >> (80 > 79 characters) >> ./ipatests/test_integration/test_caless.py:1035:44: E225 missing >> whitespace around operator >> >> >> 3) Isn't there a way to do this with pytest's fixtures? >> >>> +def server_install_teardown(func): >>> + def wrapped(*args): >>> + try: >>> + func(*args) >>> + finally: >>> + args[0].uninstall_server() >>> + return wrapped >>> + >>> +def replica_install_teardown(func): >>> + def wrapped(*args): >>> + try: >>> + func(*args) >>> + finally: >>> + # Uninstall replica >>> + replica = args[0].replicas[0] >>> + tasks.kinit_admin(args[0].master) >>> + args[0].uninstall_server(replica) >>> + args[0].master.run_command(['ipa-replica-manage', 'del', >>> + replica.hostname, '--force'], >>> + raiseonerr=False) >>> + args[0].master.run_command(['ipa', 'host-del', >>> + replica.hostname], >>> + raiseonerr=False) >>> + return wrapped >>> + >> >> 4) Is it necessary to create the $TEST_DIR in the test? Isn't it created >> by the framework? >> >>> + host.transport.mkdir_recursive(host.config.test_dir) >> >> >> 5) I don't think the comment match the code. >> >>> >>> + # Remove CA cert in /etc/pki/nssdb, in case of failed >>> (un)install >>> + for host in cls.get_all_hosts(): >>> + cls.uninstall_server(host) >>> + >>> super(CALessBase, cls).uninstall(mh) >> >> >> 6) No! Create list with one element, iterate that list and append every >> item to the other list. Maybe there's better way (Hint: append). >> I've seen this on multiple places. >> >>> if unattended: >>> args.extend(['-U']) >> >> 7) Why don't you (extend and) use >> ipatests.test_integaration.tasks.(un)install_{master,replica}? >> This could be done pretty much all over the code. >> >>> host.run_command(['ipa-server-install', '--uninstall', '-U']) >> >> 8) Use ipaplatform.paths for certutil and other binaries. If the binary >> is not there feel free to add it. >> I've seen this on multiple places. >> >>> + host.run_command(['certutil', '-d', paths.NSS_DB_DIR, '-D', >>> + '-n', 'External CA cert'], >>> + raiseonerr=False) >>> + # A workaround forhttps://fedorahosted.org/freeipa/ticket/4639 >>> + result = host.run_command(['certutil', '-L', '-d', >>> + paths.HTTPD_ALIAS_DIR]) >>> + for rawcert in result.stdout_text.split('\n')[4: -1]: >>> + cert = rawcert.split(' ')[0] >>> + host.run_command(['certutil', '-D', '-d', >>> paths.HTTPD_ALIAS_DIR, >>> + '-n', cert]) >>> >> >> 9) certmonger is system service. You can check if is is .enabled() and >> .running(). And IIUC the comment is negation of what the code does. >> >>> >>> # Verify certmonger was not started >>> result = host.run_command(['getcert', 'list'], >>> raiseonerr=False) >>> - assert result > 0 >>> - assert ('Please verify that the certmonger service has >>> been ' >>> - 'started.' in result.stdout_text), >>> result.stdout_text >>> + assert result.returncode == 0 >> >> 10) What is the point of calling uninstall_server() when it will be >> called in the finally block of server_install_teardown anyway? >> >>> + @server_install_teardown >>> def test_revoked_http(self): >>> "IPA server install with revoked HTTP certificate" >>> >>> if result.returncode == 0: >>> + self.uninstall_server() >>> raise nose.SkipTest( >>> "Known CA-less installation defect, see " >>> +"https://fedorahosted.org/freeipa/ticket/4270") >>> >>> assert result.returncode > 0 >>> >> >> Nitpick) Do not mix fixing typos/grammar/spelling/style with functional >> changes. >> >>> - def test_incorect_http_pin(self): >>> + @pytest.mark.xfail(reason='freeipa ticket 5378') >>> + def test_incorrect_http_pin(self): >>> "Install new HTTP certificate with incorrect PKCS#12 password" >> >> > > I forget to mention the most important problem: > > 0) It does not work. > ============================= test session starts > ============================== > platform linux2 -- Python 2.7.11 -- py-1.4.30 -- pytest-2.7.3 > rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini > plugins: multihost, sourceorder > collected 88 items > > test_integration/test_caless.py > F..xFF.FFFFxFFx.FFF.FFxF.FF.EEExEEEEsEExEEExEEsEExEEEEFEEEEEEEExxEEEEEEEEEEEEExxEEEEEEEE This looks like a configuration issue. May I take a look at your setup? > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From dkupka at redhat.com Wed Apr 20 11:27:11 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 20 Apr 2016 13:27:11 +0200 Subject: [Freeipa-devel] [PATCH 0461] Limit max username lenght to 255 in config-mod In-Reply-To: <5710EFAB.8060507@redhat.com> References: <570FBB79.5010704@redhat.com> <5710CE00.30409@redhat.com> <5710CFB6.8020307@redhat.com> <5710E685.8080005@redhat.com> <5710EFAB.8060507@redhat.com> Message-ID: <5717678F.5080601@redhat.com> On 15/04/16 15:42, Martin Basti wrote: > > > On 15.04.2016 15:03, Petr Vobornik wrote: >> On 04/15/2016 01:25 PM, Martin Basti wrote: >>> >>> On 15.04.2016 13:18, David Kupka wrote: >>>> On 14/04/16 17:47, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5774 >>>>> >>>>> Patch attached. >>>>> >>>>> >>>> Hi, >>>> works for me, ACK. >>>> >>>> FYI: While trying this I've hit related issue >>>> (https://fedorahosted.org/freeipa/ticket/5822) but I believe the >>>> impact is minimal. >>> Pushed to master: 93871bf017e1bc5f2c176aa3419278d49fcc003b >>> >> API.txt and version was not updated: >> >> -option: Int('ipamaxusernamelength', attribute=True, autofill=False, >> cli_name='maxusername', minvalue=1, multivalue=False, required=False) >> +option: Int('ipamaxusernamelength', attribute=True, autofill=False, >> cli_name='maxusername', maxvalue=255, minvalue=1, multivalue=False, >> required=False) >> > Sorry. > > Patch attached. Sorry, I haven't noticed this. I remember that previously this type of errors aborted build. Why was this changed? Anyway, the patch fixes it, ACK. -- David Kupka From mbasti at redhat.com Wed Apr 20 11:31:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Apr 2016 13:31:06 +0200 Subject: [Freeipa-devel] [PATCH 0461] Limit max username lenght to 255 in config-mod In-Reply-To: <5717678F.5080601@redhat.com> References: <570FBB79.5010704@redhat.com> <5710CE00.30409@redhat.com> <5710CFB6.8020307@redhat.com> <5710E685.8080005@redhat.com> <5710EFAB.8060507@redhat.com> <5717678F.5080601@redhat.com> Message-ID: <5717687A.70503@redhat.com> On 20.04.2016 13:27, David Kupka wrote: > On 15/04/16 15:42, Martin Basti wrote: >> >> >> On 15.04.2016 15:03, Petr Vobornik wrote: >>> On 04/15/2016 01:25 PM, Martin Basti wrote: >>>> >>>> On 15.04.2016 13:18, David Kupka wrote: >>>>> On 14/04/16 17:47, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5774 >>>>>> >>>>>> Patch attached. >>>>>> >>>>>> >>>>> Hi, >>>>> works for me, ACK. >>>>> >>>>> FYI: While trying this I've hit related issue >>>>> (https://fedorahosted.org/freeipa/ticket/5822) but I believe the >>>>> impact is minimal. >>>> Pushed to master: 93871bf017e1bc5f2c176aa3419278d49fcc003b >>>> >>> API.txt and version was not updated: >>> >>> -option: Int('ipamaxusernamelength', attribute=True, autofill=False, >>> cli_name='maxusername', minvalue=1, multivalue=False, required=False) >>> +option: Int('ipamaxusernamelength', attribute=True, autofill=False, >>> cli_name='maxusername', maxvalue=255, minvalue=1, multivalue=False, >>> required=False) >>> >> Sorry. >> >> Patch attached. > > Sorry, I haven't noticed this. I remember that previously this type of > errors aborted build. Why was this changed? > > Anyway, the patch fixes it, ACK. > > Pushed to master: 3dc3d7a61068098e556e6b65b4a56b364a5323dd From pvomacka at redhat.com Wed Apr 20 14:10:36 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 20 Apr 2016 16:10:36 +0200 Subject: [Freeipa-devel] [PATCH] 0009 webui: Show certificates in useful format In-Reply-To: <5710EFDF.9080508@redhat.com> References: <56E7FEA8.3010404@redhat.com> <56E99E3A.3040200@redhat.com> <56FA4E21.3040504@redhat.com> <56FBAE6A.6040008@redhat.com> <5710EFDF.9080508@redhat.com> Message-ID: <57178DDC.2010703@redhat.com> On 04/15/2016 03:42 PM, Petr Vobornik wrote: > On 03/30/2016 12:46 PM, Pavel Vomacka wrote: >> >> On 03/29/2016 11:42 AM, Pavel Vomacka wrote: >>> >>> On 03/16/2016 06:56 PM, Petr Vobornik wrote: >>>> On 03/15/2016 01:23 PM, Pavel Vomacka wrote: >>>>> Hello, >>>>> >>>>> patch for https://fedorahosted.org/freeipa/ticket/5311 is attached. >>>>> >>>>> -- >>>>> Pavel^3 Vomacka >>>>> >>>> Not tested, but can we avoid using
s with "white-space: pre" and >>>> therefore use only IPA.cert.pem_cert_format(text). >>>> >>>> Also, it should be displayed in monospaced, so probably add: >>>> >>>> .certificate-widget .certificate { >>>> font-family: monospace; >>>> overflow-x: auto; >>>> white-space: pre; >>>> } >>> Fixed. >>>> >>>> Probably as a separate patch or ticket: we can add "download" button which >>>> would offer the certificate in form of data uri[1] with 'download' attribute >>>> of 'a' element [2]. So user will get pem encoded file without any hassle. >>>> >>>> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/data_URIs >>>> [2] https://developer.mozilla.org/en/docs/Web/HTML/Element/a >>> The download button is really good idea. There is attached another patch which >>> adds this button. If we need new ticket let me know and I will file it. >>> >>> -- >>> Pavel^3 Vomacka >>> >>> >> Self NACK, css parts should be moved to less files. Attaching new patches. >> > patch 9-3: ACK > > patch 10-2: > > 1. Use @font-family-base variable (defined in variable.less) for the > font-family value > + a { > + font-family: 'Open Sans', Helvetica, Arial, sans-serif; > + float: right; > + } > > > 2. Wouldn't it be better to put the download button next to the show > button? Or maybe in the actions menu which is planned in the next patches? > Yes, I would say that the best would be to leave this part to the planned actions menu as you wrote above. Actually, this whole ticket will be fixed in ticket #5381. From pviktori at redhat.com Wed Apr 20 14:13:28 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 20 Apr 2016 16:13:28 +0200 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160420041143.GA4140@mniranja.pnq.csb> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> Message-ID: <57178E88.40207@redhat.com> On 04/20/2016 06:11 AM, Niranjan wrote: > Petr Viktorin wrote: >> On 04/18/2016 12:39 PM, Niranjan wrote: >>> Niranjan wrote: >>>> Niranjan wrote: >>>>> Petr Viktorin wrote: >>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed >>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would >>>>>>> like to get more inputs on how to use pytest-multihost to execute commands >>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be >>>>>>> installed. >>>>>> >>>>>> Wow. I'm surprised the only problem on Windows is the "set -e". >>>>>> >>>>>> Regarding the patch: >>>>>> >>>>>> - Why is get_winhost_class needed? I don't see it called anywhere. >>>>>> - Similarly, why is host_type needed? Your patch only sets it. >>>>>> >>>>>> If run_command of WinHost and Unix hosts are this similar, I would put >>>>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class >>>>>> attribute named e.g. "command_prelude", use it in run_command, and move >>>>>> run_command from Host to BaseHost. >>>>>> Would that work, or am I missing something? >>>>> How do we detect the host is windows/unix then , we still need host_type >>>>> to know what the type of host is (unix/windows)? >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Viktorin >>>> Please review the attached patch. >> >> Sorry for the delay. >> >> The information about whether the host is Unix or Windows is available: >> the class is either Host or WinHost, so I don't think an extra host_type >> is necessary. >> I'd be open to adding host_type as *configuration* (and corresponding >> attribute) if it also selected the actual Host class. Currently to use >> WinHost you need to write custom code. > I would like to have host_type available. We would like to add more > functions in classes that override Host/WinHost class , which > can be then called depending upon the host_type. Ah, I see; you're not using the WinHost subclass right now. I added a host_type; it is used to select the Host class. You can define a "host_classes" dict in your Domain class to list Host classes, and the particular Host class will be selected according to the host_type. The usage would be like this: --------- class QeHost(QeBaseHost): """Linux host class""" @classmethod def gethostname(self): """ Return system hostname """ cmd = self.run_command(['hostname'], raiseonerr=False) return cmd.stdout_text.strip() ... class QeWinHost(QeBaseHost, pytest_multihost.host.WinHost): """Windows host class""" @classmethod def gethostname(self): """ Return system hostname """ cmd = self.run_command(['hostname', '-A'], set_env=False, raiseonerr=False) return cmd.stdout_text.strip() ... class QeDomain: ... host_classes = {'default': QeHost, 'windows': QeWinHost} # remove your existing "get_host_class" method when host_classes is defined ... --------- And in the config, define host_type to 'windows'. Would it work for you like this? -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-host_type-make-it-possible-to-use-Windows-hosts.patch Type: text/x-patch Size: 8132 bytes Desc: not available URL: From mbasti at redhat.com Wed Apr 20 14:57:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Apr 2016 16:57:08 +0200 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command Message-ID: <571798C4.5040200@redhat.com> https://fedorahosted.org/freeipa/ticket/5281 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0463-Performace-don-t-download-password-attributes-in-hos.patch Type: text/x-patch Size: 1947 bytes Desc: not available URL: From mbasti at redhat.com Wed Apr 20 15:27:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Apr 2016 17:27:16 +0200 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <56F3EB49.7090701@redhat.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> Message-ID: <57179FD4.5070904@redhat.com> On 24.03.2016 14:27, Martin Basti wrote: > > > On 24.03.2016 13:55, Jan Cholasta wrote: >> On 18.3.2016 23:27, Timo Aaltonen wrote: >>> On 17.03.2016 18:36, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5681 >>> >>> would be nicer if ipa-httpd.conf was a template with the current >>> hardcoded values replaced with platform paths.. >> >> +1, I would also prefer if the file was renamed to >> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. > ipa-httpd.conf.template should be in /user/share/ipa, directory > init/systemd copied only to rpm and then copied to /etc/systemd/system > AFAIK > >> >>> >>> >>> not relevant to this patch, but there are others candidates for >>> templates like: >>> >>> daemons/dnssec/ipa-dnskeysyncd.service >>> daemons/dnssec/ipa-ods-exporter.service >>> install/conf/ipa.conf >> > Updated patch attached, sorry for delay. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0441.2-Configure-httpd-service-from-installer-instead-of-di.patch Type: text/x-patch Size: 9813 bytes Desc: not available URL: From mbasti at redhat.com Wed Apr 20 15:49:27 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Apr 2016 17:49:27 +0200 Subject: [Freeipa-devel] [PATCHES 0464-0468] always set hostname during installation Message-ID: <5717A507.8050707@redhat.com> https://fedorahosted.org/freeipa/ticket/5794 It requires my patch 441.2 Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0464-Always-set-hostname.patch Type: text/x-patch Size: 10698 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0465-Remove-deprecated-hostname-restoration-from-Fedora18.patch Type: text/x-patch Size: 3263 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0466-Remove-unused-hostname-variables.patch Type: text/x-patch Size: 1180 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0467-Log-errors-from-backup_and_replace-hostname-to-logge.patch Type: text/x-patch Size: 1282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0468-Tasks-raise-NotImplementedError-for-not-implemented-.patch Type: text/x-patch Size: 4749 bytes Desc: not available URL: From mbasti at redhat.com Wed Apr 20 15:53:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Apr 2016 17:53:32 +0200 Subject: [Freeipa-devel] [PATCH] Added description related to 'status' in ipactl man page In-Reply-To: <5714A0EB.8050102@redhat.com> References: <5710D3EB.7040500@redhat.com> <5714A0EB.8050102@redhat.com> Message-ID: <5717A5FC.60407@redhat.com> On 18.04.2016 10:55, Petr Spacek wrote: > On 15.4.2016 13:43, Abhijeet Kasurde wrote: >> Hi All, >> >> Please review these patches. >> >> Fixes: https://fedorahosted.org/freeipa/ticket/5768 > LGTM > Works for me, ACK pushed to * master: 5b81435ae2422ae5c8afe26ec40eaf8b36d18359 Added description related to 'status' in ipactl man page * ipa-4-3: e9a0e37332d4803ec0ea9be27914a72b83569043 Added description related to 'status' in ipactl man page From pvomacka at redhat.com Wed Apr 20 15:59:41 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 20 Apr 2016 17:59:41 +0200 Subject: [Freeipa-devel] [PATCH] 0015, 16 webui: Add 'Skip overlap check' checkbox to the dns adder dialogs In-Reply-To: <570F871C.1070209@redhat.com> References: <570F7904.6000908@redhat.com> <570F871C.1070209@redhat.com> Message-ID: <5717A76D.3020000@redhat.com> On 04/14/2016 02:03 PM, Martin Basti wrote: > > > On 14.04.2016 13:03, Pavel Vomacka wrote: >> Hello, >> >> The first patch (0015) adds the checkbox to the dns zone adder dialog. >> >> The second patch (0016) adds the 'skip overlap check' checkbox to the >> dns forward zone adder dialog. This patch requires the previous one. >> The patch 0016 might not be used in case that the dns forward zone >> dialog shouldn't contain that checkbox. >> >> -- >> Pavel^3 Vomacka >> >> > Can we add hint to webUI what 'skip overlap check' means? Maybe > description from ipa dns[forward]zone-add --help. > > Martin^2 > > Yes, it is included in these new pathes. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0015-2-Add-skip-overlap-check-checkbox-into-add-zone-dialog.patch Type: text/x-patch Size: 3017 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0016-2-Add-skip-overlap-check-checkbox-to-the-add-dns-forwa.patch Type: text/x-patch Size: 1260 bytes Desc: not available URL: From mbasti at redhat.com Wed Apr 20 16:00:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Apr 2016 18:00:18 +0200 Subject: [Freeipa-devel] [TEST][patch-0033] Added assertion errors to topology tests, track N 5772 In-Reply-To: <570D0311.5040305@redhat.com> References: <56FCF65C.8000709@redhat.com> <56FCF6F3.9040007@redhat.com> <56FD05C3.6010305@redhat.com> <56FD3F17.8000507@redhat.com> <57029A79.8080408@redhat.com> <570503B4.9010702@redhat.com> <570D0311.5040305@redhat.com> Message-ID: <5717A792.6000801@redhat.com> On 12.04.2016 16:15, Martin Babinsky wrote: > On 04/06/2016 02:40 PM, Oleg Fayans wrote: >> Hi Martin, >> >> The updated patches are attached >> >> On 04/04/2016 06:46 PM, Martin Babinsky wrote: >>> On 03/31/2016 05:15 PM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review. The updated patch(es) are included >>>> >>>> Testrun output can be found here: >>>> >>>> http://fpaste.org/347800/59421745/ >>>> >>>> On 03/31/2016 01:10 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 31.03.2016 12:07, Oleg Fayans wrote: >>>>>> Please, disregard it for a while, it does not pass lint. >>>>>> >>>>>> On 03/31/2016 12:05 PM, Oleg Fayans wrote: >>>>>>> >>>>>>> >>>>> NACK >>>>> >>>>> Please send unrelated changes in separate patches. I do not see >>>>> relation >>>>> between changing variable names, adding assertion messages and >>>>> setting >>>>> replication sleep-a-bit wait. >>>> >>>> Agreed. There are two necessary bugfixes for the testsuite to run. >>>> They >>>> were put into a separate patch >>>> >>>>> >>>>> IMO to the ticket in the patch only assertion changes are related. >>>>> >>>>> For the pylint related errors: >>>>> assert ('any value', 'in tuple') >>>>> is always true. >>>>> right syntax is >>>>> assert (any test), ('error msg') >>>> >>>> thank you! >>>> >>>>> >>>>> Martin^2 >>>> >>>> >>>> >>> Hi Oleg, >>> >>> Patch 0033: >>> >>> 1.) >>> First of all, the commit message does not tell much about what the >>> patch >>> does, I would prefer something like "Improve reporting of failed tests >>> in topology test suite". >> >> Done >> >>> >>> 2.) Since what you are doing is basically comparing the contents of a >>> list of dicts containing expected data with a list of dicts with data >>> parsed from test results, why are you not using "assert_deepequal" >>> function from 'ipatests/util.py' module? It is also used in e.g. XMLRPC >>> tests and it reports the failures fairly well (e.g. redundant keys, >>> missing keys, expected value mismatch, container length mismatch etc.) >> >> Indeed :) Done. >> >>> >>> Patch 034: >>> >>> I think this is a good use case for 'wait_for_replication' function >>> from >>> 'ipatests/test_integration/tasks.py' module. You need to establish LDAP >>> connection to the host but this is very easy, see how it's done in >>> 'test_simple_replication' suite[1]. >>> >>> I would prefer this approach (if applicable) instead of using sleep(). >> >> Implemented. >> >>> >>> In any way, your formatting of assertions is wrong and makes the code >>> nearly unreadable. See the attached patch for an example of pep8 >>> compliant and pleasant formatting >> >> Thank you, that looks really way more readable. >> >>> >>> [1] >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_integration/test_simple_replication.py#n42 >>> >>> >>> >>> >>> >> > > Thanks, ACK. > Pushed master: * 1974f20aec8de61d0e8d5a550df6a5fabd4b383a Improve reporting of failed tests in topology test suite * 1c79c1ea2d077d8699c7e3190526a45e627a7a18 Bugfixes in managed topology tests ipa-4-3: * b41164f237341ccf2546b73585e804aac4cffc8e Improve reporting of failed tests in topology test suite * 10e9e33ac057d5ad4e42cd7207b7203ce1d100d1 Bugfixes in managed topology tests From mbasti at redhat.com Wed Apr 20 16:08:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 20 Apr 2016 18:08:13 +0200 Subject: [Freeipa-devel] [PATCH] 0050 caacl: correctly handle full user principal name In-Reply-To: <20160314051824.GX4492@redhat.com> References: <20160314040417.GH12127@dhcp-40-8.bne.redhat.com> <20160314051824.GX4492@redhat.com> Message-ID: <5717A96D.2070407@redhat.com> On 14.03.2016 06:18, Alexander Bokovoy wrote: > On Mon, 14 Mar 2016, Fraser Tweedale wrote: >> The attached patch fixes >> https://fedorahosted.org/freeipa/ticket/5733. Thanks to Alexander >> for finding and reporting. >> >> Cheers, >> Fraser > >> From 9bd7b74d9c928f386bd7dae59588580881ed1a9d Mon Sep 17 00:00:00 2001 >> From: Fraser Tweedale >> Date: Mon, 14 Mar 2016 14:49:47 +1100 >> Subject: [PATCH] caacl: correctly handle full user principal name >> >> The caacl HBAC request is correct when just the username is given, >> but the full 'user at REALM' form was not handled correctly. >> >> Fixes: https://fedorahosted.org/freeipa/ticket/5733 > A context might be helpful here: if you are using certmonger's -K option > to specify a user principal name to add to certificate, the name will > get normalized to include the realm. This is how it gets to caacl check. > > ACK. > Pushed to: master: c2b92b57354923a8099a0da446cef63802d2447b ipa-4-3: 90ca7d4167d25f50b36322a817f1f62930a7ea58 ipa-4-2: 8a8ee89cf738a3cdae848bd9db4d358d94da6d26 From pvomacka at redhat.com Wed Apr 20 17:05:35 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 20 Apr 2016 19:05:35 +0200 Subject: [Freeipa-devel] [PATCH] 0013, 0017 webui: Add ability to convert users from preserved to staged state In-Reply-To: <57111A54.5070005@redhat.com> References: <570E4210.1090409@redhat.com> <57111A54.5070005@redhat.com> Message-ID: <5717B6DF.2010000@redhat.com> On 04/15/2016 06:44 PM, Petr Vobornik wrote: > On 04/13/2016 02:56 PM, Pavel Vomacka wrote: >> Hello, >> >> This patch adds ability to convert users from preserved to staged state. >> >> Fixes this ticket: https://fedorahosted.org/freeipa/ticket/5371 >> >> -- >> Pavel^3 Vomacka >> >> > The patch requires rebase. Attached rebased patches. I split this one patch into two patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0013-2-Add-ability-to-stage-multiple-users.patch Type: text/x-patch Size: 5660 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0017-Add-option-to-stage-user-from-details-page.patch Type: text/x-patch Size: 5429 bytes Desc: not available URL: From ftweedal at redhat.com Thu Apr 21 03:30:04 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 Apr 2016 13:30:04 +1000 Subject: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication In-Reply-To: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> References: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> Message-ID: <20160421033003.GH18277@dhcp-40-8.bne.redhat.com> On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > Hi all, > > The attached patches configure lightweight CA key replication on IPA > CAs, on upgrade and installation. > > Patches 0051..0052 from my other mail are also needed for the system > to work, but this patchset does not depend on them and can be > reviewed independently. > > There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > - it just puts the necessary principals/keys/configuration in place. > > Cheers, > Fraser > New patches attached; 0054-2 changes the service name from 'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the principal to search server Custodia keys. Cheers, Fraser -------------- next part -------------- From b30e8d640a03ec81d5a1f962a81076993d9cea69 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Apr 2016 12:42:35 +1000 Subject: [PATCH 53/54] Optionally add service name to Custodia key DNs Lightweight CAs support introduces new service principals for Dogtag, with Custodia keys. The current Custodia key creation uses a DN that contains only they key type and the hostname, so keys for multiple services on the same host cannot be created. Add the 'generate_keys' method to generate keys for a host or an arbitrary service. When a service name is given, include the service name in the DN. This change does not affect searching because all searching is done using the ipaKeyUsage and memberPrincipal attributes. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipapython/secrets/kem.py | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py index 1025ed7980f055c82c602634e8845fa490cf0514..533121779241d30e19fef4c050bb69c55d29ec22 100644 --- a/ipapython/secrets/kem.py +++ b/ipapython/secrets/kem.py @@ -105,10 +105,11 @@ class KEMLdap(iSecLdap): encoding=serialization.Encoding.DER, format=serialization.PublicFormat.SubjectPublicKeyInfo) - def set_key(self, usage, host, principal, key): + def set_key(self, usage, servicename, host, principal, key): public_key = self._format_public_key(key) conn = self.connect() - name = '%s/%s' % (KEY_USAGE_MAP[usage], host) + service_segment = '~' + servicename if servicename else '' + name = '%s%s/%s' % (KEY_USAGE_MAP[usage], service_segment, host) dn = 'cn=%s,%s' % (name, self.keysbase) try: mods = [('objectClass', ['nsContainer', @@ -170,15 +171,18 @@ class IPAKEMKeys(KEMKeysStore): return conn.get_key(usage, kid) def generate_server_keys(self): - principal = 'host/%s@%s' % (self.host, self.realm) + self.generate_keys() + + def generate_keys(self, servicename=None): + principal = '%s/%s@%s' % (servicename or 'host', self.host, self.realm) # Neutralize the key with read if any self._server_keys = None # Generate private key and store it pubkeys = newServerKeys(self.config['server_keys'], principal) # Store public key in LDAP ldapconn = KEMLdap(self.ldap_uri) - ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) - ldapconn.set_key(KEY_USAGE_ENC, self.host, principal, pubkeys[1]) + ldapconn.set_key(KEY_USAGE_SIG, servicename, self.host, principal, pubkeys[0]) + ldapconn.set_key(KEY_USAGE_ENC, servicename, self.host, principal, pubkeys[1]) @property def server_keys(self): -- 2.5.5 -------------- next part -------------- From 8fa16b34e9c866d2f2470d70cb4b265e28013a16 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Apr 2016 16:47:33 +1000 Subject: [PATCH 54/54] Setup lightweight CA key retrieval on install/upgrade To configure Dogtag lightweight CA key replication on installation and upgrade: - add the 'dogtag/$HOSTNAME' service principal - create the pricipal's Custodia keys - add ACI to allow the principal to read server Custodia keys - retrieve keytab - configure the IPACustodiaKeyRetriever in CS.cfg Part of: https://fedorahosted.org/freeipa/ticket/4559 --- install/tools/ipa-ca-install | 4 ++++ install/updates/20-aci.update | 3 +++ ipaplatform/base/constants.py | 1 + ipaserver/install/cainstance.py | 43 +++++++++++++++++++++++++++++++++++++ ipaserver/install/server/install.py | 8 ++++++- ipaserver/install/server/upgrade.py | 6 +++++- 6 files changed, 63 insertions(+), 2 deletions(-) diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install index 1bc5def03bf687a1e4f9fb38a54363b5429c8fc4..0af5b39116b4649423ed2a51579e2adc767d802b 100755 --- a/install/tools/ipa-ca-install +++ b/install/tools/ipa-ca-install @@ -226,6 +226,10 @@ def install_master(safe_options, options): ca.install_check(True, None, options) ca.install(True, None, options) + CA = cainstance.CAInstance( + api.env.realm, certs.NSS_DIR, host_name=api.env.host) + CA.setup_lightweight_ca_key_retrieval() + def install(safe_options, options, filename): options.promote = False diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index 4802ae0458e8b870bf3127764ebabac1a48f7cf2..2e9a36da442c392c9161861615b1744eeb6b799c 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -136,3 +136,6 @@ add:aci: (target = "ldap:///cn=replication,cn=etc,$SUFFIX")(targetattr = "nsDS5R dn: cn=ipa,cn=etc,$SUFFIX add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia secrets"; allow(write) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX" and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) + +# Dogtag service principals can search Custodia keys +add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal")(version 3.0; acl "Dogtag service principals can search Custodia keys"; allow(read, search, compare) userdn = "ldap:///krbprincipalname=dogtag/*@$REALM,cn=services,cn=accounts,$SUFFIX";) diff --git a/ipaplatform/base/constants.py b/ipaplatform/base/constants.py index 3e1c4c6f761444bf1e8d527691aa53282e46f17e..26a9799838a2b3fb2d5ebab9e5e3cf7c4ba041ef 100644 --- a/ipaplatform/base/constants.py +++ b/ipaplatform/base/constants.py @@ -17,6 +17,7 @@ class BaseConstantsNamespace(object): NAMED_GROUP = "named" PKI_USER = 'pkiuser' PKI_GROUP = 'pkiuser' + PKI_GSSAPI_SERVICE_NAME = 'dogtag' # ntpd init variable used for daemon options NTPD_OPTS_VAR = "OPTIONS" # quote used for daemon options diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index a21f7d2671461dfb99797d39fc7ee5706317241f..7e1aaf5d7ae5744d043787d1b5d3ab6bf6fc7333 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -59,6 +59,7 @@ from ipapython.certdb import get_ca_nickname from ipapython.dn import DN from ipapython.ipa_log_manager import log_mgr,\ standard_logging_setup, root_logger +from ipapython.secrets.kem import IPAKEMKeys from ipaserver.install import certs from ipaserver.install import dsinstance @@ -66,6 +67,7 @@ from ipaserver.install import installutils from ipaserver.install import ldapupdate from ipaserver.install import replication from ipaserver.install import service +from ipaserver.install import sysupgrade from ipaserver.install.dogtaginstance import (export_kra_agent_pem, DogtagInstance) from ipaserver.plugins import ldap2 @@ -1356,11 +1358,52 @@ class CAInstance(DogtagInstance): self.step("updating IPA configuration", update_ipa_conf) self.step("Restart HTTP server to pick up changes", self.__restart_http_instance) + self.step("Configure lightweight CA key retrieval", + self.setup_lightweight_ca_key_retrieval) self.step("enabling CA instance", self.__enable_instance) self.start_creation(runtime=210) + def setup_lightweight_ca_key_retrieval(self): + if sysupgrade.get_upgrade_state('dogtag', 'setup_lwca_key_retrieval'): + return + + root_logger.info('[Set up lightweight CA key retrieval]') + + service = constants.PKI_GSSAPI_SERVICE_NAME + principal = '{}/{}@{}'.format(service, api.env.host, self.realm) + pent = pwd.getpwnam(constants.PKI_USER) + + root_logger.info('Creating principal') + installutils.kadmin_addprinc(principal) + self.suffix = ipautil.realm_to_suffix(self.realm) + if not self.admin_conn: + self.ldap_connect() + self.move_service(principal) + + root_logger.info('Retrieving keytab') + keytab = os.path.join(paths.PKI_TOMCAT, service + '.keytab') + installutils.create_keytab(keytab, principal) + os.chmod(keytab, 0o600) + os.chown(keytab, pent.pw_uid, pent.pw_gid) + + root_logger.info('Creating Custodia keys') + keyfile = os.path.join(paths.PKI_TOMCAT, service + '.keys') + keystore = IPAKEMKeys({'server_keys': keyfile}) + keystore.generate_keys(service) + os.chmod(keyfile, 0o600) + os.chown(keyfile, pent.pw_uid, pent.pw_gid) + + root_logger.info('Configuring key retriever') + installutils.set_directive( + paths.CA_CS_CFG_PATH, + 'features.authority.keyRetrieverClass', + 'com.netscape.ca.IPACustodiaKeyRetriever', + quotes=False, separator='=') + + sysupgrade.set_upgrade_state('dogtag', 'setup_lwca_key_retieval', True) + def replica_ca_install_check(config): if not config.setup_ca: diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py index f01022c4c3a056513db47f70727aa48157a8c6f2..d9fcd7e6098c1bdd7647c300695f583f43bde9e5 100644 --- a/ipaserver/install/server/install.py +++ b/ipaserver/install/server/install.py @@ -892,7 +892,8 @@ def install(installer): ca.install_step_0(False, None, options) # Now put the CA cert where other instances exepct it - ca_instance = cainstance.CAInstance(realm_name, certs.NSS_DIR) + ca_instance = cainstance.CAInstance( + realm_name, certs.NSS_DIR, host_name=host_name) ca_instance.publish_ca_cert(CACERT) else: # Put the CA cert where other instances expect it @@ -922,6 +923,11 @@ def install(installer): # generated ds.add_cert_to_service() + if setup_ca: + # CA was configured before Kerberos; + # add Custodia client princ and keys now + ca_instance.setup_lightweight_ca_key_retrieval() + memcache = memcacheinstance.MemcacheInstance() memcache.create_instance('MEMCACHE', host_name, dm_password, ipautil.realm_to_suffix(realm_name)) diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index 3e60cfd3630c359268cf16219527088b5c63ba86..cc003c7146d547b5778f4d5d8d1c4f7eedc69ec7 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1463,7 +1463,8 @@ def upgrade_configuration(): if subject_base: sub_dict['SUBJECT_BASE'] = subject_base - ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) + ca = cainstance.CAInstance( + api.env.realm, certs.NSS_DIR, host_name=api.env.host) with installutils.stopped_service('pki-tomcatd', 'pki-tomcat'): # Dogtag must be stopped to be able to backup CS.cfg config @@ -1658,6 +1659,9 @@ def upgrade_configuration(): ca_import_included_profiles(ca) add_default_caacl(ca) + if ca.is_configured(): + ca.setup_lightweight_ca_key_retrieval() + set_sssd_domain_option('ipa_server_mode', 'True') if ds_running and not ds.is_running(): -- 2.5.5 From ftweedal at redhat.com Thu Apr 21 05:19:43 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 Apr 2016 15:19:43 +1000 Subject: [Freeipa-devel] [PATCH] 0055 Authorise CA Agent to manage lightweight CAs Message-ID: <20160421051943.GK18277@dhcp-40-8.bne.redhat.com> The attached patch is part of lightweight CA support. It just adds some ACL rules to Dogtag database, and does not depend the version of Dogtag (so it's ok to merge immediately, when ACKed). Thanks, Fraser -------------- next part -------------- From 362f7f9ec385cc2625d852ccf514508e231e78db Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 21 Apr 2016 15:09:18 +1000 Subject: [PATCH] Authorise CA Agent to manage lightweight CAs Add Dogtag ACLs that authorise the CA Agent certificate to manage lightweight CAs. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipaserver/install/cainstance.py | 45 ++++++++++++++++++++++++++++++++----- ipaserver/install/server/upgrade.py | 11 +++++++++ 2 files changed, 51 insertions(+), 5 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 7e1aaf5d7ae5744d043787d1b5d3ab6bf6fc7333..54159dd052640618dd1952d1501e8acb82bb91e2 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -417,6 +417,7 @@ class CAInstance(DogtagInstance): self.step("importing RA certificate from PKCS #12 file", lambda: self.import_ra_cert(ra_p12, configure_renewal=False)) self.step("authorizing RA to modify profiles", configure_profiles_acl) + self.step("authorizing RA to manage lightweight CAs", configure_lightweight_ca_acls) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) self.step("configure certificate renewals", self.configure_renewal) if not self.clone: @@ -1635,11 +1636,6 @@ def ensure_entry(dn, **attrs): def configure_profiles_acl(): """Allow the Certificate Manager Agents group to modify profiles.""" - server_id = installutils.realm_to_serverid(api.env.realm) - dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id - updated = False - - dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) new_rules = [ 'certServer.profile.configuration:read,modify:allow (read,modify) ' 'group="Certificate Manager Agents":' @@ -1648,6 +1644,45 @@ def configure_profiles_acl(): 'certServer.ca.account:login,logout:allow (login,logout) ' 'user="anybody":Anybody can login and logout', ] + return __add_acls(new_rules) + + +def configure_lightweight_ca_acls(): + """Allow Certificate Manager Agents to manage lightweight CAs.""" + new_rules = [ + 'certServer.ca.authorities:list,read' + ':allow (list,read) user="anybody"' + ':Anybody may list and read lightweight authorities', + + 'certServer.ca.authorities:create,modify' + ':allow (create,modify) group="Administrators"' + ':Administrators may create and modify lightweight authorities', + + 'certServer.ca.authorities:delete' + ':allow (delete) group="Administrators"' + ':Administrators may delete lightweight authorities', + + 'certServer.ca.authorities:create,modify,delete' + ':allow (create,modify,delete) group="Certificate Manager Agents"' + ':Certificate Manager Agents may manage lightweight authorities', + ] + return __add_acls(new_rules) + + +def __add_acls(new_rules): + """Add the given Dogtag ACLs. + + ``new_rules`` + Iterable of ACL rule values to add + + Return ``True`` if any ACLs were added otherwise ``False``. + + """ + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + updated = False + + dn = DN(('cn', 'aclResources'), ('o', 'ipaca')) conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) if not conn.isconnected(): diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index cc003c7146d547b5778f4d5d8d1c4f7eedc69ec7..ed7e54882de947aac0088981898b0aaa926b7137 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -302,6 +302,16 @@ def ca_configure_profiles_acl(ca): return cainstance.configure_profiles_acl() +def ca_configure_lightweight_ca_acls(ca): + root_logger.info('[Authorizing RA Agent to manage lightweight CAs]') + + if not ca.is_configured(): + root_logger.info('CA is not configured') + return False + + return cainstance.configure_lightweight_ca_acls() + + def ca_enable_ldap_profile_subsystem(ca): root_logger.info('[Ensuring CA is using LDAPProfileSubsystem]') if not ca.is_configured(): @@ -1640,6 +1650,7 @@ def upgrade_configuration(): certificate_renewal_update(ca, ds, http), ca_enable_pkix(ca), ca_configure_profiles_acl(ca), + ca_configure_lightweight_ca_acls(ca), ]) if ca_restart: -- 2.5.5 From mrniranjan at fedoraproject.org Thu Apr 21 05:25:20 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Thu, 21 Apr 2016 10:55:20 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <57178E88.40207@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> <57178E88.40207@redhat.com> Message-ID: <20160421052520.GA5879@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/20/2016 06:11 AM, Niranjan wrote: > > Petr Viktorin wrote: > >> On 04/18/2016 12:39 PM, Niranjan wrote: > >>> Niranjan wrote: > >>>> Niranjan wrote: > >>>>> Petr Viktorin wrote: > >>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>>>> Greetings, > >>>>>>> > >>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>>>> installed. > >>>>>> > >>>>>> Wow. I'm surprised the only problem on Windows is the "set -e". > >>>>>> > >>>>>> Regarding the patch: > >>>>>> > >>>>>> - Why is get_winhost_class needed? I don't see it called anywhere. > >>>>>> - Similarly, why is host_type needed? Your patch only sets it. > >>>>>> > >>>>>> If run_command of WinHost and Unix hosts are this similar, I would put > >>>>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >>>>>> attribute named e.g. "command_prelude", use it in run_command, and move > >>>>>> run_command from Host to BaseHost. > >>>>>> Would that work, or am I missing something? > >>>>> How do we detect the host is windows/unix then , we still need host_type > >>>>> to know what the type of host is (unix/windows)? > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Petr Viktorin > >>>> Please review the attached patch. > >> > >> Sorry for the delay. > >> > >> The information about whether the host is Unix or Windows is available: > >> the class is either Host or WinHost, so I don't think an extra host_type > >> is necessary. > >> I'd be open to adding host_type as *configuration* (and corresponding > >> attribute) if it also selected the actual Host class. Currently to use > >> WinHost you need to write custom code. > > I would like to have host_type available. We would like to add more > > functions in classes that override Host/WinHost class , which > > can be then called depending upon the host_type. > > Ah, I see; you're not using the WinHost subclass right now. > > I added a host_type; it is used to select the Host class. > You can define a "host_classes" dict in your Domain class to list Host > classes, and the particular Host class will be selected according to the > host_type. > > The usage would be like this: > > --------- > > class QeHost(QeBaseHost): > """Linux host class""" > @classmethod > def gethostname(self): > """ Return system hostname """ > cmd = self.run_command(['hostname'], raiseonerr=False) > return cmd.stdout_text.strip() > ... > > class QeWinHost(QeBaseHost, pytest_multihost.host.WinHost): > """Windows host class""" > > @classmethod > def gethostname(self): > """ Return system hostname """ > cmd = self.run_command(['hostname', '-A'], set_env=False, > raiseonerr=False) > return cmd.stdout_text.strip() > ... > > > class QeDomain: > ... > host_classes = {'default': QeHost, 'windows': QeWinHost} > > # remove your existing "get_host_class" method when host_classes is > defined > ... > > --------- > > And in the config, define host_type to 'windows'. > > > Would it work for you like this? Most of the things worked by doing this: class QeBaseHost(pytest_multihost.host.BaseHost): """ QeBaseHost subclass of multhost plugin BaseHost class """ transport_class = transport.SSHTransport class QeHost(QeBaseHost): """ QeHost subclass of multihost plugin host class. This extends functionality of the host class for SSSD QE purposes. Here we add support functions that will be very widely used across tests and must be run on any or all hosts in the environment. """ def gethostname(self): """ Return system hostname """ cmd = self.run_command(['hostname'], raiseonerr=False) return cmd.stdout_text.strip() class QeWinHost(QeBaseHost, pytest_multihost.host.WinHost): """ Windows Host class """ @classmethod def gethostname(cls): """ Return System hostname """ cmd = cls.run_command(['hostname', '-A'], set_env=False, raiseonerr=False) return cmd.stdout_text.strip() class QeDomain(pytest_multihost.config.Domain): """ QeDomain subclass of multihost plugin domain class. """ def __init__(self, config, name, domain_type): """ Subclass of pytest_multihost.config.Domain :param obj config: config config :param str name: Name :param str domain_type: :return None: """ self.type = str(domain_type) self.config = config self.name = str(name) self.hosts = [] host_classes = {'default': QeHost, 'windows': QeWinHost} Specifically i see that you have "transport_class = transport.SSHTransport" added to Host Class but not in WinHost class. So initially it failed transport class not available, but after i added below lines it worked: class QeBaseHost(pytest_multihost.host.BaseHost): """ QeBaseHost subclass of multhost plugin BaseHost class """ transport_class = transport.SSHTransport Apart from the above minor thing, Everything else works. Again the above 3 lines solves the minor issue, just wanted to know if the above lines are to be added and is by design. > > -- > Petr Viktorin > From b010bfca67a9aa985728f7d60ada713db9cf1b1e Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] Add 'host_type', make it possible to use Windows hosts > > Add global parameter windows_test_dir to specify test directory > for Windows > Windows hosts (WinHost) use this directory by default. > test_dir can now be set individually for each host. > Move run_command from Host class to BaseHost class > Add a "host_type" configuration option and Host attribute. This > is used to select the Host subclass. By default it can > be 'default' or 'windows' (but Config subclasses can define more). > > Signed-off-by: Petr Viktorin > --- > pytest_multihost/config.py | 15 +++++++-- > pytest_multihost/host.py | 56 ++++++++++++++++++++------------- > test_pytestmultihost/test_testconfig.py | 12 ++++++- > 3 files changed, 58 insertions(+), 25 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c2..197d7ad 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > @@ -179,8 +182,16 @@ class Domain(object): > self.hosts = [] > > def get_host_class(self, host_dict): > - from pytest_multihost.host import Host > - return Host > + host_type = host_dict.get('host_type', 'default') > + return self.host_classes[host_type] > + > + @property > + def host_classes(self): > + from pytest_multihost.host import Host, WinHost > + return { > + 'default': Host, > + 'windows': WinHost, > + } > > @property > def roles(self): > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db5..9cc5e29 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -25,9 +25,12 @@ class BaseHost(object): > See README for an overview of the core classes. > """ > transport_class = None > + command_prelude = '' > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, password=None, > + test_dir=None, host_type=None): > + self.host_type = host_type > self.domain = domain > self.role = str(role) > if username is None: > @@ -40,6 +43,10 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if test_dir is None: > + self.test_dir = domain.config.test_dir > + else: > + self.test_dir = test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -78,7 +85,7 @@ class BaseHost(object): > self.host_key = None > self.ssh_port = 22 > > - self.env_sh_path = os.path.join(domain.config.test_dir, 'env.sh') > + self.env_sh_path = os.path.join(self.test_dir, 'env.sh') > > self.log_collectors = [] > > @@ -118,20 +125,28 @@ class BaseHost(object): > > username = dct.pop('username', None) > password = dct.pop('password', None) > + host_type = dct.pop('host_type', 'default') > > check_config_dict_empty(dct, 'host %s' % hostname) > > - return cls(domain, hostname, role, ip, external_hostname, > - username, password) > + return cls(domain, hostname, role, > + ip=ip, > + external_hostname=external_hostname, > + username=username, > + password=password, > + host_type=host_type) > > def to_dict(self): > """Export info about this Host to a dict""" > - return { > + result = { > 'name': str(self.hostname), > 'ip': self.ip, > 'role': self.role, > 'external_hostname': self.external_hostname, > } > + if self.host_type != 'default': > + result['host_type'] = self.host_type > + return result > > @property > def config(self): > @@ -204,28 +219,18 @@ class BaseHost(object): > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > - > - > -class Host(BaseHost): > - """A Unix host""" > - transport_class = transport.SSHTransport > - > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > # Set working directory > if cwd is None: > - cwd = self.config.test_dir > + cwd = self.test_dir > command.stdin.write('cd %s\n' % shell_quote(cwd)) > > # Set the environment > if set_env: > command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > + > + if self.command_prelude: > + command.stdin.write(self.command_prelude) > > if isinstance(argv, basestring): > # Run a shell command given as a string > @@ -247,11 +252,18 @@ class Host(BaseHost): > return command > > > +class Host(BaseHost): > + """A Unix host""" > + transport_class = transport.SSHTransport > + command_prelude = 'set -e\n' > + > + > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > - > - This is a stub; Windows hosts can't currently be interacted with. > """ > > - pass > + def __init__(self, domain, hostname, role, **kwargs): > + # Set test_dir to the Windows directory, if not given explicitly > + kwargs.setdefault('test_dir', domain.config.windows_test_dir) > + super(WinHost, self).__init__(domain, hostname, role, **kwargs) > diff --git a/test_pytestmultihost/test_testconfig.py b/test_pytestmultihost/test_testconfig.py > index 8239a2c..b32fd38 100644 > --- a/test_pytestmultihost/test_testconfig.py > +++ b/test_pytestmultihost/test_testconfig.py > @@ -116,7 +116,8 @@ class TestComplexConfig(CheckConfig): > dict(name='srv', ip='192.0.2.33', role='srv'), > ]), > dict(name='adomain2.test', hosts=[ > - dict(name='master.adomain2.test', ip='192.0.2.65'), > + dict(name='master.adomain2.test', ip='192.0.2.65', > + host_type='windows'), > ]), > ], > ) > @@ -197,6 +198,7 @@ class TestComplexConfig(CheckConfig): > ip="192.0.2.65", > external_hostname="master.adomain2.test", > role="master", > + host_type='windows', > ), > ], > ), > @@ -228,3 +230,11 @@ class TestComplexConfig(CheckConfig): > ad_dom = conf.domains[1] > assert ad_dom.roles == ['srv'] > assert ad_dom.extra_roles == ['srv'] > + > + assert conf.test_dir != conf.windows_test_dir > + > + assert conf.domains[0].hosts[0].host_type == 'default' > + assert conf.domains[0].hosts[0].test_dir == conf.test_dir > + > + assert conf.domains[2].hosts[0].host_type == 'windows' > + assert conf.domains[2].hosts[0].test_dir == conf.windows_test_dir > -- > 2.5.5 > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From ftweedal at redhat.com Thu Apr 21 06:28:27 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 Apr 2016 16:28:27 +1000 Subject: [Freeipa-devel] V4/Sub-CAs review In-Reply-To: <57161E1F.6020001@redhat.com> Message-ID: <20160421062827.GM18277@dhcp-40-8.bne.redhat.com> Christian, thank you for the review. Responses inline. I will update the design page soon with clarifications and information about backup. On Tue, Apr 19, 2016 at 01:24:54PM +0200, Christian Heimes wrote: > Hi Fraser, > > I'm the reviewer for your Sub-CAs and RFC 2818 designs. Let's start with > Sub-CAs first. http://www.freeipa.org/page/V4/Sub-CAs > > In general the design is well written -- accurate as usual. I didn't > want to ACK the design with a simple LGTM, so I put myself in the > position of a customer and potential user of Sub-CAs. From the end-users > perspective couple of points in the design doc are either unclear or are > not addressed details. > > > 1) How can I restrict a Sub-CA to a specific key usage or DNS suffix? > > The design doc mentions a comment from the puppet community or the > possibility to use a SubCA for short-lived certs for VPN authentication. > As a customer I would like to restrict the KU, EKU and maybe name > constraints, e.g. a SubCA for hosts should be limited to EKU "TLS > webserver auth". Would it be possible to use a custom profile to > generate a SubCA and let users select the profile in ipa ca-add? > For things that go in EE cert, specify the target sub-CA in addition an appropriate profile. (More on that below). For things that go in CA cert (e.g. NameConstraints) - not an initial requirement but definitely a nice-to-have - a special-purpose profile is needed. Such profiles can be added/managed via the `certprofile' plugin. Dogtag will have to be updated to provide the means of specifying an alternative profile when creating the CA (see ticket[1]), and the means of conveying any data required. These options will be reflected in the ca-add options. [1] https://fedorahosted.org/pki/ticket/1338 > 2) What is the relationship between Sub-CAs and profiles? > > From the design doc it is unclear how cert profiles and Sub-CAs > interact. The certificate profile doc has > http://www.freeipa.org/page/V4/Certificate_Profiles#Schema_2, but that's > too technical. I'm not even sure I fully understand the meaning of the > schema and how memberCa affects profiles. > tl;dr profiles and authorities don't affect each other, but caacls determine which profiles and authorities can be used together, for which subject principals. CA ACLs currently determine which profiles can be used with which subject principals. With Lightweight CAs, CA ACLs are expanded in scope to also include which CA(s) can be used with which profiles for a particular subject principal. This is what the memberCa attribute of the caacl object class accomplishes. A single caacl rule allows specified (or all) profiles to be used by specified (or all - if caCategory=all) CAs to issue certificates to specified principals or principal types. > > 3) How can I make FreeIPA use a specific Sub-CA in a cert request? > > IMO a 1:n relationship between CAs and profiles would make sense. That > way ipa cert-request --profile-id=caVPNCert could automatically select > the VPN Sub-CA. > Simply supply the ``--ca `` option. http://www.freeipa.org/page/V4/Sub-CAs#ipa_cert-request Your suggestion about a default sub-CA for a profile is interesting. We still need the option to specify both CA and profile but it is good UX becaues it will cover many use cases. I filed a ticket[2]. [2] https://fedorahosted.org/freeipa/ticket/5836 > > 4) Where is the private key of a Sub-CAs stored locally and how is it > secured? > Customers will like to know where Dogtag keeps its crown jewels and how > they are secured. > Stored in the NSSDB. For key replication, Custodia transports the key wrapped by the signing key of the "host authority" (i.e. the CA that Dogtag was installed with). There's a ticket for HSM support[3] but FreeIPA doesn't support HSM yet, anyway. [3] https://fedorahosted.org/pki/ticket/2292 > > 5) What is the backup and export strategy for a Sub-CA private key? > > Similar to 4), customers want to backup the private keys. > I'll look at what the main IPA backup process does. If it already backs up the whole of /etc/pki/pki-tomcat/alias, we're good. If not, I'll extend it to include whatever is needed. > > Christian > From ftweedal at redhat.com Thu Apr 21 06:49:45 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 Apr 2016 16:49:45 +1000 Subject: [Freeipa-devel] V4/RFC 2818 review In-Reply-To: <57164967.2020800@redhat.com> References: <57163D29.8030400@redhat.com> <57164967.2020800@redhat.com> Message-ID: <20160421064945.GP18277@dhcp-40-8.bne.redhat.com> On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: > Christian Heimes wrote: > >Hi Fraser, > > > >and now to the review of your design doc for RFC 2818-compliant subject > >alternative names in certs, > >http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > > > > >1) RFC 2818 vs. RFC 6125 > > > >First I like to address a more general topic. Your design mentions RFC > >6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > >verification and we should follow the rules in RFC 6125, whenever 2818 > >lacks specification or there is a conflict between both RFCs. I can tell > >you some horror stories from Python's ssl module related to both RFCs. > > > >https://tools.ietf.org/html/rfc2818, HTTP Over TLS > > > >https://tools.ietf.org/html/rfc6125, Representation and Verification of > >Domain-Based Application Service Identity within Internet Public Key > >Infrastructure Using X.509 (PKIX) Certificates in the Context of > >Transport Layer Security (TLS) > > > >As far as I'm familiar with RFC 6125, your proposal doesn't conflict > >with the more modern RFC. It also makes sense to name the design after > >the RFC, which has deprecated CN. I still like to check your design > >against RFC 6125. > > > >Fraser, do you agree? > > > > > >2) SAN validation in ipa cert-request > > > >In the paragraph "ipa cert-request changes" you write that the plugin > >"[...] ensure that one element of the DNS names list matches the > >principal name". Shouldn't the plugin validate *all* DNS names and > >verify that the principal is allowed to request a cert for all fields in > >SAN? > > Are there plans for any other SAN types? IP address or other oddball types > like MS UPN? > We support almost all of them in Dogtag, and only support a few types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). We should work out what we can do with IP address; I recall it is needed (or wanted) for some cloud/IaaS use cases. DirectoryName would be simple to support (just check that it matches DN of target principal). I wonder if there is a use case for it, or for any other SAN types... > > > >3) Should FreeIPA deprecate cert request without SAN or at least warn > >the user? > > > >IMHO it makes sense to deprecate CN only cert requests. > > I'd mark it as deprecated over at least a major release in order to handle > older versions that may still make requests without a SAN. > We have to be careful here. CN is depreated for DNS name checking in HTTP (or other network protocols using TLS). Fine - but there could be other certificate use cases that require CN, e.g. user certs where Subject DN corresponds to a directory name. We can deprecate it and eventually reject requests that include CN - but only for service cert profile(s). (This would require a new profile component designed for this purpose). > > > >4) update "Issue New Certificate for Host" dialog and documentation > > > >The web UI has an update "Issue New Certificate for Host" dialog which > >explains how to create a CSR with certutil. This dialog should be > >updated to explain how to add a SAN DNS field. The option for SAN DNS is > >'-8 fqdn' or '--extSAN dns:fqdn', e.g. > > > >Create a CSR with subject CN=,O=, for example: > ># certutil -R -d -a -g -s > >'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' > > rob > From ftweedal at redhat.com Thu Apr 21 07:06:42 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 Apr 2016 17:06:42 +1000 Subject: [Freeipa-devel] V4/RFC 2818 review In-Reply-To: <57163D29.8030400@redhat.com> References: <57163D29.8030400@redhat.com> Message-ID: <20160421070642.GQ18277@dhcp-40-8.bne.redhat.com> On Tue, Apr 19, 2016 at 04:14:01PM +0200, Christian Heimes wrote: > Hi Fraser, > > and now to the review of your design doc for RFC 2818-compliant subject > alternative names in certs, > http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > > 1) RFC 2818 vs. RFC 6125 > > First I like to address a more general topic. Your design mentions RFC > 6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > verification and we should follow the rules in RFC 6125, whenever 2818 > lacks specification or there is a conflict between both RFCs. I can tell > you some horror stories from Python's ssl module related to both RFCs. > > https://tools.ietf.org/html/rfc2818, HTTP Over TLS > > https://tools.ietf.org/html/rfc6125, Representation and Verification of > Domain-Based Application Service Identity within Internet Public Key > Infrastructure Using X.509 (PKIX) Certificates in the Context of > Transport Layer Security (TLS) > > As far as I'm familiar with RFC 6125, your proposal doesn't conflict > with the more modern RFC. It also makes sense to name the design after > the RFC, which has deprecated CN. I still like to check your design > against RFC 6125. > > Fraser, do you agree? > The scope of RFC 6125 seems much larger than RFC 2818, e.g. moving toward support for SRVName and uniformResourceIdentifier, and deprecating wildcard certs. It absolutely makes sense to check my design against RFC 6125 but I don't think it makes sense to indicate that the design aspires to "RFC 6125 compliance" (it does not). I think I will leave the design name and scope as-is but I will update the design to mention RFC 6125 and the need to comply with relevant aspects thereof. > > 2) SAN validation in ipa cert-request > > In the paragraph "ipa cert-request changes" you write that the plugin > "[...] ensure that one element of the DNS names list matches the > principal name". Shouldn't the plugin validate *all* DNS names and > verify that the principal is allowed to request a cert for all fields in > SAN? > The preceding point states: For each dNSName in the subjectAltName extension, in addition to the existing checks, append the value to the list of DNS names. These existing checks ensure that each dnsName matches a principal that is "managed by" the nominated subject principal (nb: each host/service manages itself). The final point ensure that one of the dnsNames does actually correspond to the subject principal. i.e. you can't issue containing dnsNames managed by the subject principal, yet omit a dnsName for the subject principal itself. I will expand the wording of the design to (try to) clarify this. > > 3) Should FreeIPA deprecate cert request without SAN or at least warn > the user? > > IMHO it makes sense to deprecate CN only cert requests. > See my response to Rob's reply. > > 4) update "Issue New Certificate for Host" dialog and documentation > > The web UI has an update "Issue New Certificate for Host" dialog which > explains how to create a CSR with certutil. This dialog should be > updated to explain how to add a SAN DNS field. The option for SAN DNS is > '-8 fqdn' or '--extSAN dns:fqdn', e.g. > > Create a CSR with subject CN=,O=, for example: > # certutil -R -d -a -g -s > 'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' > Yes, good idea. Thanks for the review! Fraser From jcholast at redhat.com Thu Apr 21 07:11:34 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Apr 2016 09:11:34 +0200 Subject: [Freeipa-devel] [PATCHES 551-552] ipalib: add basecert plugins In-Reply-To: <57051322.8090706@redhat.com> References: <56E956B0.9000804@redhat.com> <57051322.8090706@redhat.com> Message-ID: On 6.4.2016 15:46, Pavel Vomacka wrote: > > > On 03/16/2016 01:50 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches implement the server-side part of >> . >> >> Honza >> > Hi, > > thank you for the patches. I tested them and they work well. But I would > like to ask you whether would be possible to extend the response of > 'basecert_find' method and probably also 'basecert_show' response. I > think of these information: > > 1) information whether the certificate is issued by our CA or not. You can check for that by comparing the issuer name of the certificate to "CN=Certificate Authority,$SUBJECT_BASE". You can get subject base from config-show. > > 2) this probably wouldn't be possible (as we discussed), but I rather > write it too - the information about revocation reason. The same as the > 'cert_show' provides. Added --check-revocation flag to request this information. Currently it works only on certificates issued by our CA. > > 3) MD5 and SHA1 fingerprints as the 'cert_show' method returns Added, also included SHA-256. > > Thank you again. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-551.1-ldap-fix-handling-of-binary-data-in-search-filters.patch Type: text/x-patch Size: 1201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-552.1-api-add-basecert-plugins.patch Type: text/x-patch Size: 20482 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 21 07:19:47 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Apr 2016 09:19:47 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <57161B2F.5060406@redhat.com> References: <570E5C67.40201@redhat.com> <570F3BBC.7000800@redhat.com> <570F594F.6080007@redhat.com> <57161B2F.5060406@redhat.com> Message-ID: <004d0e91-18bb-c240-7988-3b880f032321@redhat.com> On 19.4.2016 13:49, Martin Babinsky wrote: > On 04/14/2016 10:48 AM, Martin Babinsky wrote: >> On 04/14/2016 08:42 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 13.4.2016 16:49, Martin Babinsky wrote: >>>> This is a WIP patch which moves the `ipa-replica-manage del` subcommand >>>> to the 'server-del' API method and exposes it as CLI command[1]. A CI >>>> test suite is also included. >>> >>>> `server-del` now accepts the following options: >>>> * `--cleanup`: perform a cleanup after an already deleted master >>> >>> I would prefer if this was actually called --force, for reasons >>> explained in the design thread: >>> . >>> >>> >>>> * `--force-removal`: force master removal, i.e. ignore topology errors >>> >>> So, this is actually the all-powerful --force option we always try to >>> avoid, but with a different name (and not very good one - if you are >>> removing something, what other than removal would you need to force?). >>> >>> Could you split this into separate options? >>> >> There are actually two checks that we need to pass/bypass before we can >> remove the master entry and run all the cleanup shenanigans: >> >> 1.) the topology is not disconnected already or is not being >> disconnected by the action >> >> 2.) the action does leave at least one CA/DNS server, does not remove >> DNSSec keymaster and we can promote other master to CA renewal master >> >> So IIUC we would need three options actually: >> >> * one that bypasses topology checks ('--ignore-topology-disconnect') >> * one that bypasses the check for remaining services >> ('--ignore-last-services?') >> * one that will cleanup leftovers only, ignoring NotFound error >> ('--cleanup'), this one is already there > > Actually '--force' should replace '--cleanup' as it does basically the > same job. Right. > What about the remaining two proposed options? --ignore-topology-disconnect is good. The other one should use "role" rather than "service", e.g. --ignore-last-of-role. -- Jan Cholasta From mbasti at redhat.com Thu Apr 21 07:17:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 09:17:39 +0200 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command In-Reply-To: <571798C4.5040200@redhat.com> References: <571798C4.5040200@redhat.com> Message-ID: <57187E93.1040707@redhat.com> On 20.04.2016 16:57, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5281 > > Patch attached. > > selfNACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Apr 21 07:21:41 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Apr 2016 09:21:41 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <57160BAF.4020702@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> <57160BAF.4020702@redhat.com> Message-ID: <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> On 19.4.2016 12:42, Martin Babinsky wrote: > On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: >> >> On 04/14/2016 10:59 AM, Martin Babinsky wrote: >>> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>>> Martin Babinsky wrote: >>>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>>> subcommand >>>>>> to the 'server-del' API method and exposes it as CLI command[1]. A CI >>>>>> test suite is also included. >>>>>> >>>>>> There are some issues with the patch I would like to discuss in more >>>>>> detail on the list: >>>>>> >>>>>> 1.) In the original subcommand there was a lot of output (mostly >>>>>> print >>>>>> statements) during all stages of master removal. I have tried to port >>>>>> these as messages to the command which results in quite voluminous >>>>>> response sent back to the frontend. Should we try to reduce the >>>>>> output? >>>>> >>>>> I don't think it applies anymore. These messages were there so the >>>>> user >>>>> would know something was happening. If it is an API command there >>>>> isn't >>>>> much we can do other than add something to the cli to print "This >>>>> could >>>>> take a bit" before making the call. >>>> >>>> +1 >>>> >>> This is already implemented in PoC. So I guess we may reduce the >>> output only to the following: >>> >>> >>> In CLI print: >>> "Removing {server} from replication topology, " >>> "please wait... >>> >>> The adding info messages: >>> >>> "checking topology connectivity" | "skipping topology connectivity >>> check" >>> "checking remaining services" | "skipping check for remaining services" >>> "performing cleanup" >>> "Deleted server {server}" >>> >>> >>>>> >>>>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>>>> would >>>>>> me a separate API method called during server_del postcallback. >>>>>> However >>>>>> since the two objects ended up sharing a lot of state (e.g. topology >>>>>> state from pre-callback, messages) i have merged it to server-del. >>>>>> That >>>>>> makes the code rather unwieldy but I found it difficult to keep the >>>>>> two >>>>>> entities separate without some hacking around framework capabilities >>>>> >>>>> I haven't looked at the code but as a general principal having >>>>> separate >>>>> operations has saved our bacon on more than one occasion. >>>> >>>> The patch adds a force option, which allows you to re-run server-del >>>> even if the master entry does not exist anymore, so I think we are >>>> safe. >>>> >>>>> >>>>>> 3.) since actions in post-callback require a knowledge about topology >>>>>> state gathered in pre-callback, I had to store some information in >>>>>> the >>>>>> command's context. Sorry about that, if you know about some way to >>>>>> circumvent me, let me know. >>>>> >>>>> Looks like it is the only way since you are extending server_del. >>>>> Another option would be to drop pre/post and add all this topology >>>>> stuff >>>>> directly to server_del execute. >>>>> >>>>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>>>> forwarding of the request to other master that can do the job. Is >>>>>> this >>>>>> okay? >>>> >>>> Why can't the master remove itself? >>>> >>> Because it removes its own replication agreements hence any changes in >>> DIT (like removed principals, s4u2 proxy targets etc.) won't replicate >>> to other masters. >> It shouldn't remove replication agreements, in fact this should be >> prevented by the topology plugin. >> The removal of the agreements will be triggered by removing the master >> entry > > That is true, but there is a plenty of cleanup code that is executed > *after* the master entry is removed and these changes would not > replicate if the agreements were removed by topology plugin in the > meanwhile. What kind of cleanup is it? Can it be done before instead? -- Jan Cholasta From abokovoy at redhat.com Thu Apr 21 07:22:33 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 21 Apr 2016 10:22:33 +0300 Subject: [Freeipa-devel] V4/RFC 2818 review In-Reply-To: <20160421064945.GP18277@dhcp-40-8.bne.redhat.com> References: <57163D29.8030400@redhat.com> <57164967.2020800@redhat.com> <20160421064945.GP18277@dhcp-40-8.bne.redhat.com> Message-ID: <20160421072233.GA24892@redhat.com> On Thu, 21 Apr 2016, Fraser Tweedale wrote: >On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: >> Christian Heimes wrote: >> >Hi Fraser, >> > >> >and now to the review of your design doc for RFC 2818-compliant subject >> >alternative names in certs, >> >http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance >> > >> > >> >1) RFC 2818 vs. RFC 6125 >> > >> >First I like to address a more general topic. Your design mentions RFC >> >6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname >> >verification and we should follow the rules in RFC 6125, whenever 2818 >> >lacks specification or there is a conflict between both RFCs. I can tell >> >you some horror stories from Python's ssl module related to both RFCs. >> > >> >https://tools.ietf.org/html/rfc2818, HTTP Over TLS >> > >> >https://tools.ietf.org/html/rfc6125, Representation and Verification of >> >Domain-Based Application Service Identity within Internet Public Key >> >Infrastructure Using X.509 (PKIX) Certificates in the Context of >> >Transport Layer Security (TLS) >> > >> >As far as I'm familiar with RFC 6125, your proposal doesn't conflict >> >with the more modern RFC. It also makes sense to name the design after >> >the RFC, which has deprecated CN. I still like to check your design >> >against RFC 6125. >> > >> >Fraser, do you agree? >> > >> > >> >2) SAN validation in ipa cert-request >> > >> >In the paragraph "ipa cert-request changes" you write that the plugin >> >"[...] ensure that one element of the DNS names list matches the >> >principal name". Shouldn't the plugin validate *all* DNS names and >> >verify that the principal is allowed to request a cert for all fields in >> >SAN? >> >> Are there plans for any other SAN types? IP address or other oddball types >> like MS UPN? >> >We support almost all of them in Dogtag, and only support a few >types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). > >We should work out what we can do with IP address; I recall it is >needed (or wanted) for some cloud/IaaS use cases. Yes, some of Openstack code expects IP address in the certificates. >DirectoryName would be simple to support (just check that it matches >DN of target principal). I wonder if there is a use case for it, or >for any other SAN types... dNSName and id-pkinit-san are used by Kerberos PKINIT support in MIT Kerberos for host-based principals. id-pkinit-san is also in use for mapping of the principal in general. In fact, Kerberos PKINIT retrieves all SANs and UPNs from the certificate and allows to match them by the matching rules -- id-pkinit-san goes to list of principals, id-ms-san-upn goes to the list of UPNs which are then merged together and can be addressed with keyword in the matching rule. This allows very flexible matching: pkinit_cert_match = ||.*DoE.*.*@EXAMPLE.COM pkinit_cert_match = &&msScLogin,clientAuth.*DoE.* pkinit_cert_match = msScLogin,clientAuthdigitalSignature >> > >> >3) Should FreeIPA deprecate cert request without SAN or at least warn >> >the user? >> > >> >IMHO it makes sense to deprecate CN only cert requests. >> >> I'd mark it as deprecated over at least a major release in order to handle >> older versions that may still make requests without a SAN. >> >We have to be careful here. CN is depreated for DNS name checking >in HTTP (or other network protocols using TLS). Fine - but there >could be other certificate use cases that require CN, e.g. user >certs where Subject DN corresponds to a directory name. Yes. pkinit_cert_match's rule is using Subject DN for checks. >We can deprecate it and eventually reject requests that include CN - >but only for service cert profile(s). (This would require a new >profile component designed for this purpose). Please do not do it. There are known uses for it at least with Kerberos. Of course, most of them are rather for user certificates but in reality Kerberos does not require you to have service principals always as DNS names. -- / Alexander Bokovoy From ftweedal at redhat.com Thu Apr 21 07:34:51 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 21 Apr 2016 17:34:51 +1000 Subject: [Freeipa-devel] V4/RFC 2818 review In-Reply-To: <20160421072233.GA24892@redhat.com> References: <57163D29.8030400@redhat.com> <57164967.2020800@redhat.com> <20160421064945.GP18277@dhcp-40-8.bne.redhat.com> <20160421072233.GA24892@redhat.com> Message-ID: <20160421073451.GR18277@dhcp-40-8.bne.redhat.com> On Thu, Apr 21, 2016 at 10:22:33AM +0300, Alexander Bokovoy wrote: > On Thu, 21 Apr 2016, Fraser Tweedale wrote: > >On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: > >>Christian Heimes wrote: > >>>Hi Fraser, > >>> > >>>and now to the review of your design doc for RFC 2818-compliant subject > >>>alternative names in certs, > >>>http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > >>> > >>> > >>>1) RFC 2818 vs. RFC 6125 > >>> > >>>First I like to address a more general topic. Your design mentions RFC > >>>6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > >>>verification and we should follow the rules in RFC 6125, whenever 2818 > >>>lacks specification or there is a conflict between both RFCs. I can tell > >>>you some horror stories from Python's ssl module related to both RFCs. > >>> > >>>https://tools.ietf.org/html/rfc2818, HTTP Over TLS > >>> > >>>https://tools.ietf.org/html/rfc6125, Representation and Verification of > >>>Domain-Based Application Service Identity within Internet Public Key > >>>Infrastructure Using X.509 (PKIX) Certificates in the Context of > >>>Transport Layer Security (TLS) > >>> > >>>As far as I'm familiar with RFC 6125, your proposal doesn't conflict > >>>with the more modern RFC. It also makes sense to name the design after > >>>the RFC, which has deprecated CN. I still like to check your design > >>>against RFC 6125. > >>> > >>>Fraser, do you agree? > >>> > >>> > >>>2) SAN validation in ipa cert-request > >>> > >>>In the paragraph "ipa cert-request changes" you write that the plugin > >>>"[...] ensure that one element of the DNS names list matches the > >>>principal name". Shouldn't the plugin validate *all* DNS names and > >>>verify that the principal is allowed to request a cert for all fields in > >>>SAN? > >> > >>Are there plans for any other SAN types? IP address or other oddball types > >>like MS UPN? > >> > >We support almost all of them in Dogtag, and only support a few > >types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). > > > >We should work out what we can do with IP address; I recall it is > >needed (or wanted) for some cloud/IaaS use cases. > Yes, some of Openstack code expects IP address in the certificates. > > >DirectoryName would be simple to support (just check that it matches > >DN of target principal). I wonder if there is a use case for it, or > >for any other SAN types... > dNSName and id-pkinit-san are used by Kerberos PKINIT support in MIT > Kerberos for host-based principals. id-pkinit-san is also in use for > mapping of the principal in general. > > In fact, Kerberos PKINIT retrieves all SANs and UPNs from the certificate and > allows to match them by the matching rules -- id-pkinit-san goes to list > of principals, id-ms-san-upn goes to the list of UPNs which are then > merged together and can be addressed with keyword in the matching > rule. > > This allows very flexible matching: > pkinit_cert_match = ||.*DoE.*.*@EXAMPLE.COM > pkinit_cert_match = &&msScLogin,clientAuth.*DoE.* > pkinit_cert_match = msScLogin,clientAuthdigitalSignature > Thank you for the information! > > > >>> > >>>3) Should FreeIPA deprecate cert request without SAN or at least warn > >>>the user? > >>> > >>>IMHO it makes sense to deprecate CN only cert requests. > >> > >>I'd mark it as deprecated over at least a major release in order to handle > >>older versions that may still make requests without a SAN. > >> > >We have to be careful here. CN is depreated for DNS name checking > >in HTTP (or other network protocols using TLS). Fine - but there > >could be other certificate use cases that require CN, e.g. user > >certs where Subject DN corresponds to a directory name. > Yes. pkinit_cert_match's rule is using Subject DN for checks. > > > >We can deprecate it and eventually reject requests that include CN - > >but only for service cert profile(s). (This would require a new > >profile component designed for this purpose). > Please do not do it. There are known uses for it at least with Kerberos. > Of course, most of them are rather for user certificates but in reality > Kerberos does not require you to have service principals always as DNS > names. > There is the option of implementing the component that prohibits CN. I was by no means suggesting it should be used for all profiles. Customers can use it on a custom profile if they want. We could use it on the default service cert profile if we want. Cheers, Fraser From mbabinsk at redhat.com Thu Apr 21 08:11:57 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Apr 2016 10:11:57 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> <57160BAF.4020702@redhat.com> <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> Message-ID: <57188B4D.70707@redhat.com> On 04/21/2016 09:21 AM, Jan Cholasta wrote: > On 19.4.2016 12:42, Martin Babinsky wrote: >> On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: >>> >>> On 04/14/2016 10:59 AM, Martin Babinsky wrote: >>>> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>>>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>>>> Martin Babinsky wrote: >>>>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>>>> subcommand >>>>>>> to the 'server-del' API method and exposes it as CLI command[1]. >>>>>>> A CI >>>>>>> test suite is also included. >>>>>>> >>>>>>> There are some issues with the patch I would like to discuss in more >>>>>>> detail on the list: >>>>>>> >>>>>>> 1.) In the original subcommand there was a lot of output (mostly >>>>>>> print >>>>>>> statements) during all stages of master removal. I have tried to >>>>>>> port >>>>>>> these as messages to the command which results in quite voluminous >>>>>>> response sent back to the frontend. Should we try to reduce the >>>>>>> output? >>>>>> >>>>>> I don't think it applies anymore. These messages were there so the >>>>>> user >>>>>> would know something was happening. If it is an API command there >>>>>> isn't >>>>>> much we can do other than add something to the cli to print "This >>>>>> could >>>>>> take a bit" before making the call. >>>>> >>>>> +1 >>>>> >>>> This is already implemented in PoC. So I guess we may reduce the >>>> output only to the following: >>>> >>>> >>>> In CLI print: >>>> "Removing {server} from replication topology, " >>>> "please wait... >>>> >>>> The adding info messages: >>>> >>>> "checking topology connectivity" | "skipping topology connectivity >>>> check" >>>> "checking remaining services" | "skipping check for remaining services" >>>> "performing cleanup" >>>> "Deleted server {server}" >>>> >>>> >>>>>> >>>>>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>>>>> would >>>>>>> me a separate API method called during server_del postcallback. >>>>>>> However >>>>>>> since the two objects ended up sharing a lot of state (e.g. topology >>>>>>> state from pre-callback, messages) i have merged it to server-del. >>>>>>> That >>>>>>> makes the code rather unwieldy but I found it difficult to keep the >>>>>>> two >>>>>>> entities separate without some hacking around framework capabilities >>>>>> >>>>>> I haven't looked at the code but as a general principal having >>>>>> separate >>>>>> operations has saved our bacon on more than one occasion. >>>>> >>>>> The patch adds a force option, which allows you to re-run server-del >>>>> even if the master entry does not exist anymore, so I think we are >>>>> safe. >>>>> >>>>>> >>>>>>> 3.) since actions in post-callback require a knowledge about >>>>>>> topology >>>>>>> state gathered in pre-callback, I had to store some information in >>>>>>> the >>>>>>> command's context. Sorry about that, if you know about some way to >>>>>>> circumvent me, let me know. >>>>>> >>>>>> Looks like it is the only way since you are extending server_del. >>>>>> Another option would be to drop pre/post and add all this topology >>>>>> stuff >>>>>> directly to server_del execute. >>>>>> >>>>>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>>>>> forwarding of the request to other master that can do the job. Is >>>>>>> this >>>>>>> okay? >>>>> >>>>> Why can't the master remove itself? >>>>> >>>> Because it removes its own replication agreements hence any changes in >>>> DIT (like removed principals, s4u2 proxy targets etc.) won't replicate >>>> to other masters. >>> It shouldn't remove replication agreements, in fact this should be >>> prevented by the topology plugin. >>> The removal of the agreements will be triggered by removing the master >>> entry >> >> That is true, but there is a plenty of cleanup code that is executed >> *after* the master entry is removed and these changes would not >> replicate if the agreements were removed by topology plugin in the >> meanwhile. > > What kind of cleanup is it? Can it be done before instead? > Well most of the code can be run in pre-callback if all the checks are passed/forced. However there is a check for deleted segments and this one should be run after the removal of master entry to see if topology plugin removed all dangling segments pointing to master. I am not quite sure if it make sense to run this check in the master which is being removed. -- Martin^3 Babinsky From lkrispen at redhat.com Thu Apr 21 08:41:14 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 Apr 2016 10:41:14 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <57188B4D.70707@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> <57160BAF.4020702@redhat.com> <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> <57188B4D.70707@redhat.com> Message-ID: <5718922A.40209@redhat.com> On 04/21/2016 10:11 AM, Martin Babinsky wrote: > On 04/21/2016 09:21 AM, Jan Cholasta wrote: >> On 19.4.2016 12:42, Martin Babinsky wrote: >>> On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: >>>> >>>> On 04/14/2016 10:59 AM, Martin Babinsky wrote: >>>>> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>>>>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>>>>> Martin Babinsky wrote: >>>>>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>>>>> subcommand >>>>>>>> to the 'server-del' API method and exposes it as CLI command[1]. >>>>>>>> A CI >>>>>>>> test suite is also included. >>>>>>>> >>>>>>>> There are some issues with the patch I would like to discuss in >>>>>>>> more >>>>>>>> detail on the list: >>>>>>>> >>>>>>>> 1.) In the original subcommand there was a lot of output (mostly >>>>>>>> print >>>>>>>> statements) during all stages of master removal. I have tried to >>>>>>>> port >>>>>>>> these as messages to the command which results in quite voluminous >>>>>>>> response sent back to the frontend. Should we try to reduce the >>>>>>>> output? >>>>>>> >>>>>>> I don't think it applies anymore. These messages were there so the >>>>>>> user >>>>>>> would know something was happening. If it is an API command there >>>>>>> isn't >>>>>>> much we can do other than add something to the cli to print "This >>>>>>> could >>>>>>> take a bit" before making the call. >>>>>> >>>>>> +1 >>>>>> >>>>> This is already implemented in PoC. So I guess we may reduce the >>>>> output only to the following: >>>>> >>>>> >>>>> In CLI print: >>>>> "Removing {server} from replication topology, " >>>>> "please wait... >>>>> >>>>> The adding info messages: >>>>> >>>>> "checking topology connectivity" | "skipping topology connectivity >>>>> check" >>>>> "checking remaining services" | "skipping check for remaining >>>>> services" >>>>> "performing cleanup" >>>>> "Deleted server {server}" >>>>> >>>>> >>>>>>> >>>>>>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>>>>>> would >>>>>>>> me a separate API method called during server_del postcallback. >>>>>>>> However >>>>>>>> since the two objects ended up sharing a lot of state (e.g. >>>>>>>> topology >>>>>>>> state from pre-callback, messages) i have merged it to server-del. >>>>>>>> That >>>>>>>> makes the code rather unwieldy but I found it difficult to keep >>>>>>>> the >>>>>>>> two >>>>>>>> entities separate without some hacking around framework >>>>>>>> capabilities >>>>>>> >>>>>>> I haven't looked at the code but as a general principal having >>>>>>> separate >>>>>>> operations has saved our bacon on more than one occasion. >>>>>> >>>>>> The patch adds a force option, which allows you to re-run server-del >>>>>> even if the master entry does not exist anymore, so I think we are >>>>>> safe. >>>>>> >>>>>>> >>>>>>>> 3.) since actions in post-callback require a knowledge about >>>>>>>> topology >>>>>>>> state gathered in pre-callback, I had to store some information in >>>>>>>> the >>>>>>>> command's context. Sorry about that, if you know about some way to >>>>>>>> circumvent me, let me know. >>>>>>> >>>>>>> Looks like it is the only way since you are extending server_del. >>>>>>> Another option would be to drop pre/post and add all this topology >>>>>>> stuff >>>>>>> directly to server_del execute. >>>>>>> >>>>>>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>>>>>> forwarding of the request to other master that can do the job. Is >>>>>>>> this >>>>>>>> okay? >>>>>> >>>>>> Why can't the master remove itself? >>>>>> >>>>> Because it removes its own replication agreements hence any >>>>> changes in >>>>> DIT (like removed principals, s4u2 proxy targets etc.) won't >>>>> replicate >>>>> to other masters. >>>> It shouldn't remove replication agreements, in fact this should be >>>> prevented by the topology plugin. >>>> The removal of the agreements will be triggered by removing the master >>>> entry >>> >>> That is true, but there is a plenty of cleanup code that is executed >>> *after* the master entry is removed and these changes would not >>> replicate if the agreements were removed by topology plugin in the >>> meanwhile. >> >> What kind of cleanup is it? Can it be done before instead? >> > > Well most of the code can be run in pre-callback if all the checks are > passed/forced. > > However there is a check for deleted segments and this one should be > run after the removal of master entry to see if topology plugin > removed all dangling segments pointing to master. I am not quite sure > if it make sense to run this check in the master which is being removed. no, it is not guranteed that the information on the removed master will be correct. If the del is applied to the to be removed master the topology plugin will only on a master which is remaining start the removal of segments, these will alos be replicated back to the removed master, but the repl agreements to this master will also be removed, so no gurantee which mods will be available on the removed master, and you should also be able to remove a master if it is down - so applying the full removal on a remaining server makes sense. What is the behaviour if the removal of a server would disconnect topology ? -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From mbasti at redhat.com Thu Apr 21 09:19:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 11:19:45 +0200 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <57179FD4.5070904@redhat.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> <57179FD4.5070904@redhat.com> Message-ID: <57189B31.9090209@redhat.com> On 20.04.2016 17:27, Martin Basti wrote: > > > On 24.03.2016 14:27, Martin Basti wrote: >> >> >> On 24.03.2016 13:55, Jan Cholasta wrote: >>> On 18.3.2016 23:27, Timo Aaltonen wrote: >>>> On 17.03.2016 18:36, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5681 >>>> >>>> would be nicer if ipa-httpd.conf was a template with the current >>>> hardcoded values replaced with platform paths.. >>> >>> +1, I would also prefer if the file was renamed to >>> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. >> ipa-httpd.conf.template should be in /user/share/ipa, directory >> init/systemd copied only to rpm and then copied to >> /etc/systemd/system AFAIK >> >>> >>>> >>>> >>>> not relevant to this patch, but there are others candidates for >>>> templates like: >>>> >>>> daemons/dnssec/ipa-dnskeysyncd.service >>>> daemons/dnssec/ipa-ods-exporter.service >>>> install/conf/ipa.conf >>> >> > > Updated patch attached, sorry for delay. > > Updated patch attached (fixed unused import). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0441.3-Configure-httpd-service-from-installer-instead-of-di.patch Type: text/x-patch Size: 9627 bytes Desc: not available URL: From mkubik at redhat.com Thu Apr 21 09:24:03 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 21 Apr 2016 11:24:03 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <57038E52.3090900@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> Message-ID: <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> On 04/05/2016 12:07 PM, Martin Babinsky wrote: > On 04/05/2016 10:24 AM, Milan Kub?k wrote: >> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>> >>>>> Patches attached. >>>>> >>>>> >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Hi Milan, >>>> >>>> >>>> >>>> I would be more happy if you could send a separate patch for the >>>> context >>>> manager fix, since the issue is orthogonal to the added test case >>>> (even >>>> if the test suite explodes without it). >>>> >>>> >>>> >>>> Otherwise LGTM. >>>> >>>> >>>> >>>> >>>> >>> >>> Done. Patch 0035 now applies to all branches, context manager fix >>> needs separate patch for ipa-4-2. >>> >> Updated commit message in patches 0036 to include the ticket. >> > Thanks, ACK. > Add freeipa-devel back to the loop & push request :) -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Apr 21 09:45:35 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 21 Apr 2016 11:45:35 +0200 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160421052520.GA5879@mniranja.pnq.csb> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> <57178E88.40207@redhat.com> <20160421052520.GA5879@mniranja.pnq.csb> Message-ID: <5718A13F.5070809@redhat.com> On 04/21/2016 07:25 AM, Niranjan wrote: > Petr Viktorin wrote: >> On 04/20/2016 06:11 AM, Niranjan wrote: >>> Petr Viktorin wrote: >>>> On 04/18/2016 12:39 PM, Niranjan wrote: >>>>> Niranjan wrote: >>>>>> Niranjan wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed >>>>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would >>>>>>>>> like to get more inputs on how to use pytest-multihost to execute commands >>>>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be >>>>>>>>> installed. >>>>>>>> >>>>>>>> Wow. I'm surprised the only problem on Windows is the "set -e". >>>>>>>> >>>>>>>> Regarding the patch: >>>>>>>> >>>>>>>> - Why is get_winhost_class needed? I don't see it called anywhere. >>>>>>>> - Similarly, why is host_type needed? Your patch only sets it. >>>>>>>> >>>>>>>> If run_command of WinHost and Unix hosts are this similar, I would put >>>>>>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class >>>>>>>> attribute named e.g. "command_prelude", use it in run_command, and move >>>>>>>> run_command from Host to BaseHost. >>>>>>>> Would that work, or am I missing something? >>>>>>> How do we detect the host is windows/unix then , we still need host_type >>>>>>> to know what the type of host is (unix/windows)? >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Petr Viktorin >>>>>> Please review the attached patch. >>>> >>>> Sorry for the delay. >>>> >>>> The information about whether the host is Unix or Windows is available: >>>> the class is either Host or WinHost, so I don't think an extra host_type >>>> is necessary. >>>> I'd be open to adding host_type as *configuration* (and corresponding >>>> attribute) if it also selected the actual Host class. Currently to use >>>> WinHost you need to write custom code. >>> I would like to have host_type available. We would like to add more >>> functions in classes that override Host/WinHost class , which >>> can be then called depending upon the host_type. >> >> Ah, I see; you're not using the WinHost subclass right now. >> >> I added a host_type; it is used to select the Host class. >> You can define a "host_classes" dict in your Domain class to list Host >> classes, and the particular Host class will be selected according to the >> host_type. >> >> The usage would be like this: >> >> --------- >> >> class QeHost(QeBaseHost): >> """Linux host class""" >> @classmethod >> def gethostname(self): >> """ Return system hostname """ >> cmd = self.run_command(['hostname'], raiseonerr=False) >> return cmd.stdout_text.strip() >> ... >> >> class QeWinHost(QeBaseHost, pytest_multihost.host.WinHost): >> """Windows host class""" >> >> @classmethod >> def gethostname(self): >> """ Return system hostname """ >> cmd = self.run_command(['hostname', '-A'], set_env=False, >> raiseonerr=False) >> return cmd.stdout_text.strip() >> ... >> >> >> class QeDomain: >> ... >> host_classes = {'default': QeHost, 'windows': QeWinHost} >> >> # remove your existing "get_host_class" method when host_classes is >> defined >> ... >> >> --------- >> >> And in the config, define host_type to 'windows'. >> >> >> Would it work for you like this? > Most of the things worked [...] > > Specifically i see that you have "transport_class = transport.SSHTransport" added to Host Class > but not in WinHost class. So initially it failed transport class not available, but after i added below lines > it worked: > > class QeBaseHost(pytest_multihost.host.BaseHost): > """ QeBaseHost subclass of multhost plugin BaseHost class """ > transport_class = transport.SSHTransport > > Apart from the above minor thing, Everything else works. Again the above 3 lines solves the minor issue, > just wanted to know if the above lines are to be added and is by design. Right, since SSHTransport works for Windows hosts as well, I've added it to BaseHost. With this version of patch it shouldn't be necessary to add it in your code. If this works for you, I'll commit it and release. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-host_type-make-it-possible-to-use-Windows-hosts.patch Type: text/x-patch Size: 8135 bytes Desc: not available URL: From pvoborni at redhat.com Thu Apr 21 10:12:02 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Apr 2016 12:12:02 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <5718922A.40209@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> <57160BAF.4020702@redhat.com> <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> <57188B4D.70707@redhat.com> <5718922A.40209@redhat.com> Message-ID: <5718A772.2010103@redhat.com> On 04/21/2016 10:41 AM, Ludwig Krispenz wrote: > > On 04/21/2016 10:11 AM, Martin Babinsky wrote: >> On 04/21/2016 09:21 AM, Jan Cholasta wrote: >>> On 19.4.2016 12:42, Martin Babinsky wrote: >>>> On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: >>>>> >>>>> On 04/14/2016 10:59 AM, Martin Babinsky wrote: >>>>>> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>>>>>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>>>>>> Martin Babinsky wrote: >>>>>>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>>>>>> subcommand >>>>>>>>> to the 'server-del' API method and exposes it as CLI command[1]. >>>>>>>>> A CI >>>>>>>>> test suite is also included. >>>>>>>>> >>>>>>>>> There are some issues with the patch I would like to discuss in >>>>>>>>> more >>>>>>>>> detail on the list: >>>>>>>>> >>>>>>>>> 1.) In the original subcommand there was a lot of output (mostly >>>>>>>>> print >>>>>>>>> statements) during all stages of master removal. I have tried to >>>>>>>>> port >>>>>>>>> these as messages to the command which results in quite voluminous >>>>>>>>> response sent back to the frontend. Should we try to reduce the >>>>>>>>> output? >>>>>>>> >>>>>>>> I don't think it applies anymore. These messages were there so the >>>>>>>> user >>>>>>>> would know something was happening. If it is an API command there >>>>>>>> isn't >>>>>>>> much we can do other than add something to the cli to print "This >>>>>>>> could >>>>>>>> take a bit" before making the call. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>> This is already implemented in PoC. So I guess we may reduce the >>>>>> output only to the following: >>>>>> >>>>>> >>>>>> In CLI print: >>>>>> "Removing {server} from replication topology, " >>>>>> "please wait... >>>>>> >>>>>> The adding info messages: >>>>>> >>>>>> "checking topology connectivity" | "skipping topology connectivity >>>>>> check" >>>>>> "checking remaining services" | "skipping check for remaining >>>>>> services" >>>>>> "performing cleanup" >>>>>> "Deleted server {server}" >>>>>> >>>>>> >>>>>>>> >>>>>>>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>>>>>>> would >>>>>>>>> me a separate API method called during server_del postcallback. >>>>>>>>> However >>>>>>>>> since the two objects ended up sharing a lot of state (e.g. >>>>>>>>> topology >>>>>>>>> state from pre-callback, messages) i have merged it to server-del. >>>>>>>>> That >>>>>>>>> makes the code rather unwieldy but I found it difficult to keep >>>>>>>>> the >>>>>>>>> two >>>>>>>>> entities separate without some hacking around framework >>>>>>>>> capabilities >>>>>>>> >>>>>>>> I haven't looked at the code but as a general principal having >>>>>>>> separate >>>>>>>> operations has saved our bacon on more than one occasion. >>>>>>> >>>>>>> The patch adds a force option, which allows you to re-run server-del >>>>>>> even if the master entry does not exist anymore, so I think we are >>>>>>> safe. >>>>>>> >>>>>>>> >>>>>>>>> 3.) since actions in post-callback require a knowledge about >>>>>>>>> topology >>>>>>>>> state gathered in pre-callback, I had to store some information in >>>>>>>>> the >>>>>>>>> command's context. Sorry about that, if you know about some way to >>>>>>>>> circumvent me, let me know. >>>>>>>> >>>>>>>> Looks like it is the only way since you are extending server_del. >>>>>>>> Another option would be to drop pre/post and add all this topology >>>>>>>> stuff >>>>>>>> directly to server_del execute. >>>>>>>> >>>>>>>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>>>>>>> forwarding of the request to other master that can do the job. Is >>>>>>>>> this >>>>>>>>> okay? >>>>>>> >>>>>>> Why can't the master remove itself? >>>>>>> >>>>>> Because it removes its own replication agreements hence any >>>>>> changes in >>>>>> DIT (like removed principals, s4u2 proxy targets etc.) won't >>>>>> replicate >>>>>> to other masters. >>>>> It shouldn't remove replication agreements, in fact this should be >>>>> prevented by the topology plugin. >>>>> The removal of the agreements will be triggered by removing the master >>>>> entry >>>> >>>> That is true, but there is a plenty of cleanup code that is executed >>>> *after* the master entry is removed and these changes would not >>>> replicate if the agreements were removed by topology plugin in the >>>> meanwhile. >>> >>> What kind of cleanup is it? Can it be done before instead? >>> >> >> Well most of the code can be run in pre-callback if all the checks are >> passed/forced. >> >> However there is a check for deleted segments and this one should be >> run after the removal of master entry to see if topology plugin >> removed all dangling segments pointing to master. I am not quite sure >> if it make sense to run this check in the master which is being removed. > no, it is not guranteed that the information on the removed master will > be correct. If the del is applied to the to be removed master the > topology plugin will only on a master which is remaining start the > removal of segments, these will alos be replicated back to the removed > master, but the repl agreements to this master will also be removed, so > no gurantee which mods will be available on the removed master, and you > should also be able to remove a master if it is down - so applying the > full removal on a remaining server makes sense. > > What is the behaviour if the removal of a server would disconnect > topology ? > > What would be the use-case for master to remove itself? The only one I see, which was proposed in design page is that in `ipa-server-install --uninstall` the installer would call `ipa server-del $to_be_removed` on different replica so that uninstallation would be done in single step. But effectively this is not removing itself from API point of view. Calling `ipa server-del $me` without subsequent uninstallation seems pointless to me. In `ipa-replica-manage` a replica can't remove itself as well. -- Petr Vobornik From lkrispen at redhat.com Thu Apr 21 10:22:24 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 Apr 2016 12:22:24 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <5718A772.2010103@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> <57160BAF.4020702@redhat.com> <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> <57188B4D.70707@redhat.com> <5718922A.40209@redhat.com> <5718A772.2010103@redhat.com> Message-ID: <5718A9E0.6040301@redhat.com> On 04/21/2016 12:12 PM, Petr Vobornik wrote: > On 04/21/2016 10:41 AM, Ludwig Krispenz wrote: >> On 04/21/2016 10:11 AM, Martin Babinsky wrote: >>> On 04/21/2016 09:21 AM, Jan Cholasta wrote: >>>> On 19.4.2016 12:42, Martin Babinsky wrote: >>>>> On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: >>>>>> On 04/14/2016 10:59 AM, Martin Babinsky wrote: >>>>>>> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>>>>>>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>>>>>>> Martin Babinsky wrote: >>>>>>>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>>>>>>> subcommand >>>>>>>>>> to the 'server-del' API method and exposes it as CLI command[1]. >>>>>>>>>> A CI >>>>>>>>>> test suite is also included. >>>>>>>>>> >>>>>>>>>> There are some issues with the patch I would like to discuss in >>>>>>>>>> more >>>>>>>>>> detail on the list: >>>>>>>>>> >>>>>>>>>> 1.) In the original subcommand there was a lot of output (mostly >>>>>>>>>> print >>>>>>>>>> statements) during all stages of master removal. I have tried to >>>>>>>>>> port >>>>>>>>>> these as messages to the command which results in quite voluminous >>>>>>>>>> response sent back to the frontend. Should we try to reduce the >>>>>>>>>> output? >>>>>>>>> I don't think it applies anymore. These messages were there so the >>>>>>>>> user >>>>>>>>> would know something was happening. If it is an API command there >>>>>>>>> isn't >>>>>>>>> much we can do other than add something to the cli to print "This >>>>>>>>> could >>>>>>>>> take a bit" before making the call. >>>>>>>> +1 >>>>>>>> >>>>>>> This is already implemented in PoC. So I guess we may reduce the >>>>>>> output only to the following: >>>>>>> >>>>>>> >>>>>>> In CLI print: >>>>>>> "Removing {server} from replication topology," >>>>>>> "please wait... >>>>>>> >>>>>>> The adding info messages: >>>>>>> >>>>>>> "checking topology connectivity" | "skipping topology connectivity >>>>>>> check" >>>>>>> "checking remaining services" | "skipping check for remaining >>>>>>> services" >>>>>>> "performing cleanup" >>>>>>> "Deleted server {server}" >>>>>>> >>>>>>> >>>>>>>>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>>>>>>>> would >>>>>>>>>> me a separate API method called during server_del postcallback. >>>>>>>>>> However >>>>>>>>>> since the two objects ended up sharing a lot of state (e.g. >>>>>>>>>> topology >>>>>>>>>> state from pre-callback, messages) i have merged it to server-del. >>>>>>>>>> That >>>>>>>>>> makes the code rather unwieldy but I found it difficult to keep >>>>>>>>>> the >>>>>>>>>> two >>>>>>>>>> entities separate without some hacking around framework >>>>>>>>>> capabilities >>>>>>>>> I haven't looked at the code but as a general principal having >>>>>>>>> separate >>>>>>>>> operations has saved our bacon on more than one occasion. >>>>>>>> The patch adds a force option, which allows you to re-run server-del >>>>>>>> even if the master entry does not exist anymore, so I think we are >>>>>>>> safe. >>>>>>>> >>>>>>>>>> 3.) since actions in post-callback require a knowledge about >>>>>>>>>> topology >>>>>>>>>> state gathered in pre-callback, I had to store some information in >>>>>>>>>> the >>>>>>>>>> command's context. Sorry about that, if you know about some way to >>>>>>>>>> circumvent me, let me know. >>>>>>>>> Looks like it is the only way since you are extending server_del. >>>>>>>>> Another option would be to drop pre/post and add all this topology >>>>>>>>> stuff >>>>>>>>> directly to server_del execute. >>>>>>>>> >>>>>>>>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>>>>>>>> forwarding of the request to other master that can do the job. Is >>>>>>>>>> this >>>>>>>>>> okay? >>>>>>>> Why can't the master remove itself? >>>>>>>> >>>>>>> Because it removes its own replication agreements hence any >>>>>>> changes in >>>>>>> DIT (like removed principals, s4u2 proxy targets etc.) won't >>>>>>> replicate >>>>>>> to other masters. >>>>>> It shouldn't remove replication agreements, in fact this should be >>>>>> prevented by the topology plugin. >>>>>> The removal of the agreements will be triggered by removing the master >>>>>> entry >>>>> That is true, but there is a plenty of cleanup code that is executed >>>>> *after* the master entry is removed and these changes would not >>>>> replicate if the agreements were removed by topology plugin in the >>>>> meanwhile. >>>> What kind of cleanup is it? Can it be done before instead? >>>> >>> Well most of the code can be run in pre-callback if all the checks are >>> passed/forced. >>> >>> However there is a check for deleted segments and this one should be >>> run after the removal of master entry to see if topology plugin >>> removed all dangling segments pointing to master. I am not quite sure >>> if it make sense to run this check in the master which is being removed. >> no, it is not guranteed that the information on the removed master will >> be correct. If the del is applied to the to be removed master the >> topology plugin will only on a master which is remaining start the >> removal of segments, these will alos be replicated back to the removed >> master, but the repl agreements to this master will also be removed, so >> no gurantee which mods will be available on the removed master, and you >> should also be able to remove a master if it is down - so applying the >> full removal on a remaining server makes sense. >> >> What is the behaviour if the removal of a server would disconnect >> topology ? >> >> > What would be the use-case for master to remove itself? I don't think that there is a use case except uninstall, but this doesen't prevent users to run the command. And then there are a few options how to handle this. - accept it and try to do the best - reject it and say it should be run on any other master - automatically execute this on another master - I think this is Martin's current plan > > The only one I see, which was proposed in design page is that in > `ipa-server-install --uninstall` the installer would call `ipa > server-del $to_be_removed` on different replica so that uninstallation > would be done in single step. But effectively this is not removing > itself from API point of view. > > Calling `ipa server-del $me` without subsequent uninstallation seems > pointless to me. In `ipa-replica-manage` a replica can't remove itself > as well. -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill From mbabinsk at redhat.com Thu Apr 21 10:43:12 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Apr 2016 12:43:12 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <5718A9E0.6040301@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> <57160BAF.4020702@redhat.com> <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> <57188B4D.70707@redhat.com> <5718922A.40209@redhat.com> <5718A772.2010103@redhat.com> <5718A9E0.6040301@redhat.com> Message-ID: <5718AEC0.7080407@redhat.com> On 04/21/2016 12:22 PM, Ludwig Krispenz wrote: > > On 04/21/2016 12:12 PM, Petr Vobornik wrote: >> On 04/21/2016 10:41 AM, Ludwig Krispenz wrote: >>> On 04/21/2016 10:11 AM, Martin Babinsky wrote: >>>> On 04/21/2016 09:21 AM, Jan Cholasta wrote: >>>>> On 19.4.2016 12:42, Martin Babinsky wrote: >>>>>> On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: >>>>>>> On 04/14/2016 10:59 AM, Martin Babinsky wrote: >>>>>>>> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>>>>>>>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>>>>>>>> Martin Babinsky wrote: >>>>>>>>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>>>>>>>> subcommand >>>>>>>>>>> to the 'server-del' API method and exposes it as CLI command[1]. >>>>>>>>>>> A CI >>>>>>>>>>> test suite is also included. >>>>>>>>>>> >>>>>>>>>>> There are some issues with the patch I would like to discuss in >>>>>>>>>>> more >>>>>>>>>>> detail on the list: >>>>>>>>>>> >>>>>>>>>>> 1.) In the original subcommand there was a lot of output (mostly >>>>>>>>>>> print >>>>>>>>>>> statements) during all stages of master removal. I have tried to >>>>>>>>>>> port >>>>>>>>>>> these as messages to the command which results in quite >>>>>>>>>>> voluminous >>>>>>>>>>> response sent back to the frontend. Should we try to reduce the >>>>>>>>>>> output? >>>>>>>>>> I don't think it applies anymore. These messages were there so >>>>>>>>>> the >>>>>>>>>> user >>>>>>>>>> would know something was happening. If it is an API command there >>>>>>>>>> isn't >>>>>>>>>> much we can do other than add something to the cli to print "This >>>>>>>>>> could >>>>>>>>>> take a bit" before making the call. >>>>>>>>> +1 >>>>>>>>> >>>>>>>> This is already implemented in PoC. So I guess we may reduce the >>>>>>>> output only to the following: >>>>>>>> >>>>>>>> >>>>>>>> In CLI print: >>>>>>>> "Removing {server} from replication topology," >>>>>>>> "please wait... >>>>>>>> >>>>>>>> The adding info messages: >>>>>>>> >>>>>>>> "checking topology connectivity" | "skipping topology connectivity >>>>>>>> check" >>>>>>>> "checking remaining services" | "skipping check for remaining >>>>>>>> services" >>>>>>>> "performing cleanup" >>>>>>>> "Deleted server {server}" >>>>>>>> >>>>>>>> >>>>>>>>>>> 2.) In the original discussion[2] we assumed that the cleanup >>>>>>>>>>> part >>>>>>>>>>> would >>>>>>>>>>> me a separate API method called during server_del postcallback. >>>>>>>>>>> However >>>>>>>>>>> since the two objects ended up sharing a lot of state (e.g. >>>>>>>>>>> topology >>>>>>>>>>> state from pre-callback, messages) i have merged it to >>>>>>>>>>> server-del. >>>>>>>>>>> That >>>>>>>>>>> makes the code rather unwieldy but I found it difficult to keep >>>>>>>>>>> the >>>>>>>>>>> two >>>>>>>>>>> entities separate without some hacking around framework >>>>>>>>>>> capabilities >>>>>>>>>> I haven't looked at the code but as a general principal having >>>>>>>>>> separate >>>>>>>>>> operations has saved our bacon on more than one occasion. >>>>>>>>> The patch adds a force option, which allows you to re-run >>>>>>>>> server-del >>>>>>>>> even if the master entry does not exist anymore, so I think we are >>>>>>>>> safe. >>>>>>>>> >>>>>>>>>>> 3.) since actions in post-callback require a knowledge about >>>>>>>>>>> topology >>>>>>>>>>> state gathered in pre-callback, I had to store some >>>>>>>>>>> information in >>>>>>>>>>> the >>>>>>>>>>> command's context. Sorry about that, if you know about some >>>>>>>>>>> way to >>>>>>>>>>> circumvent me, let me know. >>>>>>>>>> Looks like it is the only way since you are extending server_del. >>>>>>>>>> Another option would be to drop pre/post and add all this >>>>>>>>>> topology >>>>>>>>>> stuff >>>>>>>>>> directly to server_del execute. >>>>>>>>>> >>>>>>>>>>> 4.) The master can not remove itself. I have implemented an >>>>>>>>>>> ad-hoc >>>>>>>>>>> forwarding of the request to other master that can do the >>>>>>>>>>> job. Is >>>>>>>>>>> this >>>>>>>>>>> okay? >>>>>>>>> Why can't the master remove itself? >>>>>>>>> >>>>>>>> Because it removes its own replication agreements hence any >>>>>>>> changes in >>>>>>>> DIT (like removed principals, s4u2 proxy targets etc.) won't >>>>>>>> replicate >>>>>>>> to other masters. >>>>>>> It shouldn't remove replication agreements, in fact this should be >>>>>>> prevented by the topology plugin. >>>>>>> The removal of the agreements will be triggered by removing the >>>>>>> master >>>>>>> entry >>>>>> That is true, but there is a plenty of cleanup code that is executed >>>>>> *after* the master entry is removed and these changes would not >>>>>> replicate if the agreements were removed by topology plugin in the >>>>>> meanwhile. >>>>> What kind of cleanup is it? Can it be done before instead? >>>>> >>>> Well most of the code can be run in pre-callback if all the checks are >>>> passed/forced. >>>> >>>> However there is a check for deleted segments and this one should be >>>> run after the removal of master entry to see if topology plugin >>>> removed all dangling segments pointing to master. I am not quite sure >>>> if it make sense to run this check in the master which is being >>>> removed. >>> no, it is not guranteed that the information on the removed master will >>> be correct. If the del is applied to the to be removed master the >>> topology plugin will only on a master which is remaining start the >>> removal of segments, these will alos be replicated back to the removed >>> master, but the repl agreements to this master will also be removed, so >>> no gurantee which mods will be available on the removed master, and you >>> should also be able to remove a master if it is down - so applying the >>> full removal on a remaining server makes sense. >>> >>> What is the behaviour if the removal of a server would disconnect >>> topology ? >>> >>> >> What would be the use-case for master to remove itself? > I don't think that there is a use case except uninstall, but this > doesen't prevent users to run the command. And then there are a few > options how to handle this. > - accept it and try to do the best > - reject it and say it should be run on any other master > - automatically execute this on another master - I think this is > Martin's current plan Yes, also if you run `ipa server del $server` from a client that talks to $server, what should we do? current code handle this by forwarding the request to other master as Ludwig pointed out. >> >> The only one I see, which was proposed in design page is that in >> `ipa-server-install --uninstall` the installer would call `ipa >> server-del $to_be_removed` on different replica so that uninstallation >> would be done in single step. But effectively this is not removing >> itself from API point of view. >> >> Calling `ipa server-del $me` without subsequent uninstallation seems >> pointless to me. In `ipa-replica-manage` a replica can't remove itself >> as well. > -- Martin^3 Babinsky From mbasti at redhat.com Thu Apr 21 11:47:52 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 13:47:52 +0200 Subject: [Freeipa-devel] [PATCH] 0015, 16 webui: Add 'Skip overlap check' checkbox to the dns adder dialogs In-Reply-To: <5717A76D.3020000@redhat.com> References: <570F7904.6000908@redhat.com> <570F871C.1070209@redhat.com> <5717A76D.3020000@redhat.com> Message-ID: <5718BDE8.5070004@redhat.com> On 20.04.2016 17:59, Pavel Vomacka wrote: > > > On 04/14/2016 02:03 PM, Martin Basti wrote: >> >> >> On 14.04.2016 13:03, Pavel Vomacka wrote: >>> Hello, >>> >>> The first patch (0015) adds the checkbox to the dns zone adder dialog. >>> >>> The second patch (0016) adds the 'skip overlap check' checkbox to >>> the dns forward zone adder dialog. This patch requires the previous >>> one. The patch 0016 might not be used in case that the dns forward >>> zone dialog shouldn't contain that checkbox. >>> >>> -- >>> Pavel^3 Vomacka >>> >>> >> Can we add hint to webUI what 'skip overlap check' means? Maybe >> description from ipa dns[forward]zone-add --help. >> >> Martin^2 >> >> > Yes, it is included in these new pathes. > > -- > Pavel^3 Vomacka > > > Works for me -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Apr 21 12:22:08 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Apr 2016 14:22:08 +0200 Subject: [Freeipa-devel] [WIP PATCH] server-del: perform full master removal in managed topology In-Reply-To: <5718A772.2010103@redhat.com> References: <570E5C67.40201@redhat.com> <570E617C.3060503@redhat.com> <570F379F.4000101@redhat.com> <570F5C0B.5010706@redhat.com> <570F66F2.7050407@redhat.com> <57160BAF.4020702@redhat.com> <635a45c9-b3fc-2430-85cb-67a5c77d74c3@redhat.com> <57188B4D.70707@redhat.com> <5718922A.40209@redhat.com> <5718A772.2010103@redhat.com> Message-ID: <5718C5F0.8080605@redhat.com> On 04/21/2016 12:12 PM, Petr Vobornik wrote: > On 04/21/2016 10:41 AM, Ludwig Krispenz wrote: >> >> On 04/21/2016 10:11 AM, Martin Babinsky wrote: >>> On 04/21/2016 09:21 AM, Jan Cholasta wrote: >>>> On 19.4.2016 12:42, Martin Babinsky wrote: >>>>> On 04/14/2016 11:46 AM, Ludwig Krispenz wrote: >>>>>> >>>>>> On 04/14/2016 10:59 AM, Martin Babinsky wrote: >>>>>>> On 04/14/2016 08:24 AM, Jan Cholasta wrote: >>>>>>>> On 13.4.2016 17:10, Rob Crittenden wrote: >>>>>>>>> Martin Babinsky wrote: >>>>>>>>>> This is a WIP patch which moves the `ipa-replica-manage del` >>>>>>>>>> subcommand >>>>>>>>>> to the 'server-del' API method and exposes it as CLI command[1]. >>>>>>>>>> A CI >>>>>>>>>> test suite is also included. >>>>>>>>>> >>>>>>>>>> There are some issues with the patch I would like to discuss in >>>>>>>>>> more >>>>>>>>>> detail on the list: >>>>>>>>>> >>>>>>>>>> 1.) In the original subcommand there was a lot of output (mostly >>>>>>>>>> print >>>>>>>>>> statements) during all stages of master removal. I have tried to >>>>>>>>>> port >>>>>>>>>> these as messages to the command which results in quite voluminous >>>>>>>>>> response sent back to the frontend. Should we try to reduce the >>>>>>>>>> output? >>>>>>>>> >>>>>>>>> I don't think it applies anymore. These messages were there so the >>>>>>>>> user >>>>>>>>> would know something was happening. If it is an API command there >>>>>>>>> isn't >>>>>>>>> much we can do other than add something to the cli to print "This >>>>>>>>> could >>>>>>>>> take a bit" before making the call. >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>> This is already implemented in PoC. So I guess we may reduce the >>>>>>> output only to the following: >>>>>>> >>>>>>> >>>>>>> In CLI print: >>>>>>> "Removing {server} from replication topology," >>>>>>> "please wait... >>>>>>> >>>>>>> The adding info messages: >>>>>>> >>>>>>> "checking topology connectivity" | "skipping topology connectivity >>>>>>> check" >>>>>>> "checking remaining services" | "skipping check for remaining >>>>>>> services" >>>>>>> "performing cleanup" >>>>>>> "Deleted server {server}" >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>> 2.) In the original discussion[2] we assumed that the cleanup part >>>>>>>>>> would >>>>>>>>>> me a separate API method called during server_del postcallback. >>>>>>>>>> However >>>>>>>>>> since the two objects ended up sharing a lot of state (e.g. >>>>>>>>>> topology >>>>>>>>>> state from pre-callback, messages) i have merged it to server-del. >>>>>>>>>> That >>>>>>>>>> makes the code rather unwieldy but I found it difficult to keep >>>>>>>>>> the >>>>>>>>>> two >>>>>>>>>> entities separate without some hacking around framework >>>>>>>>>> capabilities >>>>>>>>> >>>>>>>>> I haven't looked at the code but as a general principal having >>>>>>>>> separate >>>>>>>>> operations has saved our bacon on more than one occasion. >>>>>>>> >>>>>>>> The patch adds a force option, which allows you to re-run server-del >>>>>>>> even if the master entry does not exist anymore, so I think we are >>>>>>>> safe. >>>>>>>> >>>>>>>>> >>>>>>>>>> 3.) since actions in post-callback require a knowledge about >>>>>>>>>> topology >>>>>>>>>> state gathered in pre-callback, I had to store some information in >>>>>>>>>> the >>>>>>>>>> command's context. Sorry about that, if you know about some way to >>>>>>>>>> circumvent me, let me know. >>>>>>>>> >>>>>>>>> Looks like it is the only way since you are extending server_del. >>>>>>>>> Another option would be to drop pre/post and add all this topology >>>>>>>>> stuff >>>>>>>>> directly to server_del execute. >>>>>>>>> >>>>>>>>>> 4.) The master can not remove itself. I have implemented an ad-hoc >>>>>>>>>> forwarding of the request to other master that can do the job. Is >>>>>>>>>> this >>>>>>>>>> okay? >>>>>>>> >>>>>>>> Why can't the master remove itself? >>>>>>>> >>>>>>> Because it removes its own replication agreements hence any >>>>>>> changes in >>>>>>> DIT (like removed principals, s4u2 proxy targets etc.) won't >>>>>>> replicate >>>>>>> to other masters. >>>>>> It shouldn't remove replication agreements, in fact this should be >>>>>> prevented by the topology plugin. >>>>>> The removal of the agreements will be triggered by removing the master >>>>>> entry >>>>> >>>>> That is true, but there is a plenty of cleanup code that is executed >>>>> *after* the master entry is removed and these changes would not >>>>> replicate if the agreements were removed by topology plugin in the >>>>> meanwhile. >>>> >>>> What kind of cleanup is it? Can it be done before instead? >>>> >>> >>> Well most of the code can be run in pre-callback if all the checks are >>> passed/forced. >>> >>> However there is a check for deleted segments and this one should be >>> run after the removal of master entry to see if topology plugin >>> removed all dangling segments pointing to master. I am not quite sure >>> if it make sense to run this check in the master which is being removed. >> no, it is not guranteed that the information on the removed master will >> be correct. If the del is applied to the to be removed master the >> topology plugin will only on a master which is remaining start the >> removal of segments, these will alos be replicated back to the removed >> master, but the repl agreements to this master will also be removed, so >> no gurantee which mods will be available on the removed master, and you >> should also be able to remove a master if it is down - so applying the >> full removal on a remaining server makes sense. >> >> What is the behaviour if the removal of a server would disconnect >> topology ? >> >> > > What would be the use-case for master to remove itself? > > The only one I see, which was proposed in design page is that in > `ipa-server-install --uninstall` the installer would call `ipa > server-del $to_be_removed` on different replica so that uninstallation > would be done in single step. But effectively this is not removing > itself from API point of view. > > Calling `ipa server-del $me` without subsequent uninstallation seems > pointless to me. In `ipa-replica-manage` a replica can't remove itself > as well. > We have been discussing this with Jan and we challenged the current workflow of replica removal, since it is not entirely symmetrical to the replica installation in domain level 1. That's why we have devised the following "demotion" scheme during server-del: 1.) checks for topology connectivity and remaining CA/DNS roles are performed 2.) the host is removed from 'ipaservers' group (we would need a 'host can remove itself from the ipaservers' ACI for that 3.) host's ldap principal will be removed from replication managers group 4.) finally the master entry itself is removed. This should trigger the topology plugin which will contact remove master and remove dangling segments 5.) to preserve original behavior which also removes host keytab and principals, the master shall contact remote replica to perform 'host-disable' of the master (the only step that would require 'assisted suicide'). We may add option to 'server-del' to keep/disable host entry so that we can demote promoted replicas back to clients in the future. What do you think of this approach? -- Martin^3 Babinsky From mrniranjan at fedoraproject.org Thu Apr 21 12:33:56 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Thu, 21 Apr 2016 18:03:56 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5718A13F.5070809@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> <57178E88.40207@redhat.com> <20160421052520.GA5879@mniranja.pnq.csb> <5718A13F.5070809@redhat.com> Message-ID: <20160421123356.GA25016@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/21/2016 07:25 AM, Niranjan wrote: > > Petr Viktorin wrote: > >> On 04/20/2016 06:11 AM, Niranjan wrote: > >>> Petr Viktorin wrote: > >>>> On 04/18/2016 12:39 PM, Niranjan wrote: > >>>>> Niranjan wrote: > >>>>>> Niranjan wrote: > >>>>>>> Petr Viktorin wrote: > >>>>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>>>>>> Greetings, > >>>>>>>>> > >>>>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>>>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>>>>>> installed. > >>>>>>>> > >>>>>>>> Wow. I'm surprised the only problem on Windows is the "set -e". > >>>>>>>> > >>>>>>>> Regarding the patch: > >>>>>>>> > >>>>>>>> - Why is get_winhost_class needed? I don't see it called anywhere. > >>>>>>>> - Similarly, why is host_type needed? Your patch only sets it. > >>>>>>>> > >>>>>>>> If run_command of WinHost and Unix hosts are this similar, I would put > >>>>>>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >>>>>>>> attribute named e.g. "command_prelude", use it in run_command, and move > >>>>>>>> run_command from Host to BaseHost. > >>>>>>>> Would that work, or am I missing something? > >>>>>>> How do we detect the host is windows/unix then , we still need host_type > >>>>>>> to know what the type of host is (unix/windows)? > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Petr Viktorin > >>>>>> Please review the attached patch. > >>>> > >>>> Sorry for the delay. > >>>> > >>>> The information about whether the host is Unix or Windows is available: > >>>> the class is either Host or WinHost, so I don't think an extra host_type > >>>> is necessary. > >>>> I'd be open to adding host_type as *configuration* (and corresponding > >>>> attribute) if it also selected the actual Host class. Currently to use > >>>> WinHost you need to write custom code. > >>> I would like to have host_type available. We would like to add more > >>> functions in classes that override Host/WinHost class , which > >>> can be then called depending upon the host_type. > >> > >> Ah, I see; you're not using the WinHost subclass right now. > >> > >> I added a host_type; it is used to select the Host class. > >> You can define a "host_classes" dict in your Domain class to list Host > >> classes, and the particular Host class will be selected according to the > >> host_type. > >> > >> The usage would be like this: > >> > >> --------- > >> > >> class QeHost(QeBaseHost): > >> """Linux host class""" > >> @classmethod > >> def gethostname(self): > >> """ Return system hostname """ > >> cmd = self.run_command(['hostname'], raiseonerr=False) > >> return cmd.stdout_text.strip() > >> ... > >> > >> class QeWinHost(QeBaseHost, pytest_multihost.host.WinHost): > >> """Windows host class""" > >> > >> @classmethod > >> def gethostname(self): > >> """ Return system hostname """ > >> cmd = self.run_command(['hostname', '-A'], set_env=False, > >> raiseonerr=False) > >> return cmd.stdout_text.strip() > >> ... > >> > >> > >> class QeDomain: > >> ... > >> host_classes = {'default': QeHost, 'windows': QeWinHost} > >> > >> # remove your existing "get_host_class" method when host_classes is > >> defined > >> ... > >> > >> --------- > >> > >> And in the config, define host_type to 'windows'. > >> > >> > >> Would it work for you like this? > > Most of the things worked [...] > > > > Specifically i see that you have "transport_class = transport.SSHTransport" added to Host Class > > but not in WinHost class. So initially it failed transport class not available, but after i added below lines > > it worked: > > > > class QeBaseHost(pytest_multihost.host.BaseHost): > > """ QeBaseHost subclass of multhost plugin BaseHost class """ > > transport_class = transport.SSHTransport > > > > Apart from the above minor thing, Everything else works. Again the above 3 lines solves the minor issue, > > just wanted to know if the above lines are to be added and is by design. > > Right, since SSHTransport works for Windows hosts as well, I've added it > to BaseHost. With this version of patch it shouldn't be necessary to add > it in your code. > > If this works for you, I'll commit it and release. I will test and let you know asap > > > -- > Petr Viktorin > From 7eb346c0bf29b1fddfd962675258a3895fbc8300 Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] Add 'host_type', make it possible to use Windows hosts > > Add global parameter windows_test_dir to specify test directory > for Windows > Windows hosts (WinHost) use this directory by default. > test_dir can now be set individually for each host. > Move run_command from Host class to BaseHost class > Add a "host_type" configuration option and Host attribute. This > is used to select the Host subclass. By default it can > be 'default' or 'windows' (but Config subclasses can define more). > > Signed-off-by: Petr Viktorin > --- > pytest_multihost/config.py | 15 +++++++-- > pytest_multihost/host.py | 57 ++++++++++++++++++++------------- > test_pytestmultihost/test_testconfig.py | 12 ++++++- > 3 files changed, 58 insertions(+), 26 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c2..197d7ad 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > @@ -179,8 +182,16 @@ class Domain(object): > self.hosts = [] > > def get_host_class(self, host_dict): > - from pytest_multihost.host import Host > - return Host > + host_type = host_dict.get('host_type', 'default') > + return self.host_classes[host_type] > + > + @property > + def host_classes(self): > + from pytest_multihost.host import Host, WinHost > + return { > + 'default': Host, > + 'windows': WinHost, > + } > > @property > def roles(self): > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db5..826372d 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -24,10 +24,13 @@ class BaseHost(object): > > See README for an overview of the core classes. > """ > - transport_class = None > + transport_class = transport.SSHTransport > + command_prelude = '' > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, password=None, > + test_dir=None, host_type=None): > + self.host_type = host_type > self.domain = domain > self.role = str(role) > if username is None: > @@ -40,6 +43,10 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if test_dir is None: > + self.test_dir = domain.config.test_dir > + else: > + self.test_dir = test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -78,7 +85,7 @@ class BaseHost(object): > self.host_key = None > self.ssh_port = 22 > > - self.env_sh_path = os.path.join(domain.config.test_dir, 'env.sh') > + self.env_sh_path = os.path.join(self.test_dir, 'env.sh') > > self.log_collectors = [] > > @@ -118,20 +125,28 @@ class BaseHost(object): > > username = dct.pop('username', None) > password = dct.pop('password', None) > + host_type = dct.pop('host_type', 'default') > > check_config_dict_empty(dct, 'host %s' % hostname) > > - return cls(domain, hostname, role, ip, external_hostname, > - username, password) > + return cls(domain, hostname, role, > + ip=ip, > + external_hostname=external_hostname, > + username=username, > + password=password, > + host_type=host_type) > > def to_dict(self): > """Export info about this Host to a dict""" > - return { > + result = { > 'name': str(self.hostname), > 'ip': self.ip, > 'role': self.role, > 'external_hostname': self.external_hostname, > } > + if self.host_type != 'default': > + result['host_type'] = self.host_type > + return result > > @property > def config(self): > @@ -204,28 +219,18 @@ class BaseHost(object): > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > - > - > -class Host(BaseHost): > - """A Unix host""" > - transport_class = transport.SSHTransport > - > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > # Set working directory > if cwd is None: > - cwd = self.config.test_dir > + cwd = self.test_dir > command.stdin.write('cd %s\n' % shell_quote(cwd)) > > # Set the environment > if set_env: > command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > + > + if self.command_prelude: > + command.stdin.write(self.command_prelude) > > if isinstance(argv, basestring): > # Run a shell command given as a string > @@ -247,11 +252,17 @@ class Host(BaseHost): > return command > > > +class Host(BaseHost): > + """A Unix host""" > + command_prelude = 'set -e\n' > + > + > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > - > - This is a stub; Windows hosts can't currently be interacted with. > """ > > - pass > + def __init__(self, domain, hostname, role, **kwargs): > + # Set test_dir to the Windows directory, if not given explicitly > + kwargs.setdefault('test_dir', domain.config.windows_test_dir) > + super(WinHost, self).__init__(domain, hostname, role, **kwargs) > diff --git a/test_pytestmultihost/test_testconfig.py b/test_pytestmultihost/test_testconfig.py > index 8239a2c..b32fd38 100644 > --- a/test_pytestmultihost/test_testconfig.py > +++ b/test_pytestmultihost/test_testconfig.py > @@ -116,7 +116,8 @@ class TestComplexConfig(CheckConfig): > dict(name='srv', ip='192.0.2.33', role='srv'), > ]), > dict(name='adomain2.test', hosts=[ > - dict(name='master.adomain2.test', ip='192.0.2.65'), > + dict(name='master.adomain2.test', ip='192.0.2.65', > + host_type='windows'), > ]), > ], > ) > @@ -197,6 +198,7 @@ class TestComplexConfig(CheckConfig): > ip="192.0.2.65", > external_hostname="master.adomain2.test", > role="master", > + host_type='windows', > ), > ], > ), > @@ -228,3 +230,11 @@ class TestComplexConfig(CheckConfig): > ad_dom = conf.domains[1] > assert ad_dom.roles == ['srv'] > assert ad_dom.extra_roles == ['srv'] > + > + assert conf.test_dir != conf.windows_test_dir > + > + assert conf.domains[0].hosts[0].host_type == 'default' > + assert conf.domains[0].hosts[0].test_dir == conf.test_dir > + > + assert conf.domains[2].hosts[0].host_type == 'windows' > + assert conf.domains[2].hosts[0].test_dir == conf.windows_test_dir > -- > 2.5.5 > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Thu Apr 21 13:04:43 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Thu, 21 Apr 2016 18:34:43 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <5718A13F.5070809@redhat.com> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> <57178E88.40207@redhat.com> <20160421052520.GA5879@mniranja.pnq.csb> <5718A13F.5070809@redhat.com> Message-ID: <20160421130443.GA29591@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/21/2016 07:25 AM, Niranjan wrote: > > Petr Viktorin wrote: > >> On 04/20/2016 06:11 AM, Niranjan wrote: > >>> Petr Viktorin wrote: > >>>> On 04/18/2016 12:39 PM, Niranjan wrote: > >>>>> Niranjan wrote: > >>>>>> Niranjan wrote: > >>>>>>> Petr Viktorin wrote: > >>>>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>>>>>> Greetings, > >>>>>>>>> > >>>>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>>>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>>>>>> installed. > >>>>>>>> > >>>>>>>> Wow. I'm surprised the only problem on Windows is the "set -e". > >>>>>>>> > >>>>>>>> Regarding the patch: > >>>>>>>> > >>>>>>>> - Why is get_winhost_class needed? I don't see it called anywhere. > >>>>>>>> - Similarly, why is host_type needed? Your patch only sets it. > >>>>>>>> > >>>>>>>> If run_command of WinHost and Unix hosts are this similar, I would put > >>>>>>>> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >>>>>>>> attribute named e.g. "command_prelude", use it in run_command, and move > >>>>>>>> run_command from Host to BaseHost. > >>>>>>>> Would that work, or am I missing something? > >>>>>>> How do we detect the host is windows/unix then , we still need host_type > >>>>>>> to know what the type of host is (unix/windows)? > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Petr Viktorin > >>>>>> Please review the attached patch. > >>>> > >>>> Sorry for the delay. > >>>> > >>>> The information about whether the host is Unix or Windows is available: > >>>> the class is either Host or WinHost, so I don't think an extra host_type > >>>> is necessary. > >>>> I'd be open to adding host_type as *configuration* (and corresponding > >>>> attribute) if it also selected the actual Host class. Currently to use > >>>> WinHost you need to write custom code. > >>> I would like to have host_type available. We would like to add more > >>> functions in classes that override Host/WinHost class , which > >>> can be then called depending upon the host_type. > >> > >> Ah, I see; you're not using the WinHost subclass right now. > >> > >> I added a host_type; it is used to select the Host class. > >> You can define a "host_classes" dict in your Domain class to list Host > >> classes, and the particular Host class will be selected according to the > >> host_type. > >> > >> The usage would be like this: > >> > >> --------- > >> > >> class QeHost(QeBaseHost): > >> """Linux host class""" > >> @classmethod > >> def gethostname(self): > >> """ Return system hostname """ > >> cmd = self.run_command(['hostname'], raiseonerr=False) > >> return cmd.stdout_text.strip() > >> ... > >> > >> class QeWinHost(QeBaseHost, pytest_multihost.host.WinHost): > >> """Windows host class""" > >> > >> @classmethod > >> def gethostname(self): > >> """ Return system hostname """ > >> cmd = self.run_command(['hostname', '-A'], set_env=False, > >> raiseonerr=False) > >> return cmd.stdout_text.strip() > >> ... > >> > >> > >> class QeDomain: > >> ... > >> host_classes = {'default': QeHost, 'windows': QeWinHost} > >> > >> # remove your existing "get_host_class" method when host_classes is > >> defined > >> ... > >> > >> --------- > >> > >> And in the config, define host_type to 'windows'. > >> > >> > >> Would it work for you like this? > > Most of the things worked [...] > > > > Specifically i see that you have "transport_class = transport.SSHTransport" added to Host Class > > but not in WinHost class. So initially it failed transport class not available, but after i added below lines > > it worked: > > > > class QeBaseHost(pytest_multihost.host.BaseHost): > > """ QeBaseHost subclass of multhost plugin BaseHost class """ > > transport_class = transport.SSHTransport > > > > Apart from the above minor thing, Everything else works. Again the above 3 lines solves the minor issue, > > just wanted to know if the above lines are to be added and is by design. > > Right, since SSHTransport works for Windows hosts as well, I've added it > to BaseHost. With this version of patch it shouldn't be necessary to add > it in your code. > > If this works for you, I'll commit it and release. With this latest patch it worked after removing the line "transport_class = transport.SSHTransport" from QeBaseHost class. Please go ahead and commit it. > > > -- > Petr Viktorin > From 7eb346c0bf29b1fddfd962675258a3895fbc8300 Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Tue, 12 Apr 2016 17:18:10 +0530 > Subject: [PATCH] Add 'host_type', make it possible to use Windows hosts > > Add global parameter windows_test_dir to specify test directory > for Windows > Windows hosts (WinHost) use this directory by default. > test_dir can now be set individually for each host. > Move run_command from Host class to BaseHost class > Add a "host_type" configuration option and Host attribute. This > is used to select the Host subclass. By default it can > be 'default' or 'windows' (but Config subclasses can define more). > > Signed-off-by: Petr Viktorin > --- > pytest_multihost/config.py | 15 +++++++-- > pytest_multihost/host.py | 57 ++++++++++++++++++++------------- > test_pytestmultihost/test_testconfig.py | 12 ++++++- > 3 files changed, 58 insertions(+), 26 deletions(-) > > diff --git a/pytest_multihost/config.py b/pytest_multihost/config.py > index 31045c2..197d7ad 100644 > --- a/pytest_multihost/config.py > +++ b/pytest_multihost/config.py > @@ -45,6 +45,7 @@ class Config(object): > self.ssh_password = kwargs.get('ssh_password') > self.ssh_username = kwargs.get('ssh_username', 'root') > self.ipv6 = bool(kwargs.get('ipv6', False)) > + self.windows_test_dir = kwargs.get('windows_test_dir', '/home/Administrator') > > if not self.ssh_password and not self.ssh_key_filename: > self.ssh_key_filename = '~/.ssh/id_rsa' > @@ -80,6 +81,8 @@ class Config(object): > dct['ssh_key_filename'] = dct.pop('root_ssh_key_filename') > if 'root_password' in dct: > dct['ssh_password'] = dct.pop('root_password') > + if 'windows_test_dir' in dct: > + dct['windows_test_dir'] = dct.pop('windows_test_dir') > > all_init_args = set(init_args) | set(cls.extra_init_args) > extra_args = set(dct) - all_init_args > @@ -179,8 +182,16 @@ class Domain(object): > self.hosts = [] > > def get_host_class(self, host_dict): > - from pytest_multihost.host import Host > - return Host > + host_type = host_dict.get('host_type', 'default') > + return self.host_classes[host_type] > + > + @property > + def host_classes(self): > + from pytest_multihost.host import Host, WinHost > + return { > + 'default': Host, > + 'windows': WinHost, > + } > > @property > def roles(self): > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index e6c0db5..826372d 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -24,10 +24,13 @@ class BaseHost(object): > > See README for an overview of the core classes. > """ > - transport_class = None > + transport_class = transport.SSHTransport > + command_prelude = '' > > def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None, username=None, password=None): > + external_hostname=None, username=None, password=None, > + test_dir=None, host_type=None): > + self.host_type = host_type > self.domain = domain > self.role = str(role) > if username is None: > @@ -40,6 +43,10 @@ class BaseHost(object): > else: > self.ssh_key_filename = None > self.ssh_password = password > + if test_dir is None: > + self.test_dir = domain.config.test_dir > + else: > + self.test_dir = test_dir > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -78,7 +85,7 @@ class BaseHost(object): > self.host_key = None > self.ssh_port = 22 > > - self.env_sh_path = os.path.join(domain.config.test_dir, 'env.sh') > + self.env_sh_path = os.path.join(self.test_dir, 'env.sh') > > self.log_collectors = [] > > @@ -118,20 +125,28 @@ class BaseHost(object): > > username = dct.pop('username', None) > password = dct.pop('password', None) > + host_type = dct.pop('host_type', 'default') > > check_config_dict_empty(dct, 'host %s' % hostname) > > - return cls(domain, hostname, role, ip, external_hostname, > - username, password) > + return cls(domain, hostname, role, > + ip=ip, > + external_hostname=external_hostname, > + username=username, > + password=password, > + host_type=host_type) > > def to_dict(self): > """Export info about this Host to a dict""" > - return { > + result = { > 'name': str(self.hostname), > 'ip': self.ip, > 'role': self.role, > 'external_hostname': self.external_hostname, > } > + if self.host_type != 'default': > + result['host_type'] = self.host_type > + return result > > @property > def config(self): > @@ -204,28 +219,18 @@ class BaseHost(object): > does not exit with return code 0 > :param cwd: The working directory for the command > """ > - raise NotImplementedError() > - > - > -class Host(BaseHost): > - """A Unix host""" > - transport_class = transport.SSHTransport > - > - def run_command(self, argv, set_env=True, stdin_text=None, > - log_stdout=True, raiseonerr=True, > - cwd=None): > - # This will give us a Bash shell > command = self.transport.start_shell(argv, log_stdout=log_stdout) > - > # Set working directory > if cwd is None: > - cwd = self.config.test_dir > + cwd = self.test_dir > command.stdin.write('cd %s\n' % shell_quote(cwd)) > > # Set the environment > if set_env: > command.stdin.write('. %s\n' % shell_quote(self.env_sh_path)) > - command.stdin.write('set -e\n') > + > + if self.command_prelude: > + command.stdin.write(self.command_prelude) > > if isinstance(argv, basestring): > # Run a shell command given as a string > @@ -247,11 +252,17 @@ class Host(BaseHost): > return command > > > +class Host(BaseHost): > + """A Unix host""" > + command_prelude = 'set -e\n' > + > + > class WinHost(BaseHost): > """ > Representation of a remote Windows host. > - > - This is a stub; Windows hosts can't currently be interacted with. > """ > > - pass > + def __init__(self, domain, hostname, role, **kwargs): > + # Set test_dir to the Windows directory, if not given explicitly > + kwargs.setdefault('test_dir', domain.config.windows_test_dir) > + super(WinHost, self).__init__(domain, hostname, role, **kwargs) > diff --git a/test_pytestmultihost/test_testconfig.py b/test_pytestmultihost/test_testconfig.py > index 8239a2c..b32fd38 100644 > --- a/test_pytestmultihost/test_testconfig.py > +++ b/test_pytestmultihost/test_testconfig.py > @@ -116,7 +116,8 @@ class TestComplexConfig(CheckConfig): > dict(name='srv', ip='192.0.2.33', role='srv'), > ]), > dict(name='adomain2.test', hosts=[ > - dict(name='master.adomain2.test', ip='192.0.2.65'), > + dict(name='master.adomain2.test', ip='192.0.2.65', > + host_type='windows'), > ]), > ], > ) > @@ -197,6 +198,7 @@ class TestComplexConfig(CheckConfig): > ip="192.0.2.65", > external_hostname="master.adomain2.test", > role="master", > + host_type='windows', > ), > ], > ), > @@ -228,3 +230,11 @@ class TestComplexConfig(CheckConfig): > ad_dom = conf.domains[1] > assert ad_dom.roles == ['srv'] > assert ad_dom.extra_roles == ['srv'] > + > + assert conf.test_dir != conf.windows_test_dir > + > + assert conf.domains[0].hosts[0].host_type == 'default' > + assert conf.domains[0].hosts[0].test_dir == conf.test_dir > + > + assert conf.domains[2].hosts[0].host_type == 'windows' > + assert conf.domains[2].hosts[0].test_dir == conf.windows_test_dir > -- > 2.5.5 > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Apr 21 13:25:25 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Apr 2016 15:25:25 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> Message-ID: <5718D4C5.1020906@redhat.com> On 04/21/2016 11:24 AM, Milan Kub?k wrote: > On 04/05/2016 12:07 PM, Martin Babinsky wrote: >> On 04/05/2016 10:24 AM, Milan Kub?k wrote: >>> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>>> >>>>>> Patches attached. >>>>>> >>>>>> >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hi Milan, >>>>> >>>>> >>>>> >>>>> I would be more happy if you could send a separate patch for the >>>>> context >>>>> manager fix, since the issue is orthogonal to the added test case >>>>> (even >>>>> if the test suite explodes without it). >>>>> >>>>> >>>>> >>>>> Otherwise LGTM. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> Done. Patch 0035 now applies to all branches, context manager fix >>>> needs separate patch for ipa-4-2. >>>> >>> Updated commit message in patches 0036 to include the ticket. >>> >> Thanks, ACK. >> > Add freeipa-devel back to the loop & push request :) > > -- > Milan Kubik > Ah sorry I forgot how to mailing list. ACK again for our push-bot (aka mbasti) -- Martin^3 Babinsky From mbabinsk at redhat.com Thu Apr 21 13:29:47 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Apr 2016 15:29:47 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <5718D4C5.1020906@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> <5718D4C5.1020906@redhat.com> Message-ID: <5718D5CB.200@redhat.com> On 04/21/2016 03:25 PM, Martin Babinsky wrote: > On 04/21/2016 11:24 AM, Milan Kub?k wrote: >> On 04/05/2016 12:07 PM, Martin Babinsky wrote: >>> On 04/05/2016 10:24 AM, Milan Kub?k wrote: >>>> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>>>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>>>> >>>>>>> Patches attached. >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi Milan, >>>>>> >>>>>> >>>>>> >>>>>> I would be more happy if you could send a separate patch for the >>>>>> context >>>>>> manager fix, since the issue is orthogonal to the added test case >>>>>> (even >>>>>> if the test suite explodes without it). >>>>>> >>>>>> >>>>>> >>>>>> Otherwise LGTM. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Done. Patch 0035 now applies to all branches, context manager fix >>>>> needs separate patch for ipa-4-2. >>>>> >>>> Updated commit message in patches 0036 to include the ticket. >>>> >>> Thanks, ACK. >>> >> Add freeipa-devel back to the loop & push request :) >> >> -- >> Milan Kubik >> > Ah sorry I forgot how to mailing list. > > ACK again for our push-bot (aka mbasti) > I see that the fix for the failing test was already pushed so you can remove the xfail mark from the test and it should be all green now. Sorry for the confusion. -- Martin^3 Babinsky From mbasti at redhat.com Thu Apr 21 13:30:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 15:30:25 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <5718D4C5.1020906@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> <5718D4C5.1020906@redhat.com> Message-ID: <5718D5F1.3030909@redhat.com> On 21.04.2016 15:25, Martin Babinsky wrote: > On 04/21/2016 11:24 AM, Milan Kub?k wrote: >> On 04/05/2016 12:07 PM, Martin Babinsky wrote: >>> On 04/05/2016 10:24 AM, Milan Kub?k wrote: >>>> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>>>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>>>> >>>>>>> Patches attached. >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi Milan, >>>>>> >>>>>> >>>>>> >>>>>> I would be more happy if you could send a separate patch for the >>>>>> context >>>>>> manager fix, since the issue is orthogonal to the added test case >>>>>> (even >>>>>> if the test suite explodes without it). >>>>>> >>>>>> >>>>>> >>>>>> Otherwise LGTM. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Done. Patch 0035 now applies to all branches, context manager fix >>>>> needs separate patch for ipa-4-2. >>>>> >>>> Updated commit message in patches 0036 to include the ticket. >>>> >>> Thanks, ACK. >>> >> Add freeipa-devel back to the loop & push request :) >> >> -- >> Milan Kubik >> > Ah sorry I forgot how to mailing list. > > ACK again for our push-bot (aka mbasti) > PushError: Push rejected by bot (Reason: test should not be marked as xfail) From mbasti at redhat.com Thu Apr 21 13:48:50 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 15:48:50 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <5718D5F1.3030909@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> <5718D4C5.1020906@redhat.com> <5718D5F1.3030909@redhat.com> Message-ID: <5718DA42.3010004@redhat.com> On 21.04.2016 15:30, Martin Basti wrote: > > > On 21.04.2016 15:25, Martin Babinsky wrote: >> On 04/21/2016 11:24 AM, Milan Kub?k wrote: >>> On 04/05/2016 12:07 PM, Martin Babinsky wrote: >>>> On 04/05/2016 10:24 AM, Milan Kub?k wrote: >>>>> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>>>>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>>>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>>>>> >>>>>>>> Patches attached. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hi Milan, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I would be more happy if you could send a separate patch for the >>>>>>> context >>>>>>> manager fix, since the issue is orthogonal to the added test case >>>>>>> (even >>>>>>> if the test suite explodes without it). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Otherwise LGTM. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Done. Patch 0035 now applies to all branches, context manager fix >>>>>> needs separate patch for ipa-4-2. >>>>>> >>>>> Updated commit message in patches 0036 to include the ticket. >>>>> >>>> Thanks, ACK. >>>> >>> Add freeipa-devel back to the loop & push request :) >>> >>> -- >>> Milan Kubik >>> >> Ah sorry I forgot how to mailing list. >> >> ACK again for our push-bot (aka mbasti) >> > PushError: Push rejected by bot (Reason: test should not be marked as > xfail) > ... because issue was already fixed From mkubik at redhat.com Thu Apr 21 13:55:23 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 21 Apr 2016 15:55:23 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <5718D5CB.200@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> <5718D4C5.1020906@redhat.com> <5718D5CB.200@redhat.com> Message-ID: On 04/21/2016 03:29 PM, Martin Babinsky wrote: > On 04/21/2016 03:25 PM, Martin Babinsky wrote: >> On 04/21/2016 11:24 AM, Milan Kub?k wrote: >>> On 04/05/2016 12:07 PM, Martin Babinsky wrote: >>>> On 04/05/2016 10:24 AM, Milan Kub?k wrote: >>>>> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>>>>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>>>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>>>>> >>>>>>>> Patches attached. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hi Milan, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I would be more happy if you could send a separate patch for the >>>>>>> context >>>>>>> manager fix, since the issue is orthogonal to the added test case >>>>>>> (even >>>>>>> if the test suite explodes without it). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Otherwise LGTM. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Done. Patch 0035 now applies to all branches, context manager fix >>>>>> needs separate patch for ipa-4-2. >>>>>> >>>>> Updated commit message in patches 0036 to include the ticket. >>>>> >>>> Thanks, ACK. >>>> >>> Add freeipa-devel back to the loop & push request :) >>> >>> -- >>> Milan Kubik >>> >> Ah sorry I forgot how to mailing list. >> >> ACK again for our push-bot (aka mbasti) >> > > I see that the fix for the failing test was already pushed so you can > remove the xfail mark from the test and it should be all green now. > > Sorry for the confusion. > I haven't noticed, sorry. Updated patch attached. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0035-2-ipatests-Add-test-case-for-requesting-a-certificate-.patch Type: text/x-patch Size: 1422 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Apr 21 14:30:55 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 21 Apr 2016 16:30:55 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> <5718D4C5.1020906@redhat.com> <5718D5CB.200@redhat.com> Message-ID: <5718E41F.4050201@redhat.com> On 04/21/2016 03:55 PM, Milan Kub?k wrote: > On 04/21/2016 03:29 PM, Martin Babinsky wrote: >> On 04/21/2016 03:25 PM, Martin Babinsky wrote: >>> On 04/21/2016 11:24 AM, Milan Kub?k wrote: >>>> On 04/05/2016 12:07 PM, Martin Babinsky wrote: >>>>> On 04/05/2016 10:24 AM, Milan Kub?k wrote: >>>>>> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>>>>>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>>>>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>>>>>> >>>>>>>>> Patches attached. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hi Milan, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I would be more happy if you could send a separate patch for the >>>>>>>> context >>>>>>>> manager fix, since the issue is orthogonal to the added test case >>>>>>>> (even >>>>>>>> if the test suite explodes without it). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Otherwise LGTM. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Done. Patch 0035 now applies to all branches, context manager fix >>>>>>> needs separate patch for ipa-4-2. >>>>>>> >>>>>> Updated commit message in patches 0036 to include the ticket. >>>>>> >>>>> Thanks, ACK. >>>>> >>>> Add freeipa-devel back to the loop & push request :) >>>> >>>> -- >>>> Milan Kubik >>>> >>> Ah sorry I forgot how to mailing list. >>> >>> ACK again for our push-bot (aka mbasti) >>> >> >> I see that the fix for the failing test was already pushed so you can >> remove the xfail mark from the test and it should be all green now. >> >> Sorry for the confusion. >> > > I haven't noticed, sorry. Updated patch attached. > > > -- > Milan Kubik > All is green, ACK. I would recommend pushing patch 0036 first, then patch 0035 to avoid false negative errors when bisecting. -- Martin^3 Babinsky From mbasti at redhat.com Thu Apr 21 15:09:14 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 17:09:14 +0200 Subject: [Freeipa-devel] [patch 0035] ipatests: Add test case for requesting a certificate with full principal. In-Reply-To: <5718E41F.4050201@redhat.com> References: <56FE4732.30904@redhat.com> <570369D8.609@redhat.com> <570374B6.5020702@redhat.com> <57037622.9050305@redhat.com> <57038E52.3090900@redhat.com> <01b19ed1-c9b2-b74a-00f3-93e3457a18de@redhat.com> <5718D4C5.1020906@redhat.com> <5718D5CB.200@redhat.com> <5718E41F.4050201@redhat.com> Message-ID: <5718ED1A.4020505@redhat.com> On 21.04.2016 16:30, Martin Babinsky wrote: > On 04/21/2016 03:55 PM, Milan Kub?k wrote: >> On 04/21/2016 03:29 PM, Martin Babinsky wrote: >>> On 04/21/2016 03:25 PM, Martin Babinsky wrote: >>>> On 04/21/2016 11:24 AM, Milan Kub?k wrote: >>>>> On 04/05/2016 12:07 PM, Martin Babinsky wrote: >>>>>> On 04/05/2016 10:24 AM, Milan Kub?k wrote: >>>>>>> On 04/05/2016 10:17 AM, Milan Kub?k wrote: >>>>>>>> On 04/05/2016 09:31 AM, Martin Babinsky wrote: >>>>>>>>> On 04/01/2016 12:02 PM, Milan Kub?k wrote: >>>>>>>>> >>>>>>>>>> Patches attached. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5733 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hi Milan, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I would be more happy if you could send a separate patch for the >>>>>>>>> context >>>>>>>>> manager fix, since the issue is orthogonal to the added test case >>>>>>>>> (even >>>>>>>>> if the test suite explodes without it). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Otherwise LGTM. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Done. Patch 0035 now applies to all branches, context manager fix >>>>>>>> needs separate patch for ipa-4-2. >>>>>>>> >>>>>>> Updated commit message in patches 0036 to include the ticket. >>>>>>> >>>>>> Thanks, ACK. >>>>>> >>>>> Add freeipa-devel back to the loop & push request :) >>>>> >>>>> -- >>>>> Milan Kubik >>>>> >>>> Ah sorry I forgot how to mailing list. >>>> >>>> ACK again for our push-bot (aka mbasti) >>>> >>> >>> I see that the fix for the failing test was already pushed so you can >>> remove the xfail mark from the test and it should be all green now. >>> >>> Sorry for the confusion. >>> >> >> I haven't noticed, sorry. Updated patch attached. >> >> >> -- >> Milan Kubik >> > > All is green, ACK. > > I would recommend pushing patch 0036 first, then patch 0035 to avoid > false negative errors when bisecting. > Tests pushed to: master: * b0b9972213760dcf351cdd85dbfe2c38fc21b2e6 ipatests: fix for change_principal context manager * 0472300dffc1b77533a6bb7397d6a5fa11439303 ipatests: Add test case for requesting a certificate with full principal. ipa-4-3: * c4fa656b0e0850ddd6400caaa676eae4ec46da06 ipatests: fix for change_principal context manager * e183030067bae2df318324e9fcaafa8ea272f4b4 ipatests: Add test case for requesting a certificate with full principal. ipa-4-2: * eadd47eec6ceb38b001bc9bff14e2a5aa83eb2ab ipatests: fix for change_principal context manager * ffd670379b16940499c1ef86d676c05886cb1116 ipatests: Add test case for requesting a certificate with full principal. From pspacek at redhat.com Thu Apr 21 15:39:14 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Apr 2016 17:39:14 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1461086255.30315.46.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> <571500DF.20204@redhat.com> <1461008004.30315.15.camel@redhat.com> <5715F65E.2030403@redhat.com> <1461086255.30315.46.camel@redhat.com> Message-ID: <5718F422.4000205@redhat.com> On 19.4.2016 19:17, Simo Sorce wrote: > On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote: >> On 18.4.2016 21:33, Simo Sorce wrote: >>> On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote: >>>> * Find, filter and copy hand-made records from main tree into the >>>> _locations sub-trees. This means that every hand-made record >>>> needs to be copied and synchronized N-times where N = number of IPA >>>> locations. >>> >>> This ^^ seem the one that provides the best semantics for admins and the >>> least unexpected results. >>> >>>> My favorite option for the first version is 'document that enabling >>>> DNS location will hide hand-made records in IPA domain.' >>> >>> I do not think this is acceptable, sorry. >>> >>>> The feature is disabled by default and needs additional configuration >>>> anyway so simply upgrading should not break anything. >>> >>> It is also useless this way. >>> >>>> I'm eager to hear opinions and answers to questions above. >>> >>> HTH, >> >> Well it does not help because you did not answer the questions listed in the >> design page. >> >> Anyway, here is third version of the design. It avoids copying user-made >> records (basically 2 DNAMEs were replaced with bunch of CNAMEs): >> >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29 >> >> It seems like a good middle ground: >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals > > It does seem like a decent middle ground. > And I guess an admin would be able to add custom templates if he wants > to have specific services forwarded to the location specific subtree ? Yes, the bind-dyndb-ldap's RecordGenerator and PerServerConfigInLDAP are generic enough. At the moment we do not plan to expose these mechanisms in user interface, we might do that later on. >> This required changes in RecordGenerator design, too: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator > > I do not see where you specify the specific record names you forward to > the location trees here? I do not understand the question. Let's have a look at the example: # DN specifies DNS node name which will hold the generated record: dn: idnsName=_udp,idnsname=example.com.,cn=dns,dc=example,dc=com # this is equivalent to _udp.example.com. objectClass: idnsTemplateObject objectClass: top objectClass: idnsRecord idnsName: _udp # sub-type determines type of the generated record = DNAME idnsTemplateAttribute;dnamerecord: _udp.\{substitutionvariable_ipalocation\}._locations # generated value will be _udp.your-location._locations # it is a relative name so zone name (example.com) will be automatically appended The template is just string, so you can specify an absolute name if you want: idnsTemplateAttribute;dnamerecord: _udp.\{substitutionvariable_ipalocation\}._locations.another.zone.example. Of course 'ipalocation' is just a variable name so user can define his own in PerServerConfigInLDAP. Is it clearer now? Petr^2 Spacek >> Also, CLI was updated to follow Honza's recommendations from previous e-mails: >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CLI > > Thanks for updating all designs in concert. > > Simo. From simo at redhat.com Thu Apr 21 16:58:43 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 21 Apr 2016 12:58:43 -0400 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <5718F422.4000205@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> <571500DF.20204@redhat.com> <1461008004.30315.15.camel@redhat.com> <5715F65E.2030403@redhat.com> <1461086255.30315.46.camel@redhat.com> <5718F422.4000205@redhat.com> Message-ID: <1461257923.30315.101.camel@redhat.com> On Thu, 2016-04-21 at 17:39 +0200, Petr Spacek wrote: > On 19.4.2016 19:17, Simo Sorce wrote: > > On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote: > >> On 18.4.2016 21:33, Simo Sorce wrote: > >>> On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote: > >>>> * Find, filter and copy hand-made records from main tree into the > >>>> _locations sub-trees. This means that every hand-made record > >>>> needs to be copied and synchronized N-times where N = number of IPA > >>>> locations. > >>> > >>> This ^^ seem the one that provides the best semantics for admins and the > >>> least unexpected results. > >>> > >>>> My favorite option for the first version is 'document that enabling > >>>> DNS location will hide hand-made records in IPA domain.' > >>> > >>> I do not think this is acceptable, sorry. > >>> > >>>> The feature is disabled by default and needs additional configuration > >>>> anyway so simply upgrading should not break anything. > >>> > >>> It is also useless this way. > >>> > >>>> I'm eager to hear opinions and answers to questions above. > >>> > >>> HTH, > >> > >> Well it does not help because you did not answer the questions listed in the > >> design page. > >> > >> Anyway, here is third version of the design. It avoids copying user-made > >> records (basically 2 DNAMEs were replaced with bunch of CNAMEs): > >> > >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29 > >> > >> It seems like a good middle ground: > >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals > > > > It does seem like a decent middle ground. > > And I guess an admin would be able to add custom templates if he wants > > to have specific services forwarded to the location specific subtree ? > > Yes, the bind-dyndb-ldap's RecordGenerator and PerServerConfigInLDAP are > generic enough. At the moment we do not plan to expose these mechanisms in > user interface, we might do that later on. > > > >> This required changes in RecordGenerator design, too: > >> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator > > > > I do not see where you specify the specific record names you forward to > > the location trees here? > > I do not understand the question. Let's have a look at the example: > > # DN specifies DNS node name which will hold the generated record: > dn: idnsName=_udp,idnsname=example.com.,cn=dns,dc=example,dc=com > # this is equivalent to _udp.example.com. > > objectClass: idnsTemplateObject > objectClass: top > objectClass: idnsRecord > idnsName: _udp > > # sub-type determines type of the generated record = DNAME > idnsTemplateAttribute;dnamerecord: > _udp.\{substitutionvariable_ipalocation\}._locations > # generated value will be _udp.your-location._locations > # it is a relative name so zone name (example.com) will be automatically appended > > The template is just string, so you can specify an absolute name if you want: > idnsTemplateAttribute;dnamerecord: > _udp.\{substitutionvariable_ipalocation\}._locations.another.zone.example. > > Of course 'ipalocation' is just a variable name so user can define his own in > PerServerConfigInLDAP. > > Is it clearer now? Sorry I thought you said in option 3 that you would only create records for specific services using CNAMEs I was looking for how you configure which services you are going to pick in that case and couldn't see it. This example is a DNAME one and looks to me it is about option 2 ? -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Apr 21 17:25:29 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 21 Apr 2016 19:25:29 +0200 Subject: [Freeipa-devel] [PATCH] 957 ipa-client-install: fix typo in nslcd service name Message-ID: <57190D09.3050802@redhat.com> related but does not implement https://fedorahosted.org/freeipa/ticket/5806 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0957-ipa-client-install-fix-typo-in-nslcd-service-name.patch Type: text/x-patch Size: 904 bytes Desc: not available URL: From slaznick at redhat.com Thu Apr 21 17:28:55 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 21 Apr 2016 19:28:55 +0200 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <57189B31.9090209@redhat.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> <57179FD4.5070904@redhat.com> <57189B31.9090209@redhat.com> Message-ID: <57190DD7.3060508@redhat.com> On 04/21/2016 11:19 AM, Martin Basti wrote: > > > On 20.04.2016 17:27, Martin Basti wrote: >> >> >> On 24.03.2016 14:27, Martin Basti wrote: >>> >>> >>> On 24.03.2016 13:55, Jan Cholasta wrote: >>>> On 18.3.2016 23:27, Timo Aaltonen wrote: >>>>> On 17.03.2016 18:36, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5681 >>>>> >>>>> would be nicer if ipa-httpd.conf was a template with the current >>>>> hardcoded values replaced with platform paths.. >>>> >>>> +1, I would also prefer if the file was renamed to >>>> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. >>> ipa-httpd.conf.template should be in /user/share/ipa, directory >>> init/systemd copied only to rpm and then copied to >>> /etc/systemd/system AFAIK >>> >>>> >>>>> >>>>> >>>>> not relevant to this patch, but there are others candidates for >>>>> templates like: >>>>> >>>>> daemons/dnssec/ipa-dnskeysyncd.service >>>>> daemons/dnssec/ipa-ods-exporter.service >>>>> install/conf/ipa.conf >>>> >>> >> >> Updated patch attached, sorry for delay. >> >> > Updated patch attached (fixed unused import). > > Seems to work as expected. However, wouldn't it be better to use installutils.remove_file instead of remove_httpd_service_ipa_conf (or at least log the possible error during os.unlink) to get the same behavior as with the other config files? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Apr 21 17:39:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 19:39:02 +0200 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1461257923.30315.101.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> <56D06321.3080109@redhat.com> <56FCD8A4.70107@redhat.com> <57025274.8020908@redhat.com> <5702554F.3050207@redhat.com> <5704CDC4.40907@redhat.com> <5704CF86.3000709@redhat.com> <5714DFAF.2060303@redhat.com> <5714F24F.70203@redhat.com> <571500DF.20204@redhat.com> <1461008004.30315.15.camel@redhat.com> <5715F65E.2030403@redhat.com> <1461086255.30315.46.camel@redhat.com> <5718F422.4000205@redhat.com> <1461257923.30315.101.camel@redhat.com> Message-ID: <57191036.9030806@redhat.com> On 21.04.2016 18:58, Simo Sorce wrote: > On Thu, 2016-04-21 at 17:39 +0200, Petr Spacek wrote: >> On 19.4.2016 19:17, Simo Sorce wrote: >>> On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote: >>>> On 18.4.2016 21:33, Simo Sorce wrote: >>>>> On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote: >>>>>> * Find, filter and copy hand-made records from main tree into the >>>>>> _locations sub-trees. This means that every hand-made record >>>>>> needs to be copied and synchronized N-times where N = number of IPA >>>>>> locations. >>>>> This ^^ seem the one that provides the best semantics for admins and the >>>>> least unexpected results. >>>>> >>>>>> My favorite option for the first version is 'document that enabling >>>>>> DNS location will hide hand-made records in IPA domain.' >>>>> I do not think this is acceptable, sorry. >>>>> >>>>>> The feature is disabled by default and needs additional configuration >>>>>> anyway so simply upgrading should not break anything. >>>>> It is also useless this way. >>>>> >>>>>> I'm eager to hear opinions and answers to questions above. >>>>> HTH, >>>> Well it does not help because you did not answer the questions listed in the >>>> design page. >>>> >>>> Anyway, here is third version of the design. It avoids copying user-made >>>> records (basically 2 DNAMEs were replaced with bunch of CNAMEs): >>>> >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29 >>>> >>>> It seems like a good middle ground: >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals >>> It does seem like a decent middle ground. >>> And I guess an admin would be able to add custom templates if he wants >>> to have specific services forwarded to the location specific subtree ? >> Yes, the bind-dyndb-ldap's RecordGenerator and PerServerConfigInLDAP are >> generic enough. At the moment we do not plan to expose these mechanisms in >> user interface, we might do that later on. >> >> >>>> This required changes in RecordGenerator design, too: >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator >>> I do not see where you specify the specific record names you forward to >>> the location trees here? >> I do not understand the question. Let's have a look at the example: >> >> # DN specifies DNS node name which will hold the generated record: >> dn: idnsName=_udp,idnsname=example.com.,cn=dns,dc=example,dc=com >> # this is equivalent to _udp.example.com. >> >> objectClass: idnsTemplateObject >> objectClass: top >> objectClass: idnsRecord >> idnsName: _udp >> >> # sub-type determines type of the generated record = DNAME >> idnsTemplateAttribute;dnamerecord: >> _udp.\{substitutionvariable_ipalocation\}._locations >> # generated value will be _udp.your-location._locations >> # it is a relative name so zone name (example.com) will be automatically appended >> >> The template is just string, so you can specify an absolute name if you want: >> idnsTemplateAttribute;dnamerecord: >> _udp.\{substitutionvariable_ipalocation\}._locations.another.zone.example. >> >> Of course 'ipalocation' is just a variable name so user can define his own in >> PerServerConfigInLDAP. >> >> Is it clearer now? > Sorry I thought you said in option 3 that you would only create records > for specific services using CNAMEs > I was looking for how you configure which services you are going to pick > in that case and couldn't see it. > This example is a DNAME one and looks to me it is about option 2 ? > I put there image for version 3 there, and put/fix some implementation details there. I will add more implementation details tomorrow. Basically, IPA knows what services are on which server (except NTP, will be fixed), so based on this we are able to generate proper SRV records in all locations, and mark the original one by attribute 'idnsTemplateAttribute;cnamerecord' Please see example here, I will refer on it later http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CNAME_data_generation In case that server is not configured to provide Location specific data, or the server is old, the original SRV record (marked with 'idnsTemplateAttribute') will be used. In case that server is configured to provide location specific data, bind-dyndb-ldap will replace the original SRV record by CNAME according to location. Other SRV records (those not marked by 'idnsTemplateAttribute') are untouched. Martin From mbasti at redhat.com Thu Apr 21 17:50:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 21 Apr 2016 19:50:18 +0200 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <57190DD7.3060508@redhat.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> <57179FD4.5070904@redhat.com> <57189B31.9090209@redhat.com> <57190DD7.3060508@redhat.com> Message-ID: <571912DA.2010300@redhat.com> On 21.04.2016 19:28, Stanislav Laznicka wrote: > On 04/21/2016 11:19 AM, Martin Basti wrote: >> >> >> On 20.04.2016 17:27, Martin Basti wrote: >>> >>> >>> On 24.03.2016 14:27, Martin Basti wrote: >>>> >>>> >>>> On 24.03.2016 13:55, Jan Cholasta wrote: >>>>> On 18.3.2016 23:27, Timo Aaltonen wrote: >>>>>> On 17.03.2016 18:36, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5681 >>>>>> >>>>>> would be nicer if ipa-httpd.conf was a template with the current >>>>>> hardcoded values replaced with platform paths.. >>>>> >>>>> +1, I would also prefer if the file was renamed to >>>>> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. >>>> ipa-httpd.conf.template should be in /user/share/ipa, directory >>>> init/systemd copied only to rpm and then copied to >>>> /etc/systemd/system AFAIK >>>> >>>>> >>>>>> >>>>>> >>>>>> not relevant to this patch, but there are others candidates for >>>>>> templates like: >>>>>> >>>>>> daemons/dnssec/ipa-dnskeysyncd.service >>>>>> daemons/dnssec/ipa-ods-exporter.service >>>>>> install/conf/ipa.conf >>>>> >>>> >>> >>> Updated patch attached, sorry for delay. >>> >>> >> Updated patch attached (fixed unused import). >> >> > > Seems to work as expected. However, wouldn't it be better to use > installutils.remove_file instead of remove_httpd_service_ipa_conf (or > at least log the possible error during os.unlink) to get the same > behavior as with the other config files? It could be, but because I created platform specific method for adding httpd service config, it seems natural to me to create inverse operation platform specific too. I have no strong opinion about this, Timo what might be better, you use platform specific code more than we? :) Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Thu Apr 21 20:09:19 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 21 Apr 2016 22:09:19 +0200 Subject: [Freeipa-devel] [PATCH] 957 ipa-client-install: fix typo in nslcd service name In-Reply-To: <57190D09.3050802@redhat.com> References: <57190D09.3050802@redhat.com> Message-ID: <20160421200918.GA30804@10.4.128.1> On (21/04/16 19:25), Petr Vobornik wrote: >related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >-- >Petr Vobornik >From b9b8716ec9ba5a5cdbed1f6cdedf7cff8878f08f Mon Sep 17 00:00:00 2001 >From: Petr Vobornik >Date: Thu, 21 Apr 2016 19:23:31 +0200 >Subject: [PATCH] ipa-client-install: fix typo in nslcd service name > >related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >--- > client/ipa-client-install | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/client/ipa-client-install b/client/ipa-client-install >index c38843f85639a9118cd1a471709992690643d79a..0e6e65c4ad4ce01fe1257eee4bb2633a70c3de4e 100755 >--- a/client/ipa-client-install >+++ b/client/ipa-client-install >@@ -2938,7 +2938,7 @@ def install(options, env, fstore, statestore): > nscd.service_name) > > nslcd = services.knownservices.nslcd >- if nscd.is_installed(): >+ if nslcd.is_installed(): > save_state(nslcd) I thought that milestone "Future Releases" has lower priority then "FreeIPA 4.4 Backlog" Therefore I would prefer to close ticket #5806 and implement following one https://fedorahosted.org/freeipa/ticket/5557#comment:2 LS From rcritten at redhat.com Thu Apr 21 20:42:43 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Apr 2016 16:42:43 -0400 Subject: [Freeipa-devel] [PATCH] 957 ipa-client-install: fix typo in nslcd service name In-Reply-To: <20160421200918.GA30804@10.4.128.1> References: <57190D09.3050802@redhat.com> <20160421200918.GA30804@10.4.128.1> Message-ID: <57193B43.6060408@redhat.com> Lukas Slebodnik wrote: > On (21/04/16 19:25), Petr Vobornik wrote: >> related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >> -- >> Petr Vobornik > >>From b9b8716ec9ba5a5cdbed1f6cdedf7cff8878f08f Mon Sep 17 00:00:00 2001 >> From: Petr Vobornik >> Date: Thu, 21 Apr 2016 19:23:31 +0200 >> Subject: [PATCH] ipa-client-install: fix typo in nslcd service name >> >> related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >> --- >> client/ipa-client-install | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/client/ipa-client-install b/client/ipa-client-install >> index c38843f85639a9118cd1a471709992690643d79a..0e6e65c4ad4ce01fe1257eee4bb2633a70c3de4e 100755 >> --- a/client/ipa-client-install >> +++ b/client/ipa-client-install >> @@ -2938,7 +2938,7 @@ def install(options, env, fstore, statestore): >> nscd.service_name) >> >> nslcd = services.knownservices.nslcd >> - if nscd.is_installed(): >> + if nslcd.is_installed(): >> save_state(nslcd) > > I thought that milestone "Future Releases" has lower priority > then "FreeIPA 4.4 Backlog" > > Therefore I would prefer to close ticket #5806 and implement following one > https://fedorahosted.org/freeipa/ticket/5557#comment:2 I don't understand what you are suggesting. Tickets aren't swapped like this and certainly non-related bugs aren't closed for another. This patch just fixes an obvious one-liner as agreed upon in triage. The rest will be potentially addressed later. ACK on the patch. rob From tjaalton at ubuntu.com Thu Apr 21 20:55:06 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 21 Apr 2016 23:55:06 +0300 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <571912DA.2010300@redhat.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> <57179FD4.5070904@redhat.com> <57189B31.9090209@redhat.com> <57190DD7.3060508@redhat.com> <571912DA.2010300@redhat.com> Message-ID: <57193E2A.1080000@ubuntu.com> 21.04.2016, 20:50, Martin Basti kirjoitti: > > > On 21.04.2016 19:28, Stanislav Laznicka wrote: >> On 04/21/2016 11:19 AM, Martin Basti wrote: >>> >>> >>> On 20.04.2016 17:27, Martin Basti wrote: >>>> >>>> >>>> On 24.03.2016 14:27, Martin Basti wrote: >>>>> >>>>> >>>>> On 24.03.2016 13:55, Jan Cholasta wrote: >>>>>> On 18.3.2016 23:27, Timo Aaltonen wrote: >>>>>>> On 17.03.2016 18:36, Martin Basti wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/5681 >>>>>>> >>>>>>> would be nicer if ipa-httpd.conf was a template with the current >>>>>>> hardcoded values replaced with platform paths.. >>>>>> >>>>>> +1, I would also prefer if the file was renamed to >>>>>> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. >>>>> ipa-httpd.conf.template should be in /user/share/ipa, directory >>>>> init/systemd copied only to rpm and then copied to >>>>> /etc/systemd/system AFAIK >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> not relevant to this patch, but there are others candidates for >>>>>>> templates like: >>>>>>> >>>>>>> daemons/dnssec/ipa-dnskeysyncd.service >>>>>>> daemons/dnssec/ipa-ods-exporter.service >>>>>>> install/conf/ipa.conf >>>>>> >>>>> >>>> >>>> Updated patch attached, sorry for delay. >>>> >>>> >>> Updated patch attached (fixed unused import). >>> >>> >> >> Seems to work as expected. However, wouldn't it be better to use >> installutils.remove_file instead of remove_httpd_service_ipa_conf (or >> at least log the possible error during os.unlink) to get the same >> behavior as with the other config files? > > It could be, but because I created platform specific method for adding > httpd service config, it seems natural to me to create inverse operation > platform specific too. > I have no strong opinion about this, Timo what might be better, you use > platform specific code more than we? :) Well, with this patch in I'd just reuse the methods from RedHatTaskNamespace() just like some others are being used right now. Systemd is all I support anyway. -- t From lslebodn at redhat.com Thu Apr 21 21:07:21 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 21 Apr 2016 23:07:21 +0200 Subject: [Freeipa-devel] [PATCH] 957 ipa-client-install: fix typo in nslcd service name In-Reply-To: <57193B43.6060408@redhat.com> References: <57190D09.3050802@redhat.com> <20160421200918.GA30804@10.4.128.1> <57193B43.6060408@redhat.com> Message-ID: <20160421210720.GB30804@10.4.128.1> On (21/04/16 16:42), Rob Crittenden wrote: >Lukas Slebodnik wrote: >> On (21/04/16 19:25), Petr Vobornik wrote: >> > related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >> > -- >> > Petr Vobornik >> >> > From b9b8716ec9ba5a5cdbed1f6cdedf7cff8878f08f Mon Sep 17 00:00:00 2001 >> > From: Petr Vobornik >> > Date: Thu, 21 Apr 2016 19:23:31 +0200 >> > Subject: [PATCH] ipa-client-install: fix typo in nslcd service name >> > >> > related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >> > --- >> > client/ipa-client-install | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/client/ipa-client-install b/client/ipa-client-install >> > index c38843f85639a9118cd1a471709992690643d79a..0e6e65c4ad4ce01fe1257eee4bb2633a70c3de4e 100755 >> > --- a/client/ipa-client-install >> > +++ b/client/ipa-client-install >> > @@ -2938,7 +2938,7 @@ def install(options, env, fstore, statestore): >> > nscd.service_name) >> > >> > nslcd = services.knownservices.nslcd >> > - if nscd.is_installed(): >> > + if nslcd.is_installed(): >> > save_state(nslcd) >> >> I thought that milestone "Future Releases" has lower priority >> then "FreeIPA 4.4 Backlog" >> >> Therefore I would prefer to close ticket #5806 and implement following one >> https://fedorahosted.org/freeipa/ticket/5557#comment:2 > >I don't understand what you are suggesting. Tickets aren't swapped like this >and certainly non-related bugs aren't closed for another. > >This patch just fixes an obvious one-liner as agreed upon in triage. The rest >will be potentially addressed later. > >ACK on the patch. > I cannot see a reason to fix oneliner. This code is not tested and should be removed (#5557) Or someone should write integration test. I'm sorry but conditional-NACK (missing integration test) LS From rcritten at redhat.com Fri Apr 22 03:02:12 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Apr 2016 23:02:12 -0400 Subject: [Freeipa-devel] [PATCH] 957 ipa-client-install: fix typo in nslcd service name In-Reply-To: <20160421210720.GB30804@10.4.128.1> References: <57190D09.3050802@redhat.com> <20160421200918.GA30804@10.4.128.1> <57193B43.6060408@redhat.com> <20160421210720.GB30804@10.4.128.1> Message-ID: <57199434.2090005@redhat.com> Lukas Slebodnik wrote: > On (21/04/16 16:42), Rob Crittenden wrote: >> Lukas Slebodnik wrote: >>> On (21/04/16 19:25), Petr Vobornik wrote: >>>> related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >>>> -- >>>> Petr Vobornik >>> >>>> From b9b8716ec9ba5a5cdbed1f6cdedf7cff8878f08f Mon Sep 17 00:00:00 2001 >>>> From: Petr Vobornik >>>> Date: Thu, 21 Apr 2016 19:23:31 +0200 >>>> Subject: [PATCH] ipa-client-install: fix typo in nslcd service name >>>> >>>> related but does not implement https://fedorahosted.org/freeipa/ticket/5806 >>>> --- >>>> client/ipa-client-install | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/client/ipa-client-install b/client/ipa-client-install >>>> index c38843f85639a9118cd1a471709992690643d79a..0e6e65c4ad4ce01fe1257eee4bb2633a70c3de4e 100755 >>>> --- a/client/ipa-client-install >>>> +++ b/client/ipa-client-install >>>> @@ -2938,7 +2938,7 @@ def install(options, env, fstore, statestore): >>>> nscd.service_name) >>>> >>>> nslcd = services.knownservices.nslcd >>>> - if nscd.is_installed(): >>>> + if nslcd.is_installed(): >>>> save_state(nslcd) >>> >>> I thought that milestone "Future Releases" has lower priority >>> then "FreeIPA 4.4 Backlog" >>> >>> Therefore I would prefer to close ticket #5806 and implement following one >>> https://fedorahosted.org/freeipa/ticket/5557#comment:2 >> >> I don't understand what you are suggesting. Tickets aren't swapped like this >> and certainly non-related bugs aren't closed for another. >> >> This patch just fixes an obvious one-liner as agreed upon in triage. The rest >> will be potentially addressed later. >> >> ACK on the patch. >> > I cannot see a reason to fix oneliner. > This code is not tested and should be removed (#5557) I fail to see the controversy here. These are two completely and absolutely unrelated bugs. > Or someone should write integration test. > > I'm sorry but conditional-NACK (missing integration test) I've been out of the project a while, so perhaps my knowledge is stale, but AFAIU upstream QE writes the integration tests, not the developers. This was at least true when I was a daily contributor. At least at one time QE did testing using --no-sssd. Whether that is still the case I don't know but I do remember fixing bugs around it. And this particular bug might not be immediately apparent unless a specific configuration was present. I noticed the bug while reading code, not in production. rob From mbasti at redhat.com Fri Apr 22 06:09:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 08:09:01 +0200 Subject: [Freeipa-devel] [PATCH] 957 ipa-client-install: fix typo in nslcd service name In-Reply-To: <57199434.2090005@redhat.com> References: <57190D09.3050802@redhat.com> <20160421200918.GA30804@10.4.128.1> <57193B43.6060408@redhat.com> <20160421210720.GB30804@10.4.128.1> <57199434.2090005@redhat.com> Message-ID: <5719BFFD.1020907@redhat.com> On 22.04.2016 05:02, Rob Crittenden wrote: > Lukas Slebodnik wrote: >> On (21/04/16 16:42), Rob Crittenden wrote: >>> Lukas Slebodnik wrote: >>>> On (21/04/16 19:25), Petr Vobornik wrote: >>>>> related but does not implement >>>>> https://fedorahosted.org/freeipa/ticket/5806 >>>>> -- >>>>> Petr Vobornik >>>> >>>>> From b9b8716ec9ba5a5cdbed1f6cdedf7cff8878f08f Mon Sep 17 00:00:00 >>>>> 2001 >>>>> From: Petr Vobornik >>>>> Date: Thu, 21 Apr 2016 19:23:31 +0200 >>>>> Subject: [PATCH] ipa-client-install: fix typo in nslcd service name >>>>> >>>>> related but does not implement >>>>> https://fedorahosted.org/freeipa/ticket/5806 >>>>> --- >>>>> client/ipa-client-install | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/client/ipa-client-install b/client/ipa-client-install >>>>> index >>>>> c38843f85639a9118cd1a471709992690643d79a..0e6e65c4ad4ce01fe1257eee4bb2633a70c3de4e >>>>> 100755 >>>>> --- a/client/ipa-client-install >>>>> +++ b/client/ipa-client-install >>>>> @@ -2938,7 +2938,7 @@ def install(options, env, fstore, statestore): >>>>> nscd.service_name) >>>>> >>>>> nslcd = services.knownservices.nslcd >>>>> - if nscd.is_installed(): >>>>> + if nslcd.is_installed(): >>>>> save_state(nslcd) >>>> >>>> I thought that milestone "Future Releases" has lower priority >>>> then "FreeIPA 4.4 Backlog" >>>> >>>> Therefore I would prefer to close ticket #5806 and implement >>>> following one >>>> https://fedorahosted.org/freeipa/ticket/5557#comment:2 >>> >>> I don't understand what you are suggesting. Tickets aren't swapped >>> like this >>> and certainly non-related bugs aren't closed for another. >>> >>> This patch just fixes an obvious one-liner as agreed upon in triage. >>> The rest >>> will be potentially addressed later. >>> >>> ACK on the patch. +1 >>> >> I cannot see a reason to fix oneliner. >> This code is not tested and should be removed (#5557) > > I fail to see the controversy here. These are two completely and > absolutely unrelated bugs. > >> Or someone should write integration test. >> >> I'm sorry but conditional-NACK (missing integration test) > > I've been out of the project a while, so perhaps my knowledge is > stale, but AFAIU upstream QE writes the integration tests, not the > developers. This was at least true when I was a daily contributor. > > At least at one time QE did testing using --no-sssd. Whether that is > still the case I don't know but I do remember fixing bugs around it. > And this particular bug might not be immediately apparent unless a > specific configuration was present. I noticed the bug while reading > code, not in production. > > rob > Patch do exactly the same as was agreed on devel meeting. I don't see reason why we shouldn't fix oneliner. Pushed to master: a023dcbc5c2e60d29938588845905b62986c3a93 From lslebodn at redhat.com Fri Apr 22 07:45:28 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 22 Apr 2016 09:45:28 +0200 Subject: [Freeipa-devel] [PATCH] 957 ipa-client-install: fix typo in nslcd service name In-Reply-To: <5719BFFD.1020907@redhat.com> References: <57190D09.3050802@redhat.com> <20160421200918.GA30804@10.4.128.1> <57193B43.6060408@redhat.com> <20160421210720.GB30804@10.4.128.1> <57199434.2090005@redhat.com> <5719BFFD.1020907@redhat.com> Message-ID: <20160422074527.GA22280@10.4.128.1> On (22/04/16 08:09), Martin Basti wrote: > > >On 22.04.2016 05:02, Rob Crittenden wrote: >> Lukas Slebodnik wrote: >> > On (21/04/16 16:42), Rob Crittenden wrote: >> > > Lukas Slebodnik wrote: >> > > > On (21/04/16 19:25), Petr Vobornik wrote: >> > > > > related but does not implement >> > > > > https://fedorahosted.org/freeipa/ticket/5806 >> > > > > -- >> > > > > Petr Vobornik >> > > > >> > > > > From b9b8716ec9ba5a5cdbed1f6cdedf7cff8878f08f Mon Sep 17 >> > > > > 00:00:00 2001 >> > > > > From: Petr Vobornik >> > > > > Date: Thu, 21 Apr 2016 19:23:31 +0200 >> > > > > Subject: [PATCH] ipa-client-install: fix typo in nslcd service name >> > > > > >> > > > > related but does not implement >> > > > > https://fedorahosted.org/freeipa/ticket/5806 >> > > > > --- >> > > > > client/ipa-client-install | 2 +- >> > > > > 1 file changed, 1 insertion(+), 1 deletion(-) >> > > > > >> > > > > diff --git a/client/ipa-client-install b/client/ipa-client-install >> > > > > index c38843f85639a9118cd1a471709992690643d79a..0e6e65c4ad4ce01fe1257eee4bb2633a70c3de4e >> > > > > 100755 >> > > > > --- a/client/ipa-client-install >> > > > > +++ b/client/ipa-client-install >> > > > > @@ -2938,7 +2938,7 @@ def install(options, env, fstore, statestore): >> > > > > nscd.service_name) >> > > > > >> > > > > nslcd = services.knownservices.nslcd >> > > > > - if nscd.is_installed(): >> > > > > + if nslcd.is_installed(): >> > > > > save_state(nslcd) >> > > > >> > > > I thought that milestone "Future Releases" has lower priority >> > > > then "FreeIPA 4.4 Backlog" >> > > > >> > > > Therefore I would prefer to close ticket #5806 and implement >> > > > following one >> > > > https://fedorahosted.org/freeipa/ticket/5557#comment:2 >> > > >> > > I don't understand what you are suggesting. Tickets aren't >> > > swapped like this >> > > and certainly non-related bugs aren't closed for another. >> > > >> > > This patch just fixes an obvious one-liner as agreed upon in >> > > triage. The rest >> > > will be potentially addressed later. >> > > >> > > ACK on the patch. >+1 >> > > >> > I cannot see a reason to fix oneliner. >> > This code is not tested and should be removed (#5557) >> >> I fail to see the controversy here. These are two completely and >> absolutely unrelated bugs. >> >> > Or someone should write integration test. >> > >> > I'm sorry but conditional-NACK (missing integration test) >> >> I've been out of the project a while, so perhaps my knowledge is stale, >> but AFAIU upstream QE writes the integration tests, not the developers. >> This was at least true when I was a daily contributor. >> You were used to old style development model (waterfall). And management mentioned that we should be more agile. All agile methodologies assume that also developers write tests. >> At least at one time QE did testing using --no-sssd. Whether that is It should have been a long time ago. Modern freeipa client (4.4) requires sssd and many features will not work with nslcd. Trust, views ... >> still the case I don't know but I do remember fixing bugs around it. And >> this particular bug might not be immediately apparent unless a specific >> configuration was present. I noticed the bug while reading code, not in >> production. >> >> rob >> >Patch do exactly the same as was agreed on devel meeting. I don't see reason >why we shouldn't fix oneliner. > Because it's not tested and there might be much more things which does not work. It should be either tested or removed. Ticket #5557 was triaged before #5806. (4 monts ago vs 10 days ago). The purpose of ticket "#5557" was to have a single line change in freeipa spec file. But after a triage it was decided that this part of code will be deprecated and later removed. I know that this patch was a oneliner but I do not see a reason why freeipa developers should waste time with fixing unested code. It's obvious it could not work since 2013-11-07 and nonody has complained yet. It's another reason to remove this code. Another reason is that freeipa-client does not have a dependency on nss-pam-ldapd. BTW I moved ticket #5557 to reconsider it one more time. LS From mbasti at redhat.com Fri Apr 22 08:08:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 10:08:44 +0200 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <57193E2A.1080000@ubuntu.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> <57179FD4.5070904@redhat.com> <57189B31.9090209@redhat.com> <57190DD7.3060508@redhat.com> <571912DA.2010300@redhat.com> <57193E2A.1080000@ubuntu.com> Message-ID: <5719DC0C.5090501@redhat.com> On 21.04.2016 22:55, Timo Aaltonen wrote: > 21.04.2016, 20:50, Martin Basti kirjoitti: >> >> On 21.04.2016 19:28, Stanislav Laznicka wrote: >>> On 04/21/2016 11:19 AM, Martin Basti wrote: >>>> >>>> On 20.04.2016 17:27, Martin Basti wrote: >>>>> >>>>> On 24.03.2016 14:27, Martin Basti wrote: >>>>>> >>>>>> On 24.03.2016 13:55, Jan Cholasta wrote: >>>>>>> On 18.3.2016 23:27, Timo Aaltonen wrote: >>>>>>>> On 17.03.2016 18:36, Martin Basti wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5681 >>>>>>>> would be nicer if ipa-httpd.conf was a template with the current >>>>>>>> hardcoded values replaced with platform paths.. >>>>>>> +1, I would also prefer if the file was renamed to >>>>>>> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. >>>>>> ipa-httpd.conf.template should be in /user/share/ipa, directory >>>>>> init/systemd copied only to rpm and then copied to >>>>>> /etc/systemd/system AFAIK >>>>>> >>>>>>>> >>>>>>>> not relevant to this patch, but there are others candidates for >>>>>>>> templates like: >>>>>>>> >>>>>>>> daemons/dnssec/ipa-dnskeysyncd.service >>>>>>>> daemons/dnssec/ipa-ods-exporter.service >>>>>>>> install/conf/ipa.conf >>>>> Updated patch attached, sorry for delay. >>>>> >>>>> >>>> Updated patch attached (fixed unused import). >>>> >>>> >>> Seems to work as expected. However, wouldn't it be better to use >>> installutils.remove_file instead of remove_httpd_service_ipa_conf (or >>> at least log the possible error during os.unlink) to get the same >>> behavior as with the other config files? >> It could be, but because I created platform specific method for adding >> httpd service config, it seems natural to me to create inverse operation >> platform specific too. >> I have no strong opinion about this, Timo what might be better, you use >> platform specific code more than we? :) > Well, with this patch in I'd just reuse the methods from > RedHatTaskNamespace() just like some others are being used right now. > Systemd is all I support anyway. > > > Updated patch attached, missing log added -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0441.4-Configure-httpd-service-from-installer-instead-of-di.patch Type: text/x-patch Size: 9762 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 22 08:13:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 10:13:04 +0200 Subject: [Freeipa-devel] [PATCH] 0015, 16 webui: Add 'Skip overlap check' checkbox to the dns adder dialogs In-Reply-To: <5718BDE8.5070004@redhat.com> References: <570F7904.6000908@redhat.com> <570F871C.1070209@redhat.com> <5717A76D.3020000@redhat.com> <5718BDE8.5070004@redhat.com> Message-ID: <5719DD10.9060600@redhat.com> On 21.04.2016 13:47, Martin Basti wrote: > > > On 20.04.2016 17:59, Pavel Vomacka wrote: >> >> >> On 04/14/2016 02:03 PM, Martin Basti wrote: >>> >>> >>> On 14.04.2016 13:03, Pavel Vomacka wrote: >>>> Hello, >>>> >>>> The first patch (0015) adds the checkbox to the dns zone adder dialog. >>>> >>>> The second patch (0016) adds the 'skip overlap check' checkbox to >>>> the dns forward zone adder dialog. This patch requires the previous >>>> one. The patch 0016 might not be used in case that the dns forward >>>> zone dialog shouldn't contain that checkbox. >>>> >>>> -- >>>> Pavel^3 Vomacka >>>> >>>> >>> Can we add hint to webUI what 'skip overlap check' means? Maybe >>> description from ipa dns[forward]zone-add --help. >>> >>> Martin^2 >>> >>> >> Yes, it is included in these new pathes. >> >> -- >> Pavel^3 Vomacka >> >> >> > Works for me > > ACK, pushed to: ipa-4-3: * ea8f0297bb5910ecbafb8dffa767b6b3ae8f1a82 Add 'skip overlap check' checkbox into add zone dialog * 5392042bbc0b64aeb6f963549dffd3ebaf1fd22b Add 'skip overlap check' checkbox to the add dns forward zone dialog master: * f4467923535b54795e79ca30e4a5de74ab66820d Add 'skip overlap check' checkbox into add zone dialog * 822186b2715f8a3ce2f48e873d7e1568d03f9f97 Add 'skip overlap check' checkbox to the add dns forward zone dialog -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Fri Apr 22 08:17:12 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 22 Apr 2016 10:17:12 +0200 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <5719DC0C.5090501@redhat.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> <57179FD4.5070904@redhat.com> <57189B31.9090209@redhat.com> <57190DD7.3060508@redhat.com> <571912DA.2010300@redhat.com> <57193E2A.1080000@ubuntu.com> <5719DC0C.5090501@redhat.com> Message-ID: <5719DE08.1070105@redhat.com> On 04/22/2016 10:08 AM, Martin Basti wrote: > > > On 21.04.2016 22:55, Timo Aaltonen wrote: >> 21.04.2016, 20:50, Martin Basti kirjoitti: >>> >>> On 21.04.2016 19:28, Stanislav Laznicka wrote: >>>> On 04/21/2016 11:19 AM, Martin Basti wrote: >>>>> >>>>> On 20.04.2016 17:27, Martin Basti wrote: >>>>>> >>>>>> On 24.03.2016 14:27, Martin Basti wrote: >>>>>>> >>>>>>> On 24.03.2016 13:55, Jan Cholasta wrote: >>>>>>>> On 18.3.2016 23:27, Timo Aaltonen wrote: >>>>>>>>> On 17.03.2016 18:36, Martin Basti wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5681 >>>>>>>>> would be nicer if ipa-httpd.conf was a template with the current >>>>>>>>> hardcoded values replaced with platform paths.. >>>>>>>> +1, I would also prefer if the file was renamed to >>>>>>>> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. >>>>>>> ipa-httpd.conf.template should be in /user/share/ipa, directory >>>>>>> init/systemd copied only to rpm and then copied to >>>>>>> /etc/systemd/system AFAIK >>>>>>> >>>>>>>>> >>>>>>>>> not relevant to this patch, but there are others candidates for >>>>>>>>> templates like: >>>>>>>>> >>>>>>>>> daemons/dnssec/ipa-dnskeysyncd.service >>>>>>>>> daemons/dnssec/ipa-ods-exporter.service >>>>>>>>> install/conf/ipa.conf >>>>>> Updated patch attached, sorry for delay. >>>>>> >>>>>> >>>>> Updated patch attached (fixed unused import). >>>>> >>>>> >>>> Seems to work as expected. However, wouldn't it be better to use >>>> installutils.remove_file instead of remove_httpd_service_ipa_conf (or >>>> at least log the possible error during os.unlink) to get the same >>>> behavior as with the other config files? >>> It could be, but because I created platform specific method for adding >>> httpd service config, it seems natural to me to create inverse >>> operation >>> platform specific too. >>> I have no strong opinion about this, Timo what might be better, you use >>> platform specific code more than we? :) >> Well, with this patch in I'd just reuse the methods from >> RedHatTaskNamespace() just like some others are being used right now. >> Systemd is all I support anyway. >> >> >> > Updated patch attached, missing log added > Thanks, jolly good. ACK. From mbasti at redhat.com Fri Apr 22 08:58:20 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 10:58:20 +0200 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command In-Reply-To: <57187E93.1040707@redhat.com> References: <571798C4.5040200@redhat.com> <57187E93.1040707@redhat.com> Message-ID: <5719E7AC.5020908@redhat.com> On 21.04.2016 09:17, Martin Basti wrote: > > > On 20.04.2016 16:57, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5281 >> >> Patch attached. >> >> > selfNACK > > Updated patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0463.2-Performace-don-t-download-password-attributes-in-hos.patch Type: text/x-patch Size: 5122 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 22 10:37:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 12:37:02 +0200 Subject: [Freeipa-devel] [PATCH 0441] Configure httpd service from installer In-Reply-To: <5719DE08.1070105@redhat.com> References: <56EADD09.2060109@redhat.com> <56EC80D3.6010703@ubuntu.com> <56F3E3A5.9000207@redhat.com> <56F3EB49.7090701@redhat.com> <57179FD4.5070904@redhat.com> <57189B31.9090209@redhat.com> <57190DD7.3060508@redhat.com> <571912DA.2010300@redhat.com> <57193E2A.1080000@ubuntu.com> <5719DC0C.5090501@redhat.com> <5719DE08.1070105@redhat.com> Message-ID: <5719FECE.8080007@redhat.com> On 22.04.2016 10:17, Stanislav Laznicka wrote: > On 04/22/2016 10:08 AM, Martin Basti wrote: >> >> >> On 21.04.2016 22:55, Timo Aaltonen wrote: >>> 21.04.2016, 20:50, Martin Basti kirjoitti: >>>> >>>> On 21.04.2016 19:28, Stanislav Laznicka wrote: >>>>> On 04/21/2016 11:19 AM, Martin Basti wrote: >>>>>> >>>>>> On 20.04.2016 17:27, Martin Basti wrote: >>>>>>> >>>>>>> On 24.03.2016 14:27, Martin Basti wrote: >>>>>>>> >>>>>>>> On 24.03.2016 13:55, Jan Cholasta wrote: >>>>>>>>> On 18.3.2016 23:27, Timo Aaltonen wrote: >>>>>>>>>> On 17.03.2016 18:36, Martin Basti wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5681 >>>>>>>>>> would be nicer if ipa-httpd.conf was a template with the current >>>>>>>>>> hardcoded values replaced with platform paths.. >>>>>>>>> +1, I would also prefer if the file was renamed to >>>>>>>>> init/systemd/httpd.conf rather than install/share/ipa-httpd.conf. >>>>>>>> ipa-httpd.conf.template should be in /user/share/ipa, directory >>>>>>>> init/systemd copied only to rpm and then copied to >>>>>>>> /etc/systemd/system AFAIK >>>>>>>> >>>>>>>>>> >>>>>>>>>> not relevant to this patch, but there are others candidates for >>>>>>>>>> templates like: >>>>>>>>>> >>>>>>>>>> daemons/dnssec/ipa-dnskeysyncd.service >>>>>>>>>> daemons/dnssec/ipa-ods-exporter.service >>>>>>>>>> install/conf/ipa.conf >>>>>>> Updated patch attached, sorry for delay. >>>>>>> >>>>>>> >>>>>> Updated patch attached (fixed unused import). >>>>>> >>>>>> >>>>> Seems to work as expected. However, wouldn't it be better to use >>>>> installutils.remove_file instead of remove_httpd_service_ipa_conf (or >>>>> at least log the possible error during os.unlink) to get the same >>>>> behavior as with the other config files? >>>> It could be, but because I created platform specific method for adding >>>> httpd service config, it seems natural to me to create inverse >>>> operation >>>> platform specific too. >>>> I have no strong opinion about this, Timo what might be better, you >>>> use >>>> platform specific code more than we? :) >>> Well, with this patch in I'd just reuse the methods from >>> RedHatTaskNamespace() just like some others are being used right now. >>> Systemd is all I support anyway. >>> >>> >>> >> Updated patch attached, missing log added >> > Thanks, jolly good. ACK. Pushed to master: * 586fee293f42388510fa5436af19460bbe1fdec5 Configure httpd service from installer instead of directly from RPM From mbasti at redhat.com Fri Apr 22 10:48:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 12:48:29 +0200 Subject: [Freeipa-devel] [PATCHES 0464-0468] always set hostname during installation In-Reply-To: <5717A507.8050707@redhat.com> References: <5717A507.8050707@redhat.com> Message-ID: <571A017D.709@redhat.com> On 20.04.2016 17:49, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5794 > > It requires my patch 441.2 > Patches attached. > > Rebased patches attached, 441 has been pushed Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0464.2-Always-set-hostname.patch Type: text/x-patch Size: 10711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0465.2-Remove-deprecated-hostname-restoration-from-Fedora18.patch Type: text/x-patch Size: 3263 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0466.2-Remove-unused-hostname-variables.patch Type: text/x-patch Size: 1180 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0467.2-Log-errors-from-backup_and_replace-hostname-to-logge.patch Type: text/x-patch Size: 1282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0468.2-Tasks-raise-NotImplementedError-for-not-implemented-.patch Type: text/x-patch Size: 4749 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 22 11:13:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 13:13:13 +0200 Subject: [Freeipa-devel] [PATCH 0024] ipa-replica-manage: added --suffix option for certain commands In-Reply-To: <5710DECD.5040103@redhat.com> References: <56E29266.8000501@redhat.com> <56E6E43B.4050805@redhat.com> <56E7AADC.3060407@redhat.com> <56E7F642.8010109@redhat.com> <56E90C5C.2020703@redhat.com> <56E925D0.2080305@redhat.com> <56E9637B.5080307@redhat.com> <56F2B380.9030504@redhat.com> <1183297765.33667649.1458760420403.JavaMail.zimbra@redhat.com> <56F42D93.5050505@redhat.com> <56FBE818.80805@redhat.com> <5704FB3C.2050003@redhat.com> <570E3013.7030006@redhat.com> <5710DECD.5040103@redhat.com> Message-ID: <571A0749.9020402@redhat.com> On 15.04.2016 14:30, Stanislav Laznicka wrote: > On 04/13/2016 01:40 PM, Martin Basti wrote: >> >> >> On 06.04.2016 14:04, Stanislav Laznicka wrote: >>> On 03/30/2016 04:52 PM, Martin Basti wrote: >>>> On 24.03.2016 19:10, Stanislav Laznicka wrote: >>>>> On 03/23/2016 08:13 PM, Martin Basti wrote: >>>>>> [...] >>>>>> Can you please update design >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 >>>>>> (mainly >>>>>> the --suffix option)? Also there are missing clean-ruv and list-ruv >>>>>> commands in design, and fix usage at the bottom. >>>>>> >>>>>> 1) >>>>>> I don't understand this expression >>>>>> + if dirman_passwd is None or ( >>>>>> + not dirman_passwd and args[0] in >>>>>> cs_enabled_commands): >>>>>> >>>>>> You already tested if subcommand belongs to cs_enabled_commands few >>>>>> lines above, IMO the 'dirman_password is None' expression is enough. >>>>> If I understand it well, when empty password is entered, the >>>>> program continues and uses Kerberos credentials for some >>>>> operations. E.g. for list-ruv, if empty password is entered, the >>>>> command would only display RUVs for domain tree but not for the CA >>>>> tree no matter if CA is set up or not (in the current state of the >>>>> patch, after get_ruv refactoring). This here is one possible way >>>>> around this, although the check for non-empty password might >>>>> probably just as well be in get_ruv_both_suffixes. >>>> >>>> ok >>>>>> 2) >>>>>> +# tuple of commands that work with ca tree and need Directory >>>>>> Manager >>>>>> password >>>>>> +cs_enabled_commands = ("list-ruv", "clean-ruv", "abort-clean-ruv") >>>>>> >>>>>> this variable is used only toi detect if dirman passwd is needed, I >>>>>> suggest to rename it to commands_req_dirman_passwd, or something >>>>>> better. >>>>>> >>>>>> 3) >>>>>> Q: Do we need is_cs_set() function? >>>>>> A: Yes! >>>>>> >>>>>> I wanted to give you ultimate NACK, but then I checked how >>>>>> get_ruv code >>>>>> works and I changed my mind. >>>>>> >>>>>> Please write a comment where is_cs_set function is used, why we need >>>>>> extra function instead of catching an exception, possibly you can >>>>>> open a >>>>>> refactoring ticket. >>>>> After the refactoring changes, is_cs_set should not be needed >>>>> anymore, removed it. >>>>>> >>>>>> Shame: >>>>>> 1) >>>>>> + if not test_connection(realm, host, options.nolookup) or\ >>>>>> Please use parentheses instead of backslash >>>>>> >>>>>> 2) >>>>>> + args[0] in cs_enabled_commands: >>>>>> >>>>>> + not dirman_passwd and args[0] in >>>>>> cs_enabled_commands): >>>>>> >>>>>> Indentation is not multiplication of 4 >>>>> Shame on me indeed, fixed it. >>>>>> >>>>>> Nitpicks (I don't insist on fixing these): >>>>>> 1) >>>>>> + if servers.get('ca', None): >>>>>> >>>>>> None is default >>>>>> >>>>>> 2) >>>>>> + for (netloc, rid) in servers['ca']: >>>>>> parentheses are not needed >>>>>> >>>>>> 3) >>>>>> + print("\t%s: %s" % (netloc, rid)) >>>>>> Would be nice to use .format() instead of % >>>>>> >>>>>> Martin^2 >>>>>> >>>>>> >>>>>> >>>>>> I changed my mind, ultimate NACK. >>>>>> Please fix get_ruv function, is_cs_set will not help. In case >>>>>> there are no RUVs but CA is installed, sys.exit there prevents us >>>>>> from removing RUVs (or any else operation) on domain suffix, and >>>>>> vice versa. >>>>>> I propose to move ticket to 4.4 milestone because I would like to >>>>>> avoid breaking something in 4.3, as this will hit many places in >>>>>> ipa-replica-manage. >>>>>> >>>>>> Please provide the refactoring of get_ruv as separate patch a put >>>>>> these patches on top of it. >>>>>> >>>>>> Martin2 >>>>> Did the refactoring. There also seemed to be duplicit code in >>>>> abort_clean_ruv for some reason, removed it (I hope it does not >>>>> break anything, but it seemed rather useless). Also had to change >>>>> the numbers of the patches so that they would apply. >>>> >>>> NACK >>>> >>>> * ipa-replica-manage refactoring * >>>> >>>> 1) >>>> Instead of: >>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>> - sys.exit(1) >>>> + root_logger.debug("Failed to connect to server {host}: {err}" >>>> + .format(host=host, err=e)) >>>> + raise RuntimeError(e) >>>> >>>> I expected >>>> >>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>> - sys.exit(1) >>>> + root_logger.debug(traceback.format_exc()) >>>> + raise RuntimeError("Failed to connect to server {host}: >>>> {err}" >>>> + .format(host=host, err=e))) >>> Should be fixed now. >>>> >>>> 2) >>>> - print("No RUV records found.") >>>> - sys.exit(0) >>>> >>>> Here is exit state 0, so we should not raise error. >>>> >>>> I think that we should create new nonfatal exception. >>> Made a new nonfatal error exception, then. This step was a bit >>> controversial when it comes to get_ruv_both_suffixes because it >>> needs to catch both this new exception and a RuntimeError exception >>> for both trees. As the main idea here was not to stop if either tree >>> is missing (resulting in RuntimeError in get_ruv) or contains no >>> records (NonFatalError), it is only printed that something bad may >>> have happened (or it's debug-logged in case of nonfatal errors). In >>> the end, only NonFatalError exception is raised if no records were >>> found for whatever reason resulting in the script always returning 0. >>>> >>>> 3) >>>> - print("unable to decode: %s" % ruv) >>>> + root_logger.debug("unable to decode: %s" % ruv) >>>> This may break tests, because the logger logs to stderr, leave it >>>> as print for now >>>> >>>> 4) >>>> - servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>> + try: >>>> + servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>> + except RuntimeError as e: >>>> + print(e) >>>> + sys.exit(1) >>>> >>>> again we have to print it to stdout for now. >>> 3), 4) done, although it might be better to log to stderr from patch >>> number 27 and on since the default behavior is changed anyway. >>>> >>>> * abort-clean/list/clean-ruv now work for both suffixes * >>>> >>>> - if dirman_passwd is None: >>>> + if dirman_passwd is None or ( >>>> + not dirman_passwd and args[0] in >>>> dirman_passwd_req_commands): >>>> sys.exit("Directory Manager password required") >>> Done. >>>> >>>> Please fix other patch accordingly. >>>> Martin^2 >>> >> >> 1) >> +class NonFatalError(Exception): >> + pass >> >> IMO we should be more specific and call it NoRUVsFound[Exception] >> >> 2) >> Not sure if this i sstill refactoring, it should be separate patch >> - if dirman_passwd is None: >> + if dirman_passwd is None or ( >> + not dirman_passwd and args[0] in >> dirman_passwd_req_commands): >> >> 3) >> +def get_ruv_both_suffixes >> >> I think in case where both suffixes returns RuntimeError we should >> raise RuntimeError too which results into exit with error code. >> > Please see the latest patches. Well, if CA is not installed on replica, it fails, not sure if this is expected behavior of ipa-replica-manage, or if this is related to your current patches. # ipa-replica-manage -p hesloheslo clean-dangling-ruv Failed to obtain information from 'vm-058-051.example.com': no such entry From pspacek at redhat.com Fri Apr 22 11:18:42 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Apr 2016 13:18:42 +0200 Subject: [Freeipa-devel] [PATCH] BUILD: Remove detection of libcheck In-Reply-To: <20160310094012.GC18289@mail.corp.redhat.com> References: <20160310094012.GC18289@mail.corp.redhat.com> Message-ID: <571A0892.9000504@redhat.com> On 10.3.2016 10:40, Lukas Slebodnik wrote: > ehlo, > > simple patch is attached. > >>From 2b34cdbb3b36dcf95746fdf3d843f66989b0f1c0 Mon Sep 17 00:00:00 2001 > From: Lukas Slebodnik > Date: Thu, 10 Mar 2016 10:26:52 +0100 > Subject: [PATCH] BUILD: Remove detection of libcheck > > The unit test framework check has not been used in freeipa for long time > (if ever) but there was still conditional check for this framework. > It just produced confusing warning: > Without the 'CHECK' library, you will be unable > to run all tests in the 'make check' suite > --- ACK -- Petr^2 Spacek From dkupka at redhat.com Fri Apr 22 11:21:04 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 22 Apr 2016 13:21:04 +0200 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command In-Reply-To: <5719E7AC.5020908@redhat.com> References: <571798C4.5040200@redhat.com> <57187E93.1040707@redhat.com> <5719E7AC.5020908@redhat.com> Message-ID: <571A0920.5020406@redhat.com> On 22/04/16 10:58, Martin Basti wrote: > > > On 21.04.2016 09:17, Martin Basti wrote: >> >> >> On 20.04.2016 16:57, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5281 >>> >>> Patch attached. >>> >>> >> selfNACK >> >> > Updated patch attached. > > > Works for me, ACK. -- David Kupka From mbasti at redhat.com Fri Apr 22 11:21:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 22 Apr 2016 13:21:53 +0200 Subject: [Freeipa-devel] [PATCH] BUILD: Remove detection of libcheck In-Reply-To: <571A0892.9000504@redhat.com> References: <20160310094012.GC18289@mail.corp.redhat.com> <571A0892.9000504@redhat.com> Message-ID: <571A0951.5080802@redhat.com> On 22.04.2016 13:18, Petr Spacek wrote: > On 10.3.2016 10:40, Lukas Slebodnik wrote: >> ehlo, >> >> simple patch is attached. >> >> >From 2b34cdbb3b36dcf95746fdf3d843f66989b0f1c0 Mon Sep 17 00:00:00 2001 >> From: Lukas Slebodnik >> Date: Thu, 10 Mar 2016 10:26:52 +0100 >> Subject: [PATCH] BUILD: Remove detection of libcheck >> >> The unit test framework check has not been used in freeipa for long time >> (if ever) but there was still conditional check for this framework. >> It just produced confusing warning: >> Without the 'CHECK' library, you will be unable >> to run all tests in the 'make check' suite >> --- > ACK > Pushed to master: dbc3a7511029dd954fff4cdb722f51e1f4e4b054 From pspacek at redhat.com Fri Apr 22 11:28:19 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Apr 2016 13:28:19 +0200 Subject: [Freeipa-devel] [PATCH 0096] Batch command: avoid accessing potentially undefined context.principa Message-ID: <571A0AD3.3090507@redhat.com> Hello, Batch command: avoid accessing potentially undefined context.principal This might happen when the command is called directly in Python, e.g. in installers and so on. Pylint pylint-1.5.5-1.fc24.noarch caught this. https://fedorahosted.org/freeipa/ticket/5838 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0096-Batch-command-avoid-accessing-potentially-undefined-.patch Type: text/x-patch Size: 1318 bytes Desc: not available URL: From pspacek at redhat.com Fri Apr 22 11:29:07 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Apr 2016 13:29:07 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed Message-ID: <571A0B03.9030402@redhat.com> Hello, Makefile: add sed to BuildRequires It was requried since forever but we did not explicitly mention it. Makefile: replace perl with sed Perl was missing in BuildRequires anyway and it is used only on one place, all other places are using sed. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0097-Makefile-replace-perl-with-sed.patch Type: text/x-patch Size: 2037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0098-Makefile-add-sed-to-BuildRequires.patch Type: text/x-patch Size: 784 bytes Desc: not available URL: From pspacek at redhat.com Fri Apr 22 12:35:43 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Apr 2016 14:35:43 +0200 Subject: [Freeipa-devel] [PATCH 0088-0095] Add --forward-policy option into installers In-Reply-To: <570D13A3.8060802@redhat.com> References: <56E1E3B2.3070907@redhat.com> <20160310211744.GD32482@mail.corp.redhat.com> <56F01891.5030704@redhat.com> <56FD0DBF.7030307@redhat.com> <57028A3D.1010204@redhat.com> <570D13A3.8060802@redhat.com> Message-ID: <571A1A9F.3010906@redhat.com> On 12.4.2016 17:26, Martin Basti wrote: > > > On 04.04.2016 17:37, Petr Spacek wrote: >> On 31.3.2016 13:45, Martin Basti wrote: >>> >>> On 21.03.2016 16:51, Petr Spacek wrote: >>>> On 10.3.2016 22:17, Lukas Slebodnik wrote: >>>>> On (10/03/16 22:14), Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> I forgot to send a patches before I leave, so here it is: >>>>>> >>>>>> Auto-detect default value for --forward-policy option in installers >>>>>> >>>>>> See >>>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>>> commit messages, and design page >>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I did not have time to test it thoroughly but it LGTM :-D >>>>>> >>>>>> Please note that this is first part, it does not solve upgrade (yet) and >>>>>> warnings in forwardzone-* interface. >>>>>> >>>>>> This can be solved in another patch set, this can be pushed if it passes >>>>>> review. >>>>>> >>>>> ENOPATH >>>> LOL, here it is. >>>> >>>> >>>> >>> * Remove function ipapython.ipautil.host_exists() * >>> ACK >>> >>> >>> * Extend installers with --forward-policy option * >>> 1) >>> There is no --forward-policy option in ipa-dns-install >>> >>> >>> * Move automatic empty zone list into ipapython.dnsutil and make it reusable * >>> ACK >>> >>> >>> * Add assert_absolute_dnsname() helper to ipapython.dnsutil * >>> ACK >>> >>> >>> * Move function is_auto_empty_zone() into ipapython.dnsutil * >>> ACK >>> >>> >>> * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * >>> ACK >>> >>> * Add function ipapython.dnsutil.inside_auto_empty_zone() * >>> ACK >>> >>> * Auto-detect default value for --forward-policy option in installers * >>> LGTM, but ipa-dns-install is missing option --forward-policy >>> >>> # ipa-dns-install >>> ... >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> AttributeError: Values instance has no attribute 'forward_policy' >>> >>> >>> Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK >> Thank you very much for review. >> >> Here is my second attempt :-) >> > Hello, > code works as expected, but it is quite inconsistent with current behavior > > ipa-server-install --forward-policy should raise error without --setup-dns option > > Like here: > [root at vm-058-134 ~]# ipa-server-install --forwarder=10.2.3.4 > Usage: ipa-server-install [options] > > ipa-server-install: error: You cannot specify a --forwarder option without the > --setup-dns option > ipa.ipapython.install.cli.install_tool(Server): ERROR The > ipa-server-install command failed. See /var/log/ipaserver-install.log for more > information > > Martin Fixed patches are attached. Thank you for your time! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0088-3-Remove-function-ipapython.ipautil.host_exists.patch Type: text/x-patch Size: 2546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0089-3-Extend-installers-with-forward-policy-option.patch Type: text/x-patch Size: 9760 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0090-3-Move-automatic-empty-zone-list-into-ipapython.dnsuti.patch Type: text/x-patch Size: 8307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0091-3-Add-assert_absolute_dnsname-helper-to-ipapython.dnsu.patch Type: text/x-patch Size: 1574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0092-3-Move-function-is_auto_empty_zone-into-ipapython.dnsu.patch Type: text/x-patch Size: 2212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0093-3-Use-shared-sanity-check-and-tests-ipapython.dnsutil..patch Type: text/x-patch Size: 1299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0094-3-Add-function-ipapython.dnsutil.inside_auto_empty_zon.patch Type: text/x-patch Size: 1508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0095-3-Auto-detect-default-value-for-forward-policy-option-.patch Type: text/x-patch Size: 6542 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 22 12:42:49 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 22 Apr 2016 14:42:49 +0200 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160421130443.GA29591@mniranja.pnq.csb> References: <20160406085514.GA17358@mniranja.pnq.redhat.com> <5704F243.5000006@redhat.com> <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> <57178E88.40207@redhat.com> <20160421052520.GA5879@mniranja.pnq.csb> <5718A13F.5070809@redhat.com> <20160421130443.GA29591@mniranja.pnq.csb> Message-ID: <571A1C49.2060106@redhat.com> On 04/21/2016 03:04 PM, Niranjan wrote: > Petr Viktorin wrote: >> On 04/21/2016 07:25 AM, Niranjan wrote: >>> Petr Viktorin wrote: >>>> On 04/20/2016 06:11 AM, Niranjan wrote: >>>>> Petr Viktorin wrote: >>>>>> On 04/18/2016 12:39 PM, Niranjan wrote: >>>>>>> Niranjan wrote: >>>>>>>> Niranjan wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: >>>>>>>>>>> Greetings, >>>>>>>>>>> >>>>>>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed >>>>>>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would >>>>>>>>>>> like to get more inputs on how to use pytest-multihost to execute commands >>>>>>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be >>>>>>>>>>> installed. >>>>>>>>>> [...] >> >> If this works for you, I'll commit it and release. > > With this latest patch it worked after removing the line "transport_class = > transport.SSHTransport" from QeBaseHost class. > > Please go ahead and commit it. I've commited it and released version 1.1. Packages for Fedora Rawhide are being built; if you need this for older Fedoras let me know so I don't forget to build there too. Thanks for your assistance! -- Petr Viktorin From amarecek at redhat.com Fri Apr 22 13:42:37 2016 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Fri, 22 Apr 2016 09:42:37 -0400 (EDT) Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <57191036.9030806@redhat.com> References: <56B23BE0.4000207@redhat.com> <571500DF.20204@redhat.com> <1461008004.30315.15.camel@redhat.com> <5715F65E.2030403@redhat.com> <1461086255.30315.46.camel@redhat.com> <5718F422.4000205@redhat.com> <1461257923.30315.101.camel@redhat.com> <57191036.9030806@redhat.com> Message-ID: <2081977019.4273882.1461332557447.JavaMail.zimbra@redhat.com> Design doc reviewed. Some minor specifications discussed with Petr and Martin, added to the doc. UQE_ACK. Thanks, - alich - ----- Original Message ----- > From: "Martin Basti" > To: "Simo Sorce" , "Petr Spacek" > Cc: freeipa-devel at redhat.com > Sent: Thursday, April 21, 2016 7:39:02 PM > Subject: Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface > > > > On 21.04.2016 18:58, Simo Sorce wrote: > > On Thu, 2016-04-21 at 17:39 +0200, Petr Spacek wrote: > >> On 19.4.2016 19:17, Simo Sorce wrote: > >>> On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote: > >>>> On 18.4.2016 21:33, Simo Sorce wrote: > >>>>> On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote: > >>>>>> * Find, filter and copy hand-made records from main tree into the > >>>>>> _locations sub-trees. This means that every hand-made record > >>>>>> needs to be copied and synchronized N-times where N = number of IPA > >>>>>> locations. > >>>>> This ^^ seem the one that provides the best semantics for admins and > >>>>> the > >>>>> least unexpected results. > >>>>> > >>>>>> My favorite option for the first version is 'document that enabling > >>>>>> DNS location will hide hand-made records in IPA domain.' > >>>>> I do not think this is acceptable, sorry. > >>>>> > >>>>>> The feature is disabled by default and needs additional configuration > >>>>>> anyway so simply upgrading should not break anything. > >>>>> It is also useless this way. > >>>>> > >>>>>> I'm eager to hear opinions and answers to questions above. > >>>>> HTH, > >>>> Well it does not help because you did not answer the questions listed in > >>>> the > >>>> design page. > >>>> > >>>> Anyway, here is third version of the design. It avoids copying user-made > >>>> records (basically 2 DNAMEs were replaced with bunch of CNAMEs): > >>>> > >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29 > >>>> > >>>> It seems like a good middle ground: > >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals > >>> It does seem like a decent middle ground. > >>> And I guess an admin would be able to add custom templates if he wants > >>> to have specific services forwarded to the location specific subtree ? > >> Yes, the bind-dyndb-ldap's RecordGenerator and PerServerConfigInLDAP are > >> generic enough. At the moment we do not plan to expose these mechanisms in > >> user interface, we might do that later on. > >> > >> > >>>> This required changes in RecordGenerator design, too: > >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator > >>> I do not see where you specify the specific record names you forward to > >>> the location trees here? > >> I do not understand the question. Let's have a look at the example: > >> > >> # DN specifies DNS node name which will hold the generated record: > >> dn: idnsName=_udp,idnsname=example.com.,cn=dns,dc=example,dc=com > >> # this is equivalent to _udp.example.com. > >> > >> objectClass: idnsTemplateObject > >> objectClass: top > >> objectClass: idnsRecord > >> idnsName: _udp > >> > >> # sub-type determines type of the generated record = DNAME > >> idnsTemplateAttribute;dnamerecord: > >> _udp.\{substitutionvariable_ipalocation\}._locations > >> # generated value will be _udp.your-location._locations > >> # it is a relative name so zone name (example.com) will be automatically > >> appended > >> > >> The template is just string, so you can specify an absolute name if you > >> want: > >> idnsTemplateAttribute;dnamerecord: > >> _udp.\{substitutionvariable_ipalocation\}._locations.another.zone.example. > >> > >> Of course 'ipalocation' is just a variable name so user can define his own > >> in > >> PerServerConfigInLDAP. > >> > >> Is it clearer now? > > Sorry I thought you said in option 3 that you would only create records > > for specific services using CNAMEs > > I was looking for how you configure which services you are going to pick > > in that case and couldn't see it. > > This example is a DNAME one and looks to me it is about option 2 ? > > > I put there image for version 3 there, and put/fix some implementation > details there. I will add more implementation details tomorrow. > > Basically, IPA knows what services are on which server (except NTP, will > be fixed), so based on this we are able to generate proper SRV records > in all locations, and mark the original one by attribute > 'idnsTemplateAttribute;cnamerecord' Please see example here, I will > refer on it later > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CNAME_data_generation > > > In case that server is not configured to provide Location specific data, > or the server is old, the original SRV record (marked with > 'idnsTemplateAttribute') will be used. In case that server is configured > to provide location specific data, bind-dyndb-ldap will replace the > original SRV record by CNAME according to location. > > Other SRV records (those not marked by 'idnsTemplateAttribute') are > untouched. > > Martin > > -- > 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 slaznick at redhat.com Fri Apr 22 15:15:38 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 22 Apr 2016 17:15:38 +0200 Subject: [Freeipa-devel] [PATCH 0024] ipa-replica-manage: added --suffix option for certain commands In-Reply-To: <571A0749.9020402@redhat.com> References: <56E29266.8000501@redhat.com> <56E6E43B.4050805@redhat.com> <56E7AADC.3060407@redhat.com> <56E7F642.8010109@redhat.com> <56E90C5C.2020703@redhat.com> <56E925D0.2080305@redhat.com> <56E9637B.5080307@redhat.com> <56F2B380.9030504@redhat.com> <1183297765.33667649.1458760420403.JavaMail.zimbra@redhat.com> <56F42D93.5050505@redhat.com> <56FBE818.80805@redhat.com> <5704FB3C.2050003@redhat.com> <570E3013.7030006@redhat.com> <5710DECD.5040103@redhat.com> <571A0749.9020402@redhat.com> Message-ID: <571A401A.7080804@redhat.com> On 04/22/2016 01:13 PM, Martin Basti wrote: > > > On 15.04.2016 14:30, Stanislav Laznicka wrote: >> On 04/13/2016 01:40 PM, Martin Basti wrote: >>> >>> >>> On 06.04.2016 14:04, Stanislav Laznicka wrote: >>>> On 03/30/2016 04:52 PM, Martin Basti wrote: >>>>> On 24.03.2016 19:10, Stanislav Laznicka wrote: >>>>>> On 03/23/2016 08:13 PM, Martin Basti wrote: >>>>>>> [...] >>>>>>> Can you please update design >>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 >>>>>>> (mainly >>>>>>> the --suffix option)? Also there are missing clean-ruv and list-ruv >>>>>>> commands in design, and fix usage at the bottom. >>>>>>> >>>>>>> 1) >>>>>>> I don't understand this expression >>>>>>> + if dirman_passwd is None or ( >>>>>>> + not dirman_passwd and args[0] in >>>>>>> cs_enabled_commands): >>>>>>> >>>>>>> You already tested if subcommand belongs to cs_enabled_commands few >>>>>>> lines above, IMO the 'dirman_password is None' expression is >>>>>>> enough. >>>>>> If I understand it well, when empty password is entered, the >>>>>> program continues and uses Kerberos credentials for some >>>>>> operations. E.g. for list-ruv, if empty password is entered, the >>>>>> command would only display RUVs for domain tree but not for the >>>>>> CA tree no matter if CA is set up or not (in the current state of >>>>>> the patch, after get_ruv refactoring). This here is one possible >>>>>> way around this, although the check for non-empty password might >>>>>> probably just as well be in get_ruv_both_suffixes. >>>>> >>>>> ok >>>>>>> 2) >>>>>>> +# tuple of commands that work with ca tree and need Directory >>>>>>> Manager >>>>>>> password >>>>>>> +cs_enabled_commands = ("list-ruv", "clean-ruv", "abort-clean-ruv") >>>>>>> >>>>>>> this variable is used only toi detect if dirman passwd is needed, I >>>>>>> suggest to rename it to commands_req_dirman_passwd, or something >>>>>>> better. >>>>>>> >>>>>>> 3) >>>>>>> Q: Do we need is_cs_set() function? >>>>>>> A: Yes! >>>>>>> >>>>>>> I wanted to give you ultimate NACK, but then I checked how >>>>>>> get_ruv code >>>>>>> works and I changed my mind. >>>>>>> >>>>>>> Please write a comment where is_cs_set function is used, why we >>>>>>> need >>>>>>> extra function instead of catching an exception, possibly you >>>>>>> can open a >>>>>>> refactoring ticket. >>>>>> After the refactoring changes, is_cs_set should not be needed >>>>>> anymore, removed it. >>>>>>> >>>>>>> Shame: >>>>>>> 1) >>>>>>> + if not test_connection(realm, host, options.nolookup) or\ >>>>>>> Please use parentheses instead of backslash >>>>>>> >>>>>>> 2) >>>>>>> + args[0] in cs_enabled_commands: >>>>>>> >>>>>>> + not dirman_passwd and args[0] in >>>>>>> cs_enabled_commands): >>>>>>> >>>>>>> Indentation is not multiplication of 4 >>>>>> Shame on me indeed, fixed it. >>>>>>> >>>>>>> Nitpicks (I don't insist on fixing these): >>>>>>> 1) >>>>>>> + if servers.get('ca', None): >>>>>>> >>>>>>> None is default >>>>>>> >>>>>>> 2) >>>>>>> + for (netloc, rid) in servers['ca']: >>>>>>> parentheses are not needed >>>>>>> >>>>>>> 3) >>>>>>> + print("\t%s: %s" % (netloc, rid)) >>>>>>> Would be nice to use .format() instead of % >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> I changed my mind, ultimate NACK. >>>>>>> Please fix get_ruv function, is_cs_set will not help. In case >>>>>>> there are no RUVs but CA is installed, sys.exit there prevents >>>>>>> us from removing RUVs (or any else operation) on domain suffix, >>>>>>> and vice versa. >>>>>>> I propose to move ticket to 4.4 milestone because I would like >>>>>>> to avoid breaking something in 4.3, as this will hit many places >>>>>>> in ipa-replica-manage. >>>>>>> >>>>>>> Please provide the refactoring of get_ruv as separate patch a >>>>>>> put these patches on top of it. >>>>>>> >>>>>>> Martin2 >>>>>> Did the refactoring. There also seemed to be duplicit code in >>>>>> abort_clean_ruv for some reason, removed it (I hope it does not >>>>>> break anything, but it seemed rather useless). Also had to change >>>>>> the numbers of the patches so that they would apply. >>>>> >>>>> NACK >>>>> >>>>> * ipa-replica-manage refactoring * >>>>> >>>>> 1) >>>>> Instead of: >>>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>>> - sys.exit(1) >>>>> + root_logger.debug("Failed to connect to server {host}: >>>>> {err}" >>>>> + .format(host=host, err=e)) >>>>> + raise RuntimeError(e) >>>>> >>>>> I expected >>>>> >>>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>>> - sys.exit(1) >>>>> + root_logger.debug(traceback.format_exc()) >>>>> + raise RuntimeError("Failed to connect to server {host}: >>>>> {err}" >>>>> + .format(host=host, err=e))) >>>> Should be fixed now. >>>>> >>>>> 2) >>>>> - print("No RUV records found.") >>>>> - sys.exit(0) >>>>> >>>>> Here is exit state 0, so we should not raise error. >>>>> >>>>> I think that we should create new nonfatal exception. >>>> Made a new nonfatal error exception, then. This step was a bit >>>> controversial when it comes to get_ruv_both_suffixes because it >>>> needs to catch both this new exception and a RuntimeError exception >>>> for both trees. As the main idea here was not to stop if either >>>> tree is missing (resulting in RuntimeError in get_ruv) or contains >>>> no records (NonFatalError), it is only printed that something bad >>>> may have happened (or it's debug-logged in case of nonfatal >>>> errors). In the end, only NonFatalError exception is raised if no >>>> records were found for whatever reason resulting in the script >>>> always returning 0. >>>>> >>>>> 3) >>>>> - print("unable to decode: %s" % ruv) >>>>> + root_logger.debug("unable to decode: %s" % ruv) >>>>> This may break tests, because the logger logs to stderr, leave it >>>>> as print for now >>>>> >>>>> 4) >>>>> - servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>>> + try: >>>>> + servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>>> + except RuntimeError as e: >>>>> + print(e) >>>>> + sys.exit(1) >>>>> >>>>> again we have to print it to stdout for now. >>>> 3), 4) done, although it might be better to log to stderr from >>>> patch number 27 and on since the default behavior is changed anyway. >>>>> >>>>> * abort-clean/list/clean-ruv now work for both suffixes * >>>>> >>>>> - if dirman_passwd is None: >>>>> + if dirman_passwd is None or ( >>>>> + not dirman_passwd and args[0] in >>>>> dirman_passwd_req_commands): >>>>> sys.exit("Directory Manager password required") >>>> Done. >>>>> >>>>> Please fix other patch accordingly. >>>>> Martin^2 >>>> >>> >>> 1) >>> +class NonFatalError(Exception): >>> + pass >>> >>> IMO we should be more specific and call it NoRUVsFound[Exception] >>> >>> 2) >>> Not sure if this i sstill refactoring, it should be separate patch >>> - if dirman_passwd is None: >>> + if dirman_passwd is None or ( >>> + not dirman_passwd and args[0] in >>> dirman_passwd_req_commands): >>> >>> 3) >>> +def get_ruv_both_suffixes >>> >>> I think in case where both suffixes returns RuntimeError we should >>> raise RuntimeError too which results into exit with error code. >>> >> Please see the latest patches. > Well, if CA is not installed on replica, it fails, not sure if this is > expected behavior of ipa-replica-manage, or if this is related to your > current patches. > > # ipa-replica-manage -p hesloheslo clean-dangling-ruv > Failed to obtain information from 'vm-058-051.example.com': no such entry > It's actually a bug in clean_dangling_ruvs that was not created in these patches. I opened a separate ticket for it: https://fedorahosted.org/freeipa/ticket/5840. From mkubik at redhat.com Fri Apr 22 22:13:46 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Sat, 23 Apr 2016 00:13:46 +0200 Subject: [Freeipa-devel] [patch 0037] spec: Add python-sssdconfig dependency for python-ipatests package Message-ID: <839e1682-0572-ea40-a66f-19b99ce1ddc5@redhat.com> https://fedorahosted.org/freeipa/ticket/5843 Applies to ipa-4-3, master -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0037-spec-Add-python-sssdconfig-dependency-for-python-ipa.patch Type: text/x-patch Size: 1094 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Sat Apr 23 00:21:28 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Sat, 23 Apr 2016 05:51:28 +0530 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <571A1C49.2060106@redhat.com> References: <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> <57178E88.40207@redhat.com> <20160421052520.GA5879@mniranja.pnq.csb> <5718A13F.5070809@redhat.com> <20160421130443.GA29591@mniranja.pnq.csb> <571A1C49.2060106@redhat.com> Message-ID: <20160423002128.GA26650@mniranja.pnq.csb> Petr Viktorin wrote: > On 04/21/2016 03:04 PM, Niranjan wrote: > > Petr Viktorin wrote: > >> On 04/21/2016 07:25 AM, Niranjan wrote: > >>> Petr Viktorin wrote: > >>>> On 04/20/2016 06:11 AM, Niranjan wrote: > >>>>> Petr Viktorin wrote: > >>>>>> On 04/18/2016 12:39 PM, Niranjan wrote: > >>>>>>> Niranjan wrote: > >>>>>>>> Niranjan wrote: > >>>>>>>>> Petr Viktorin wrote: > >>>>>>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: > >>>>>>>>>>> Greetings, > >>>>>>>>>>> > >>>>>>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed > >>>>>>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would > >>>>>>>>>>> like to get more inputs on how to use pytest-multihost to execute commands > >>>>>>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>>>>>>>>>> installed. > >>>>>>>>>> > [...] > >> > >> If this works for you, I'll commit it and release. > > > > With this latest patch it worked after removing the line "transport_class = > > transport.SSHTransport" from QeBaseHost class. > > > > Please go ahead and commit it. > > I've commited it and released version 1.1. Packages for Fedora Rawhide > are being built; if you need this for older Fedoras let me know so I > don't forget to build there too. No for fedora it's fine, but mostly we are using this in RHEL7, so if you can build it for epel7 it would be great, else it's fine, i will build this for RHEL7, i intend to use this for sssd functional testing. Also i tried to pull the latest from python-pytest-multihost.git from git.fedoraproject.org, i could not see it merged. > > Thanks for your assistance! > You're welcome. > > -- > Petr Viktorin Regards Niranjan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 328 bytes Desc: not available URL: From jcholast at redhat.com Mon Apr 25 05:23:00 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Apr 2016 07:23:00 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: <571A0B03.9030402@redhat.com> References: <571A0B03.9030402@redhat.com> Message-ID: Hi, On 22.4.2016 13:29, Petr Spacek wrote: > Hello, > > Makefile: add sed to BuildRequires > > It was requried since forever but we did not explicitly mention it. IIRC sed is part of the minimum build environemnt and as such should not be explicitly required in the spec file. I personally don't care, but this is the likely reason why it wan't there from the beginning. > > Makefile: replace perl with sed > > Perl was missing in BuildRequires anyway and it is used only on one place, > all other places are using sed. Honza -- Jan Cholasta From jcholast at redhat.com Mon Apr 25 05:55:46 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Apr 2016 07:55:46 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <20160420062254.GE18277@dhcp-40-8.bne.redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> <1460467890.8657.25.camel@redhat.com> <20160413011550.GI18277@dhcp-40-8.bne.redhat.com> <20160414063300.GN18277@dhcp-40-8.bne.redhat.com> <1461008648.30315.24.camel@redhat.com> <20160420062254.GE18277@dhcp-40-8.bne.redhat.com> Message-ID: <98e01be1-16c2-5f3c-6f95-a6e6447a1f1f@redhat.com> Hi, On 20.4.2016 08:22, Fraser Tweedale wrote: > On Mon, Apr 18, 2016 at 03:44:08PM -0400, Simo Sorce wrote: >> On Thu, 2016-04-14 at 16:33 +1000, Fraser Tweedale wrote: >>> On Wed, Apr 13, 2016 at 11:15:50AM +1000, Fraser Tweedale wrote: >>>> On Tue, Apr 12, 2016 at 09:31:30AM -0400, Simo Sorce wrote: >>>>> On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote: >>>>>> On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: >>>>>>> On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: >>>>>>>> - name = gssapi.Name('host@%s' % (self.client,), >>>>>>>> >>>>>>>> - gssapi.NameType.hostbased_service) >>>>>>> >>>>>>> If you remove this then on a serve that has nfs keys in the keytab you >>>>>>> may end up acquiring the wrong credentials. >>>>>>> You need to pass down what credentials you want to use to initialize the >>>>>>> cred store, we canot rely on ordering in the system keytab case. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> Thanks Simo; updated patch attached. >>>>> >>>>> Except the ACI the rest looks good to me. >>>>> For ACI please add a separate patch that follows the naming scheme for >>>>> subCA keys. >>>>> >>>> The ACI here targets the Custodia server public keys, so the client >>>> can search and read them. It should just read: >>>> >>>> add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") >>>> (targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal") >>>> (version 3.0; acl "Anyone can search Custodia public keys"; >>>> allow(read, search, compare) userdn = "ldap:///all";) >>>> >>>> I don't mind putting the ACI in a separate patch, but it is >>>> necessary to restrict read access on the public keys to only the >>>> dogtag-ipa-custodia service principals. >>>> >>> Updated patches attached. ACI was split into new patch and >>> simplified (removed ($dn) macro). >> >> Ack on the custodia patch. >> However do we really need to allow *anyone* to look up these keys ? >> I know they are "public" keys, but still ... I think I would prefer a >> stricter ACI. >> > OK, I rescind the ACI patch (0052) and will include a more specific > ACI in a new version of the patch that adds the principal. > > 0051 is good to merge now :) I think it would be better to merge the `client` and `client_servicename` into a single `client_principal` argument, as both of the arguments are used only to specify the principal name of the client. Also I would prefer if the keyfile and keytab arguments were required, because it's better if you can explicitly see what values are used at the call site. Why is init_creds() now called from __init__()? Why is it still called from _auth_header()? Why is ldap_uri now passed to IPAKEMKeys()? > > Thanks for the review, Simo. > Fraser > -- Jan Cholasta From lslebodn at redhat.com Mon Apr 25 07:29:16 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 25 Apr 2016 09:29:16 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: References: <571A0B03.9030402@redhat.com> Message-ID: <20160425072916.GA8197@10.4.128.1> On (25/04/16 07:23), Jan Cholasta wrote: >Hi, > >On 22.4.2016 13:29, Petr Spacek wrote: >> Hello, >> >> Makefile: add sed to BuildRequires >> >> It was requried since forever but we did not explicitly mention it. > >IIRC sed is part of the minimum build environemnt and as such should not be >explicitly required in the spec file. I personally don't care, but this is >the likely reason why it wan't there from the beginning. > +1 It is part of group "@buildsys-build". and fedora packaging guidelines does not recommend to list packages from this group in BuildRequires. LS From pspacek at redhat.com Mon Apr 25 07:34:45 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Apr 2016 09:34:45 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: <20160425072916.GA8197@10.4.128.1> References: <571A0B03.9030402@redhat.com> <20160425072916.GA8197@10.4.128.1> Message-ID: <571DC895.6050206@redhat.com> On 25.4.2016 09:29, Lukas Slebodnik wrote: > On (25/04/16 07:23), Jan Cholasta wrote: >> Hi, >> >> On 22.4.2016 13:29, Petr Spacek wrote: >>> Hello, >>> >>> Makefile: add sed to BuildRequires >>> >>> It was requried since forever but we did not explicitly mention it. >> >> IIRC sed is part of the minimum build environemnt and as such should not be >> explicitly required in the spec file. I personally don't care, but this is >> the likely reason why it wan't there from the beginning. >> > +1 > > It is part of group "@buildsys-build". > and fedora packaging guidelines does not recommend to list > packages from this group in BuildRequires. I consider this piece of Fedora guidelines brain-dead as "explicit is better than implicit". Anyway, feel free to NACK it so the status of the patch is clear and this thread can die. I do not insist on it. -- Petr^2 Spacek From mbabinsk at redhat.com Mon Apr 25 07:36:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 Apr 2016 09:36:36 +0200 Subject: [Freeipa-devel] [patch 0037] spec: Add python-sssdconfig dependency for python-ipatests package In-Reply-To: <839e1682-0572-ea40-a66f-19b99ce1ddc5@redhat.com> References: <839e1682-0572-ea40-a66f-19b99ce1ddc5@redhat.com> Message-ID: <571DC904.2010103@redhat.com> On 04/23/2016 12:13 AM, Milan Kub?k wrote: > https://fedorahosted.org/freeipa/ticket/5843 > > Applies to ipa-4-3, master > > -- > Milan Kubik > > > Hi Milan, the dependency on python-sssdconfig was introduced by my fix to https://fedorahosted.org/freeipa/ticket/5625 (I know, shame) which also landed in ipa-4-2, so you'll need to send a patch also for this branch (the current one obviously does not apply). Also in ipa-4-3 and master patch you should require python3-sssdconfig for python3-ipatests. -- Martin^3 Babinsky From lslebodn at redhat.com Mon Apr 25 07:39:39 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 25 Apr 2016 09:39:39 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: <571A0B03.9030402@redhat.com> References: <571A0B03.9030402@redhat.com> Message-ID: <20160425073939.GB8197@10.4.128.1> On (22/04/16 13:29), Petr Spacek wrote: >Hello, > >Makefile: add sed to BuildRequires > >It was requried since forever but we did not explicitly mention it. > >Makefile: replace perl with sed > >Perl was missing in BuildRequires anyway and it is used only on one place, >all other places are using sed. > >-- >Petr^2 Spacek >From 3c7a3c87d62358407d856119e384c70040acec1e Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Fri, 22 Apr 2016 10:40:11 +0200 >Subject: [PATCH] Makefile: replace perl with sed > >Perl was missing in BuildRequires anyway and it is used only on one place, >all other places are using sed. >--- > Makefile | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > ACK >From 2deaef91ab71c0e78b2142c2102cfe65f0e4ed96 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Fri, 22 Apr 2016 10:40:37 +0200 >Subject: [PATCH] Makefile: add sed to BuildRequires > >It was requried since forever but we did not explicitly mention it. >--- > freeipa.spec.in | 1 + > 1 file changed, 1 insertion(+) > NACK As it was mentioned elsewhere in thread this patch is not needed. LS From jcholast at redhat.com Mon Apr 25 07:59:37 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Apr 2016 09:59:37 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: <571DC895.6050206@redhat.com> References: <571A0B03.9030402@redhat.com> <20160425072916.GA8197@10.4.128.1> <571DC895.6050206@redhat.com> Message-ID: <40e66788-c252-4739-5619-6c6eaa64fdb2@redhat.com> On 25.4.2016 09:34, Petr Spacek wrote: > On 25.4.2016 09:29, Lukas Slebodnik wrote: >> On (25/04/16 07:23), Jan Cholasta wrote: >>> Hi, >>> >>> On 22.4.2016 13:29, Petr Spacek wrote: >>>> Hello, >>>> >>>> Makefile: add sed to BuildRequires >>>> >>>> It was requried since forever but we did not explicitly mention it. >>> >>> IIRC sed is part of the minimum build environemnt and as such should not be >>> explicitly required in the spec file. I personally don't care, but this is >>> the likely reason why it wan't there from the beginning. >>> >> +1 >> >> It is part of group "@buildsys-build". >> and fedora packaging guidelines does not recommend to list >> packages from this group in BuildRequires. > > I consider this piece of Fedora guidelines brain-dead as "explicit is better > than implicit". Anyway, feel free to NACK it so the status of the patch is > clear and this thread can die. I do not insist on it. I can't find it in the guidelines anymore, so LGTM. -- Jan Cholasta From mkubik at redhat.com Mon Apr 25 07:59:06 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 25 Apr 2016 09:59:06 +0200 Subject: [Freeipa-devel] [patch 0037] spec: Add python-sssdconfig dependency for python-ipatests package In-Reply-To: <571DC904.2010103@redhat.com> References: <839e1682-0572-ea40-a66f-19b99ce1ddc5@redhat.com> <571DC904.2010103@redhat.com> Message-ID: On 04/25/2016 09:36 AM, Martin Babinsky wrote: > On 04/23/2016 12:13 AM, Milan Kub?k wrote: >> https://fedorahosted.org/freeipa/ticket/5843 >> >> Applies to ipa-4-3, master >> >> -- >> Milan Kubik >> >> >> > > Hi Milan, > > the dependency on python-sssdconfig was introduced by my fix to > https://fedorahosted.org/freeipa/ticket/5625 (I know, shame) which > also landed in ipa-4-2, so you'll need to send a patch also for this > branch (the current one obviously does not apply). > > Also in ipa-4-3 and master patch you should require python3-sssdconfig > for python3-ipatests. > Good catch, thanks. Fixed in new patches. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0037-1-spec-Add-python-sssdconfig-dependency-for-python-ipa.patch Type: text/x-patch Size: 1095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa42-0037-1-spec-Add-python-sssdconfig-dependency-for-freeipa-te.patch Type: text/x-patch Size: 806 bytes Desc: not available URL: From lslebodn at redhat.com Mon Apr 25 08:12:57 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 25 Apr 2016 10:12:57 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: <40e66788-c252-4739-5619-6c6eaa64fdb2@redhat.com> References: <571A0B03.9030402@redhat.com> <20160425072916.GA8197@10.4.128.1> <571DC895.6050206@redhat.com> <40e66788-c252-4739-5619-6c6eaa64fdb2@redhat.com> Message-ID: <20160425081256.GC8197@10.4.128.1> On (25/04/16 09:59), Jan Cholasta wrote: >On 25.4.2016 09:34, Petr Spacek wrote: >> On 25.4.2016 09:29, Lukas Slebodnik wrote: >> > On (25/04/16 07:23), Jan Cholasta wrote: >> > > Hi, >> > > >> > > On 22.4.2016 13:29, Petr Spacek wrote: >> > > > Hello, >> > > > >> > > > Makefile: add sed to BuildRequires >> > > > >> > > > It was requried since forever but we did not explicitly mention it. >> > > >> > > IIRC sed is part of the minimum build environemnt and as such should not be >> > > explicitly required in the spec file. I personally don't care, but this is >> > > the likely reason why it wan't there from the beginning. >> > > >> > +1 >> > >> > It is part of group "@buildsys-build". >> > and fedora packaging guidelines does not recommend to list >> > packages from this group in BuildRequires. >> >> I consider this piece of Fedora guidelines brain-dead as "explicit is better >> than implicit". Anyway, feel free to NACK it so the status of the patch is >> clear and this thread can die. I do not insist on it. > >I can't find it in the guidelines anymore, so LGTM. > It seems that it was changed since I read it last time. There is vague description of which packages should be there. http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 It is important that your package list all necessary build dependencies using the BuildRequires?: tag. You may assume that enough of an environment exists for RPM to function and execute basic shell scripts, but you should not assume any other packages are present as RPM dependencies and anything brought into the buildroot by the build system may change over time. But utility fedora-review still complains if you list packages from group "@buildsys-build" LS From slaznick at redhat.com Mon Apr 25 08:39:29 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Mon, 25 Apr 2016 10:39:29 +0200 Subject: [Freeipa-devel] [PATCH 0024] ipa-replica-manage: added --suffix option for certain commands In-Reply-To: <571A401A.7080804@redhat.com> References: <56E29266.8000501@redhat.com> <56E6E43B.4050805@redhat.com> <56E7AADC.3060407@redhat.com> <56E7F642.8010109@redhat.com> <56E90C5C.2020703@redhat.com> <56E925D0.2080305@redhat.com> <56E9637B.5080307@redhat.com> <56F2B380.9030504@redhat.com> <1183297765.33667649.1458760420403.JavaMail.zimbra@redhat.com> <56F42D93.5050505@redhat.com> <56FBE818.80805@redhat.com> <5704FB3C.2050003@redhat.com> <570E3013.7030006@redhat.com> <5710DECD.5040103@redhat.com> <571A0749.9020402@redhat.com> <571A401A.7080804@redhat.com> Message-ID: <571DD7C1.6050804@redhat.com> On 04/22/2016 05:15 PM, Stanislav Laznicka wrote: > On 04/22/2016 01:13 PM, Martin Basti wrote: >> >> >> On 15.04.2016 14:30, Stanislav Laznicka wrote: >>> On 04/13/2016 01:40 PM, Martin Basti wrote: >>>> >>>> >>>> On 06.04.2016 14:04, Stanislav Laznicka wrote: >>>>> On 03/30/2016 04:52 PM, Martin Basti wrote: >>>>>> On 24.03.2016 19:10, Stanislav Laznicka wrote: >>>>>>> On 03/23/2016 08:13 PM, Martin Basti wrote: >>>>>>>> [...] >>>>>>>> Can you please update design >>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 >>>>>>>> (mainly >>>>>>>> the --suffix option)? Also there are missing clean-ruv and >>>>>>>> list-ruv >>>>>>>> commands in design, and fix usage at the bottom. >>>>>>>> >>>>>>>> 1) >>>>>>>> I don't understand this expression >>>>>>>> + if dirman_passwd is None or ( >>>>>>>> + not dirman_passwd and args[0] in >>>>>>>> cs_enabled_commands): >>>>>>>> >>>>>>>> You already tested if subcommand belongs to cs_enabled_commands >>>>>>>> few >>>>>>>> lines above, IMO the 'dirman_password is None' expression is >>>>>>>> enough. >>>>>>> If I understand it well, when empty password is entered, the >>>>>>> program continues and uses Kerberos credentials for some >>>>>>> operations. E.g. for list-ruv, if empty password is entered, the >>>>>>> command would only display RUVs for domain tree but not for the >>>>>>> CA tree no matter if CA is set up or not (in the current state >>>>>>> of the patch, after get_ruv refactoring). This here is one >>>>>>> possible way around this, although the check for non-empty >>>>>>> password might probably just as well be in get_ruv_both_suffixes. >>>>>> >>>>>> ok >>>>>>>> 2) >>>>>>>> +# tuple of commands that work with ca tree and need Directory >>>>>>>> Manager >>>>>>>> password >>>>>>>> +cs_enabled_commands = ("list-ruv", "clean-ruv", >>>>>>>> "abort-clean-ruv") >>>>>>>> >>>>>>>> this variable is used only toi detect if dirman passwd is >>>>>>>> needed, I >>>>>>>> suggest to rename it to commands_req_dirman_passwd, or >>>>>>>> something better. >>>>>>>> >>>>>>>> 3) >>>>>>>> Q: Do we need is_cs_set() function? >>>>>>>> A: Yes! >>>>>>>> >>>>>>>> I wanted to give you ultimate NACK, but then I checked how >>>>>>>> get_ruv code >>>>>>>> works and I changed my mind. >>>>>>>> >>>>>>>> Please write a comment where is_cs_set function is used, why we >>>>>>>> need >>>>>>>> extra function instead of catching an exception, possibly you >>>>>>>> can open a >>>>>>>> refactoring ticket. >>>>>>> After the refactoring changes, is_cs_set should not be needed >>>>>>> anymore, removed it. >>>>>>>> >>>>>>>> Shame: >>>>>>>> 1) >>>>>>>> + if not test_connection(realm, host, options.nolookup) or\ >>>>>>>> Please use parentheses instead of backslash >>>>>>>> >>>>>>>> 2) >>>>>>>> + args[0] in cs_enabled_commands: >>>>>>>> >>>>>>>> + not dirman_passwd and args[0] in >>>>>>>> cs_enabled_commands): >>>>>>>> >>>>>>>> Indentation is not multiplication of 4 >>>>>>> Shame on me indeed, fixed it. >>>>>>>> >>>>>>>> Nitpicks (I don't insist on fixing these): >>>>>>>> 1) >>>>>>>> + if servers.get('ca', None): >>>>>>>> >>>>>>>> None is default >>>>>>>> >>>>>>>> 2) >>>>>>>> + for (netloc, rid) in servers['ca']: >>>>>>>> parentheses are not needed >>>>>>>> >>>>>>>> 3) >>>>>>>> + print("\t%s: %s" % (netloc, rid)) >>>>>>>> Would be nice to use .format() instead of % >>>>>>>> >>>>>>>> Martin^2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I changed my mind, ultimate NACK. >>>>>>>> Please fix get_ruv function, is_cs_set will not help. In case >>>>>>>> there are no RUVs but CA is installed, sys.exit there prevents >>>>>>>> us from removing RUVs (or any else operation) on domain suffix, >>>>>>>> and vice versa. >>>>>>>> I propose to move ticket to 4.4 milestone because I would like >>>>>>>> to avoid breaking something in 4.3, as this will hit many >>>>>>>> places in ipa-replica-manage. >>>>>>>> >>>>>>>> Please provide the refactoring of get_ruv as separate patch a >>>>>>>> put these patches on top of it. >>>>>>>> >>>>>>>> Martin2 >>>>>>> Did the refactoring. There also seemed to be duplicit code in >>>>>>> abort_clean_ruv for some reason, removed it (I hope it does not >>>>>>> break anything, but it seemed rather useless). Also had to >>>>>>> change the numbers of the patches so that they would apply. >>>>>> >>>>>> NACK >>>>>> >>>>>> * ipa-replica-manage refactoring * >>>>>> >>>>>> 1) >>>>>> Instead of: >>>>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>>>> - sys.exit(1) >>>>>> + root_logger.debug("Failed to connect to server {host}: >>>>>> {err}" >>>>>> + .format(host=host, err=e)) >>>>>> + raise RuntimeError(e) >>>>>> >>>>>> I expected >>>>>> >>>>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>>>> - sys.exit(1) >>>>>> + root_logger.debug(traceback.format_exc()) >>>>>> + raise RuntimeError("Failed to connect to server {host}: >>>>>> {err}" >>>>>> + .format(host=host, err=e))) >>>>> Should be fixed now. >>>>>> >>>>>> 2) >>>>>> - print("No RUV records found.") >>>>>> - sys.exit(0) >>>>>> >>>>>> Here is exit state 0, so we should not raise error. >>>>>> >>>>>> I think that we should create new nonfatal exception. >>>>> Made a new nonfatal error exception, then. This step was a bit >>>>> controversial when it comes to get_ruv_both_suffixes because it >>>>> needs to catch both this new exception and a RuntimeError >>>>> exception for both trees. As the main idea here was not to stop if >>>>> either tree is missing (resulting in RuntimeError in get_ruv) or >>>>> contains no records (NonFatalError), it is only printed that >>>>> something bad may have happened (or it's debug-logged in case of >>>>> nonfatal errors). In the end, only NonFatalError exception is >>>>> raised if no records were found for whatever reason resulting in >>>>> the script always returning 0. >>>>>> >>>>>> 3) >>>>>> - print("unable to decode: %s" % ruv) >>>>>> + root_logger.debug("unable to decode: %s" % ruv) >>>>>> This may break tests, because the logger logs to stderr, leave it >>>>>> as print for now >>>>>> >>>>>> 4) >>>>>> - servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>>>> + try: >>>>>> + servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>>>> + except RuntimeError as e: >>>>>> + print(e) >>>>>> + sys.exit(1) >>>>>> >>>>>> again we have to print it to stdout for now. >>>>> 3), 4) done, although it might be better to log to stderr from >>>>> patch number 27 and on since the default behavior is changed anyway. >>>>>> >>>>>> * abort-clean/list/clean-ruv now work for both suffixes * >>>>>> >>>>>> - if dirman_passwd is None: >>>>>> + if dirman_passwd is None or ( >>>>>> + not dirman_passwd and args[0] in >>>>>> dirman_passwd_req_commands): >>>>>> sys.exit("Directory Manager password required") >>>>> Done. >>>>>> >>>>>> Please fix other patch accordingly. >>>>>> Martin^2 >>>>> >>>> >>>> 1) >>>> +class NonFatalError(Exception): >>>> + pass >>>> >>>> IMO we should be more specific and call it NoRUVsFound[Exception] >>>> >>>> 2) >>>> Not sure if this i sstill refactoring, it should be separate patch >>>> - if dirman_passwd is None: >>>> + if dirman_passwd is None or ( >>>> + not dirman_passwd and args[0] in >>>> dirman_passwd_req_commands): >>>> >>>> 3) >>>> +def get_ruv_both_suffixes >>>> >>>> I think in case where both suffixes returns RuntimeError we should >>>> raise RuntimeError too which results into exit with error code. >>>> >>> Please see the latest patches. >> Well, if CA is not installed on replica, it fails, not sure if this >> is expected behavior of ipa-replica-manage, or if this is related to >> your current patches. >> >> # ipa-replica-manage -p hesloheslo clean-dangling-ruv >> Failed to obtain information from 'vm-058-051.example.com': no such >> entry >> > It's actually a bug in clean_dangling_ruvs that was not created in > these patches. I opened a separate ticket for it: > https://fedorahosted.org/freeipa/ticket/5840. > Please see the updated patches. I added verbose flag to get_ruv_both_suffixes and made list-ruv print that RUVs were not found in either of the trees instead of empty output for that tree. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0026-4-replica-manage-fail-nicely-when-DM-psswd-required.patch Type: text/x-patch Size: 1592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0027-4-ipa-replica-manage-refactoring.patch Type: text/x-patch Size: 5164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0028-4-abort-clean-list-clean-ruv-now-work-for-both-suffixe.patch Type: text/x-patch Size: 9913 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0029-4-Moved-password-check-from-clean_dangling_ruv.patch Type: text/x-patch Size: 1827 bytes Desc: not available URL: From akasurde at redhat.com Mon Apr 25 11:00:28 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 25 Apr 2016 16:30:28 +0530 Subject: [Freeipa-devel] [PATCH] Added warning to user for Internet Explorer Message-ID: <571DF8CC.8070305@redhat.com> Hi All, Please review the attached patch. Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0009-Added-warning-to-user-for-Internet-Explorer.patch Type: text/x-patch Size: 1097 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Apr 25 11:27:25 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 Apr 2016 13:27:25 +0200 Subject: [Freeipa-devel] [DESIGN REVIEW] V4/Manage_replication_topology_4_4 Message-ID: <571DFF1D.9060607@redhat.com> Hi list, this is my review of the http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 design page authored by Petr Vobornik. Overall the page needs some more polishing, there is a number of TODOs and typos which need to be expanded/fixed. Here are some more specific points: 1.) there is a lengthy discussion about the interface and behavior of server-del API command on this list.[1] The server_del description should be updated to reflect the conclusion reached by this discussion. 2.) we should also put more thought into actions which should be performed by `server-del` regarding cleanup of leftover references to replica's ldap/ and HTTP/ principals and DNS records. The thing is that the original code assumes that the cleanup is performed under admin/Directory Manager credentials, while we should assume that most of these tasks should be doable by host itself (see server uninstall use-case). I shall make some more research into this. 3.) I would rewrite Topology graph section in Feature management because the current text is not very readable. Also is there a plan to show roles of an IPA master when clicking on it on the graph or is it a stretch for 4.4? [1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00101.html -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Apr 25 11:43:25 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 25 Apr 2016 13:43:25 +0200 Subject: [Freeipa-devel] [patch 0037] spec: Add python-sssdconfig dependency for python-ipatests package In-Reply-To: References: <839e1682-0572-ea40-a66f-19b99ce1ddc5@redhat.com> <571DC904.2010103@redhat.com> Message-ID: <571E02DD.3070301@redhat.com> On 04/25/2016 09:59 AM, Milan Kub?k wrote: > On 04/25/2016 09:36 AM, Martin Babinsky wrote: >> On 04/23/2016 12:13 AM, Milan Kub?k wrote: >>> https://fedorahosted.org/freeipa/ticket/5843 >>> >>> Applies to ipa-4-3, master >>> >>> -- >>> Milan Kubik >>> >>> >>> >> >> Hi Milan, >> >> the dependency on python-sssdconfig was introduced by my fix to >> https://fedorahosted.org/freeipa/ticket/5625 (I know, shame) which >> also landed in ipa-4-2, so you'll need to send a patch also for this >> branch (the current one obviously does not apply). >> >> Also in ipa-4-3 and master patch you should require python3-sssdconfig >> for python3-ipatests. >> > Good catch, thanks. > Fixed in new patches. > > -- > Milan Kubik > Thanks, ACK. -- Martin^3 Babinsky From lhellebr at redhat.com Mon Apr 25 12:48:25 2016 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Mon, 25 Apr 2016 14:48:25 +0200 Subject: [Freeipa-devel] URI in HBAC Message-ID: <571E1219.9060100@redhat.com> http://www.freeipa.org/page/V4/URI-based_HBAC I have made some important changes to the design document of this proposed feature. The difference is mainly changing regular expression interpretation of URI to longest-prefix matching. This change was done mainly because of upstream's reactions. I value any further comments and particularly discussion about the two topics mentioned at the end of the design page: * For backwards compatibility, lack of URI in request means any URI is matched (as described in the design document). Is it a good idea? Any other solution? * How about multiple URI's in one HBAC rule? Is it a good idea? How to interpret combinations of host+scheme+port (one field) and URI paths (another field) in that case? -- Lukas Hellebrandt Associate Quality Engineer lhellebr at redhat.com From redhatrises at gmail.com Mon Apr 25 13:32:20 2016 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 25 Apr 2016 07:32:20 -0600 Subject: [Freeipa-devel] Possble FreeIPA Trac Malicious Link Message-ID: Hey all, This is something we may need to watch for. I noticed that a possible malicious link was added to the FreeIPA Trac start page. You can view it here: https://fedorahosted.org/freeipa/wiki/WikiStart?action=diff&version=22. I changed it back to the original text before the change. I know that the 389 Trac webpage had issues earlier this year with spam. Just an FYI. Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Apr 25 14:58:25 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Apr 2016 16:58:25 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option Message-ID: <571E3091.3090003@redhat.com> Hello, ipa-nis-manage: add status option https://bugzilla.redhat.com/show_bug.cgi?id=1329275 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0099-ipa-nis-manage-add-status-option.patch Type: text/x-patch Size: 3824 bytes Desc: not available URL: From pspacek at redhat.com Mon Apr 25 15:08:18 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 25 Apr 2016 17:08:18 +0200 Subject: [Freeipa-devel] [PATCH 0100-0101] ipa-nis-manage: fix nits in manual page Message-ID: <571E32E2.9050101@redhat.com> Hello, ipa-nis-manage: mention return code 3 in man page ipa-nis-manage: Replace text references to compat plugin with NIS -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0100-ipa-nis-manage-Replace-text-references-to-compat-plu.patch Type: text/x-patch Size: 1337 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0101-ipa-nis-manage-mention-return-code-3-in-man-page.patch Type: text/x-patch Size: 775 bytes Desc: not available URL: From pviktori at redhat.com Mon Apr 25 15:18:38 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Apr 2016 17:18:38 +0200 Subject: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows In-Reply-To: <20160423002128.GA26650@mniranja.pnq.csb> References: <20160412090701.GA12547@mniranja.pnq.csb> <20160413085330.GA31535@mniranja.pnq.csb> <20160418103922.GA25347@mniranja.pnq.csb> <5714F69B.2090602@redhat.com> <20160420041143.GA4140@mniranja.pnq.csb> <57178E88.40207@redhat.com> <20160421052520.GA5879@mniranja.pnq.csb> <5718A13F.5070809@redhat.com> <20160421130443.GA29591@mniranja.pnq.csb> <571A1C49.2060106@redhat.com> <20160423002128.GA26650@mniranja.pnq.csb> Message-ID: <571E354E.5060004@redhat.com> On 04/23/2016 02:21 AM, Niranjan wrote: > Petr Viktorin wrote: >> On 04/21/2016 03:04 PM, Niranjan wrote: >>> Petr Viktorin wrote: >>>> On 04/21/2016 07:25 AM, Niranjan wrote: >>>>> Petr Viktorin wrote: >>>>>> On 04/20/2016 06:11 AM, Niranjan wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 04/18/2016 12:39 PM, Niranjan wrote: >>>>>>>>> Niranjan wrote: >>>>>>>>>> Niranjan wrote: >>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>> On 04/06/2016 10:55 AM, Niranjan wrote: >>>>>>>>>>>>> Greetings, >>>>>>>>>>>>> >>>>>>>>>>>>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have proposed >>>>>>>>>>>>> a patch, I think this patch is more of a workaround , than a solution. I would >>>>>>>>>>>>> like to get more inputs on how to use pytest-multihost to execute commands >>>>>>>>>>>>> on Windows. The method i am using requires cygwin with openssh/bash to be >>>>>>>>>>>>> installed. >>>>>>>>>>>> >> [...] >>>> >>>> If this works for you, I'll commit it and release. >>> >>> With this latest patch it worked after removing the line "transport_class = >>> transport.SSHTransport" from QeBaseHost class. >>> >>> Please go ahead and commit it. >> >> I've commited it and released version 1.1. Packages for Fedora Rawhide >> are being built; if you need this for older Fedoras let me know so I >> don't forget to build there too. > No for fedora it's fine, but mostly we are using this in RHEL7, so if you > can build it for epel7 it would be great, else it's fine, i will build > this for RHEL7, i intend to use this for sssd functional testing. I'll leave the RHEL version to you. > Also i tried to pull the latest from python-pytest-multihost.git from > git.fedoraproject.org, i could not see it merged. My mistake. It should be fixed now. -- Petr Viktorin From dkupka at redhat.com Tue Apr 26 06:32:46 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 26 Apr 2016 08:32:46 +0200 Subject: [Freeipa-devel] [PATCHES 0464-0468] always set hostname during installation In-Reply-To: <571A017D.709@redhat.com> References: <5717A507.8050707@redhat.com> <571A017D.709@redhat.com> Message-ID: <571F0B8E.20901@redhat.com> On 22/04/16 12:48, Martin Basti wrote: > > > On 20.04.2016 17:49, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5794 >> >> It requires my patch 441.2 >> Patches attached. >> >> > > Rebased patches attached, 441 has been pushed > > Martin^2 > > > Thanks for patch set. Works for me, ACK. -- David Kupka From jcholast at redhat.com Tue Apr 26 07:11:19 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Apr 2016 09:11:19 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals In-Reply-To: <98e01be1-16c2-5f3c-6f95-a6e6447a1f1f@redhat.com> References: <20160408142339.GV18277@dhcp-40-8.bne.redhat.com> <1460126839.7463.195.camel@redhat.com> <20160409001100.GY18277@dhcp-40-8.bne.redhat.com> <1460467890.8657.25.camel@redhat.com> <20160413011550.GI18277@dhcp-40-8.bne.redhat.com> <20160414063300.GN18277@dhcp-40-8.bne.redhat.com> <1461008648.30315.24.camel@redhat.com> <20160420062254.GE18277@dhcp-40-8.bne.redhat.com> <98e01be1-16c2-5f3c-6f95-a6e6447a1f1f@redhat.com> Message-ID: On 25.4.2016 07:55, Jan Cholasta wrote: > Hi, > > On 20.4.2016 08:22, Fraser Tweedale wrote: >> On Mon, Apr 18, 2016 at 03:44:08PM -0400, Simo Sorce wrote: >>> On Thu, 2016-04-14 at 16:33 +1000, Fraser Tweedale wrote: >>>> On Wed, Apr 13, 2016 at 11:15:50AM +1000, Fraser Tweedale wrote: >>>>> On Tue, Apr 12, 2016 at 09:31:30AM -0400, Simo Sorce wrote: >>>>>> On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote: >>>>>>> On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote: >>>>>>>> On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote: >>>>>>>>> - name = gssapi.Name('host@%s' % (self.client,), >>>>>>>>> >>>>>>>>> - gssapi.NameType.hostbased_service) >>>>>>>> >>>>>>>> If you remove this then on a serve that has nfs keys in the >>>>>>>> keytab you >>>>>>>> may end up acquiring the wrong credentials. >>>>>>>> You need to pass down what credentials you want to use to >>>>>>>> initialize the >>>>>>>> cred store, we canot rely on ordering in the system keytab case. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> Thanks Simo; updated patch attached. >>>>>> >>>>>> Except the ACI the rest looks good to me. >>>>>> For ACI please add a separate patch that follows the naming scheme >>>>>> for >>>>>> subCA keys. >>>>>> >>>>> The ACI here targets the Custodia server public keys, so the client >>>>> can search and read them. It should just read: >>>>> >>>>> add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX") >>>>> (targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal") >>>>> (version 3.0; acl "Anyone can search Custodia public keys"; >>>>> allow(read, search, compare) userdn = "ldap:///all";) >>>>> >>>>> I don't mind putting the ACI in a separate patch, but it is >>>>> necessary to restrict read access on the public keys to only the >>>>> dogtag-ipa-custodia service principals. >>>>> >>>> Updated patches attached. ACI was split into new patch and >>>> simplified (removed ($dn) macro). >>> >>> Ack on the custodia patch. >>> However do we really need to allow *anyone* to look up these keys ? >>> I know they are "public" keys, but still ... I think I would prefer a >>> stricter ACI. >>> >> OK, I rescind the ACI patch (0052) and will include a more specific >> ACI in a new version of the patch that adds the principal. >> >> 0051 is good to merge now :) > > I think it would be better to merge the `client` and > `client_servicename` into a single `client_principal` argument, as both > of the arguments are used only to specify the principal name of the client. > > Also I would prefer if the keyfile and keytab arguments were required, > because it's better if you can explicitly see what values are used at > the call site. Actually these would better be class attributes, like: class BaseCustodiaClient(object): client_service_name = None keyfile = None keytab = None # CustodiaClient code ... class CustodiaClient(BaseCustodiaClient): @property def client_service_name(self): return 'host@%s' % (self.client,) keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys') keytab = paths.KRB5_KEYTAB Later you can inherit DogtagCustodiaClient from BaseCustodiaClient and override the attributes as appropriate. > > Why is init_creds() now called from __init__()? Why is it still called > from _auth_header()? > > Why is ldap_uri now passed to IPAKEMKeys()? > >> >> Thanks for the review, Simo. >> Fraser >> > > -- Jan Cholasta From jcholast at redhat.com Tue Apr 26 08:02:45 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Apr 2016 10:02:45 +0200 Subject: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication In-Reply-To: <20160421033003.GH18277@dhcp-40-8.bne.redhat.com> References: <20160414063937.GO18277@dhcp-40-8.bne.redhat.com> <20160421033003.GH18277@dhcp-40-8.bne.redhat.com> Message-ID: <2a1b79e5-83c5-001c-abc3-676ae787f6a6@redhat.com> On 21.4.2016 05:30, Fraser Tweedale wrote: > On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: >> Hi all, >> >> The attached patches configure lightweight CA key replication on IPA >> CAs, on upgrade and installation. >> >> Patches 0051..0052 from my other mail are also needed for the system >> to work, but this patchset does not depend on them and can be >> reviewed independently. >> >> There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 >> - it just puts the necessary principals/keys/configuration in place. >> >> Cheers, >> Fraser >> > New patches attached; 0054-2 changes the service name from > 'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the > principal to search server Custodia keys. Patch 53: I'm not sure about this approach - the cn of custodia keys in LDAP is a free-form string, I would not tie it to service names, but rather try to keep it short. In the key replication section of the design page, you mention "ca/$NAME", I think this is a good template for the cn and that we should stick to it. Patch 54: 1) This belongs to CAInstance.configure_instance(): + CA = cainstance.CAInstance( + api.env.realm, certs.NSS_DIR, host_name=api.env.host) + CA.setup_lightweight_ca_key_retrieval() 2) Any ACI changes should be in a separate patch. (What happened to patch 52?) 3) This is not a platform constant, just a constant: + PKI_GSSAPI_SERVICE_NAME = 'dogtag' 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please split it into a "setup keytab" and "setup custodia" parts. 5) This also belongs to CAInstance.configure_instance(): + if setup_ca: + # CA was configured before Kerberos; + # add Custodia client princ and keys now + ca_instance.setup_lightweight_ca_key_retrieval() In order for that to work, you need to move the ca.install_step_1() after krb.create_instance(), but that should be OK, since KrbInstance does not talk to the CA. Honza -- Jan Cholasta From dkupka at redhat.com Tue Apr 26 08:09:59 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 26 Apr 2016 10:09:59 +0200 Subject: [Freeipa-devel] [PATCH 0095-0098] NTP: use augeas, configure chronyd, do not overwrite config In-Reply-To: <56E6B641.7030202@redhat.com> References: <56E27ED4.4020306@redhat.com> <56E6B2A6.9050904@redhat.com> <56E6B641.7030202@redhat.com> Message-ID: <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> On 14/03/16 14:01, Martin Basti wrote: > > > On 14.03.2016 13:46, Martin Babinsky wrote: >> On 03/11/2016 09:16 AM, David Kupka wrote: >>> Current version (0.5.0) of python-augeas is missing copy() method. Use >>> dkupka/python-augeas copr repo before new version it's build and >>> available in the official repos. >>> >>> >>> >> Hi David, >> >> TLDR: NACK :D. >> >> Here are high-level remarks to discuss: >> >> Maybe it would be a good idea to move ipaaugeas/changeconf and ntp to >> ipaplatform since it is dealing with (sorta) platform specific >> behavior (ntp vs. chrony vs. whatever we will have for timesync in the >> future). CC'ing Jan for thoughts. >> >> Also regarding patches 0096-0097, we could have platform specific >> TimeDateService object that could wrap NTP/chrony management. for >> example, the task namespace functions in Pathc 0096 could be >> reimplemented as a methods of the service (RedhatTimeDateService, >> FedoraTimeDateService etc.) and then called in a platform-agnostic >> manner. >> >> Here are some comments regarding code: >> >> Patch 0095: >> >> 1.) >> + IPA_CUSTOM_AUGEAS_LENSES_DIR = '/usr/share/augeas/lenses/ipa/' >> >> Do not forget to add this directory to %install and %files spection of >> the spec file so that it is correctly added to RPM build. >> >> 2.) >> >> please separate import of system-wide and IPA-specific modules by >> blank line >> >> +import collections >> +from augeas import Augeas >> +from ipaplatform.paths import paths >> +from ipapython.ipa_log_manager import root_logger >> >> 3.) the call to parent's __new__ should have signature 'super(aug_obj, >> cls).__new__(*args, **kwargs)' >> >> + cls._instance = super(aug_obj, cls).__new__(cls, *args, >> **kwargs) >> >> 4.) >> >> + raise RuntimeError('Augeas lenses was loaded. Could not >> add more' >> + 'lenses.') >> >> Should be 'Augeas lenses _were_ loaded' >> >> 5.) >> >> + if lens in self.lenses: >> + raise RuntimeError('Lens %s already added.' % lens) >> + self.lenses.append(lens) >> + load_path = '/augeas/load/{0}'.format(lens >> >> >> Shouldn't the following code use os.path,join to construct the load_path? >> >> 6.) I would prefer the following indentation style in the add_lens() >> method >> >> @@ -65,9 +65,9 @@ class aug_obj(object): >> for conf_file in conf_files: >> self._aug.set(os.path.join(load_path, 'incl[0]'), conf_file) >> self.tree['old'] = self.tree.get(conf_file, None) >> - self.tree[conf_file] = aug_node(self._aug, >> - os.path.join('/files', >> - conf_file[1:])) >> + self.tree[conf_file] = aug_node( >> + self._aug, os.path.join('/files', conf_file[1:]) >> + ) >> >> 7.) I would also prefer if the hardcoded paths like '/augeas/load', >> 'files', and '//error' would be made into either module variables or >> class members. >> >> 8.) >> >> + def load(self): >> + if self._loaded: >> + raise RuntimeError('Augeas lenses was loaded. Could not >> add more' >> + 'lenses.') >> >> Fix the excpetion text in the same way as in 4.) >> >> 9.) >> >> + errors = self._aug.match(os.path.join('//error')) >> >> is the os.path.join necessary here? >> >> 10.) I guess you can rewrite the error message in load() method using >> list comprehension: >> >> @@ -76,9 +76,9 @@ class aug_obj(object): >> self._aug.load() >> errors = self._aug.match(os.path.join('//error')) >> if errors: >> - err_msg = "" >> - for error in errors: >> - err_msg += ("{}: {}".format(error, >> self._aug.get(error))) >> + err_msg = '\n'.join( >> + ["{}: {}".format(e, self._aug.get(e)) for e in errors] >> + ) >> raise RuntimeError(err_msg) >> self._loaded = True >> >> 11.) >> >> +class aug_node(collections.MutableMapping): >> + """ Single augeas node. >> + Can be handled as python dict(). >> + """ >> + def __init__(self, aug, path): >> + self._aug = aug >> + if path and os.path.isabs(path): >> + self._path = path >> + else: >> + self._tmp = _tmp_path(aug, path) >> + self._path = self._tmp.path >> >> Isn't it better to change signature of __init__ to: >> >> def __init__(self, aug, path=None): >> >> and then test whether path is None? >> >> 12.) >> >> def __setitem__(self, key, node): >> + target = os.path.join(self._path, key) >> + end = '{0}[0]'.format(os.path.join(self._path, key)) >> + if self._aug.match(target): >> + self._aug.remove(target) >> + target_list = aug_list(self._aug, target) >> + for src_node in aug_list(node._aug, node._path): >> + target_list.append(src_node) >> >> The 'end' variable is declared but not used. >> >> 13.) >> >> + >> + def __len__(self): >> + return len(self._aug.match('{0}/*'.format(self._path))) >> + >> + def __iter__(self): >> + for key in self._aug.match('{0}/*'.format(self._path)): >> + yield self._aug.label(key) >> + raise StopIteration() >> + >> >> Shouldn't we construct paths using os.path.join for the sake of >> consistency? >> >> 14.) >> >> + def __bool__(self): >> + return (bool(len(self)) or bool(self.value)) >> >> The parentheses around the boolean expression are not needed >> >> 15.) >> >> +class aug_list(collections.MutableSequence): >> + """Augeas NODESET. >> + Can be handled as a list(). >> + """ >> + def __init__(self, aug, path): >> + self._aug = aug >> + if path and os.path.isabs(path): >> + self._path = path >> + else: >> + self._tmp = _tmp_path(aug, path) >> + self._path = self._tmp.path >> >> I would use 'path=None' int he signature and then test whether 'path >> is not None'. >> >> 16.) >> >> + if not self._aug.match(target): >> + raise IndexError() >> >> It would be nice if you could put some basic error message into the >> raised exceptions, like "node index out of range" or something like that >> >> 17.) >> >> + elif isinstance(index, slice): >> + label = self._path.split('/')[-1] >> >> you could use os.path.basename() to get the leaf node. >> >> >> 18.) >> >> + replace = range_target[:len(node)] >> + delete = create = [] >> >> Be careful here as you create two references to the same empty list >> object, which is probably not what you wanted. >> >> 19.) >> + try: >> + create_start = range_target[-1]+1 >> + except IndexError: >> + create_start = self._idx_pos(index.start) >> + create_stop = create_start+len(node)-len(replace) >> + create = list(range(create_start, create_stop)) >> >> Please respect PEP8 and put spaces around arithmetic operators in >> assignments. >> >> Also it would be nice to have at least a minimal test suite for this >> module, but that may be a separate ticket. >> >> patch 0096: >> >> 1.) please fix the commit message >> 2.) please use new-style license header in ipapython/ntp.py >> 3.) >> >> + return ("Conflicting Time&Date synchroniztion service '%s' is " >> + "currently enabled and/or running on the system." >> + % self.conflicting_service) >> >> Please fix the typo in the error message. >> >> 4.) >> + service = services.service(self.service_name) >> + if sstore: >> + if sstore.get_state('ntp', 'enabled') is None: >> + sstore.backup_state('ntp', 'enabled', >> service.is_enabled()) >> + >> + if fstore: >> + if not fstore.has_file(self.conf_file): >> + fstore.backup_file(self.conf_file) >> >> the conditions in the 'if' statement can be merged into single AND >> expression >> >> 5.) >> + self._store_service_state(sstore, fstore) >> + if sstore: >> + sstore.backup_state('ntp', "enabled", service.is_enabled()) >> + >> + if fstore: >> + fstore.backup_file(self.conf_file) >> >> I think these checks are redundant here. >> >> 6.) >> + # In such case it is OK to fail >> + try: >> + restored = fstore.restore_file(self.conf_file) >> + except Exception: >> + pass >> >> Instead of 'pass' it would be better to set restored to False so that >> you don't hit NameError later. >> >> 7.) >> + >> + def configure_client(self, ntp_servers=[], sstore=None, >> fstore=None): >> + self.server_options['burst'] = None >> + self.server_options['iburst'] = None >> >> I would rather set these instance variables in __init__() than here. >> >> 8.) >> >> + def configure_client(self, ntp_servers=[], sstore=None, >> fstore=None): >> + self.conf_file = paths.CHRONY_CONF >> self.conf_file is already defined in constructor. >> >> 9.) >> >> + self.server_options['iburst'] = None >> this should be moved to __init__() >> >> 10.) >> + with ipaaugeas.aug_obj() as aug: >> + try: >> + aug.add_lens(self.lens, [self.conf_file]) >> + aug.load() >> + except RuntimeError as e: >> + raise NTPConfigurationError(e) >> >> This code is repeated quite a few times, maybe it would be a good idea >> to factor it out to a method of NTPService object. >> >> >> Patch 0097: >> >> 1.) please fix a typo here: >> >> + description="Disble any other Time synchronization services." >> >> 2.) >> >> + installutils, kra, krbinstance, memcacheinstance, ntpinstance, >> you have 2 spaces before 'ntpinstance' >> > > I'm adding my nitpicks too :) > > 1) > +#!/usr/bin/python > > This should not be in modules, only in executable files > > 2) > Missing license in ipaaugeas.py > > Martin^2 Hello, after offline discussion with Honza I've rewritten the augeas wrapper and modified ipautil/ntp.py accordingly. The rest should be pretty much the same. Patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0095.1-augeas-add-wrapper-around-python-binding.patch Type: text/x-patch Size: 4812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0096.1-ntp-Add-module-for-NTP-configuration.patch Type: text/x-patch Size: 15332 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0097.1-ntp-Add-platform-specific-tasks.patch Type: text/x-patch Size: 3667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0098.1-ntp-install-Use-tasks-to-configure-NTP-daemon.patch Type: text/x-patch Size: 33116 bytes Desc: not available URL: From dkupka at redhat.com Tue Apr 26 08:17:39 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 26 Apr 2016 10:17:39 +0200 Subject: [Freeipa-devel] Possble FreeIPA Trac Malicious Link In-Reply-To: References: Message-ID: <83fdaf41-5d1b-942b-8f91-eb994eae34d4@redhat.com> On 25/04/16 15:32, Gabe Alford wrote: > Hey all, > > This is something we may need to watch for. I noticed that a possible malicious > link was added to the FreeIPA Trac start page. You can view it here: > https://fedorahosted.org/freeipa/wiki/WikiStart?action=diff&version=22. I > changed it back to the original text before the change. I know that the 389 Trac > webpage had issues earlier this year with spam. Just an FYI. > > Gabe > > > Hello Gabe, thanks for noticing and fixing. I've contacted Fedora infrastructure admin with request to ban the user and he informed me that the account was already blocked by antispam detection mechanism. Also he added few more rules for faster detection next time. -- David Kupka From pspacek at redhat.com Tue Apr 26 08:22:23 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Apr 2016 10:22:23 +0200 Subject: [Freeipa-devel] [PATCH 0095-0098] NTP: use augeas, configure chronyd, do not overwrite config In-Reply-To: <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> References: <56E27ED4.4020306@redhat.com> <56E6B2A6.9050904@redhat.com> <56E6B641.7030202@redhat.com> <7616143a-af30-25b6-b20f-b4eefc28f6ad@redhat.com> Message-ID: <571F253F.7030101@redhat.com> On 26.4.2016 10:09, David Kupka wrote: > diff --git a/ipapython/configfile.py b/ipapython/configfile.py > new file mode 100644 > index 0000000000000000000000000000000000000000..b48a9eae97dc4c1b19d6ae7e961ce701a4a36ed7 > --- /dev/null > +++ b/ipapython/configfile.py NACK, I think that Augeas magic is underdocumented. Possible form of documentation are doctests :-) -- Petr^2 Spacek From jcholast at redhat.com Tue Apr 26 10:28:03 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Apr 2016 12:28:03 +0200 Subject: [Freeipa-devel] [DESIGN] Thin client Message-ID: <24f7dbe9-8086-39ac-9283-48bd5398c8f3@redhat.com> Hi, see for initial design of the Thin client feature. The API compatibility part of the design is work in progress (by me), as is the client side caching part (by David). Big thanks to David for actually writing most of the text in the design page. Comments and suggestions are welcome. Honza -- Jan Cholasta From jcholast at redhat.com Tue Apr 26 10:57:09 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Apr 2016 12:57:09 +0200 Subject: [Freeipa-devel] URI in HBAC In-Reply-To: <571E1219.9060100@redhat.com> References: <571E1219.9060100@redhat.com> Message-ID: Hi, On 25.4.2016 14:48, Luk?? Hellebrandt wrote: > http://www.freeipa.org/page/V4/URI-based_HBAC > > I have made some important changes to the design document of this > proposed feature. The difference is mainly changing regular expression > interpretation of URI to longest-prefix matching. > > This change was done mainly because of upstream's reactions. I value any > further comments and particularly discussion about the two topics > mentioned at the end of the design page: > > * For backwards compatibility, lack of URI in request means any URI is > matched (as described in the design document). Is it a good idea? Any > other solution? For other attributes in HBAC rules, the lack of a value means nothing is matched. To match anything, you have to set "${attribute}category" to "all". I would prefer if URI matching was consistent with this, if it's possible. > > * How about multiple URI's in one HBAC rule? Is it a good idea? How to > interpret combinations of host+scheme+port (one field) and URI paths > (another field) in that case? I think it is not only good idea, but actually necessary. I guess you would have to consider an URI matched if it's host+scheme+port matches any of the host+scheme+port patterns and at the same time it's path matches any of the path patterns. BTW what is the reason to split URIs into separate fields? If it's just case sensitivity, I would like to point out that you can switch case sensitivity on and off in the middle of a Perl regex using "(?i)" and "(?-i)". Honza -- Jan Cholasta From pspacek at redhat.com Tue Apr 26 11:26:36 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Apr 2016 13:26:36 +0200 Subject: [Freeipa-devel] [DESIGN] Thin client In-Reply-To: <24f7dbe9-8086-39ac-9283-48bd5398c8f3@redhat.com> References: <24f7dbe9-8086-39ac-9283-48bd5398c8f3@redhat.com> Message-ID: <571F506C.7000204@redhat.com> On 26.4.2016 12:28, Jan Cholasta wrote: > Hi, > > see for initial design of the > Thin client feature. The API compatibility part of the design is work in > progress (by me), as is the client side caching part (by David). > > Big thanks to David for actually writing most of the text in the design page. > > Comments and suggestions are welcome. In general it is good. I have two questions: 1) Caching > IPA client can cache downloaded metadata to reduce traffic and reduce start up time. IPA client can send metadata fingerprint with request. When newer metadata are available server must add warning to the response. Shouldn't it be an hard error when client sends old metadata? I do not like the warning because when you receive a warning it is too late to cancel the command. 2) Client/server side plugins. I expect that some very special features (like client-side OTP provisioning) might depend particular version/range of version on the client. Will the metadata include version range which can be checked on client side to make sure that everything is compatible (for given command/plugin)? Other than that it seems reasonable. I'm looking forward to see more details! -- Petr^2 Spacek From pvomacka at redhat.com Tue Apr 26 11:33:31 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 26 Apr 2016 13:33:31 +0200 Subject: [Freeipa-devel] [PATCH] 0018-0030 webui: add support for more certificates Message-ID: <571F520B.2000501@redhat.com> Hello, the attached patches add support for more certificates and ability to add and remove certificates. Fixes these two tickets: https://fedorahosted.org/freeipa/ticket/5108 https://fedorahosted.org/freeipa/ticket/5381 These patches add ability to view, get, download, revoke, restore and delete each certificate directly from user/host/service details page. There is also button for adding new certificates. There is one known issue, that after page save action is performed some data disappear (includes certificates). This issue has a ticket already: https://fedorahosted.org/freeipa/ticket/5776 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0018-Add-support-for-dropdown-menu-in-multivalued-widget.patch Type: text/x-patch Size: 3900 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0019-Extends-functionality-of-DropdownWidget.patch Type: text/x-patch Size: 1606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0020-Add-working-widget.patch Type: text/x-patch Size: 4537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0021-Add-ability-to-turn-off-activity-icon.patch Type: text/x-patch Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0022-Add-Object-adapter.patch Type: text/x-patch Size: 2322 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0023-Refactored-certificate-view-and-restore-dialog.patch Type: text/x-patch Size: 12559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0024-Changed-the-way-how-to-handle-restore-and-revoke-act.patch Type: text/x-patch Size: 3651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0025-Remove-old-useless-actions-get-and-view.patch Type: text/x-patch Size: 3360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0026-Add-widget-for-showing-multiple-certificates.patch Type: text/x-patch Size: 9988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0027-Add-certificate-widget.patch Type: text/x-patch Size: 19218 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0028-Add-new-certificates-widget-to-the-user-details-page.patch Type: text/x-patch Size: 2794 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0029-Add-new-certificates-widget-to-the-host-details-page.patch Type: text/x-patch Size: 5693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0030-Add-new-certificates-widget-to-the-service-details-p.patch Type: text/x-patch Size: 4493 bytes Desc: not available URL: From mbasti at redhat.com Tue Apr 26 11:41:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 26 Apr 2016 13:41:29 +0200 Subject: [Freeipa-devel] [PATCH 0439] Do not do extra search for ipasshpubkey In-Reply-To: <571A2947.4040604@redhat.com> References: <56E804A4.4000505@redhat.com> <56EBF37F.4090101@redhat.com> <56EF9937.5030100@redhat.com> <570FB451.60409@redhat.com> <571A2947.4040604@redhat.com> Message-ID: <571F53E9.3030907@redhat.com> On 22.04.2016 15:38, Stanislav Laznicka wrote: > Seems to work as expected. > > Nitpick: feel free to fix the typo in the commit message: behavioar. > ACK nonetheless. Standa forgot to sent ACK on list :), please note that ACK is here -----^^^^ Typo fixed Pushed to master: 14ee02dcbd6cbb6c221ac7526e471a9fc58fcc82 Martin^2 > > > On 04/14/2016 05:16 PM, Martin Basti wrote: >> >> >> On 21.03.2016 07:48, Jan Cholasta wrote: >>> On 18.3.2016 13:24, Martin Babinsky wrote: >>>> On 03/15/2016 01:48 PM, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/3376 >>>>> >>>>> Patch attached. >>>>> >>>>> >>>> ACK but fix the 'behavioar' typo in the commit message before pushing. >>> >>> 1) You are breaking the default_attributes contract by declaring >>> ipasshpubkey as default attribute and then removing it from the >>> result. This is a hack, which makes the code less readable ("If >>> ipasshpubkey is in default_attributes, why am I not getting it in >>> the result?") and requires every developer to remember to remove >>> ipasshpubkey themselves if they are using user/host objects in their >>> code and want the same behavior as user/host commands. Please keep >>> the change isolated in the relevant commands. >>> >>> 2) Don't add ipasshpubkey to search_attributes, we don't want >>> user-find and friends to search inside ipasshpubkey. >>> >> Updated patch attached. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Apr 26 11:54:57 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Apr 2016 13:54:57 +0200 Subject: [Freeipa-devel] [DESIGN] Thin client In-Reply-To: <571F506C.7000204@redhat.com> References: <24f7dbe9-8086-39ac-9283-48bd5398c8f3@redhat.com> <571F506C.7000204@redhat.com> Message-ID: On 26.4.2016 13:26, Petr Spacek wrote: > On 26.4.2016 12:28, Jan Cholasta wrote: >> Hi, >> >> see for initial design of the >> Thin client feature. The API compatibility part of the design is work in >> progress (by me), as is the client side caching part (by David). >> >> Big thanks to David for actually writing most of the text in the design page. >> >> Comments and suggestions are welcome. > > In general it is good. > > I have two questions: > 1) Caching >> IPA client can cache downloaded metadata to reduce traffic and reduce start up time. IPA client can send metadata fingerprint with request. When newer metadata are available server must add warning to the response. > > Shouldn't it be an hard error when client sends old metadata? I do not like > the warning because when you receive a warning it is too late to cancel the > command. You are right that a hard error might be better in this case. However, a metadata update should have no effect on the functionality of the command being executed, so it can very well be a warning to save the client a round trip to the server. (Note that the client sends only fingerprint of the metadata.) > > > 2) Client/server side plugins. > I expect that some very special features (like client-side OTP provisioning) > might depend particular version/range of version on the client. > > Will the metadata include version range which can be checked on client side to > make sure that everything is compatible (for given command/plugin)? No. You can't make incompatible changes to existing commands, so everything the client needs to know is whether the server supports the command or not, which is already provided in the metadata. If you *need* to do incompatible changes, you will have to introduce a new version of the command (which is basically a different command with the same name), but the server will still support the old version, so old clients will not break. > > > Other than that it seems reasonable. I'm looking forward to see more details! > -- Jan Cholasta From pvomacka at redhat.com Tue Apr 26 12:02:47 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 26 Apr 2016 14:02:47 +0200 Subject: [Freeipa-devel] [PATCH] 0018-0030 webui: add support for more certificates In-Reply-To: <571F520B.2000501@redhat.com> References: <571F520B.2000501@redhat.com> Message-ID: <571F58E7.1070703@redhat.com> I forgot to mention that my patches requires patches from : https://www.redhat.com/archives/freeipa-devel/2016-April/msg00209.html On 04/26/2016 01:33 PM, Pavel Vomacka wrote: > Hello, > > the attached patches add support for more certificates and ability to > add and remove certificates. Fixes these two tickets: > https://fedorahosted.org/freeipa/ticket/5108 > https://fedorahosted.org/freeipa/ticket/5381 > > These patches add ability to view, get, download, revoke, restore and > delete each certificate directly from user/host/service details page. > There is also button for adding new certificates. > > There is one known issue, that after page save action is performed > some data disappear (includes certificates). This issue has a ticket > already: https://fedorahosted.org/freeipa/ticket/5776 > > -- > Pavel^3 Vomacka > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Apr 26 12:03:38 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 26 Apr 2016 14:03:38 +0200 Subject: [Freeipa-devel] [PATCHES 0464-0468] always set hostname during installation In-Reply-To: <571F0B8E.20901@redhat.com> References: <5717A507.8050707@redhat.com> <571A017D.709@redhat.com> <571F0B8E.20901@redhat.com> Message-ID: <571F591A.4060200@redhat.com> On 26.04.2016 08:32, David Kupka wrote: > On 22/04/16 12:48, Martin Basti wrote: >> >> >> On 20.04.2016 17:49, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5794 >>> >>> It requires my patch 441.2 >>> Patches attached. >>> >>> >> >> Rebased patches attached, 441 has been pushed >> >> Martin^2 >> >> >> > Thanks for patch set. Works for me, ACK. > master: * c5686295f14c955d34d9598ddb80b30cb9df663c Always set hostname * 30f3d198d0dcac32deb1c129a1bf406e70b57774 Remove deprecated hostname restoration from Fedora18 * d3ac5125ce2b22cf87dbcd98a6eaf71e0f288440 Remove unused hostname variables * 5e10b2eed29f845e079288c4aa9c8f59967d6dcc Log errors from backup_and_replace hostname to logger * 813aab1b8e4026e10056677b2fc98fc4faa56ddb Tasks: raise NotImplementedError for not implemented methods From pspacek at redhat.com Tue Apr 26 12:16:54 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Apr 2016 14:16:54 +0200 Subject: [Freeipa-devel] URI in HBAC In-Reply-To: References: <571E1219.9060100@redhat.com> Message-ID: <571F5C36.7090803@redhat.com> On 26.4.2016 12:57, Jan Cholasta wrote: > Hi, > > On 25.4.2016 14:48, Luk?? Hellebrandt wrote: >> http://www.freeipa.org/page/V4/URI-based_HBAC >> >> I have made some important changes to the design document of this >> proposed feature. The difference is mainly changing regular expression >> interpretation of URI to longest-prefix matching. >> >> This change was done mainly because of upstream's reactions. I value any >> further comments and particularly discussion about the two topics >> mentioned at the end of the design page: >> >> * For backwards compatibility, lack of URI in request means any URI is >> matched (as described in the design document). Is it a good idea? Any >> other solution? > > For other attributes in HBAC rules, the lack of a value means nothing is > matched. To match anything, you have to set "${attribute}category" to "all". I > would prefer if URI matching was consistent with this, if it's possible. My understanding is that requests lacking URI parameter should not match any HBAC rules with non-empty URI. This will be backwards compatible because old clients will simply ignore new rules which cannot be evaluated properly anyway (for lack of information in client's request). >> * How about multiple URI's in one HBAC rule? Is it a good idea? How to >> interpret combinations of host+scheme+port (one field) and URI paths >> (another field) in that case? > > I think it is not only good idea, but actually necessary. I guess you would > have to consider an URI matched if it's host+scheme+port matches any of the > host+scheme+port patterns and at the same time it's path matches any of the > path patterns. > > BTW what is the reason to split URIs into separate fields? If it's just case > sensitivity, I would like to point out that you can switch case sensitivity on > and off in the middle of a Perl regex using "(?i)" and "(?-i)". Personally I would rather see host+scheme+port split into separate attributes. That would allow reporting like 'give me all rules for FTP' etc. without substring magic. And yes, I agree with Honza that multiple values should be evaluated as logical OR. E.g. schemes: {http, https, ftp, ftps} URI: /home/pspacek host: any allow: pspacek should grant user pspacek access to directory /home/pspacek on any host as long as the scheme is http/https/ftp/ftps. -- Petr^2 Spacek From mbasti at redhat.com Tue Apr 26 12:21:30 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 26 Apr 2016 14:21:30 +0200 Subject: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command In-Reply-To: <571A0920.5020406@redhat.com> References: <571798C4.5040200@redhat.com> <57187E93.1040707@redhat.com> <5719E7AC.5020908@redhat.com> <571A0920.5020406@redhat.com> Message-ID: <571F5D4A.7060003@redhat.com> On 22.04.2016 13:21, David Kupka wrote: > On 22/04/16 10:58, Martin Basti wrote: >> >> >> On 21.04.2016 09:17, Martin Basti wrote: >>> >>> >>> On 20.04.2016 16:57, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5281 >>>> >>>> Patch attached. >>>> >>>> >>> selfNACK >>> >>> >> Updated patch attached. >> >> >> > Works for me, ACK. > pushed to master: * fe2ce02a6f7664e377c367e16e9c2e1ad960c9d7 Performace: don't download password attributes in host/user-find From sbose at redhat.com Tue Apr 26 13:03:53 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 26 Apr 2016 15:03:53 +0200 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> Message-ID: <20160426130353.GX11731@p.redhat.com> On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > ----- Original Message ----- > > From: "Nathaniel McCallum" > > To: "Matt Rogers" , freeipa-devel at redhat.com > > Sent: Thursday, April 14, 2016 10:32:15 AM > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > Hi, > > > > > > The attached patch is a part of the authentication indicator > > > enhancements, > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > Can you add some whitespace in next_attr()? The density of the code > > there hurts readability. > > > Sure, I've attached the revised patch. Hi Matt, thank you for the patch. Currently I have the following question. You call krb5_dbe_set_string to remove the 'require_auth' data before calling ipadb_get_ldap_mod_extra_data() > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > + if (kerr) { > + goto done; > + } > + > kerr = ipadb_get_ldap_mod_extra_data(imods, > entry->tl_data, > mod_op); > Why it is needed to filter this data again in ipadb_get_ldap_mod_extra_data()? > + > static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, > krb5_tl_data *tl_data, > int mod_op) > { > krb5_error_code kerr; > krb5_tl_data *data; > + krb5_tl_data *data_tmp = NULL; > struct berval **bvs = NULL; > krb5_int16 be_type; > int n, i; > @@ -1463,6 +1663,20 @@ static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, > continue; > } > > + /* Exclude any auth indicators from krbExtraData */ > + kerr = filter_authind_str_attrs(data, &data_tmp); > + if (kerr) { > + goto done; > + } > + if (data_tmp != NULL) { > + if (data_tmp->tl_data_contents == NULL) { > + free(data_tmp); > + data_tmp = NULL; > + continue; > + } > + data = data_tmp; > + } > + > be_type = htons(data->tl_data_type); > > bvs[i] = calloc(1, sizeof(struct berval)); bye, Sumit From jpazdziora at redhat.com Tue Apr 26 13:16:37 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 26 Apr 2016 15:16:37 +0200 Subject: [Freeipa-devel] URI in HBAC In-Reply-To: <571F5C36.7090803@redhat.com> References: <571E1219.9060100@redhat.com> <571F5C36.7090803@redhat.com> Message-ID: <20160426131637.GA7871@redhat.com> On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote: > >> > >> * For backwards compatibility, lack of URI in request means any URI is > >> matched (as described in the design document). Is it a good idea? Any > >> other solution? > > > > For other attributes in HBAC rules, the lack of a value means nothing is > > matched. To match anything, you have to set "${attribute}category" to "all". I > > would prefer if URI matching was consistent with this, if it's possible. > > My understanding is that requests lacking URI parameter should not match any > HBAC rules with non-empty URI. This will be backwards compatible because old > clients will simply ignore new rules which cannot be evaluated properly anyway > (for lack of information in client's request). The problem is that old clients will not ack for the new attributes (they have no idea they should ask for them), so they will only see parts of the HBAC rules. So the question is -- what is the correct way to make sure that old clients (that would not ask for the new attributes) are not served any rules that have those new attributes set? > > BTW what is the reason to split URIs into separate fields? If it's just case > > sensitivity, I would like to point out that you can switch case sensitivity on > > and off in the middle of a Perl regex using "(?i)" and "(?-i)". > > Personally I would rather see host+scheme+port split into separate attributes. > That would allow reporting like 'give me all rules for FTP' etc. without > substring magic. > > And yes, I agree with Honza that multiple values should be evaluated as > logical OR. > > E.g. > > schemes: {http, https, ftp, ftps} > URI: /home/pspacek > host: any > allow: pspacek > should grant user pspacek access to directory /home/pspacek on any host as > long as the scheme is http/https/ftp/ftps. So you propose cartesian product of the schemes and URI attributes to be used? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From pviktori at redhat.com Tue Apr 26 13:31:25 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 26 Apr 2016 15:31:25 +0200 Subject: [Freeipa-devel] More Python 3 fixes Message-ID: <571F6DAD.2090107@redhat.com> Hello, Here are two patches for problems with using IPA with Python 3. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0775-dns-plugin-Fix-zone-normalization-under-Python-3.patch Type: text/x-patch Size: 1219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0776-sysrestore-Iterate-over-a-list-of-dict-keys.patch Type: text/x-patch Size: 1044 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 26 13:56:44 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Apr 2016 15:56:44 +0200 Subject: [Freeipa-devel] URI in HBAC In-Reply-To: <20160426131637.GA7871@redhat.com> References: <571E1219.9060100@redhat.com> <571F5C36.7090803@redhat.com> <20160426131637.GA7871@redhat.com> Message-ID: <571F739C.1080706@redhat.com> On 26.4.2016 15:16, Jan Pazdziora wrote: > On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote: >>>> >>>> * For backwards compatibility, lack of URI in request means any URI is >>>> matched (as described in the design document). Is it a good idea? Any >>>> other solution? >>> >>> For other attributes in HBAC rules, the lack of a value means nothing is >>> matched. To match anything, you have to set "${attribute}category" to "all". I >>> would prefer if URI matching was consistent with this, if it's possible. >> >> My understanding is that requests lacking URI parameter should not match any >> HBAC rules with non-empty URI. This will be backwards compatible because old >> clients will simply ignore new rules which cannot be evaluated properly anyway >> (for lack of information in client's request). > > The problem is that old clients will not ack for the new attributes > (they have no idea they should ask for them), so they will only see > parts of the HBAC rules. > > So the question is -- what is the correct way to make sure that old > clients (that would not ask for the new attributes) are not served > any rules that have those new attributes set? > >>> BTW what is the reason to split URIs into separate fields? If it's just case >>> sensitivity, I would like to point out that you can switch case sensitivity on >>> and off in the middle of a Perl regex using "(?i)" and "(?-i)". >> >> Personally I would rather see host+scheme+port split into separate attributes. >> That would allow reporting like 'give me all rules for FTP' etc. without >> substring magic. >> >> And yes, I agree with Honza that multiple values should be evaluated as >> logical OR. >> >> E.g. >> >> schemes: {http, https, ftp, ftps} >> URI: /home/pspacek >> host: any >> allow: pspacek >> should grant user pspacek access to directory /home/pspacek on any host as >> long as the scheme is http/https/ftp/ftps. > > So you propose cartesian product of the schemes and URI attributes > to be used? Yes. Before we can discuss this further we need to see current LDAP schema and code. Lukas, please share the code with us. -- Petr^2 Spacek From pvomacka at redhat.com Tue Apr 26 14:23:30 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 26 Apr 2016 16:23:30 +0200 Subject: [Freeipa-devel] [PATCH] 0018-0030 webui: add support for more certificates In-Reply-To: <571F58E7.1070703@redhat.com> References: <571F520B.2000501@redhat.com> <571F58E7.1070703@redhat.com> Message-ID: <571F79E2.2000106@redhat.com> Self-NACK for patches 0027, 28, 29, 30 - used incorrect policy. I also attach all patches which were not changed - it is easier to get the whole patchset. On 04/26/2016 02:02 PM, Pavel Vomacka wrote: > I forgot to mention that my patches requires patches from : > https://www.redhat.com/archives/freeipa-devel/2016-April/msg00209.html > > > On 04/26/2016 01:33 PM, Pavel Vomacka wrote: >> Hello, >> >> the attached patches add support for more certificates and ability to >> add and remove certificates. Fixes these two tickets: >> https://fedorahosted.org/freeipa/ticket/5108 >> https://fedorahosted.org/freeipa/ticket/5381 >> >> These patches add ability to view, get, download, revoke, restore and >> delete each certificate directly from user/host/service details page. >> There is also button for adding new certificates. >> >> There is one known issue, that after page save action is performed >> some data disappear (includes certificates). This issue has a ticket >> already: https://fedorahosted.org/freeipa/ticket/5776 >> >> -- >> Pavel^3 Vomacka >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0018-Add-support-for-dropdown-menu-in-multivalued-widget.patch Type: text/x-patch Size: 3900 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0019-Extends-functionality-of-DropdownWidget.patch Type: text/x-patch Size: 1606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0020-Add-working-widget.patch Type: text/x-patch Size: 4537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0021-Add-ability-to-turn-off-activity-icon.patch Type: text/x-patch Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0022-Add-Object-adapter.patch Type: text/x-patch Size: 2322 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0023-Refactored-certificate-view-and-restore-dialog.patch Type: text/x-patch Size: 12559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0024-Changed-the-way-how-to-handle-restore-and-revoke-act.patch Type: text/x-patch Size: 3651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0025-Remove-old-useless-actions-get-and-view.patch Type: text/x-patch Size: 3360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0026-Add-widget-for-showing-multiple-certificates.patch Type: text/x-patch Size: 9988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0027-2-Add-certificate-widget.patch Type: text/x-patch Size: 19238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0028-2-Add-new-certificates-widget-to-the-user-details-page.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0029-2-Add-new-certificates-widget-to-the-host-details-page.patch Type: text/x-patch Size: 5134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0030-2-Add-new-certificates-widget-to-the-service-details-p.patch Type: text/x-patch Size: 3934 bytes Desc: not available URL: From pvomacka at redhat.com Tue Apr 26 15:23:43 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 26 Apr 2016 17:23:43 +0200 Subject: [Freeipa-devel] [PATCH] Added warning to user for Internet Explorer In-Reply-To: <571DF8CC.8070305@redhat.com> References: <571DF8CC.8070305@redhat.com> Message-ID: <571F87FF.5010706@redhat.com> On 04/25/2016 01:00 PM, Abhijeet Kasurde wrote: > Hi All, > > Please review the attached patch. > > Thanks, > Abhijeet Kasurde > > Hi, thank you for the patch, ACK. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 26 15:37:28 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Apr 2016 10:37:28 -0500 Subject: [Freeipa-devel] [PATCH] Added warning to user for Internet Explorer In-Reply-To: <571F87FF.5010706@redhat.com> References: <571DF8CC.8070305@redhat.com> <571F87FF.5010706@redhat.com> Message-ID: <571F8B38.3040207@redhat.com> Pavel Vomacka wrote: > > > On 04/25/2016 01:00 PM, Abhijeet Kasurde wrote: >> Hi All, >> >> Please review the attached patch. >> >> Thanks, >> Abhijeet Kasurde >> >> > Hi, > > thank you for the patch, ACK. I would add an "a" and change it to "Internet Explorer is no longer a supported browser." rob From pvoborni at redhat.com Tue Apr 26 16:12:17 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 26 Apr 2016 18:12:17 +0200 Subject: [Freeipa-devel] [DESIGN] Thin client In-Reply-To: <24f7dbe9-8086-39ac-9283-48bd5398c8f3@redhat.com> References: <24f7dbe9-8086-39ac-9283-48bd5398c8f3@redhat.com> Message-ID: <8a333217-eae4-5b67-125e-6ef457f9be05@redhat.com> On 04/26/2016 12:28 PM, Jan Cholasta wrote: > Hi, > > see for initial design of > the Thin client feature. The API compatibility part of the design is > work in progress (by me), as is the client side caching part (by David). > > Big thanks to David for actually writing most of the text in the design > page. > > Comments and suggestions are welcome. > > Honza > 1. "IPA client can send metadata fingerprint with request." When the client will send the metadata and when it won't? It will for all 4.4+ servers? And won't for the legacy ones? 2. How the client will determine #1? Will it use ipa ping in the very first request and then use this version of metadata until version(legacy server) or metadata fingerprint changes? Which will trigger download of metadata in next request? 3. I don't much understand: """ To avoid breaking users' scripts the client MUST use the oldest version of command available by default. User CAN change the default behavior to use the latest available version instead of the oldest and CAN specify per command override. """ What is the oldest command available? E.g. I have a 4.4 server and 4.5 client. Is it 4.4 or some older, legacy one? If I have 4.5 server and 4.4 client is it 4.4 with available override to use 4.5 given that the client knows new version of command from metadata? -- Petr Vobornik From mrogers at redhat.com Tue Apr 26 18:02:04 2016 From: mrogers at redhat.com (Matt Rogers) Date: Tue, 26 Apr 2016 14:02:04 -0400 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160426130353.GX11731@p.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> Message-ID: <20160426180203.GC4455@mail.redhat.com> On 04/26, Sumit Bose wrote: > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > > > > ----- Original Message ----- > > > From: "Nathaniel McCallum" > > > To: "Matt Rogers" , freeipa-devel at redhat.com > > > Sent: Thursday, April 14, 2016 10:32:15 AM > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > > Hi, > > > > > > > > The attached patch is a part of the authentication indicator > > > > enhancements, > > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > > > Can you add some whitespace in next_attr()? The density of the code > > > there hurts readability. > > > > > Sure, I've attached the revised patch. > > Hi Matt, > > thank you for the patch. Currently I have the following question. > > You call krb5_dbe_set_string to remove the 'require_auth' data before > calling ipadb_get_ldap_mod_extra_data() > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > + if (kerr) { > > + goto done; > > + } > > + > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > entry->tl_data, > > mod_op); > > > > Why it is needed to filter this data again in > ipadb_get_ldap_mod_extra_data()? > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I believe I left there in error - We decided to operate on a filtered copy of the tl_data (which filter_authind_str_attrs() handles) rather than removing it completely with krb5_dbe_set_string(). I had tested with the above code commented out but forgot to remove it with the submitted patch. I've attached the updated patch. Thanks for spotting that. -- Matt Rogers Red Hat, Inc -------------- next part -------------- >From a75ca3d391554c0254c1b2d206f96edc29f11149 Mon Sep 17 00:00:00 2001 From: Matt Rogers Date: Fri, 25 Mar 2016 17:01:40 -0400 Subject: [PATCH] ipa_kdb: add krbPrincipalAuthInd handling Store and retrieve the authentication indicator "require_auth" string in the krbPrincipalAuthInd attribute. Skip storing auth indicators to krbExtraData. --- daemons/ipa-kdb/ipa_kdb_principals.c | 278 +++++++++++++++++++++++++++++++++++ install/share/60kerberos.ldif | 6 +- 2 files changed, 282 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 629f8193223c924267f6d5f39d258cfbc51c7f63..fbfb15d179790e30ea69e43f693bd90fdd0ff2ec 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -54,6 +54,7 @@ static char *std_principal_attrs[] = { "krbLastSuccessfulAuth", "krbLastFailedAuth", "krbLoginFailedCount", + "krbPrincipalAuthInd", "krbExtraData", "krbLastAdminUnlock", "krbObjectReferences", @@ -428,6 +429,85 @@ done: return kerr; } +static void strv_free(char **strv) +{ + int i; + + if (strv == NULL) { + return; + } + + for (i = 0; strv[i] != NULL; i++) { + free(strv[i]); + } + + free(strv); +} + +static krb5_error_code ipadb_get_ldap_auth_ind(krb5_context kcontext, + LDAP *lcontext, + LDAPMessage *lentry, + krb5_db_entry *entry) +{ + krb5_error_code ret = 0; + char **authinds = NULL; + char *aistr = NULL; + char *ap = NULL; + size_t len = 0; + size_t l = 0; + int count = 0; + int i = 0; + + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "krbPrincipalAuthInd", + &authinds); + switch (ret) { + case 0: + break; + case ENOENT: + return 0; + default: + return ret; + } + + for (count = 0; authinds != NULL && authinds[count] != NULL; count++) { + len += strlen(authinds[count]) + 1; + } + + if (len == 0) { + strv_free(authinds); + return 0; + } + + aistr = malloc(len); + if (aistr == NULL) { + ret = errno; + goto cleanup; + } + + /* Create a space-separated string of authinds. */ + ap = aistr; + l = len; + for (i = 0; i < count; i++) { + ret = snprintf(ap, l, "%s ", authinds[i]); + if (ret <= 0 || ret > l) { + ret = ENOMEM; + goto cleanup; + } + ap += ret; + l -= ret; + } + aistr[len - 1] = '\0'; + + ret = krb5_dbe_set_string(kcontext, entry, "require_auth", + aistr); + +cleanup: + strv_free(authinds); + free(aistr); + + return ret; +} + static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, char *principal, LDAPMessage *lentry, @@ -611,6 +691,10 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, goto done; } + ret = ipadb_get_ldap_auth_ind(kcontext, lcontext, lentry, entry); + if (ret) + goto done; + ret = ipadb_ldap_attr_to_key_data(lcontext, lentry, "krbPrincipalKey", &res_key_data, &result, &mkvno); @@ -1422,12 +1506,128 @@ done: return kerr; } +/* Find the next key and value pair in *pos and update *pos. */ +static bool next_attr(const char **pos, const char *end, + const char **key_out, const char **val_out) +{ + const char *key, *key_end, *val, *val_end; + + *key_out = *val_out = NULL; + + if (*pos == end) { + return false; + } + + key = *pos; + key_end = memchr(key, '\0', end - key); + if (key_end == NULL) { /* Malformed representation; give up. */ + return false; + } + + val = key_end + 1; + val_end = memchr(val, '\0', end - val); + if (val_end == NULL) { /* Malformed representation; give up. */ + return false; + } + + *key_out = key; + *val_out = val; + *pos = val_end + 1; + + return true; +} + +static krb5_error_code filter_authind_str_attrs(krb5_tl_data *data, + krb5_tl_data **data_out) +{ + krb5_error_code ret = 0; + krb5_tl_data *new_data = NULL; + char *new_content = NULL; + char *new_cp = NULL; + const char *pos = NULL; + const char *end = NULL; + const char *key = NULL; + const char *val = NULL; + size_t data_len = 0; + size_t new_len = 0; + + *data_out = NULL; + + if (data->tl_data_type != KRB5_TL_STRING_ATTRS) { + return 0; + } + + pos = (const char *)data->tl_data_contents; + data_len = data->tl_data_length; + end = pos + data_len; + + new_data = malloc(sizeof(*new_data)); + if (new_data == NULL) { + return errno; + } + new_content = malloc(data_len); + if (new_content == NULL) { + ret = errno; + goto done; + } + + new_cp = new_content; + while (next_attr(&pos, end, &key, &val)) { + if (strcmp(key, "require_auth") == 0) { + continue; + } + + ret = snprintf(new_cp, data_len, "%s", key); + if (ret <= 0 || ret > data_len) { + ret = ENOMEM; + goto done; + } + new_cp += (ret + 1); + data_len -= (ret + 1); + + ret = snprintf(new_cp, data_len, "%s", val); + if (ret <= 0 || ret > data_len) { + ret = ENOMEM; + goto done; + } + new_cp += (ret + 1); + data_len -= (ret + 1); + } + + if (data_len > 0) { + new_len = data->tl_data_length - data_len; + } else { + new_len = data->tl_data_length; + } + + /* "require_auth" was the only entry, return empty contents */ + if (new_len == 0) { + free(new_content); + new_content = NULL; + } + + new_data->tl_data_type = data->tl_data_type; + new_data->tl_data_next = data->tl_data_next; + new_data->tl_data_contents = new_content; + new_data->tl_data_length = new_len; + *data_out = new_data; + ret = 0; + +done: + if (ret) { + free(new_content); + free(new_data); + } + return ret; +} + static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, krb5_tl_data *tl_data, int mod_op) { krb5_error_code kerr; krb5_tl_data *data; + krb5_tl_data *data_tmp = NULL; struct berval **bvs = NULL; krb5_int16 be_type; int n, i; @@ -1463,6 +1663,20 @@ static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, continue; } + /* Exclude any auth indicators from krbExtraData */ + kerr = filter_authind_str_attrs(data, &data_tmp); + if (kerr) { + goto done; + } + if (data_tmp != NULL) { + if (data_tmp->tl_data_contents == NULL) { + free(data_tmp); + data_tmp = NULL; + continue; + } + data = data_tmp; + } + be_type = htons(data->tl_data_type); bvs[i] = calloc(1, sizeof(struct berval)); @@ -1497,6 +1711,10 @@ done: free(bvs[i]); } } + if (data_tmp != NULL) { + free(data_tmp->tl_data_contents); + free(data_tmp); + } free(bvs); return kerr; } @@ -1649,6 +1867,62 @@ done: return kerr; } +static krb5_error_code ipadb_get_ldap_mod_auth_ind(krb5_context kcontext, + struct ipadb_mods *imods, + krb5_db_entry *entry, + int mod_op) +{ + krb5_error_code ret = 0; + char **strlist = NULL; + char *ais = NULL; + char *ai = NULL; + char *s = NULL; + size_t ai_size = 0; + int cnt = 0; + int i = 0; + + ret = krb5_dbe_get_string(kcontext, entry, "require_auth", &ais); + if (ret) { + return ret; + } + if (ais == NULL) { + return 0; + } + + ai_size = strlen(ais) + 1; + + for (i = 0; i < ai_size; i++) { + if (ais[i] != ' ') { + continue; + } + if (i > 0 && ais[i - 1] != ' ') { + cnt++; + } + } + + strlist = calloc(cnt + 2, sizeof(*strlist)); + if (strlist == NULL) { + free(ais); + return errno; + } + + cnt = 0; + ai = strtok_r(ais, " ", &s); + while (ai != NULL) { + if (ai[0] != '\0') { + strlist[cnt++] = ai; + } + ai = strtok_r(NULL, " ", &s); + } + + ret = ipadb_get_ldap_mod_str_list(imods, "krbPrincipalAuthInd", + strlist, cnt, mod_op); + + free(ais); + free(strlist); + return ret; +} + static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, struct ipadb_mods *imods, krb5_db_entry *entry, @@ -1835,6 +2109,10 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, } } + kerr = ipadb_get_ldap_mod_auth_ind(kcontext, imods, entry, mod_op); + if (kerr) + goto done; + /* KADM5_TL_DATA */ if (entry->mask & KMASK_TL_DATA) { kerr = ipadb_get_tl_data(entry, diff --git a/install/share/60kerberos.ldif b/install/share/60kerberos.ldif index 8698e3a0538fd42443f4a3221fccfb739d4c104d..45bea2aefd3993a521e8ea732f902279622f8cb8 100644 --- a/install/share/60kerberos.ldif +++ b/install/share/60kerberos.ldif @@ -266,7 +266,9 @@ attributetypes: ( 2.16.840.1.113719.1.301.4.53.1 NAME 'krbPrincContainerRef' EQU attributetypes: ( 1.3.6.1.4.1.5322.21.2.5 NAME 'krbLastAdminUnlock' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) ##### A list of services to which a service principal can delegate. attributetypes: ( 1.3.6.1.4.1.5322.21.2.4 NAME 'krbAllowedToDelegateTo' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) -######################################################################## +##### A list of authentication indicator strings, one of which must be satisfied +##### to authenticate to the principal as a service. +attributetypes: ( 2.16.840.1.113730.3.8.15.2.1 NAME 'krbPrincipalAuthInd' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15) ######################################################################## # Object Class Definitions # ######################################################################## @@ -294,7 +296,7 @@ objectClasses: ( 2.16.840.1.113719.1.301.6.4.1 NAME 'krbKdcService' SUP ( krbSer objectClasses: ( 2.16.840.1.113719.1.301.6.5.1 NAME 'krbPwdService' SUP ( krbService ) ) ###### The principal data auxiliary class. Holds principal information ###### and is used to store principal information for Person, Service objects. -objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbLastAdminUnlock $ krbAllowedToDelegateTo ) ) +objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbLastAdminUnlock $ krbAllowedToDelegateTo $ krbPrincipalAuthInd ) ) ###### This class is used to create additional principals and stand alone principals. objectClasses: ( 2.16.840.1.113719.1.301.6.9.1 NAME 'krbPrincipal' SUP ( top ) MUST ( krbPrincipalName ) MAY ( krbObjectReferences ) ) ###### The principal references auxiliary class. Holds all principals referred -- 2.4.3 From pspacek at redhat.com Tue Apr 26 18:11:54 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Apr 2016 20:11:54 +0200 Subject: [Freeipa-devel] [PATCH 0102] DNS: Fix upgrade - master to forward zone transformatio Message-ID: <571FAF6A.6080002@redhat.com> Hello, DNS: Fix upgrade - master to forward zone transformation This happens when upgrading from IPA <= 4.0 to versions 4.3+. DNS caching might cause false positive in code which replaces master zone with forward zone. This will effectivelly delete the master zone without adding a replacement forward zone. Solution is to use skip_overlap_check option for dnsforwardzone_add command so zone existence check is skipped and the upgrade can proceed. https://fedorahosted.org/freeipa/ticket/5851 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0102-DNS-Fix-upgrade-master-to-forward-zone-transformatio.patch Type: text/x-patch Size: 1655 bytes Desc: not available URL: From jcholast at redhat.com Wed Apr 27 05:48:10 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 Apr 2016 07:48:10 +0200 Subject: [Freeipa-devel] [DESIGN] Thin client In-Reply-To: <8a333217-eae4-5b67-125e-6ef457f9be05@redhat.com> References: <24f7dbe9-8086-39ac-9283-48bd5398c8f3@redhat.com> <8a333217-eae4-5b67-125e-6ef457f9be05@redhat.com> Message-ID: <6032315a-0b42-bcc9-44f2-dfc4df77826c@redhat.com> On 26.4.2016 18:12, Petr Vobornik wrote: > On 04/26/2016 12:28 PM, Jan Cholasta wrote: >> Hi, >> >> see for initial design of >> the Thin client feature. The API compatibility part of the design is >> work in progress (by me), as is the client side caching part (by David). >> >> Big thanks to David for actually writing most of the text in the design >> page. >> >> Comments and suggestions are welcome. >> >> Honza >> > > 1. "IPA client can send metadata fingerprint with request." > When the client will send the metadata and when it won't? It will for > all 4.4+ servers? And won't for the legacy ones? Correct. > > 2. How the client will determine #1? Will it use ipa ping in the very > first request and then use this version of metadata until version(legacy > server) or metadata fingerprint changes? Which will trigger download of > metadata in next request? The first thing the client has to do is to download the metadata. If it's an old server, this will fail. At this point the client knows it can't send the fingerprint to the server. > > 3. I don't much understand: > """ > To avoid breaking users' scripts the client MUST use the oldest version > of command available by default. User CAN change the default behavior to > use the latest available version instead of the oldest and CAN specify > per command override. > """ This paragraph is no longer up to date, as of 15 minutes ago :-) > What is the oldest command available? E.g. I have a 4.4 server and 4.5 > client. Is it 4.4 or some older, legacy one? If I have 4.5 server and > 4.4 client is it 4.4 with available override to use 4.5 given that the > client knows new version of command from metadata? The current idea is that the client will use the newest command version available at build time by default. This way nothing depending on a particular client behavior will break as long as the client is not upgraded. Users will be able to explicitly specify which command version to use. When talking to an older server which does not have the requested command version, the request will fail with an error informing the user about the highest command version available. -- Jan Cholasta From akasurde at redhat.com Wed Apr 27 06:47:02 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 27 Apr 2016 12:17:02 +0530 Subject: [Freeipa-devel] [PATCH] Added warning to user for Internet Explorer In-Reply-To: <571F8B38.3040207@redhat.com> References: <571DF8CC.8070305@redhat.com> <571F87FF.5010706@redhat.com> <571F8B38.3040207@redhat.com> Message-ID: <57206066.8020801@redhat.com> Updated patch attached. On 04/26/2016 09:07 PM, Rob Crittenden wrote: > Internet Explorer is no longer a supported browser. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0009-2-Added-warning-to-user-for-Internet-Explorer.patch Type: text/x-patch Size: 1109 bytes Desc: not available URL: From pvomacka at redhat.com Wed Apr 27 07:25:26 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 27 Apr 2016 09:25:26 +0200 Subject: [Freeipa-devel] [PATCH] 0031 webui: add ability to review certificate request dialog Message-ID: <57206966.8030302@redhat.com> Hi please review the attached patch. Fixes this ticket: https://fedorahosted.org/freeipa/ticket/5652 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0031-Add-ability-to-review-cert-request-dialog.patch Type: text/x-patch Size: 1714 bytes Desc: not available URL: From sbose at redhat.com Wed Apr 27 12:23:37 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 27 Apr 2016 14:23:37 +0200 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160426180203.GC4455@mail.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> Message-ID: <20160427122337.GB11731@p.redhat.com> On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: > On 04/26, Sumit Bose wrote: > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > > > > > > > ----- Original Message ----- > > > > From: "Nathaniel McCallum" > > > > To: "Matt Rogers" , freeipa-devel at redhat.com > > > > Sent: Thursday, April 14, 2016 10:32:15 AM > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > > > Hi, > > > > > > > > > > The attached patch is a part of the authentication indicator > > > > > enhancements, > > > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > > > > > Can you add some whitespace in next_attr()? The density of the code > > > > there hurts readability. > > > > > > > Sure, I've attached the revised patch. > > > > Hi Matt, > > > > thank you for the patch. Currently I have the following question. > > > > You call krb5_dbe_set_string to remove the 'require_auth' data before > > calling ipadb_get_ldap_mod_extra_data() > > > > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > + if (kerr) { > > > + goto done; > > > + } > > > + > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > entry->tl_data, > > > mod_op); > > > > > > > Why it is needed to filter this data again in > > ipadb_get_ldap_mod_extra_data()? > > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I > believe I left there in error - We decided to operate on a filtered copy > of the tl_data (which filter_authind_str_attrs() handles) rather than > removing it completely with krb5_dbe_set_string(). I had tested with the > above code commented out but forgot to remove it with the submitted patch. ok, makes sense. Nevertheless, comments in kdb.h like: /* String attributes (currently stored inside tl-data) map C string keys to * values. They can be set via kadmin and consumed by KDC plugins. */ and /* String attributes may not always be represented in tl-data. kadmin clients * must use the get_strings and set_string RPCs. */ make me wonder if it is a good idea to operate on the tl-data of type KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well so I'm not insisting to change it, I'm just wondering about the reasons. Would something like (error checks are missing) kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", &require_auth_str); if (require_auth_str != NULL) { kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); } kerr = ipadb_get_ldap_mod_extra_data(imods, entry->tl_data, mod_op); if (require_auth_str != NULL) { kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", require_auth_str); } have the same effect with only using the recommended API (and making the patch smaller)? bye, Sumit From lhellebr at redhat.com Wed Apr 27 13:34:21 2016 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Wed, 27 Apr 2016 15:34:21 +0200 Subject: [Freeipa-devel] URI in HBAC - code In-Reply-To: <571F739C.1080706@redhat.com> References: <571E1219.9060100@redhat.com> <571F5C36.7090803@redhat.com> <20160426131637.GA7871@redhat.com> <571F739C.1080706@redhat.com> Message-ID: <5720BFDD.7010403@redhat.com> SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac Apache module: https://github.com/lhellebr/mod_hbacauthz_pam FreeIPA: http://pastebin.com/X6H9BTwk On 04/26/2016 03:56 PM, Petr Spacek wrote: > On 26.4.2016 15:16, Jan Pazdziora wrote: >> On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote: >>>>> >>>>> * For backwards compatibility, lack of URI in request means any URI is >>>>> matched (as described in the design document). Is it a good idea? Any >>>>> other solution? >>>> >>>> For other attributes in HBAC rules, the lack of a value means nothing is >>>> matched. To match anything, you have to set "${attribute}category" to "all". I >>>> would prefer if URI matching was consistent with this, if it's possible. >>> >>> My understanding is that requests lacking URI parameter should not match any >>> HBAC rules with non-empty URI. This will be backwards compatible because old >>> clients will simply ignore new rules which cannot be evaluated properly anyway >>> (for lack of information in client's request). >> >> The problem is that old clients will not ack for the new attributes >> (they have no idea they should ask for them), so they will only see >> parts of the HBAC rules. >> >> So the question is -- what is the correct way to make sure that old >> clients (that would not ask for the new attributes) are not served >> any rules that have those new attributes set? >> >>>> BTW what is the reason to split URIs into separate fields? If it's just case >>>> sensitivity, I would like to point out that you can switch case sensitivity on >>>> and off in the middle of a Perl regex using "(?i)" and "(?-i)". >>> >>> Personally I would rather see host+scheme+port split into separate attributes. >>> That would allow reporting like 'give me all rules for FTP' etc. without >>> substring magic. >>> >>> And yes, I agree with Honza that multiple values should be evaluated as >>> logical OR. >>> >>> E.g. >>> >>> schemes: {http, https, ftp, ftps} >>> URI: /home/pspacek >>> host: any >>> allow: pspacek >>> should grant user pspacek access to directory /home/pspacek on any host as >>> long as the scheme is http/https/ftp/ftps. >> >> So you propose cartesian product of the schemes and URI attributes >> to be used? > > Yes. > > > Before we can discuss this further we need to see current LDAP schema and > code. Lukas, please share the code with us. > -- Lukas Hellebrandt Associate Quality Engineer lhellebr at redhat.com From mrogers at redhat.com Wed Apr 27 14:41:31 2016 From: mrogers at redhat.com (Matt Rogers) Date: Wed, 27 Apr 2016 10:41:31 -0400 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160427122337.GB11731@p.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> <20160427122337.GB11731@p.redhat.com> Message-ID: <20160427144131.GA17544@mail.redhat.com> On 04/27, Sumit Bose wrote: > On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: > > On 04/26, Sumit Bose wrote: > > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Nathaniel McCallum" > > > > > To: "Matt Rogers" , freeipa-devel at redhat.com > > > > > Sent: Thursday, April 14, 2016 10:32:15 AM > > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > > > > Hi, > > > > > > > > > > > > The attached patch is a part of the authentication indicator > > > > > > enhancements, > > > > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > > > > > > > Can you add some whitespace in next_attr()? The density of the code > > > > > there hurts readability. > > > > > > > > > Sure, I've attached the revised patch. > > > > > > Hi Matt, > > > > > > thank you for the patch. Currently I have the following question. > > > > > > You call krb5_dbe_set_string to remove the 'require_auth' data before > > > calling ipadb_get_ldap_mod_extra_data() > > > > > > > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > > > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > > + if (kerr) { > > > > + goto done; > > > > + } > > > > + > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > > entry->tl_data, > > > > mod_op); > > > > > > > > > > Why it is needed to filter this data again in > > > ipadb_get_ldap_mod_extra_data()? > > > > > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I > > believe I left there in error - We decided to operate on a filtered copy > > of the tl_data (which filter_authind_str_attrs() handles) rather than > > removing it completely with krb5_dbe_set_string(). I had tested with the > > above code commented out but forgot to remove it with the submitted patch. > > ok, makes sense. > > Nevertheless, comments in kdb.h like: > > /* String attributes (currently stored inside tl-data) map C string keys to > * values. They can be set via kadmin and consumed by KDC plugins. */ > > and > > /* String attributes may not always be represented in tl-data. kadmin clients > * must use the get_strings and set_string RPCs. */ > > make me wonder if it is a good idea to operate on the tl-data of type > KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well > so I'm not insisting to change it, I'm just wondering about the reasons. > > Would something like (error checks are missing) > > kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", > &require_auth_str); > > if (require_auth_str != NULL) { > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > } > > kerr = ipadb_get_ldap_mod_extra_data(imods, > entry->tl_data, > mod_op); > > if (require_auth_str != NULL) { > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", > require_auth_str); > } > > have the same effect with only using the recommended API (and making the > patch smaller)? > I believe that would be the same effect, just less efficient. But sticking to the API is probably safer in the long run. I am okay with changing it if you would prefer. -- Matt Rogers Red Hat, Inc From abokovoy at redhat.com Wed Apr 27 14:53:20 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 27 Apr 2016 17:53:20 +0300 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160427144131.GA17544@mail.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> <20160427122337.GB11731@p.redhat.com> <20160427144131.GA17544@mail.redhat.com> Message-ID: <20160427145320.x6uqcwbwnhbmn2y6@redhat.com> On Wed, 27 Apr 2016, Matt Rogers wrote: >On 04/27, Sumit Bose wrote: >> On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: >> > On 04/26, Sumit Bose wrote: >> > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: >> > > > >> > > > >> > > > ----- Original Message ----- >> > > > > From: "Nathaniel McCallum" >> > > > > To: "Matt Rogers" , freeipa-devel at redhat.com >> > > > > Sent: Thursday, April 14, 2016 10:32:15 AM >> > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling >> > > > > >> > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: >> > > > > > Hi, >> > > > > > >> > > > > > The attached patch is a part of the authentication indicator >> > > > > > enhancements, >> > > > > > adding indicator value storage and retrieval for the KDB driver. >> > > > > > >> > > > > > https://fedorahosted.org/freeipa/ticket/5782 >> > > > > >> > > > > Can you add some whitespace in next_attr()? The density of the code >> > > > > there hurts readability. >> > > > > >> > > > Sure, I've attached the revised patch. >> > > >> > > Hi Matt, >> > > >> > > thank you for the patch. Currently I have the following question. >> > > >> > > You call krb5_dbe_set_string to remove the 'require_auth' data before >> > > calling ipadb_get_ldap_mod_extra_data() >> > > >> > >> > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ >> > > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); >> > > > + if (kerr) { >> > > > + goto done; >> > > > + } >> > > > + >> > > > kerr = ipadb_get_ldap_mod_extra_data(imods, >> > > > entry->tl_data, >> > > > mod_op); >> > > > >> > > >> > > Why it is needed to filter this data again in >> > > ipadb_get_ldap_mod_extra_data()? >> > > >> > >> > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I >> > believe I left there in error - We decided to operate on a filtered copy >> > of the tl_data (which filter_authind_str_attrs() handles) rather than >> > removing it completely with krb5_dbe_set_string(). I had tested with the >> > above code commented out but forgot to remove it with the submitted patch. >> >> ok, makes sense. >> >> Nevertheless, comments in kdb.h like: >> >> /* String attributes (currently stored inside tl-data) map C string keys to >> * values. They can be set via kadmin and consumed by KDC plugins. */ >> >> and >> >> /* String attributes may not always be represented in tl-data. kadmin clients >> * must use the get_strings and set_string RPCs. */ >> >> make me wonder if it is a good idea to operate on the tl-data of type >> KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well >> so I'm not insisting to change it, I'm just wondering about the reasons. >> >> Would something like (error checks are missing) >> >> kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", >> &require_auth_str); >> >> if (require_auth_str != NULL) { >> kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); >> } >> >> kerr = ipadb_get_ldap_mod_extra_data(imods, >> entry->tl_data, >> mod_op); >> >> if (require_auth_str != NULL) { >> kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", >> require_auth_str); >> } >> >> have the same effect with only using the recommended API (and making the >> patch smaller)? >> > >I believe that would be the same effect, just less efficient. But >sticking to the API is probably safer in the long run. I am okay >with changing it if you would prefer. I think from the maintenance perspective it would be better to use the recommended API. -- / Alexander Bokovoy From rcritten at redhat.com Wed Apr 27 17:05:11 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Apr 2016 12:05:11 -0500 Subject: [Freeipa-devel] [PATCH] Added warning to user for Internet Explorer In-Reply-To: <57206066.8020801@redhat.com> References: <571DF8CC.8070305@redhat.com> <571F87FF.5010706@redhat.com> <571F8B38.3040207@redhat.com> <57206066.8020801@redhat.com> Message-ID: <5720F147.3080805@redhat.com> Abhijeet Kasurde wrote: > Updated patch attached. > > On 04/26/2016 09:07 PM, Rob Crittenden wrote: >> Internet Explorer is no longer a supported browser. > ACK From tbabej at redhat.com Thu Apr 28 10:19:38 2016 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 28 Apr 2016 12:19:38 +0200 Subject: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides In-Reply-To: <5715CE17.8090503@redhat.com> References: <56FE8B5F.8040803@redhat.com> <570279B6.1070504@redhat.com> <20160407115302.GL4768@p.redhat.com> <570DFB66.9040207@redhat.com> <570E3800.1060700@redhat.com> <5715CE17.8090503@redhat.com> Message-ID: <5721E3BA.4030409@redhat.com> On 04/19/2016 08:20 AM, Jan Cholasta wrote: > On 13.4.2016 14:13, Tomas Babej wrote: >> On 04/13/2016 09:55 AM, Tomas Babej wrote: >>> On 04/07/2016 01:53 PM, Sumit Bose wrote: >>>> On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 1.4.2016 16:53, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> this extends the user ID overrides with capability to store the user >>>>>> certificate. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4955 >>>>> >>>>> The preferred way of managing certificates nowadays is using >>>>> $OBJ-add-cert >>>>> and $OBJ-remove-cert commands, you should add them here as well. >>>>> >>>>> I would even go as far as not allowing to modify certificates using >>>>> idoverrideuser-mod - in user-mod and host-mod, it's there just for >>>>> backward >>>>> compatibility, which is not the case here. But I don't have a >>>>> strong opinion >>>>> on that. >>>>> >>>>> For consistency with user-find and host-find, the full certificate >>>>> blob >>>>> should not be shown in idoverrideuser-find. You can do that by setting >>>>> search_display_attributes attribute on the idoverrideuser class >>>>> appropriately. >>>> >>>> I tested the current patch with my related patches for SSSD and all is >>>> working as expected. >>>> >>>> bye, >>>> Sumit >>>> >>>>> >>>>> 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 >>>> >>> >>> Thanks for the reviews, >>> >>> attaching a updated patch that addresses Honza's comments. >>> >>> Tomas >>> >> >> Sending an improved version addressing a couple of additional issues. > > 1) This bit in idoverrideuser_add.pre_callback() is redundant, as the > certificate will always be DER here already: > > # Normalize the certificate to DER format > certs = options.get('usercertificate', []) > certs_der = [x509.normalize_certificate(c) for c in certs] > entry_attrs['usercertificate'] = certs_der > > > 2) You need to call convert_usercertificate_pre() in > idoverrideuser_mod.pre_callback() and convert_usercertificate_post() in > idoverrideuser_{mod,find,show}.post_callback() as well. > > Honza > Updated patch attached, mentioned issues should be fixed, I also removed one redundant import which escaped my careful eye. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0405-5-idviews-Add-user-certificate-attribute-to-user-ID-ov.patch Type: text/x-patch Size: 16086 bytes Desc: not available URL: From mbasti at redhat.com Thu Apr 28 12:28:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 14:28:56 +0200 Subject: [Freeipa-devel] [PATCH] Added warning to user for Internet Explorer In-Reply-To: <5720F147.3080805@redhat.com> References: <571DF8CC.8070305@redhat.com> <571F87FF.5010706@redhat.com> <571F8B38.3040207@redhat.com> <57206066.8020801@redhat.com> <5720F147.3080805@redhat.com> Message-ID: <57220208.7090309@redhat.com> On 27.04.2016 19:05, Rob Crittenden wrote: > Abhijeet Kasurde wrote: >> Updated patch attached. >> >> On 04/26/2016 09:07 PM, Rob Crittenden wrote: >>> Internet Explorer is no longer a supported browser. >> > > ACK > pushed to master: * f61910084d737f66b9914f3f945e9830a393c8af Added warning to user for Internet Explorer From pvoborni at redhat.com Thu Apr 28 12:36:35 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 28 Apr 2016 14:36:35 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <571E3091.3090003@redhat.com> References: <571E3091.3090003@redhat.com> Message-ID: <3341ddba-206f-feea-23bb-b826cc6aad45@redhat.com> On 04/25/2016 04:58 PM, Petr Spacek wrote: > Hello, > > ipa-nis-manage: add status option > > https://bugzilla.redhat.com/show_bug.cgi?id=1329275 > Trac ticket https://fedorahosted.org/freeipa/ticket/5856 -- Petr Vobornik From mbasti at redhat.com Thu Apr 28 12:40:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 14:40:00 +0200 Subject: [Freeipa-devel] [PATCH 0097-0098] Makefile: replace perl with sed In-Reply-To: <20160425073939.GB8197@10.4.128.1> References: <571A0B03.9030402@redhat.com> <20160425073939.GB8197@10.4.128.1> Message-ID: <572204A0.2050205@redhat.com> On 25.04.2016 09:39, Lukas Slebodnik wrote: > On (22/04/16 13:29), Petr Spacek wrote: >> Hello, >> >> Makefile: add sed to BuildRequires >> >> It was requried since forever but we did not explicitly mention it. >> >> Makefile: replace perl with sed >> >> Perl was missing in BuildRequires anyway and it is used only on one place, >> all other places are using sed. >> >> -- >> Petr^2 Spacek > >From 3c7a3c87d62358407d856119e384c70040acec1e Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 22 Apr 2016 10:40:11 +0200 >> Subject: [PATCH] Makefile: replace perl with sed >> >> Perl was missing in BuildRequires anyway and it is used only on one place, >> all other places are using sed. >> --- >> Makefile | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> > ACK > > >From 2deaef91ab71c0e78b2142c2102cfe65f0e4ed96 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 22 Apr 2016 10:40:37 +0200 >> Subject: [PATCH] Makefile: add sed to BuildRequires >> >> It was requried since forever but we did not explicitly mention it. >> --- >> freeipa.spec.in | 1 + >> 1 file changed, 1 insertion(+) >> > NACK > > As it was mentioned elsewhere in thread this patch is not needed. > > LS > pushed to master: * 8689e6be515aaf5b3d6c891e9e450b99cd8af8d4 Makefile: replace perl with sed From jcholast at redhat.com Thu Apr 28 12:45:06 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Apr 2016 14:45:06 +0200 Subject: [Freeipa-devel] [WIP] Thin client Message-ID: <4587fed6-1e63-0fe0-3749-c9793167c77c@redhat.com> Hi, I have pushed my thin client WIP branch to GitHub: . All commits up to "ipalib: use relative imports for cross-plugin imports" should be good for review. The rest is subject to change (WARNING: I will force push into this branch). Honza -- Jan Cholasta From mbasti at redhat.com Thu Apr 28 12:42:30 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 14:42:30 +0200 Subject: [Freeipa-devel] [PATCH] 0003 webui: Issue New Certificate dialogs validates data In-Reply-To: <56AA4800.60207@redhat.com> References: <56A9F99B.6090909@redhat.com> <56AA4800.60207@redhat.com> Message-ID: <57220536.6060507@redhat.com> On 28.01.2016 17:55, Pavel Vomacka wrote: > Hello, > > On 01/28/2016 12:20 PM, Pavel Vomacka wrote: >> 'Issue new certificate' dialog now validates whether user fills >> 'principal' and 'csr' field. >> In case that one of these fields is empty then it does not allow to >> submit the dialog. >> >> https://fedorahosted.org/freeipa/ticket/5432 > I'm sending edited patch. One useless section is removed. The textarea > for CSR is moved to another section which has the same layout. The > method for creating content was useless, too. So it is removed in this > patch. > > -- > Pavel Vomacka > > Bump for review -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Apr 28 12:45:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 14:45:25 +0200 Subject: [Freeipa-devel] [PATCH] 0003 webui: Issue New Certificate dialogs validates data In-Reply-To: <57220536.6060507@redhat.com> References: <56A9F99B.6090909@redhat.com> <56AA4800.60207@redhat.com> <57220536.6060507@redhat.com> Message-ID: <572205E5.9000203@redhat.com> On 28.04.2016 14:42, Martin Basti wrote: > > > On 28.01.2016 17:55, Pavel Vomacka wrote: >> Hello, >> >> On 01/28/2016 12:20 PM, Pavel Vomacka wrote: >>> 'Issue new certificate' dialog now validates whether user fills >>> 'principal' and 'csr' field. >>> In case that one of these fields is empty then it does not allow to >>> submit the dialog. >>> >>> https://fedorahosted.org/freeipa/ticket/5432 >> I'm sending edited patch. One useless section is removed. The >> textarea for CSR is moved to another section which has the same >> layout. The method for creating content was useless, too. So it is >> removed in this patch. >> >> -- >> Pavel Vomacka >> >> > Bump for review > > OK, this thread is duplicated, patch has been pushed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akasurde at redhat.com Thu Apr 28 12:52:10 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 28 Apr 2016 18:22:10 +0530 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <571E3091.3090003@redhat.com> References: <571E3091.3090003@redhat.com> Message-ID: <5722077A.7000504@redhat.com> Hi Petr, On 04/25/2016 08:28 PM, Petr Spacek wrote: > Hello, > > ipa-nis-manage: add status option > > https://bugzilla.redhat.com/show_bug.cgi?id=1329275 > > > Can you reword the error message here as well ? if len(args) != 1: sys.exit("You must specify one action, either enable or disable") Thanks, Abhijeet Kasurde -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Apr 28 14:09:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 16:09:17 +0200 Subject: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way In-Reply-To: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> References: <2130310256.43083012.1460104345665.JavaMail.zimbra@redhat.com> Message-ID: <5722198D.2040305@redhat.com> On 08.04.2016 10:32, Peter Lacko wrote: > > Hello, I have a few comments: 1) Please set up your git name and email correctly (consistently for all patches) this is not right From: root 2) -# Copyright (C) 2012 Red Hat +# Copyright (C) 2016 Red Hat leave there both years please +# Copyright (C) 2012, 2016 Red Hat 3) Please put the patch number to the email subject, it is easier to find correct patch for us Otherwise LGTM and works for me. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Apr 28 14:14:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 16:14:57 +0200 Subject: [Freeipa-devel] [PATCH 0088-0095] Add --forward-policy option into installers In-Reply-To: <571A1A9F.3010906@redhat.com> References: <56E1E3B2.3070907@redhat.com> <20160310211744.GD32482@mail.corp.redhat.com> <56F01891.5030704@redhat.com> <56FD0DBF.7030307@redhat.com> <57028A3D.1010204@redhat.com> <570D13A3.8060802@redhat.com> <571A1A9F.3010906@redhat.com> Message-ID: <57221AE1.8070204@redhat.com> On 22.04.2016 14:35, Petr Spacek wrote: > On 12.4.2016 17:26, Martin Basti wrote: >> >> On 04.04.2016 17:37, Petr Spacek wrote: >>> On 31.3.2016 13:45, Martin Basti wrote: >>>> On 21.03.2016 16:51, Petr Spacek wrote: >>>>> On 10.3.2016 22:17, Lukas Slebodnik wrote: >>>>>> On (10/03/16 22:14), Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I forgot to send a patches before I leave, so here it is: >>>>>>> >>>>>>> Auto-detect default value for --forward-policy option in installers >>>>>>> >>>>>>> See >>>>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>>>> commit messages, and design page >>>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I did not have time to test it thoroughly but it LGTM :-D >>>>>>> >>>>>>> Please note that this is first part, it does not solve upgrade (yet) and >>>>>>> warnings in forwardzone-* interface. >>>>>>> >>>>>>> This can be solved in another patch set, this can be pushed if it passes >>>>>>> review. >>>>>>> >>>>>> ENOPATH >>>>> LOL, here it is. >>>>> >>>>> >>>>> >>>> * Remove function ipapython.ipautil.host_exists() * >>>> ACK >>>> >>>> >>>> * Extend installers with --forward-policy option * >>>> 1) >>>> There is no --forward-policy option in ipa-dns-install >>>> >>>> >>>> * Move automatic empty zone list into ipapython.dnsutil and make it reusable * >>>> ACK >>>> >>>> >>>> * Add assert_absolute_dnsname() helper to ipapython.dnsutil * >>>> ACK >>>> >>>> >>>> * Move function is_auto_empty_zone() into ipapython.dnsutil * >>>> ACK >>>> >>>> >>>> * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * >>>> ACK >>>> >>>> * Add function ipapython.dnsutil.inside_auto_empty_zone() * >>>> ACK >>>> >>>> * Auto-detect default value for --forward-policy option in installers * >>>> LGTM, but ipa-dns-install is missing option --forward-policy >>>> >>>> # ipa-dns-install >>>> ... >>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>> AttributeError: Values instance has no attribute 'forward_policy' >>>> >>>> >>>> Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK >>> Thank you very much for review. >>> >>> Here is my second attempt :-) >>> >> Hello, >> code works as expected, but it is quite inconsistent with current behavior >> >> ipa-server-install --forward-policy should raise error without --setup-dns option >> >> Like here: >> [root at vm-058-134 ~]# ipa-server-install --forwarder=10.2.3.4 >> Usage: ipa-server-install [options] >> >> ipa-server-install: error: You cannot specify a --forwarder option without the >> --setup-dns option >> ipa.ipapython.install.cli.install_tool(Server): ERROR The >> ipa-server-install command failed. See /var/log/ipaserver-install.log for more >> information >> >> Martin > Fixed patches are attached. Thank you for your time! > almost ack but patches need rebase on ipa-4-3 From pvomacka at redhat.com Thu Apr 28 14:16:57 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 28 Apr 2016 16:16:57 +0200 Subject: [Freeipa-devel] [PATCH] Added fix for notifying user about locked user account in WebUI In-Reply-To: <5717192C.1010708@redhat.com> References: <5717192C.1010708@redhat.com> Message-ID: On 04/20/2016 07:52 AM, Abhijeet Kasurde wrote: > Hi All, > > Please review this patch. > > Fixes : https://fedorahosted.org/freeipa/ticket/5076 > > Thanks, > Abhijeet Kasurde > > Hi, Javascript part LGTM. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Apr 28 14:24:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 16:24:00 +0200 Subject: [Freeipa-devel] More Python 3 fixes In-Reply-To: <571F6DAD.2090107@redhat.com> References: <571F6DAD.2090107@redhat.com> Message-ID: <57221D00.8000906@redhat.com> On 26.04.2016 15:31, Petr Viktorin wrote: > Hello, > Here are two patches for problems with using IPA with Python 3. > > > > ACK Pushed master: * 28b0bfaefea02fe188b57b602396f5ef62863726 dns plugin: Fix zone normalization under Python 3 * 05cb4ba4e97d8cbffaf1c16451c488db4a90a878 sysrestore: Iterate over a list of dict keys ipa-4-3: * 1e228f27e9d6314b5cdc58c772c350b0592ebe86 dns plugin: Fix zone normalization under Python 3 * c8bcf4287f9aa881a6517f26adce001b3dbcd1c2 sysrestore: Iterate over a list of dict keys -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Apr 28 15:06:24 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 17:06:24 +0200 Subject: [Freeipa-devel] [PATCH] Added fix for notifying user about locked user account in WebUI In-Reply-To: References: <5717192C.1010708@redhat.com> Message-ID: <572226F0.5030105@redhat.com> On 28.04.2016 16:16, Pavel Vomacka wrote: > > > > On 04/20/2016 07:52 AM, Abhijeet Kasurde wrote: >> Hi All, >> >> Please review this patch. >> >> Fixes : https://fedorahosted.org/freeipa/ticket/5076 >> >> Thanks, >> Abhijeet Kasurde >> >> > > Hi, > > Javascript part LGTM. > > -- > Pavel^3 Vomacka > > ACK Pushed to master: 3d07c889ce21ffe1d8baec3fd0c13bc67aa1d725 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Apr 28 15:15:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Apr 2016 17:15:06 +0200 Subject: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option In-Reply-To: <5722077A.7000504@redhat.com> References: <571E3091.3090003@redhat.com> <5722077A.7000504@redhat.com> Message-ID: <572228FA.6040007@redhat.com> On 28.4.2016 14:52, Abhijeet Kasurde wrote: > Hi Petr, > > On 04/25/2016 08:28 PM, Petr Spacek wrote: >> Hello, >> >> ipa-nis-manage: add status option >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1329275 >> >> >> > Can you reword the error message here as well ? > > if len(args) != 1: > sys.exit("You must specify one action, either enable or disable") > > Thanks, > Abhijeet Kasurde Good catch! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0099-2-ipa-nis-manage-add-status-option.patch Type: text/x-patch Size: 3939 bytes Desc: not available URL: From pspacek at redhat.com Thu Apr 28 15:27:55 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 28 Apr 2016 17:27:55 +0200 Subject: [Freeipa-devel] [PATCH 0088-0095] Add --forward-policy option into installers In-Reply-To: <57221AE1.8070204@redhat.com> References: <56E1E3B2.3070907@redhat.com> <20160310211744.GD32482@mail.corp.redhat.com> <56F01891.5030704@redhat.com> <56FD0DBF.7030307@redhat.com> <57028A3D.1010204@redhat.com> <570D13A3.8060802@redhat.com> <571A1A9F.3010906@redhat.com> <57221AE1.8070204@redhat.com> Message-ID: <57222BFB.7050205@redhat.com> On 28.4.2016 16:14, Martin Basti wrote: > > > On 22.04.2016 14:35, Petr Spacek wrote: >> On 12.4.2016 17:26, Martin Basti wrote: >>> >>> On 04.04.2016 17:37, Petr Spacek wrote: >>>> On 31.3.2016 13:45, Martin Basti wrote: >>>>> On 21.03.2016 16:51, Petr Spacek wrote: >>>>>> On 10.3.2016 22:17, Lukas Slebodnik wrote: >>>>>>> On (10/03/16 22:14), Petr Spacek wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I forgot to send a patches before I leave, so here it is: >>>>>>>> >>>>>>>> Auto-detect default value for --forward-policy option in installers >>>>>>>> >>>>>>>> See >>>>>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>>>>> commit messages, and design page >>>>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I did not have time to test it thoroughly but it LGTM :-D >>>>>>>> >>>>>>>> Please note that this is first part, it does not solve upgrade (yet) and >>>>>>>> warnings in forwardzone-* interface. >>>>>>>> >>>>>>>> This can be solved in another patch set, this can be pushed if it passes >>>>>>>> review. >>>>>>>> >>>>>>> ENOPATH >>>>>> LOL, here it is. >>>>>> >>>>>> >>>>>> >>>>> * Remove function ipapython.ipautil.host_exists() * >>>>> ACK >>>>> >>>>> >>>>> * Extend installers with --forward-policy option * >>>>> 1) >>>>> There is no --forward-policy option in ipa-dns-install >>>>> >>>>> >>>>> * Move automatic empty zone list into ipapython.dnsutil and make it >>>>> reusable * >>>>> ACK >>>>> >>>>> >>>>> * Add assert_absolute_dnsname() helper to ipapython.dnsutil * >>>>> ACK >>>>> >>>>> >>>>> * Move function is_auto_empty_zone() into ipapython.dnsutil * >>>>> ACK >>>>> >>>>> >>>>> * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * >>>>> ACK >>>>> >>>>> * Add function ipapython.dnsutil.inside_auto_empty_zone() * >>>>> ACK >>>>> >>>>> * Auto-detect default value for --forward-policy option in installers * >>>>> LGTM, but ipa-dns-install is missing option --forward-policy >>>>> >>>>> # ipa-dns-install >>>>> ... >>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>> AttributeError: Values instance has no attribute 'forward_policy' >>>>> >>>>> >>>>> Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK >>>> Thank you very much for review. >>>> >>>> Here is my second attempt :-) >>>> >>> Hello, >>> code works as expected, but it is quite inconsistent with current behavior >>> >>> ipa-server-install --forward-policy should raise error without --setup-dns >>> option >>> >>> Like here: >>> [root at vm-058-134 ~]# ipa-server-install --forwarder=10.2.3.4 >>> Usage: ipa-server-install [options] >>> >>> ipa-server-install: error: You cannot specify a --forwarder option without the >>> --setup-dns option >>> ipa.ipapython.install.cli.install_tool(Server): ERROR The >>> ipa-server-install command failed. See /var/log/ipaserver-install.log for more >>> information >>> >>> Martin >> Fixed patches are attached. Thank you for your time! >> > almost ack but patches need rebase on ipa-4-3 Here you go. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0088-4-Remove-function-ipapython.ipautil.host_exists.patch Type: text/x-patch Size: 2694 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0089-4-Extend-installers-with-forward-policy-option.patch Type: text/x-patch Size: 9760 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0090-4-Move-automatic-empty-zone-list-into-ipapython.dnsuti.patch Type: text/x-patch Size: 8291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0091-4-Add-assert_absolute_dnsname-helper-to-ipapython.dnsu.patch Type: text/x-patch Size: 1574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0092-4-Move-function-is_auto_empty_zone-into-ipapython.dnsu.patch Type: text/x-patch Size: 2196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0093-4-Use-shared-sanity-check-and-tests-ipapython.dnsutil..patch Type: text/x-patch Size: 1299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0094-4-Add-function-ipapython.dnsutil.inside_auto_empty_zon.patch Type: text/x-patch Size: 1508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0095-4-Auto-detect-default-value-for-forward-policy-option-.patch Type: text/x-patch Size: 6542 bytes Desc: not available URL: From mbasti at redhat.com Thu Apr 28 15:33:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 17:33:04 +0200 Subject: [Freeipa-devel] [PATCH 0024] ipa-replica-manage: added --suffix option for certain commands In-Reply-To: <571DD7C1.6050804@redhat.com> References: <56E29266.8000501@redhat.com> <56E6E43B.4050805@redhat.com> <56E7AADC.3060407@redhat.com> <56E7F642.8010109@redhat.com> <56E90C5C.2020703@redhat.com> <56E925D0.2080305@redhat.com> <56E9637B.5080307@redhat.com> <56F2B380.9030504@redhat.com> <1183297765.33667649.1458760420403.JavaMail.zimbra@redhat.com> <56F42D93.5050505@redhat.com> <56FBE818.80805@redhat.com> <5704FB3C.2050003@redhat.com> <570E3013.7030006@redhat.com> <5710DECD.5040103@redhat.com> <571A0749.9020402@redhat.com> <571A401A.7080804@redhat.com> <571DD7C1.6050804@redhat.com> Message-ID: <57222D30.8080308@redhat.com> On 25.04.2016 10:39, Stanislav Laznicka wrote: > On 04/22/2016 05:15 PM, Stanislav Laznicka wrote: >> On 04/22/2016 01:13 PM, Martin Basti wrote: >>> >>> >>> On 15.04.2016 14:30, Stanislav Laznicka wrote: >>>> On 04/13/2016 01:40 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 06.04.2016 14:04, Stanislav Laznicka wrote: >>>>>> On 03/30/2016 04:52 PM, Martin Basti wrote: >>>>>>> On 24.03.2016 19:10, Stanislav Laznicka wrote: >>>>>>>> On 03/23/2016 08:13 PM, Martin Basti wrote: >>>>>>>>> [...] >>>>>>>>> Can you please update design >>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 >>>>>>>>> (mainly >>>>>>>>> the --suffix option)? Also there are missing clean-ruv and >>>>>>>>> list-ruv >>>>>>>>> commands in design, and fix usage at the bottom. >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> I don't understand this expression >>>>>>>>> + if dirman_passwd is None or ( >>>>>>>>> + not dirman_passwd and args[0] in >>>>>>>>> cs_enabled_commands): >>>>>>>>> >>>>>>>>> You already tested if subcommand belongs to >>>>>>>>> cs_enabled_commands few >>>>>>>>> lines above, IMO the 'dirman_password is None' expression is >>>>>>>>> enough. >>>>>>>> If I understand it well, when empty password is entered, the >>>>>>>> program continues and uses Kerberos credentials for some >>>>>>>> operations. E.g. for list-ruv, if empty password is entered, >>>>>>>> the command would only display RUVs for domain tree but not for >>>>>>>> the CA tree no matter if CA is set up or not (in the current >>>>>>>> state of the patch, after get_ruv refactoring). This here is >>>>>>>> one possible way around this, although the check for non-empty >>>>>>>> password might probably just as well be in get_ruv_both_suffixes. >>>>>>> >>>>>>> ok >>>>>>>>> 2) >>>>>>>>> +# tuple of commands that work with ca tree and need Directory >>>>>>>>> Manager >>>>>>>>> password >>>>>>>>> +cs_enabled_commands = ("list-ruv", "clean-ruv", >>>>>>>>> "abort-clean-ruv") >>>>>>>>> >>>>>>>>> this variable is used only toi detect if dirman passwd is >>>>>>>>> needed, I >>>>>>>>> suggest to rename it to commands_req_dirman_passwd, or >>>>>>>>> something better. >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> Q: Do we need is_cs_set() function? >>>>>>>>> A: Yes! >>>>>>>>> >>>>>>>>> I wanted to give you ultimate NACK, but then I checked how >>>>>>>>> get_ruv code >>>>>>>>> works and I changed my mind. >>>>>>>>> >>>>>>>>> Please write a comment where is_cs_set function is used, why >>>>>>>>> we need >>>>>>>>> extra function instead of catching an exception, possibly you >>>>>>>>> can open a >>>>>>>>> refactoring ticket. >>>>>>>> After the refactoring changes, is_cs_set should not be needed >>>>>>>> anymore, removed it. >>>>>>>>> >>>>>>>>> Shame: >>>>>>>>> 1) >>>>>>>>> + if not test_connection(realm, host, options.nolookup) >>>>>>>>> or\ >>>>>>>>> Please use parentheses instead of backslash >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> + args[0] in cs_enabled_commands: >>>>>>>>> >>>>>>>>> + not dirman_passwd and args[0] in >>>>>>>>> cs_enabled_commands): >>>>>>>>> >>>>>>>>> Indentation is not multiplication of 4 >>>>>>>> Shame on me indeed, fixed it. >>>>>>>>> >>>>>>>>> Nitpicks (I don't insist on fixing these): >>>>>>>>> 1) >>>>>>>>> + if servers.get('ca', None): >>>>>>>>> >>>>>>>>> None is default >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> + for (netloc, rid) in servers['ca']: >>>>>>>>> parentheses are not needed >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> + print("\t%s: %s" % (netloc, rid)) >>>>>>>>> Would be nice to use .format() instead of % >>>>>>>>> >>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I changed my mind, ultimate NACK. >>>>>>>>> Please fix get_ruv function, is_cs_set will not help. In case >>>>>>>>> there are no RUVs but CA is installed, sys.exit there prevents >>>>>>>>> us from removing RUVs (or any else operation) on domain >>>>>>>>> suffix, and vice versa. >>>>>>>>> I propose to move ticket to 4.4 milestone because I would like >>>>>>>>> to avoid breaking something in 4.3, as this will hit many >>>>>>>>> places in ipa-replica-manage. >>>>>>>>> >>>>>>>>> Please provide the refactoring of get_ruv as separate patch a >>>>>>>>> put these patches on top of it. >>>>>>>>> >>>>>>>>> Martin2 >>>>>>>> Did the refactoring. There also seemed to be duplicit code in >>>>>>>> abort_clean_ruv for some reason, removed it (I hope it does not >>>>>>>> break anything, but it seemed rather useless). Also had to >>>>>>>> change the numbers of the patches so that they would apply. >>>>>>> >>>>>>> NACK >>>>>>> >>>>>>> * ipa-replica-manage refactoring * >>>>>>> >>>>>>> 1) >>>>>>> Instead of: >>>>>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>>>>> - sys.exit(1) >>>>>>> + root_logger.debug("Failed to connect to server {host}: >>>>>>> {err}" >>>>>>> + .format(host=host, err=e)) >>>>>>> + raise RuntimeError(e) >>>>>>> >>>>>>> I expected >>>>>>> >>>>>>> - print("Failed to connect to server %s: %s" % (host, e)) >>>>>>> - sys.exit(1) >>>>>>> + root_logger.debug(traceback.format_exc()) >>>>>>> + raise RuntimeError("Failed to connect to server {host}: >>>>>>> {err}" >>>>>>> + .format(host=host, err=e))) >>>>>> Should be fixed now. >>>>>>> >>>>>>> 2) >>>>>>> - print("No RUV records found.") >>>>>>> - sys.exit(0) >>>>>>> >>>>>>> Here is exit state 0, so we should not raise error. >>>>>>> >>>>>>> I think that we should create new nonfatal exception. >>>>>> Made a new nonfatal error exception, then. This step was a bit >>>>>> controversial when it comes to get_ruv_both_suffixes because it >>>>>> needs to catch both this new exception and a RuntimeError >>>>>> exception for both trees. As the main idea here was not to stop >>>>>> if either tree is missing (resulting in RuntimeError in get_ruv) >>>>>> or contains no records (NonFatalError), it is only printed that >>>>>> something bad may have happened (or it's debug-logged in case of >>>>>> nonfatal errors). In the end, only NonFatalError exception is >>>>>> raised if no records were found for whatever reason resulting in >>>>>> the script always returning 0. >>>>>>> >>>>>>> 3) >>>>>>> - print("unable to decode: %s" % ruv) >>>>>>> + root_logger.debug("unable to decode: %s" % ruv) >>>>>>> This may break tests, because the logger logs to stderr, leave >>>>>>> it as print for now >>>>>>> >>>>>>> 4) >>>>>>> - servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>>>>> + try: >>>>>>> + servers = get_ruv(realm, host, dirman_passwd, nolookup) >>>>>>> + except RuntimeError as e: >>>>>>> + print(e) >>>>>>> + sys.exit(1) >>>>>>> >>>>>>> again we have to print it to stdout for now. >>>>>> 3), 4) done, although it might be better to log to stderr from >>>>>> patch number 27 and on since the default behavior is changed anyway. >>>>>>> >>>>>>> * abort-clean/list/clean-ruv now work for both suffixes * >>>>>>> >>>>>>> - if dirman_passwd is None: >>>>>>> + if dirman_passwd is None or ( >>>>>>> + not dirman_passwd and args[0] in >>>>>>> dirman_passwd_req_commands): >>>>>>> sys.exit("Directory Manager password required") >>>>>> Done. >>>>>>> >>>>>>> Please fix other patch accordingly. >>>>>>> Martin^2 >>>>>> >>>>> >>>>> 1) >>>>> +class NonFatalError(Exception): >>>>> + pass >>>>> >>>>> IMO we should be more specific and call it NoRUVsFound[Exception] >>>>> >>>>> 2) >>>>> Not sure if this i sstill refactoring, it should be separate patch >>>>> - if dirman_passwd is None: >>>>> + if dirman_passwd is None or ( >>>>> + not dirman_passwd and args[0] in >>>>> dirman_passwd_req_commands): >>>>> >>>>> 3) >>>>> +def get_ruv_both_suffixes >>>>> >>>>> I think in case where both suffixes returns RuntimeError we should >>>>> raise RuntimeError too which results into exit with error code. >>>>> >>>> Please see the latest patches. >>> Well, if CA is not installed on replica, it fails, not sure if this >>> is expected behavior of ipa-replica-manage, or if this is related to >>> your current patches. >>> >>> # ipa-replica-manage -p hesloheslo clean-dangling-ruv >>> Failed to obtain information from 'vm-058-051.example.com': no such >>> entry >>> >> It's actually a bug in clean_dangling_ruvs that was not created in >> these patches. I opened a separate ticket for it: >> https://fedorahosted.org/freeipa/ticket/5840. >> > Please see the updated patches. I added verbose flag to > get_ruv_both_suffixes and made list-ruv print that RUVs were not found > in either of the trees instead of empty output for that tree. ACK ipa-4-3: * 41458ab80330cc94ea3d7b1da3fe629b882f4356 replica-manage: fail nicely when DM psswd required * cf0fbbae8e2a603424d77d52ccaaf428bca1a233 ipa-replica-manage refactoring * 1ee1ee2d1ec70d8d15884eafa0472edb63ed70d3 abort-clean/list/clean-ruv now work for both suffixes * c5f135bf1b16ea3c27d5b3b62c5b751850e0df70 Moved password check from clean_dangling_ruv master: * 37865aa1d7d388042a3b8a66975b466ec27a3d38 replica-manage: fail nicely when DM psswd required * d2bb8b7bb1032bf501c984f26f47ef6778c6796a ipa-replica-manage refactoring * ee05442e5d65766774c18679af78f21a12309730 abort-clean/list/clean-ruv now work for both suffixes * c34af691def03313b61a231b85213c8f20e44cfa Moved password check from clean_dangling_ruv From mbasti at redhat.com Thu Apr 28 16:29:38 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 28 Apr 2016 18:29:38 +0200 Subject: [Freeipa-devel] [PATCH 0088-0095] Add --forward-policy option into installers In-Reply-To: <57222BFB.7050205@redhat.com> References: <56E1E3B2.3070907@redhat.com> <20160310211744.GD32482@mail.corp.redhat.com> <56F01891.5030704@redhat.com> <56FD0DBF.7030307@redhat.com> <57028A3D.1010204@redhat.com> <570D13A3.8060802@redhat.com> <571A1A9F.3010906@redhat.com> <57221AE1.8070204@redhat.com> <57222BFB.7050205@redhat.com> Message-ID: <57223A72.9000801@redhat.com> On 28.04.2016 17:27, Petr Spacek wrote: > On 28.4.2016 16:14, Martin Basti wrote: >> >> On 22.04.2016 14:35, Petr Spacek wrote: >>> On 12.4.2016 17:26, Martin Basti wrote: >>>> On 04.04.2016 17:37, Petr Spacek wrote: >>>>> On 31.3.2016 13:45, Martin Basti wrote: >>>>>> On 21.03.2016 16:51, Petr Spacek wrote: >>>>>>> On 10.3.2016 22:17, Lukas Slebodnik wrote: >>>>>>>> On (10/03/16 22:14), Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I forgot to send a patches before I leave, so here it is: >>>>>>>>> >>>>>>>>> Auto-detect default value for --forward-policy option in installers >>>>>>>>> >>>>>>>>> See >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>>>>>> commit messages, and design page >>>>>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I did not have time to test it thoroughly but it LGTM :-D >>>>>>>>> >>>>>>>>> Please note that this is first part, it does not solve upgrade (yet) and >>>>>>>>> warnings in forwardzone-* interface. >>>>>>>>> >>>>>>>>> This can be solved in another patch set, this can be pushed if it passes >>>>>>>>> review. >>>>>>>>> >>>>>>>> ENOPATH >>>>>>> LOL, here it is. >>>>>>> >>>>>>> >>>>>>> >>>>>> * Remove function ipapython.ipautil.host_exists() * >>>>>> ACK >>>>>> >>>>>> >>>>>> * Extend installers with --forward-policy option * >>>>>> 1) >>>>>> There is no --forward-policy option in ipa-dns-install >>>>>> >>>>>> >>>>>> * Move automatic empty zone list into ipapython.dnsutil and make it >>>>>> reusable * >>>>>> ACK >>>>>> >>>>>> >>>>>> * Add assert_absolute_dnsname() helper to ipapython.dnsutil * >>>>>> ACK >>>>>> >>>>>> >>>>>> * Move function is_auto_empty_zone() into ipapython.dnsutil * >>>>>> ACK >>>>>> >>>>>> >>>>>> * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * >>>>>> ACK >>>>>> >>>>>> * Add function ipapython.dnsutil.inside_auto_empty_zone() * >>>>>> ACK >>>>>> >>>>>> * Auto-detect default value for --forward-policy option in installers * >>>>>> LGTM, but ipa-dns-install is missing option --forward-policy >>>>>> >>>>>> # ipa-dns-install >>>>>> ... >>>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>>> AttributeError: Values instance has no attribute 'forward_policy' >>>>>> >>>>>> >>>>>> Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK >>>>> Thank you very much for review. >>>>> >>>>> Here is my second attempt :-) >>>>> >>>> Hello, >>>> code works as expected, but it is quite inconsistent with current behavior >>>> >>>> ipa-server-install --forward-policy should raise error without --setup-dns >>>> option >>>> >>>> Like here: >>>> [root at vm-058-134 ~]# ipa-server-install --forwarder=10.2.3.4 >>>> Usage: ipa-server-install [options] >>>> >>>> ipa-server-install: error: You cannot specify a --forwarder option without the >>>> --setup-dns option >>>> ipa.ipapython.install.cli.install_tool(Server): ERROR The >>>> ipa-server-install command failed. See /var/log/ipaserver-install.log for more >>>> information >>>> >>>> Martin >>> Fixed patches are attached. Thank you for your time! >>> >> almost ack but patches need rebase on ipa-4-3 > Here you go. > ACK (somebody have to push it, because I'm banned from fedora as spambot :) and it will take time until system unblock me due to sync) From pvoborni at redhat.com Thu Apr 28 16:47:50 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 28 Apr 2016 18:47:50 +0200 Subject: [Freeipa-devel] [PATCH 0088-0095] Add --forward-policy option into installers In-Reply-To: <57223A72.9000801@redhat.com> References: <56E1E3B2.3070907@redhat.com> <20160310211744.GD32482@mail.corp.redhat.com> <56F01891.5030704@redhat.com> <56FD0DBF.7030307@redhat.com> <57028A3D.1010204@redhat.com> <570D13A3.8060802@redhat.com> <571A1A9F.3010906@redhat.com> <57221AE1.8070204@redhat.com> <57222BFB.7050205@redhat.com> <57223A72.9000801@redhat.com> Message-ID: <55e523bd-d271-80f0-448a-e69b5aadb364@redhat.com> On 04/28/2016 06:29 PM, Martin Basti wrote: > > > On 28.04.2016 17:27, Petr Spacek wrote: >> On 28.4.2016 16:14, Martin Basti wrote: >>> >>> On 22.04.2016 14:35, Petr Spacek wrote: >>>> On 12.4.2016 17:26, Martin Basti wrote: >>>>> On 04.04.2016 17:37, Petr Spacek wrote: >>>>>> On 31.3.2016 13:45, Martin Basti wrote: >>>>>>> On 21.03.2016 16:51, Petr Spacek wrote: >>>>>>>> On 10.3.2016 22:17, Lukas Slebodnik wrote: >>>>>>>>> On (10/03/16 22:14), Petr Spacek wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I forgot to send a patches before I leave, so here it is: >>>>>>>>>> >>>>>>>>>> Auto-detect default value for --forward-policy option in >>>>>>>>>> installers >>>>>>>>>> >>>>>>>>>> See >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5710 >>>>>>>>>> commit messages, and design page >>>>>>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I did not have time to test it thoroughly but it LGTM :-D >>>>>>>>>> >>>>>>>>>> Please note that this is first part, it does not solve upgrade >>>>>>>>>> (yet) and >>>>>>>>>> warnings in forwardzone-* interface. >>>>>>>>>> >>>>>>>>>> This can be solved in another patch set, this can be pushed if >>>>>>>>>> it passes >>>>>>>>>> review. >>>>>>>>>> >>>>>>>>> ENOPATH >>>>>>>> LOL, here it is. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> * Remove function ipapython.ipautil.host_exists() * >>>>>>> ACK >>>>>>> >>>>>>> >>>>>>> * Extend installers with --forward-policy option * >>>>>>> 1) >>>>>>> There is no --forward-policy option in ipa-dns-install >>>>>>> >>>>>>> >>>>>>> * Move automatic empty zone list into ipapython.dnsutil and make it >>>>>>> reusable * >>>>>>> ACK >>>>>>> >>>>>>> >>>>>>> * Add assert_absolute_dnsname() helper to ipapython.dnsutil * >>>>>>> ACK >>>>>>> >>>>>>> >>>>>>> * Move function is_auto_empty_zone() into ipapython.dnsutil * >>>>>>> ACK >>>>>>> >>>>>>> >>>>>>> * Use shared sanity check and tests >>>>>>> ipapython.dnsutil.is_auto_empty_zone() * >>>>>>> ACK >>>>>>> >>>>>>> * Add function ipapython.dnsutil.inside_auto_empty_zone() * >>>>>>> ACK >>>>>>> >>>>>>> * Auto-detect default value for --forward-policy option in >>>>>>> installers * >>>>>>> LGTM, but ipa-dns-install is missing option --forward-policy >>>>>>> >>>>>>> # ipa-dns-install >>>>>>> ... >>>>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>>>> AttributeError: Values instance has no attribute 'forward_policy' >>>>>>> >>>>>>> >>>>>>> Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK >>>>>> Thank you very much for review. >>>>>> >>>>>> Here is my second attempt :-) >>>>>> >>>>> Hello, >>>>> code works as expected, but it is quite inconsistent with current >>>>> behavior >>>>> >>>>> ipa-server-install --forward-policy should raise error without >>>>> --setup-dns >>>>> option >>>>> >>>>> Like here: >>>>> [root at vm-058-134 ~]# ipa-server-install --forwarder=10.2.3.4 >>>>> Usage: ipa-server-install [options] >>>>> >>>>> ipa-server-install: error: You cannot specify a --forwarder option >>>>> without the >>>>> --setup-dns option >>>>> ipa.ipapython.install.cli.install_tool(Server): ERROR The >>>>> ipa-server-install command failed. See >>>>> /var/log/ipaserver-install.log for more >>>>> information >>>>> >>>>> Martin >>>> Fixed patches are attached. Thank you for your time! >>>> >>> almost ack but patches need rebase on ipa-4-3 >> Here you go. >> > > ACK (somebody have to push it, because I'm banned from fedora as spambot > :) and it will take time until system unblock me due to sync) > pushed to master: * 9ee6d379c496cd1648d58a6ecca72ed41638a3f1 Remove function ipapython.ipautil.host_exists() * 89974548891baa6dbbab401913359e398a2cbc57 Extend installers with --forward-policy option * bd32b48eb0180b73c3bd769b7ea2b369a095c000 Move automatic empty zone list into ipapython.dnsutil and make it reusable * 41464b74f43ab0a7f9ad650bdaac19308fc7ff5c Add assert_absolute_dnsname() helper to ipapython.dnsutil * 6752d6404af13a933105e53ea5875adfb933e293 Move function is_auto_empty_zone() into ipapython.dnsutil * 1df30b4646d0738c5d218acf9f65b6617a970c98 Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * c7ee765c4de086ac92922519d7065fc6b6796f10 Add function ipapython.dnsutil.inside_auto_empty_zone() * 51907d5bb8fce9e5358fed50c0ec7074ef7f0c69 Auto-detect default value for --forward-policy option in installers ipa-4-3: * 6dbc4ccbe42835780f7716d96ec45a9b94ed8b64 Remove function ipapython.ipautil.host_exists() * 54e26799540cbadafa08d1e975e46f261c521c81 Extend installers with --forward-policy option * 5c53cf2cd687fdd77a62dc12ed359953f547b86a Move automatic empty zone list into ipapython.dnsutil and make it reusable * 4a8dcc1cac0d96bf12fb608d3b12e81bbdf2503b Add assert_absolute_dnsname() helper to ipapython.dnsutil * ea1bf611f8b027f6a7140c532d1940eada2c6071 Move function is_auto_empty_zone() into ipapython.dnsutil * f2cf30d38cb28fb6f73a2df6a436658e548d2b10 Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * fbc8a23a2ca93d998ff417fb7f9b9dcde01bddc2 Add function ipapython.dnsutil.inside_auto_empty_zone() * d145f8c78a5bcc5cc21be99be6225587b106c50a Auto-detect default value for --forward-policy option in installers -- Petr Vobornik From mrogers at redhat.com Thu Apr 28 18:58:07 2016 From: mrogers at redhat.com (Matt Rogers) Date: Thu, 28 Apr 2016 14:58:07 -0400 Subject: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling In-Reply-To: <20160427144131.GA17544@mail.redhat.com> References: <194558574.39000570.1460385666567.JavaMail.zimbra@redhat.com> <1460644335.17408.8.camel@redhat.com> <719152812.40107308.1460653195693.JavaMail.zimbra@redhat.com> <20160426130353.GX11731@p.redhat.com> <20160426180203.GC4455@mail.redhat.com> <20160427122337.GB11731@p.redhat.com> <20160427144131.GA17544@mail.redhat.com> Message-ID: <20160428185807.GC19396@mail.redhat.com> On 04/27, Matt Rogers wrote: > On 04/27, Sumit Bose wrote: > > On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote: > > > On 04/26, Sumit Bose wrote: > > > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Nathaniel McCallum" > > > > > > To: "Matt Rogers" , freeipa-devel at redhat.com > > > > > > Sent: Thursday, April 14, 2016 10:32:15 AM > > > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling > > > > > > > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote: > > > > > > > Hi, > > > > > > > > > > > > > > The attached patch is a part of the authentication indicator > > > > > > > enhancements, > > > > > > > adding indicator value storage and retrieval for the KDB driver. > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782 > > > > > > > > > > > > Can you add some whitespace in next_attr()? The density of the code > > > > > > there hurts readability. > > > > > > > > > > > Sure, I've attached the revised patch. > > > > > > > > Hi Matt, > > > > > > > > thank you for the patch. Currently I have the following question. > > > > > > > > You call krb5_dbe_set_string to remove the 'require_auth' data before > > > > calling ipadb_get_ldap_mod_extra_data() > > > > > > > > > > > > + /* Delete authinds from tl_data so it is not included in krbExtraData. */ > > > > > + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > > > > + if (kerr) { > > > > > + goto done; > > > > > + } > > > > > + > > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > > > > entry->tl_data, > > > > > mod_op); > > > > > > > > > > > > > Why it is needed to filter this data again in > > > > ipadb_get_ldap_mod_extra_data()? > > > > > > > > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I > > > believe I left there in error - We decided to operate on a filtered copy > > > of the tl_data (which filter_authind_str_attrs() handles) rather than > > > removing it completely with krb5_dbe_set_string(). I had tested with the > > > above code commented out but forgot to remove it with the submitted patch. > > > > ok, makes sense. > > > > Nevertheless, comments in kdb.h like: > > > > /* String attributes (currently stored inside tl-data) map C string keys to > > * values. They can be set via kadmin and consumed by KDC plugins. */ > > > > and > > > > /* String attributes may not always be represented in tl-data. kadmin clients > > * must use the get_strings and set_string RPCs. */ > > > > make me wonder if it is a good idea to operate on the tl-data of type > > KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well > > so I'm not insisting to change it, I'm just wondering about the reasons. > > > > Would something like (error checks are missing) > > > > kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", > > &require_auth_str); > > > > if (require_auth_str != NULL) { > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); > > } > > > > kerr = ipadb_get_ldap_mod_extra_data(imods, > > entry->tl_data, > > mod_op); > > > > if (require_auth_str != NULL) { > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", > > require_auth_str); > > } > > > > have the same effect with only using the recommended API (and making the > > patch smaller)? > > > > I believe that would be the same effect, just less efficient. But > sticking to the API is probably safer in the long run. I am okay > with changing it if you would prefer. > Here's the updated patch. Thanks again for the review! -- Matt Rogers Red Hat, Inc -------------- next part -------------- >From c08bb73685b2f7a17a22e5ea066ad9b60b7c4163 Mon Sep 17 00:00:00 2001 From: Matt Rogers Date: Fri, 25 Mar 2016 17:01:40 -0400 Subject: [PATCH] ipa_kdb: add krbPrincipalAuthInd handling Store and retrieve the authentication indicator "require_auth" string in the krbPrincipalAuthInd attribute. Skip storing auth indicators to krbExtraData. --- daemons/ipa-kdb/ipa_kdb_principals.c | 171 +++++++++++++++++++++++++++++++++++ install/share/60kerberos.ldif | 6 +- 2 files changed, 175 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 629f8193223c924267f6d5f39d258cfbc51c7f63..837b4ad37f25aebbe61623e156544cf01d1c0c9e 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -54,6 +54,7 @@ static char *std_principal_attrs[] = { "krbLastSuccessfulAuth", "krbLastFailedAuth", "krbLoginFailedCount", + "krbPrincipalAuthInd", "krbExtraData", "krbLastAdminUnlock", "krbObjectReferences", @@ -428,6 +429,85 @@ done: return kerr; } +static void strv_free(char **strv) +{ + int i; + + if (strv == NULL) { + return; + } + + for (i = 0; strv[i] != NULL; i++) { + free(strv[i]); + } + + free(strv); +} + +static krb5_error_code ipadb_get_ldap_auth_ind(krb5_context kcontext, + LDAP *lcontext, + LDAPMessage *lentry, + krb5_db_entry *entry) +{ + krb5_error_code ret = 0; + char **authinds = NULL; + char *aistr = NULL; + char *ap = NULL; + size_t len = 0; + size_t l = 0; + int count = 0; + int i = 0; + + ret = ipadb_ldap_attr_to_strlist(lcontext, lentry, "krbPrincipalAuthInd", + &authinds); + switch (ret) { + case 0: + break; + case ENOENT: + return 0; + default: + return ret; + } + + for (count = 0; authinds != NULL && authinds[count] != NULL; count++) { + len += strlen(authinds[count]) + 1; + } + + if (len == 0) { + strv_free(authinds); + return 0; + } + + aistr = malloc(len); + if (aistr == NULL) { + ret = errno; + goto cleanup; + } + + /* Create a space-separated string of authinds. */ + ap = aistr; + l = len; + for (i = 0; i < count; i++) { + ret = snprintf(ap, l, "%s ", authinds[i]); + if (ret <= 0 || ret > l) { + ret = ENOMEM; + goto cleanup; + } + ap += ret; + l -= ret; + } + aistr[len - 1] = '\0'; + + ret = krb5_dbe_set_string(kcontext, entry, "require_auth", + aistr); + +cleanup: + strv_free(authinds); + free(aistr); + + return ret; +} + static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, char *principal, LDAPMessage *lentry, @@ -611,6 +691,10 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext, goto done; } + ret = ipadb_get_ldap_auth_ind(kcontext, lcontext, lentry, entry); + if (ret) + goto done; + ret = ipadb_ldap_attr_to_key_data(lcontext, lentry, "krbPrincipalKey", &res_key_data, &result, &mkvno); @@ -1428,6 +1512,7 @@ static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods, { krb5_error_code kerr; krb5_tl_data *data; + krb5_tl_data *data_tmp = NULL; struct berval **bvs = NULL; krb5_int16 be_type; int n, i; @@ -1649,6 +1734,62 @@ done: return kerr; } +static krb5_error_code ipadb_get_ldap_mod_auth_ind(krb5_context kcontext, + struct ipadb_mods *imods, + krb5_db_entry *entry, + int mod_op) +{ + krb5_error_code ret = 0; + char **strlist = NULL; + char *ais = NULL; + char *ai = NULL; + char *s = NULL; + size_t ai_size = 0; + int cnt = 0; + int i = 0; + + ret = krb5_dbe_get_string(kcontext, entry, "require_auth", &ais); + if (ret) { + return ret; + } + if (ais == NULL) { + return 0; + } + + ai_size = strlen(ais) + 1; + + for (i = 0; i < ai_size; i++) { + if (ais[i] != ' ') { + continue; + } + if (i > 0 && ais[i - 1] != ' ') { + cnt++; + } + } + + strlist = calloc(cnt + 2, sizeof(*strlist)); + if (strlist == NULL) { + free(ais); + return errno; + } + + cnt = 0; + ai = strtok_r(ais, " ", &s); + while (ai != NULL) { + if (ai[0] != '\0') { + strlist[cnt++] = ai; + } + ai = strtok_r(NULL, " ", &s); + } + + ret = ipadb_get_ldap_mod_str_list(imods, "krbPrincipalAuthInd", + strlist, cnt, mod_op); + + free(ais); + free(strlist); + return ret; +} + static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, struct ipadb_mods *imods, krb5_db_entry *entry, @@ -1657,6 +1798,7 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, krb5_error_code kerr; krb5_int32 time32le; int mkvno; + char *req_auth_str = NULL; /* check each mask flag in order */ @@ -1835,6 +1977,10 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, } } + kerr = ipadb_get_ldap_mod_auth_ind(kcontext, imods, entry, mod_op); + if (kerr) + goto done; + /* KADM5_TL_DATA */ if (entry->mask & KMASK_TL_DATA) { kerr = ipadb_get_tl_data(entry, @@ -1854,12 +2000,36 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, } } + kerr = krb5_dbe_get_string(kcontext, entry, "require_auth", + &req_auth_str); + if (kerr) { + goto done; + } + + /* Do not store auth indicators from the string attribute in + * krbExtraData. Remove require_auth value from the entry temporarily. */ + if (req_auth_str != NULL) { + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL); + if (kerr) { + goto done; + } + } + kerr = ipadb_get_ldap_mod_extra_data(imods, entry->tl_data, mod_op); if (kerr && kerr != ENOENT) { goto done; } + + /* Restore require_auth value */ + if (req_auth_str != NULL) { + kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", + req_auth_str); + if (kerr) { + goto done; + } + } } /* KADM5_LOAD */ @@ -1937,6 +2107,7 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, kerr = 0; done: + free(req_auth_str); return kerr; } diff --git a/install/share/60kerberos.ldif b/install/share/60kerberos.ldif index 8698e3a0538fd42443f4a3221fccfb739d4c104d..45bea2aefd3993a521e8ea732f902279622f8cb8 100644 --- a/install/share/60kerberos.ldif +++ b/install/share/60kerberos.ldif @@ -266,7 +266,9 @@ attributetypes: ( 2.16.840.1.113719.1.301.4.53.1 NAME 'krbPrincContainerRef' EQU attributetypes: ( 1.3.6.1.4.1.5322.21.2.5 NAME 'krbLastAdminUnlock' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) ##### A list of services to which a service principal can delegate. attributetypes: ( 1.3.6.1.4.1.5322.21.2.4 NAME 'krbAllowedToDelegateTo' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) -######################################################################## +##### A list of authentication indicator strings, one of which must be satisfied +##### to authenticate to the principal as a service. +attributetypes: ( 2.16.840.1.113730.3.8.15.2.1 NAME 'krbPrincipalAuthInd' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15) ######################################################################## # Object Class Definitions # ######################################################################## @@ -294,7 +296,7 @@ objectClasses: ( 2.16.840.1.113719.1.301.6.4.1 NAME 'krbKdcService' SUP ( krbSer objectClasses: ( 2.16.840.1.113719.1.301.6.5.1 NAME 'krbPwdService' SUP ( krbService ) ) ###### The principal data auxiliary class. Holds principal information ###### and is used to store principal information for Person, Service objects. -objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbLastAdminUnlock $ krbAllowedToDelegateTo ) ) +objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbLastAdminUnlock $ krbAllowedToDelegateTo $ krbPrincipalAuthInd ) ) ###### This class is used to create additional principals and stand alone principals. objectClasses: ( 2.16.840.1.113719.1.301.6.9.1 NAME 'krbPrincipal' SUP ( top ) MUST ( krbPrincipalName ) MAY ( krbObjectReferences ) ) ###### The principal references auxiliary class. Holds all principals referred -- 2.4.3 From akasurde at redhat.com Fri Apr 29 10:57:22 2016 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Fri, 29 Apr 2016 16:27:22 +0530 Subject: [Freeipa-devel] [PATCH] Updated ipa command man page Message-ID: <57233E12.7000706@redhat.com> Hi All, Please review this patch. Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0010-Updated-ipa-command-man-page.patch Type: text/x-patch Size: 2190 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 29 11:50:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Apr 2016 13:50:54 +0200 Subject: [Freeipa-devel] [PATCH 0100-0101] ipa-nis-manage: fix nits in manual page In-Reply-To: <571E32E2.9050101@redhat.com> References: <571E32E2.9050101@redhat.com> Message-ID: <57234A9E.1090502@redhat.com> On 25.04.2016 17:08, Petr Spacek wrote: > Hello, > > ipa-nis-manage: mention return code 3 in man page > > ipa-nis-manage: Replace text references to compat plugin with NIS > > > ACK pushed to master: * f076dfc9d792f195ccf699913cd37b29b5855d35 ipa-nis-manage: Replace text references to compat plugin with NIS * 037ee2a52c4fc4949eb0f42c03a2ec185c0e8d9c ipa-nis-manage: mention return code 3 in man page -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Apr 29 11:54:35 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Apr 2016 13:54:35 +0200 Subject: [Freeipa-devel] [patch 0037] spec: Add python-sssdconfig dependency for python-ipatests package In-Reply-To: <571E02DD.3070301@redhat.com> References: <839e1682-0572-ea40-a66f-19b99ce1ddc5@redhat.com> <571DC904.2010103@redhat.com> <571E02DD.3070301@redhat.com> Message-ID: <57234B7B.8080509@redhat.com> On 25.04.2016 13:43, Martin Babinsky wrote: > On 04/25/2016 09:59 AM, Milan Kub?k wrote: >> On 04/25/2016 09:36 AM, Martin Babinsky wrote: >>> On 04/23/2016 12:13 AM, Milan Kub?k wrote: >>>> https://fedorahosted.org/freeipa/ticket/5843 >>>> >>>> Applies to ipa-4-3, master >>>> >>>> -- >>>> Milan Kubik >>>> >>>> >>>> >>> >>> Hi Milan, >>> >>> the dependency on python-sssdconfig was introduced by my fix to >>> https://fedorahosted.org/freeipa/ticket/5625 (I know, shame) which >>> also landed in ipa-4-2, so you'll need to send a patch also for this >>> branch (the current one obviously does not apply). >>> >>> Also in ipa-4-3 and master patch you should require python3-sssdconfig >>> for python3-ipatests. >>> >> Good catch, thanks. >> Fixed in new patches. >> >> -- >> Milan Kubik >> > Thanks, ACK. > Pushed master: * 829ba69e027351e056b3bbc159722e2cf5e3f1e9 spec: Add python-sssdconfig dependency for python-ipatests package ipa-4-3: * 485d6bae1b36f7b0b94ad199f101da823fc7a53e spec: Add python-sssdconfig dependency for python-ipatests package ipa-4-2: * 492c1cb69bbba313887ac3dbcb134e4c39b1cd9c spec: Add python-sssdconfig dependency for freeipa-tests package From mbasti at redhat.com Fri Apr 29 11:56:20 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Apr 2016 13:56:20 +0200 Subject: [Freeipa-devel] [PATCH 0102] DNS: Fix upgrade - master to forward zone transformatio In-Reply-To: <571FAF6A.6080002@redhat.com> References: <571FAF6A.6080002@redhat.com> Message-ID: <57234BE4.8080404@redhat.com> On 26.04.2016 20:11, Petr Spacek wrote: > Hello, > > DNS: Fix upgrade - master to forward zone transformation > > This happens when upgrading from IPA <= 4.0 to versions 4.3+. > > DNS caching might cause false positive in code which replaces master zone > with forward zone. This will effectivelly delete the master zone > without adding a replacement forward zone. > > Solution is to use skip_overlap_check option for dnsforwardzone_add command > so zone existence check is skipped and the upgrade can proceed. > > https://fedorahosted.org/freeipa/ticket/5851 > > > ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Fri Apr 29 12:39:40 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 29 Apr 2016 14:39:40 +0200 Subject: [Freeipa-devel] [PATCH 0030] fix clean-dangling-ruv in topologies with only one CA Message-ID: <5723560C.7000804@redhat.com> https://fedorahosted.org/freeipa/ticket/5840 Please review the attached patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0030-Fix-to-clean-dangling-ruv-for-single-CA-topologies.patch Type: text/x-patch Size: 3628 bytes Desc: not available URL: From pvomacka at redhat.com Fri Apr 29 13:15:04 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 29 Apr 2016 15:15:04 +0200 Subject: [Freeipa-devel] [PATCH] 0032 webui: change lang.hitch to the javascript bind method Message-ID: <55715965-5c5f-baea-1db0-7a47956a407a@redhat.com> Hi, please review the attached patch. https://fedorahosted.org/freeipa/ticket/5702 -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0032-Change-lang.hitch-to-javascript-bind-method.patch Type: text/x-patch Size: 41099 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 29 14:32:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Apr 2016 16:32:33 +0200 Subject: [Freeipa-devel] [PATCH 0469] make: fail when API.txt or ACI.txt differ from code Message-ID: <57237081.4090800@redhat.com> https://fedorahosted.org/freeipa/ticket/5865 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0469-make-fail-when-ACI.txt-or-API.txt-differs-from-value.patch Type: text/x-patch Size: 869 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 29 14:33:54 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 29 Apr 2016 16:33:54 +0200 Subject: [Freeipa-devel] [PATCH 0470] remove unused code in SchemaCache Message-ID: <572370D2.6060407@redhat.com> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0470-Remove-unused-variable-and-finally-block-in-SchemaCa.patch Type: text/x-patch Size: 1381 bytes Desc: not available URL: From lslebodn at redhat.com Fri Apr 29 15:32:59 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 29 Apr 2016 17:32:59 +0200 Subject: [Freeipa-devel] [PATCH 0469] make: fail when API.txt or ACI.txt differ from code In-Reply-To: <57237081.4090800@redhat.com> References: <57237081.4090800@redhat.com> Message-ID: <20160429153259.GF12088@10.4.128.1> On (29/04/16 16:32), Martin Basti wrote: >https://fedorahosted.org/freeipa/ticket/5865 > >Patch attached. >From 511f9bb1645a707ee83571123df9548731cc9387 Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Fri, 29 Apr 2016 16:28:28 +0200 >Subject: [PATCH] make: fail when ACI.txt or API.txt differs from values in > source code > >This regression was caused by commit 6acaf73b0c6f7301d5a5d4292a4f9926cc370867 before this commit make rpms failed when API.txt did not match api > >https://fedorahosted.org/freeipa/ticket/5865 >--- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/Makefile b/Makefile >index 82e6936a7162ff6e0359521d5c1299ff8ee55220..9cc4d40d191cc0ab27a5c150535e49be89b23b72 100644 >--- a/Makefile >+++ b/Makefile >@@ -188,7 +188,7 @@ version-update: release-update > fi > > if [ "$(SKIP_API_VERSION_CHECK)" != "yes" ]; then \ >- ./makeapi --validate; \ >+ ./makeapi --validate && \ > ./makeaci --validate; \ > fi ACK LS From pviktori at redhat.com Fri Apr 29 17:46:56 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 29 Apr 2016 19:46:56 +0200 Subject: [Freeipa-devel] Another batch of Python 3 patches Message-ID: <57239E10.9070501@redhat.com> Hello, These patches concentrate on tests, and code that was added/changed since I last looked at the FreeIPA project. With these patches, I'm back to getting the same errors under py2 and py3 when in test_xmlrpc. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0777-test_xmlrpc-Use-absolute-imports.patch Type: text/x-patch Size: 2075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0778-xmlrpc_test-Rename-exception-instance-before-working.patch Type: text/x-patch Size: 2808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0779-radiusproxy-plugin-Use-str-error-rather-than-error.m.patch Type: text/x-patch Size: 1093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0780-xmlrpc_test-Expect-bytes-rather-than-strings-for-bin.patch Type: text/x-patch Size: 4026 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0781-ipalib.rpc-Send-base64-encoded-data-as-string-under-.patch Type: text/x-patch Size: 1172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0782-range-plugin-tests-Use-bytes-with-MockLDAP-under-Pyt.patch Type: text/x-patch Size: 4082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0783-radiusproxy-plugin-tests-Expect-bytes-not-text-for-i.patch Type: text/x-patch Size: 1808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0784-certprofile-plugin-Use-binary-mode-for-file-with-bin.patch Type: text/x-patch Size: 1102 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0785-test_add_remove_cert_cmd-Use-bytes-for-base64.b64enc.patch Type: text/x-patch Size: 1142 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 29 17:49:27 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 29 Apr 2016 19:49:27 +0200 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 In-Reply-To: <570CD35D.50204@redhat.com> References: <56C70FAA.4010606@redhat.com> <570CD35D.50204@redhat.com> Message-ID: <57239EA7.6050902@redhat.com> On 04/12/2016 12:52 PM, Petr Spacek wrote: > On 19.2.2016 13:50, Petr Viktorin wrote: >> Is it time yet? >> >> This patch switches /usr/bin/ipa to Python 3 for >> - the in-tree ./ipa command >> - RPMs, when built with_python3 > > NACK, the change in 'ipa' command broke ipa dnszone-find: > > # ipa dnsrecord-find dom-033.abc.idm.lab.eng.brq.redhat.com. > ipa: ERROR: b'dom-033.abc.idm.lab.eng.brq.redhat.com.'.: DNS zone not found > > The same command works when I switch python3->python2 in the 'ipa' command. That error is now fixed, could you please re-review? -- Petr Viktorin