Re: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods
Dne 1.12.2014 v 19:25 Petr Vobornik napsal(a):
On 12/01/2014 02:33 PM, Jan Cholasta wrote:
Hi,
Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a):
`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab
in order to allow hosts to retrieve keytab of their services or related
hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval
design page
https://fedorahosted.org/freeipa/ticket/4777
Since groups of users are supported with group members, we should
probably also support groups of hosts with hostgroup members, for
consistency.
--hostgroup options added.
Thanks, ACK.
Fixed a typo in host.py:
+label=_('Hosts Groups allowed to create keytab'),
^
and pushed to:
master: 026c9eca0920e92e56148b808c851e9bde00ece8
ipa-4-1: 1108e7145538f84da2e0dfdf4fb0e76583575dd2
I'm pondering how to handle Web UI. I'm not font of adding a third pair
of tables to host and service details pages because the amount of space
on the page required for the keytab management is much bigger than its
importance compared to other fields.
Honza
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile
On 12/03/2014 05:13 AM, Gabe Alford wrote: This patch removes the changelog and Makefile.am for ipaclient as well. Thanks, Gabe On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek mko...@redhat.com wrote: On 12/01/2014 04:25 PM, Rob Crittenden wrote: Gabe Alford wrote: On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 11/30/2014 03:28 AM, Gabe Alford wrote: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 27.11.2014 11:00, Martin Basti wrote: On 27/11/14 00:50, Gabe Alford wrote: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; mailto:redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The app_PYTHON statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin It looks like the ipaclient/Makefile.am is still being used. I tried removing it and there were errors in the build, but maybe I am wrong? It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. Feel free to rip out the outdated hg ChangeLog stuff though. rob I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not about ipa-client/Makefile.am - we still need this one as Rob correctly said. The failure that Gabe hit in build probably comes from the the SUBDIR reference in ipa-client/Makefile.am file. I assume that if the reference is removed, the removal should work. And yes, you can remove the Changelog too if you are OK with it :) Martin I think you did some error during the process. This is what I got: $ git clean -fxd $ git apply ... $ make rpms ... checking that generated files are newer than configure... done configure: creating ./config.status config.status: error: cannot find input file: `Makefile.in' Makefile:84: recipe for target 'client-autogen' failed make: *** [client-autogen] Error 1 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable
On 12/02/2014 08:57 PM, Nathaniel McCallum wrote: On Tue, 2014-11-18 at 20:26 +0100, Petr Vobornik wrote: On 13.11.2014 08:53, Martin Kosek wrote: On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: On 11/07/2014 04:44 PM, Petr Vobornik wrote: On 7.11.2014 08:58, Martin Kosek wrote: On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: On 10/29/2014 10:37 AM, Martin Kosek wrote: On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: This patch gives the administrator variables to control the size of the authentication and synchronization windows for OTP tokens. https://fedorahosted.org/freeipa/ticket/4511 NOTE: There is one known issue with this patch which I don't know how to solve. This patch changes the schema in install/share/60ipaconfig.ldif. On an upgrade, all of the new attributeTypes appear correctly. However, the modifications to the pre-existing objectClass do not show up on the server. What am I doing wrong? After modifying ipaGuiConfig manually, everything in this patch works just fine. This new version takes into account the new (proper) OIDs and attribute names. Thanks Nathaniel! The above known issue still remains. Petr3, any idea what could have gone wrong? ObjectClass MAY list extension should work just fine, AFAIK. You added a blank line to the LDIF file. This is an entry separator, so the objectClasses after the blank line don't belong to cn=schema, so they aren't considered in the update. Without the blank line it works fine. Thanks for the catch! Here is a version without the blank line. I forgot to remove the old steps defines. This patch performs this cleanup. I am now wondering, is the global config object really the nest place to add these OTP specific settings? I would prefer not to overload the object and instead: - create new ipaOTPConfig objectclass - add it to cn=otp,$SUFFIX - create otpconfig-mod and otpconfig-show commands to follow an example of dnsconfig-* and trustconfig-* commands IMO, this would allow more flexibility for the OTP settings and would also scale better for the future updates. +1 I will comment the patch as if ^^ would not exist because it will still be needed in the new plugin. Because of ^^ I did not test, just read. 1. Got: install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not recommended in array initializers Please run: jsl -nofilelisting -nosummary -nologo -conf jsl.conf in install/ui directory The goal is no have no warnings and errors. 2. new attrs should be added to 'System: Read Global Configuration' managed permission +1. Though if we go with OTP config, it should be called System: Read OTP Configuration Martin Attached is a new set of patches that replaces this single patch. This now fixes multiple issues. I now create two new entries: * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX There are two corresponding CLI commands: * totpconfig-(show|mod) * hotpconfig-(show|mod) There is no UI support for this yet (pointers welcome). This is designed so that eventually tokens can grow a per-token override, but I have not yet implemented this feature (it should be easy in the future). Additionally, I had to do some shared refactoring to address issues in ipa-otp-lasttoken, which is why all of these are now merged into a single patch set. Nathaniel I'm little confused with a state of reviews. Thierry were some of the patches ACKed in different threads or are they under review (I'm not reviewing DS plugin parts)? Patches 0001, 0002, 0003 are ACKed by Thierry, but not merged. They can and should be merged as they fix an independent bug. Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want to make TOTP/HOTP token config as separate entries (to enable future per-token overrides), your approach should make sense. Rather adding Rob to CC for sanity. That would work too. I'm open to that. I am just not sure we should create them as separate plugins, I think the new commands should be rather added to otp plugin directly so that they show in ipa help otptoken instead of adding 2 new topics just for OTP config. I can play with that. Do you plan to change it? I like the idea of a single point of help for OTP but I'm also unsure about the length of the commands. Current solution is also more consistent with a rest of the framework. Would it be something like: otptoken-totpconfig-(show|mod) otptoken-hotpconfig-(show|mod) In the latest patch, I merged totpconfig-* and
Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile
Yeah. This is what I was talking about ipaclient builds still relying on Makefile.am. Plus if you remove the ipaclient/Makefile.am and then run `make rpm`, it fails to find the *.py files to package into the rpm. Gabe On Wed, Dec 3, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com wrote: On 12/03/2014 05:13 AM, Gabe Alford wrote: This patch removes the changelog and Makefile.am for ipaclient as well. Thanks, Gabe On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek mko...@redhat.com wrote: On 12/01/2014 04:25 PM, Rob Crittenden wrote: Gabe Alford wrote: On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 11/30/2014 03:28 AM, Gabe Alford wrote: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 27.11.2014 11:00, Martin Basti wrote: On 27/11/14 00:50, Gabe Alford wrote: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; mailto:redhatri...@gmail.com mailto: redhatri...@gmail.com javascript:; wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The app_PYTHON statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin It looks like the ipaclient/Makefile.am is still being used. I tried removing it and there were errors in the build, but maybe I am wrong? It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. Feel free to rip out the outdated hg ChangeLog stuff though. rob I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not about ipa-client/Makefile.am - we still need this one as Rob correctly said. The failure that Gabe hit in build probably comes from the the SUBDIR reference in ipa-client/Makefile.am file. I assume that if the reference is removed, the removal should work. And yes, you can remove the Changelog too if you are OK with it :) Martin I think you did some error during the process. This is what I got: $ git clean -fxd $ git apply ... $ make rpms ... checking that generated files are newer than configure... done configure: creating ./config.status config.status: error: cannot find input file: `Makefile.in' Makefile:84: recipe for target 'client-autogen' failed make: *** [client-autogen] Error 1 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable
On Wed, 2014-12-03 at 14:43 +0100, Martin Kosek wrote: On 12/02/2014 08:57 PM, Nathaniel McCallum wrote: On Tue, 2014-11-18 at 20:26 +0100, Petr Vobornik wrote: On 13.11.2014 08:53, Martin Kosek wrote: On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: On 11/07/2014 04:44 PM, Petr Vobornik wrote: On 7.11.2014 08:58, Martin Kosek wrote: On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: On 10/29/2014 10:37 AM, Martin Kosek wrote: On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: This patch gives the administrator variables to control the size of the authentication and synchronization windows for OTP tokens. https://fedorahosted.org/freeipa/ticket/4511 NOTE: There is one known issue with this patch which I don't know how to solve. This patch changes the schema in install/share/60ipaconfig.ldif. On an upgrade, all of the new attributeTypes appear correctly. However, the modifications to the pre-existing objectClass do not show up on the server. What am I doing wrong? After modifying ipaGuiConfig manually, everything in this patch works just fine. This new version takes into account the new (proper) OIDs and attribute names. Thanks Nathaniel! The above known issue still remains. Petr3, any idea what could have gone wrong? ObjectClass MAY list extension should work just fine, AFAIK. You added a blank line to the LDIF file. This is an entry separator, so the objectClasses after the blank line don't belong to cn=schema, so they aren't considered in the update. Without the blank line it works fine. Thanks for the catch! Here is a version without the blank line. I forgot to remove the old steps defines. This patch performs this cleanup. I am now wondering, is the global config object really the nest place to add these OTP specific settings? I would prefer not to overload the object and instead: - create new ipaOTPConfig objectclass - add it to cn=otp,$SUFFIX - create otpconfig-mod and otpconfig-show commands to follow an example of dnsconfig-* and trustconfig-* commands IMO, this would allow more flexibility for the OTP settings and would also scale better for the future updates. +1 I will comment the patch as if ^^ would not exist because it will still be needed in the new plugin. Because of ^^ I did not test, just read. 1. Got: install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not recommended in array initializers Please run: jsl -nofilelisting -nosummary -nologo -conf jsl.conf in install/ui directory The goal is no have no warnings and errors. 2. new attrs should be added to 'System: Read Global Configuration' managed permission +1. Though if we go with OTP config, it should be called System: Read OTP Configuration Martin Attached is a new set of patches that replaces this single patch. This now fixes multiple issues. I now create two new entries: * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX There are two corresponding CLI commands: * totpconfig-(show|mod) * hotpconfig-(show|mod) There is no UI support for this yet (pointers welcome). This is designed so that eventually tokens can grow a per-token override, but I have not yet implemented this feature (it should be easy in the future). Additionally, I had to do some shared refactoring to address issues in ipa-otp-lasttoken, which is why all of these are now merged into a single patch set. Nathaniel I'm little confused with a state of reviews. Thierry were some of the patches ACKed in different threads or are they under review (I'm not reviewing DS plugin parts)? Patches 0001, 0002, 0003 are ACKed by Thierry, but not merged. They can and should be merged as they fix an independent bug. Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want to make TOTP/HOTP token config as separate entries (to enable future per-token overrides), your approach should make sense. Rather adding Rob to CC for sanity. That would work too. I'm open to that. I am just not sure we should create them as separate plugins, I think the new commands should be rather added to otp plugin directly so that they show in ipa help otptoken instead of adding 2 new topics just for OTP config. I can play with that. Do you plan to change it? I like the idea of a single point of help for OTP but I'm also unsure about the length of the commands.
[Freeipa-devel] disaster recovery if replica was compromised
Hello, I wonder what we can recommend as disaster recovery procedure for cases where a replica (its LDAP database) was compromised. Saying you are screwed doesn't sound like the right answer :-D It is clear that all passwords and keys have to be changed and complete replica re-installation is inevitable. I would expect something like: - install fresh FreeIPA server and do not connect it to the compromised topology - run migrate-ds to get users, groups etc. (review is necessary) - use this to force all users to change passwords - use this to re-generate all certificates ... This sounds like yet another case for FreeIPA-FreeIPA migration tool which could import SUDO rules and all other FreeIPA-specific stuff. Any ideas? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 2.12.2014 17:21, Simo Sorce wrote: On Tue, 02 Dec 2014 15:56:28 +0100 Petr Spacek pspa...@redhat.com wrote: On 1.12.2014 17:12, Simo Sorce wrote: On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek pspa...@redhat.com wrote: On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held the TSIG keys necessary to perform DNS updates. When the regular ipa dnsrecord-add etc... commands are called, the
Re: [Freeipa-devel] [PATCH 3] ipa-client-install shouldn't be eager in specifying zone when doing nsupdate
On 02/12/14 13:00, Jan Pazdziora wrote: Hello, presumably explicitly specifying zone is not needed and can be harmful. This should be fixed in template for uploading SSHFP keys as well. I have zone bububu.test. 2014-12-03T04:00:36Z DEBUG debug zone client.bububu.test. update delete test.client.bububu.test. IN SSHFP show send update add test.client.bububu.test. 1200 IN SSHFP 1 1 8FD003E98D818E4E2813672234410835AB5844AC update add test.client.bububu.test. 1200 IN SSHFP 1 2 37BF6366A44B67F6CA8FF8A8313B7C964CEA971CCB3E092D775FDF082170AAA4 update add test.client.bububu.test. 1200 IN SSHFP 3 1 3651173F6737DF24EB6494434AC5968B3C90B749 update add test.client.bububu.test. 1200 IN SSHFP 3 2 97EF4030A9DD471A3D4730A819B3A662E11994BB20AFC56FC3875AB1662260BF show send -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile
On 3.12.2014 14:38, Gabe Alford wrote: Yeah. This is what I was talking about ipaclient builds still relying on Makefile.am. Plus if you remove the ipaclient/Makefile.am and then run `make rpm`, it fails to find the *.py files to package into the rpm. Gabe On Wed, Dec 3, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com wrote: On 12/03/2014 05:13 AM, Gabe Alford wrote: This patch removes the changelog and Makefile.am for ipaclient as well. Thanks, Gabe On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek mko...@redhat.com wrote: On 12/01/2014 04:25 PM, Rob Crittenden wrote: Gabe Alford wrote: On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 11/30/2014 03:28 AM, Gabe Alford wrote: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 27.11.2014 11:00, Martin Basti wrote: On 27/11/14 00:50, Gabe Alford wrote: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; mailto:redhatri...@gmail.com mailto: redhatri...@gmail.com javascript:; wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The app_PYTHON statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin It looks like the ipaclient/Makefile.am is still being used. I tried removing it and there were errors in the build, but maybe I am wrong? It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. Feel free to rip out the outdated hg ChangeLog stuff though. rob I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not about ipa-client/Makefile.am - we still need this one as Rob correctly said. The failure that Gabe hit in build probably comes from the the SUBDIR reference in ipa-client/Makefile.am file. I assume that if the reference is removed, the removal should work. And yes, you can remove the Changelog too if you are OK with it :) Martin I think you did some error during the process. This is what I got: $ git clean -fxd $ git apply ... $ make rpms ... checking that generated files are newer than configure... done configure: creating ./config.status config.status: error: cannot find input file: `Makefile.in' Makefile:84: recipe for target 'client-autogen' failed make: *** [client-autogen] Error 1 Lukas, could you please help us to find a way from the Autotools maze? :-) Thank you! -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type
On 13.11.2014 18:04, Nathaniel McCallum wrote: Additionally, fix a small bug in ipa-kdb so that the disabled User Auth Type is properly handled. https://fedorahosted.org/freeipa/ticket/4720 The patch itself looks good to me, VERSION needs to be updated though. But I don't think it works. Don't know why. In my setup, user's config was not ignored. When I tested login in Web UI with: - global config: disabled, otp - user fbar's config: password - fbar had an hotp token assigned I could still login with password and not with otp. If I added 'otp' to fbar's config, I could also login with otp. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile
On (02/12/14 21:13), Gabe Alford wrote: This patch removes the changelog and Makefile.am for ipaclient as well. Thanks, Gabe On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek mko...@redhat.com wrote: On 12/01/2014 04:25 PM, Rob Crittenden wrote: Gabe Alford wrote: On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 11/30/2014 03:28 AM, Gabe Alford wrote: Ignore the last patch. Updated patch attached. On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: This patch removes the app_PYTHON usage. Thanks, Gabe On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Exactly, this was the message from Martin :-) I did not test it myself, but removing all app_PYTHON should be benign given we use Python setup.py packaging. On 11/27/2014 04:27 PM, Gabe Alford wrote: Thanks guys. Sounds like it would be better to submit a patch that removes app_PYTHON if it is considered dead code. Gabe On Thursday, November 27, 2014, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 27.11.2014 11:00, Martin Basti wrote: On 27/11/14 00:50, Gabe Alford wrote: Hello, Wondering if I could get a review. Updated patch attached. Thanks, Gabe On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; mailto:redhatri...@gmail.com mailto:redhatri...@gmail.com javascript:; wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4700 Thanks, Gabe Hello, sorry for late response. We push this ticket to backlog, as it would be part of build system refactoring. The app_PYTHON statement is not used anymore in IPA, the better solution is remove it, instead of keeping dead code up-to-date. Just to clarify: It can be pushed if it works, there is no need to postpone accepting patch if the patch seems okay and doesn't break anything. Martin, please keep in mind that contributions are welcome at any time. Milestones in Trac reflect our view of priorities but it doesn't prevent us from accepting correct patches from contributions at any time, no matter which priority is stated in Trac (or even if there is no ticket for it ...). -- Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin It looks like the ipaclient/Makefile.am is still being used. I tried removing it and there were errors in the build, but maybe I am wrong? It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. Feel free to rip out the outdated hg ChangeLog stuff though. rob I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not about ipa-client/Makefile.am - we still need this one as Rob correctly said. The failure that Gabe hit in build probably comes from the the SUBDIR reference in ipa-client/Makefile.am file. I assume that if the reference is removed, the removal should work. And yes, you can remove the Changelog too if you are OK with it :) Martin From d2e3176b6f6f2abb2ffbdfc198814bd1a845b876 Mon Sep 17 00:00:00 2001 From: Gabe redhatri...@gmail.com Date: Tue, 2 Dec 2014 14:43:57 -0700 Subject: [PATCH] Remove usage of app_PYTHON in ipaserver Makefiles https://fedorahosted.org/freeipa/ticket/4700 --- ipa-client/Makefile.am| 21 - ipa-client/ipaclient/Makefile.am | 17 - ipaserver/install/Makefile.am | 27 --- ipaserver/install/plugins/Makefile.am | 24 4 files changed, 89 deletions(-) delete mode 100644 ipa-client/ipaclient/Makefile.am delete mode 100644 ipaserver/install/Makefile.am delete mode 100644 ipaserver/install/plugins/Makefile.am diff --git a/ipa-client/Makefile.am b/ipa-client/Makefile.am index b9c7020f3b687b3c0030ed5166625e6ef07e2fa4..f6f3168774c3024e10f626b88a8952c51c0eab90 100644 --- a/ipa-client/Makefile.am +++ b/ipa-client/Makefile.am @@ -84,7 +84,6 @@ ipa_join_LDADD = \ SUBDIRS = \ ../asn1 \ - ipaclient \ ipa-install \ man \ $(NULL) @@ -97,7 +96,6 @@ EXTRA_DIST = \ README
Re: [Freeipa-devel] Gaps in upstream tests
On 25.11.2014 10:43, Petr Spacek wrote: On 7.11.2014 14:41, Martin Kosek wrote: FreeIPA team will soon grow with a new member focusing on upstream QE tests. I would like to collect ideas what are the biggest gaps in the current upstream test suite from your POV. Existing requests are tracked here: https://fedorahosted.org/freeipa/query?status=assignedstatus=newstatus=reopenedcomponent=Testscol=idcol=summarycol=componentcol=statuscol=ownercol=typecol=prioritycol=milestonegroup=milestoneorder=priority First idea that I head proposed are Upgrade tests. These are often done manually. I think that upgrade test from currently supported FreeIPA/Fedora version would go a long way (like 3.3.5 on F20 upgraded built RPMs and running unit tests). Second, it would be nice to try testing FreeIPA server in a container. Not only it would verify our container efforts, but it may also allow easy multi-master tests on one Jenkins VM or local host instead of expensive VM orchestration. Any other areas worth focusing on (besides of course testing newly developed features)? At least simple automated MitM attack against TLS. First thing which comes to mind is CLI-server interaction and also certmonger-server interaction. TLS is hard to get right and if I recall it correctly we already had a problem with certificate validation... Related link: http://thehackernews.com/2014/11/nogotofail-Network-Security-Testing-Tool.html The Nogotofail tool requires Python 2.7 and pyOpenSSL=0.13. It features an on-path network Man-in-the-Middle (MiTM), designed to work on Linux machines, as well and optional clients for the devices being tested. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 382 Fix automatic CA cert renewal endless loop in dogtag-ipa-ca-renew-agent
Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4765. Honza -- Jan Cholasta From 5e541c915c3165328bca199f295164a2a9b509e2 Mon Sep 17 00:00:00 2001 From: Jan Cholasta jchol...@redhat.com Date: Wed, 3 Dec 2014 07:43:15 + Subject: [PATCH] Fix automatic CA cert renewal endless loop in dogtag-ipa-ca-renew-agent Reset profile name after requesting the CA cert from Dogtag to prevent the automatic renewal request from being restarted in subsequent calls. https://fedorahosted.org/freeipa/ticket/4765 --- install/certmonger/dogtag-ipa-ca-renew-agent-submit | 2 ++ 1 file changed, 2 insertions(+) diff --git a/install/certmonger/dogtag-ipa-ca-renew-agent-submit b/install/certmonger/dogtag-ipa-ca-renew-agent-submit index 0a2cff1..e0dd33f 100755 --- a/install/certmonger/dogtag-ipa-ca-renew-agent-submit +++ b/install/certmonger/dogtag-ipa-ca-renew-agent-submit @@ -408,8 +408,10 @@ def renew_ca_cert(): IPA CA certificate is about to expire, use ipa-cacert-manage to renew it) elif state == 'request': +profile = os.environ['CERTMONGER_CA_PROFILE'] os.environ['CERTMONGER_CA_PROFILE'] = 'caCACert' result = call_handler(request_and_store_cert) +os.environ['CERTMONGER_CA_PROFILE'] = profile if result[0] == WAIT: return (result[0], '%s:%s' % (state, result[1])) -- 2.1.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
