Re: [Freeipa-devel] [PATCH] 0018-0030 webui: add support for more certificates

[Petr Vobornik]

On 04/26/2016 04:23 PM, Pavel Vomacka wrote:
> 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
>>>

Great stuff, couple comments below.

We can discuss some items in person. Not everything needs to be done.

I didn't run it, just reading the code.

Patch 0018:

1. Nit pick: When a value should be boolean, then following method won't
make sure that dropdown_menu won't be e.g. an object.
 +that.dropdown_menu = spec.dropdown_menu || false;

I would prefer:
 +that.dropdown_menu = !!spec.dropdown_menu;

Which retypes it to boolean. If default should be true (not this case) then:
  that.dropdown_menu = spec.dropdown_menu !== undefined ?
!!spec.dropdown_menu : true;

Also the interface is very specific. It says that the child widget will
have dropdown menu. What if the actions won't be in dropdown menu but,
e.g., some overlay menu.

Imho the interface should be:

 that.custom_actions = !!spec.custom_actions;

Than the child object would have define,e.g., :

   action_object get_custom_actions()

Interface of action_object would be e.g.:
   get_items()
   set_items(items)
   enable_item(name)
   disable_item(name)

Dropdown menu would have to define these methods.

Patch 0019:

1. Shouldn't disable_item or enable_item automatically rerender the items?

2. The rerender, used in later patches. Imo it should do only:

  if (this.ul_node) {
 construct.empty(this.ul_node);
 this._render_items(this.items);
  }

Or just re-render the one item.
  $( "li[data-name=" + item.name +"]", this.ul_node ).replaceWith(
this._render_item(item));

3. in future for loops write:
  for (var i=0, l=this.items.length; i

Re: [Freeipa-devel] [PATCH 0031] Fix replica deletion when there's no RUVs on the server

[Stanislav Laznicka]

Got distracted with the code, beautifying replacement of previous patch 
attached.


On 05/13/2016 03:30 PM, Stanislav Laznicka wrote:

https://fedorahosted.org/freeipa/ticket/5307

Please see the patch attached.




From fb06c6afc9e2d1d84de7c6119b76a9a5de008d06 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Fri, 13 May 2016 15:13:21 +0200
Subject: [PATCH] fixes premature sys.exit in ipa-replica-manage del

Deletion of a replica would fail should there
be no RUVs on the server

https://fedorahosted.org/freeipa/ticket/5307
---
 install/tools/ipa-replica-manage | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index 14e768965601cef08f13792bb5cd086534199538..fb317de915a6350fe53b139dc86e29707401d23f 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -465,9 +465,12 @@ def get_rid_by_host(realm, sourcehost, host, dirman_passwd, nolookup=False):
 """
 try:
 servers = get_ruv(realm, sourcehost, dirman_passwd, nolookup)
-except (NoRUVsFound, RuntimeError) as e:
+except RuntimeError as e:
 print(e)
-sys.exit(0 if isinstance(e, NoRUVsFound) else 1)
+sys.exit(1)
+except NoRUVsFound:
+print(e)
+servers = []
 for (netloc, rid) in servers:
 if '%s:389' % host == netloc:
 return int(rid)
@@ -962,10 +965,6 @@ def del_master_managed(realm, hostname, options):
 #And pick new CA master.
 ensure_last_services(api.Backend.ldap2, hostname, masters, options)
 
-# Save the RID value before we start deleting
-rid = get_rid_by_host(realm, options.host, hostname,
-  options.dirman_passwd, options.nolookup)
-
 # 5. Remove master entry. Topology plugin will remove replication agreements.
 try:
 api.Command.server_del(hostname_u)
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0031] Fix replica deletion when there's no RUVs on the server

[Stanislav Laznicka]

Fix.

On 05/13/2016 03:43 PM, Stanislav Laznicka wrote:
Got distracted with the code, beautifying replacement of previous 
patch attached.


On 05/13/2016 03:30 PM, Stanislav Laznicka wrote:

https://fedorahosted.org/freeipa/ticket/5307

Please see the patch attached.








From 3655cc590ba7d1fb4cf3d2b25fd54e21be3e91fa Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Fri, 13 May 2016 15:13:21 +0200
Subject: [PATCH] fixes premature sys.exit in ipa-replica-manage del

Deletion of a replica would fail should there
be no RUVs on the server

https://fedorahosted.org/freeipa/ticket/5307
---
 install/tools/ipa-replica-manage | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index 14e768965601cef08f13792bb5cd086534199538..5f5e63708ed1664d6ccda8eb7db9e83c02336f7d 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -465,9 +465,12 @@ def get_rid_by_host(realm, sourcehost, host, dirman_passwd, nolookup=False):
 """
 try:
 servers = get_ruv(realm, sourcehost, dirman_passwd, nolookup)
-except (NoRUVsFound, RuntimeError) as e:
+except RuntimeError as e:
 print(e)
-sys.exit(0 if isinstance(e, NoRUVsFound) else 1)
+sys.exit(1)
+except NoRUVsFound as e:
+print(e)
+servers = []
 for (netloc, rid) in servers:
 if '%s:389' % host == netloc:
 return int(rid)
@@ -962,10 +965,6 @@ def del_master_managed(realm, hostname, options):
 #And pick new CA master.
 ensure_last_services(api.Backend.ldap2, hostname, masters, options)
 
-# Save the RID value before we start deleting
-rid = get_rid_by_host(realm, options.host, hostname,
-  options.dirman_passwd, options.nolookup)
-
 # 5. Remove master entry. Topology plugin will remove replication agreements.
 try:
 api.Command.server_del(hostname_u)
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH 0031] Fix replica deletion when there's no RUVs on the server

[Stanislav Laznicka]

https://fedorahosted.org/freeipa/ticket/5307

Please see the patch attached.
From a8a3d6f6e6b306d84814a0745cb86b973b66d177 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Fri, 13 May 2016 15:13:21 +0200
Subject: [PATCH] fixes premature sys.exit in ipa-replica-manage del

Deletion of a replica would fail should there
be no RUVs on the server

https://fedorahosted.org/freeipa/ticket/5307
---
 install/tools/ipa-replica-manage | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index 14e768965601cef08f13792bb5cd086534199538..53283f2d172786a68bcfdfaf1f2f419ef05fae42 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -467,7 +467,10 @@ def get_rid_by_host(realm, sourcehost, host, dirman_passwd, nolookup=False):
 servers = get_ruv(realm, sourcehost, dirman_passwd, nolookup)
 except (NoRUVsFound, RuntimeError) as e:
 print(e)
-sys.exit(0 if isinstance(e, NoRUVsFound) else 1)
+if isinstance(e, RuntimeError):
+sys.exit(1)
+else:
+return None
 for (netloc, rid) in servers:
 if '%s:389' % host == netloc:
 return int(rid)
@@ -962,10 +965,6 @@ def del_master_managed(realm, hostname, options):
 #And pick new CA master.
 ensure_last_services(api.Backend.ldap2, hostname, masters, options)
 
-# Save the RID value before we start deleting
-rid = get_rid_by_host(realm, options.host, hostname,
-  options.dirman_passwd, options.nolookup)
-
 # 5. Remove master entry. Topology plugin will remove replication agreements.
 try:
 api.Command.server_del(hostname_u)
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way

[Peter Lacko]

Desciption added back, header changed to original.

Peter

- Original Message -
From: "Martin Basti" 
To: "Peter Lacko" 
Cc: freeipa-devel@redhat.com
Sent: Friday, May 13, 2016 2:02:00 PM
Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a 
non-declarative way



On 13.05.2016 13:59, Peter Lacko wrote:
> Hi,
>
> Thanks again, will remember that. I also changed header to short one.
>
> Peter

Whyyy?


>
>
> - Original Message -
> From: "Martin Basti" 
> To: "Peter Lacko" , freeipa-devel@redhat.com
> Sent: Tuesday, May 10, 2016 12:23:13 PM
> Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a 
> non-declarative way
>
>
>
> On 28.04.2016 16:09, Martin Basti wrote:
>>
>> 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
>>
>>
> Sorry I didn't noticed earlier, but your patch doesn't work under python3
>
>   from xmlrpc_test import XMLRPC_test, raises_exact
> E   ImportError: No module named 'xmlrpc_test'
>
> You must use absolute import, not relative in py3
>
> Martin^2

From a10f780ada3304ddd444194ddc318a9275e32715 Mon Sep 17 00:00:00 2001
From: Peter Lacko 
Date: Fri, 13 May 2016 13:49:40 +0200
Subject: [PATCH] Ping module tests.

Tests for ping module rewritten using non-declarative way.
No new functionality has been added.
---
 ipatests/test_xmlrpc/test_ping_plugin.py | 49 
 1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_ping_plugin.py b/ipatests/test_xmlrpc/test_ping_plugin.py
index afd34fa1482735ac802b57a5d6cd387b18574f89..fea786093dc518f6c39496574de0e38e5d7e6c7e 100644
--- a/ipatests/test_xmlrpc/test_ping_plugin.py
+++ b/ipatests/test_xmlrpc/test_ping_plugin.py
@@ -1,7 +1,8 @@
 # Authors:
 #   Petr Viktorin 
+#   Peter Lacko   
 #
-# Copyright (C) 2012  Red Hat
+# Copyright (C) 2012, 2016  Red Hat
 # see file 'COPYING' for use and warranty information
 #
 # This program is free software; you can redistribute it and/or modify
@@ -21,34 +22,32 @@
 Test the `ipalib/plugins/ping.py` module, and XML-RPC in general.
 """
 
-from ipalib import errors, _
-from ipatests.util import Fuzzy
-from ipatests.test_xmlrpc.xmlrpc_test import Declarative
 import pytest
 
+from ipalib import errors, _
+from ipatests.test_xmlrpc.tracker.base import Tracker
+from ipatests.test_xmplrpc.xmlrpc_test import XMLRPC_test, raises_exact
+from ipatests.util import assert_equal, Fuzzy
+
 
 @pytest.mark.tier1
-class test_ping(Declarative):
+class TestPing(XMLRPC_test):
+"""Test functionality of the `ipalib/plugins/ping.py` module."""
+tracker = Tracker()
 
-tests = [
-dict(
-desc='Ping the server',
-command=('ping', [], {}),
-expected=dict(
-summary=Fuzzy('IPA server version .*. API version .*')),
-),
+def test_ping(self):
+"""Ping the server."""
+result = self.tracker.run_command('ping')
+exp = {'summary': Fuzzy('IPA server version .*. API version .*')}
+assert_equal(result, exp)
 
-dict(
-desc='Try to ping with an argument',
-command=('ping', ['bad_arg'], {}),
-expected=errors.ZeroArgumentError(name='ping'),
-),
+def test_ping_with_argument(self):
+"""Try to ping with an argument."""
+with raises_exact(errors.ZeroArgumentError(name='ping')):
+self.tracker.run_command('ping', ['argument'])
 
-dict(
-desc='Try to ping with an option',
-command=('ping', [], dict(bad_arg=True)),
-expected=errors.OptionError(_('Unknown option: %(option)s'),
-option='bad_arg'),
-),
-
-]
+def test_ping_with_option(self):
+"""Try to ping with an option."""
+with raises_exact(errors.OptionError(
+_('Unknown option: %(option)s'), option='bad_arg')):
+self.tracker.run_command('ping', bad_arg=True)
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Martin Babinsky]

On 05/13/2016 12:07 PM, Alexander Bokovoy wrote:

On Thu, 12 May 2016, Martin Babinsky wrote:

We should not allow anything after @ not belonging to the list of
realm domains. We also will need to extend realm domains to include
non-domain-based UPN suffixes. This actually flies close to what I need
to finish in my AD trust UPN patches, so I need to make sure we have the
same approach there.



Does this mean that we would not be able to implement e-mail as
principal alias [1]?

Why? I have not said that. I have said that you should not be able to
specify UPN with a suffix that does not belong to us. I don't want us to
allow to have Kerberos principals aliased to a trusted forest
namespaces as this is violation of a forest trust.

I see that my reading comprehension skills are slowly declining over 
time :D. I now hope that I understand what you mean: the alias suffix 
MUST NOT overlap with any UPN suffix of a trusted forest. We then need 
to add these checks onto alias manipulation commands and add this to the 
design document.



4. Will this RFE have any impact on AD trust (possibility of cross
realm
routing, RFC 6806 section 9)



IIRC there should be no impact on trusts.

We should never allow to specify alias from the realm we don't own. This
means the code needs to look into the namespaces associated with any of
the trusted domains and reject them.



So if I understand correctly we should reject tickets incoming from
trusted domains if they do not contain canonical principal name (i.e.
UPN)?

Again, no, this is not what I said. For UPNs from trusted domains I
already have code to detect them and issue correct referral for clients
to go to the proper KDC.

OK so it seems that we will need to coordinate our respective efforts.

--
Martin^3 Babinsky

--
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

Re: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command

[Rob Crittenden]

Martin Basti wrote:



On 12.05.2016 19:48, Rob Crittenden wrote:

Martin Basti wrote:



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



It occurs to me, won't this break the UI somewhat. Isn't Enrolled one
of the attributes on the default host page. Won't this show all hosts
as unenrolled?

rob


Hi Rob,

how exactly is webUI broken? I tried host section and it works. IIUC the
Web UI uses just host-find --pkey-only, which is not affected by this
change. For additional details webUI call host-show for each listed entry


You're right, it was based on a bad assumption on my part. I assumed the 
UI took the output of host_find and displayed the results. Next time 
I'll check first.


rob

--
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

Re: [Freeipa-devel] Reviving FreeIPA translations

[Martin Babinsky]

On 05/13/2016 01:32 PM, Martin Kosek wrote:

Hello,

As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat
employee, which of course does not mean he cannot contribute to the FreeIPA
project, but that he won't have as much time for contributions as previously.

One of Tomas' responsibilities was taking care of FreeIPA translations
(Translation Maintainer role). As far as I know, there 2 main tasks associated
with the Translation Maintainer role:

1) Periodically uploading new upstream strings to the FreeIPA translation
platform of choice, which is the Fedora Zanata instance:
https://fedora.zanata.org/project/view/freeipa
The upload should happen periodically, on the right occasions, so that the
translators (especially the French and Ukrainian translations which have 100%
translated) have sufficient time to translate strings for the next version and
do not have to translate it all in couple days before release. (This was one of
the feedback I heard recently).

2) Downloading translated strings, Tomas added a short HowTo to our Release 
page:
http://www.freeipa.org/page/Release#Translations

We will need a new volunteer who would help doing 1) and 2) for the planned
releases and making sure this process runs. The first task would be uploading
current strings in master as the next release is FreeIPA 4.4 planned for June,
so it may be nice to already upload new strings we have in FreeIPA already to
Zanata, so that they can be translated in sufficient time.

Volunteer(s)?

As part of the learning process, I think it would be useful to do more
documentation of the steps taken in every translation life-cycle, current HowTo
in Release page is rather vague. I for example did not find information how to
work with translation versions that I saw defined in Zanata (branching may work
similarly as in current FreeIPA git).


I also volunteer for the job.

--
Martin^3 Babinsky

--
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

Re: [Freeipa-devel] Reviving FreeIPA translations

[Martin Basti]

On 13.05.2016 13:32, Martin Kosek wrote:

Hello,

As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat
employee, which of course does not mean he cannot contribute to the FreeIPA
project, but that he won't have as much time for contributions as previously.

One of Tomas' responsibilities was taking care of FreeIPA translations
(Translation Maintainer role). As far as I know, there 2 main tasks associated
with the Translation Maintainer role:

1) Periodically uploading new upstream strings to the FreeIPA translation
platform of choice, which is the Fedora Zanata instance:
https://fedora.zanata.org/project/view/freeipa
The upload should happen periodically, on the right occasions, so that the
translators (especially the French and Ukrainian translations which have 100%
translated) have sufficient time to translate strings for the next version and
do not have to translate it all in couple days before release. (This was one of
the feedback I heard recently).

2) Downloading translated strings, Tomas added a short HowTo to our Release 
page:
http://www.freeipa.org/page/Release#Translations

We will need a new volunteer who would help doing 1) and 2) for the planned
releases and making sure this process runs. The first task would be uploading
current strings in master as the next release is FreeIPA 4.4 planned for June,
so it may be nice to already upload new strings we have in FreeIPA already to
Zanata, so that they can be translated in sufficient time.

Volunteer(s)?

As part of the learning process, I think it would be useful to do more
documentation of the steps taken in every translation life-cycle, current HowTo
in Release page is rather vague. I for example did not find information how to
work with translation versions that I saw defined in Zanata (branching may work
similarly as in current FreeIPA git).


I volunteer

Martin^2

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way

[Martin Basti]

On 13.05.2016 13:59, Peter Lacko wrote:

Hi,

Thanks again, will remember that. I also changed header to short one.

Peter


Whyyy?





- Original Message -
From: "Martin Basti" 
To: "Peter Lacko" , freeipa-devel@redhat.com
Sent: Tuesday, May 10, 2016 12:23:13 PM
Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a 
non-declarative way



On 28.04.2016 16:09, Martin Basti wrote:


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



Sorry I didn't noticed earlier, but your patch doesn't work under python3

  from xmlrpc_test import XMLRPC_test, raises_exact
E   ImportError: No module named 'xmlrpc_test'

You must use absolute import, not relative in py3

Martin^2


--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way

[Peter Lacko]

Hi,

Thanks again, will remember that. I also changed header to short one.

Peter


- Original Message -
From: "Martin Basti" 
To: "Peter Lacko" , freeipa-devel@redhat.com
Sent: Tuesday, May 10, 2016 12:23:13 PM
Subject: Re: [Freeipa-devel] [TESTS][PATCH] Ping module tests in a 
non-declarative way



On 28.04.2016 16:09, Martin Basti wrote:
>
>
> 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
>
>
Sorry I didn't noticed earlier, but your patch doesn't work under python3

 from xmlrpc_test import XMLRPC_test, raises_exact
E   ImportError: No module named 'xmlrpc_test'

You must use absolute import, not relative in py3

Martin^2
From 18c4b8233738d517e910fec6b53b4fb5149680a0 Mon Sep 17 00:00:00 2001
From: Peter Lacko 
Date: Fri, 13 May 2016 13:49:40 +0200
Subject: [PATCH] Ping module tests.

---
 ipatests/test_xmlrpc/test_ping_plugin.py | 63 
 1 file changed, 23 insertions(+), 40 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_ping_plugin.py b/ipatests/test_xmlrpc/test_ping_plugin.py
index afd34fa1482735ac802b57a5d6cd387b18574f89..6bb84d643331035d3b6a25a14f768dcdd2164666 100644
--- a/ipatests/test_xmlrpc/test_ping_plugin.py
+++ b/ipatests/test_xmlrpc/test_ping_plugin.py
@@ -1,54 +1,37 @@
-# Authors:
-#   Petr Viktorin 
 #
-# Copyright (C) 2012  Red Hat
-# see file 'COPYING' for use and warranty information
+# Copyright (C) 2016  FreeIPA Contributors see COPYING for license
 #
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see .
 
 """
 Test the `ipalib/plugins/ping.py` module, and XML-RPC in general.
 """
 
-from ipalib import errors, _
-from ipatests.util import Fuzzy
-from ipatests.test_xmlrpc.xmlrpc_test import Declarative
 import pytest
 
+from ipalib import errors, _
+from ipatests.test_xmlrpc.tracker.base import Tracker
+from ipatests.test_xmlrpc.xmlrpc_test import XMLRPC_test, raises_exact
+from ipatests.util import assert_equal, Fuzzy
+
 
 @pytest.mark.tier1
-class test_ping(Declarative):
+class TestPing(XMLRPC_test):
+"""Test functionality of the `ipalib/plugins/ping.py` module."""
+tracker = Tracker()
 
-tests = [
-dict(
-desc='Ping the server',
-command=('ping', [], {}),
-expected=dict(
-summary=Fuzzy('IPA server version .*. API version .*')),
-),
+def test_ping(self):
+"""Ping the server."""
+result = self.tracker.run_command('ping')
+exp = {'summary': Fuzzy('IPA server version .*. API version .*')}
+assert_equal(result, exp)
 
-dict(
-desc='Try to ping with an argument',
-command=('ping', ['bad_arg'], {}),
-expected=errors.ZeroArgumentError(name='ping'),
-),
+def test_ping_with_argument(self):
+"""Try to ping with an argument."""
+with raises_exact(errors.ZeroArgumentError(name='ping')):
+self.tracker.run_command('ping', ['argument'])
 
-dict(
-desc='Try to ping with an option',
-command=('ping', [], dict(bad_arg=True)),
-expected=errors.OptionError(_('Unknown option: %(option)s'),
-option='bad_arg'),
-),
-
-]
+def test_ping_with_option(self):
+"""Try to ping with an option."""
+with raises_exact(errors.OptionError(
+_('Unknown option: %(option)s'), option='bad_arg')):
+self.tracker.run_command('ping', bad_arg=True)
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [DESIGN] Time-Based HBAC Policies

[Stanislav Laznicka]

Hello list,

We had a discussion today over integrating the Time Rules into the CLI 
and WebUI and a problem came up with with the current solution. It seems 
that while having templating handled by CoSTemplates might be nice in 
terms of easy dereferencing on SSSD side (it's handled by the DS 
itself), it's not really much possible to pick one string from the 
multi-valued accesstime attribute of HBAC Rule object and modify it.


We were thinking of a solution discussed way earlier - having our own 
time rule objects that could be referenced from each HBAC rule. That 
way, any time rule could be modified easily. As the HBAC rules are 
cached on the SSSD side periodically using the deref plugin, there 
should be no problem of inconsistency with the server database.


The original reasoning pro and against the proposed solution could be 
found on the pad 
http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would 
be really nice to hear your opinions and ideas that could help us 
overcome this problem.


Thank you,
Standa

--
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

[Freeipa-devel] I plan to delete my FreeIPA COPR repos

[Martin Kosek]

Hi all,

When we were starting building FreeIPA in the Fedora COPR service [1], the
service did not support the organizations as it can do now and we did the
official repos in my personal name space [2] as I was the common denominator
for the project at the time.

However, since that time, COPR support supports organizations, we created the
FreeIPA organization [3] and do the official builds there. FreeIPA should have
all currently supported repos, usually around 4.3 and master FreeIPA versions.

Now, is anyone still using any of my FreeIPA related repos? Can I delete them
so that it does not confuse people about what is the official repo? Comparing
what I see in FreeIPA organization repos and personal repos, the FreeIPA
organization miss FreeIPA 4.0 and 4.1 versions, but I think these can be safely
removed.

So my current plan is to delete all my personal FreeIPA repos unless I hear any
blocker. So please holler if you depend on some of my repos.

[1] https://copr.fedorainfracloud.org
[2] https://copr.fedorainfracloud.org/coprs/mkosek/
[3] https://copr.fedorainfracloud.org/groups/g/freeipa/coprs/

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] Reviving FreeIPA translations

[Martin Kosek]

Hello,

As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat
employee, which of course does not mean he cannot contribute to the FreeIPA
project, but that he won't have as much time for contributions as previously.

One of Tomas' responsibilities was taking care of FreeIPA translations
(Translation Maintainer role). As far as I know, there 2 main tasks associated
with the Translation Maintainer role:

1) Periodically uploading new upstream strings to the FreeIPA translation
platform of choice, which is the Fedora Zanata instance:
https://fedora.zanata.org/project/view/freeipa
The upload should happen periodically, on the right occasions, so that the
translators (especially the French and Ukrainian translations which have 100%
translated) have sufficient time to translate strings for the next version and
do not have to translate it all in couple days before release. (This was one of
the feedback I heard recently).

2) Downloading translated strings, Tomas added a short HowTo to our Release 
page:
http://www.freeipa.org/page/Release#Translations

We will need a new volunteer who would help doing 1) and 2) for the planned
releases and making sure this process runs. The first task would be uploading
current strings in master as the next release is FreeIPA 4.4 planned for June,
so it may be nice to already upload new strings we have in FreeIPA already to
Zanata, so that they can be translated in sufficient time.

Volunteer(s)?

As part of the learning process, I think it would be useful to do more
documentation of the steps taken in every translation life-cycle, current HowTo
in Release page is rather vague. I for example did not find information how to
work with translation versions that I saw defined in Zanata (branching may work
similarly as in current FreeIPA git).

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [TESTS]{PATCH 0013] Maximum username length higher than 255 cannot be set

[Lenka Doudova]

Patch attached.

Lenka


From 2b6d0b4fe1a3f468e5125d521194fb10d4e654c1 Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Fri, 13 May 2016 12:56:03 +0200
Subject: [PATCH] Test: Maximum username length higher than 255 cannot be set

https://fedorahosted.org/freeipa/ticket/5774
---
 ipatests/test_xmlrpc/test_config_plugin.py | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/ipatests/test_xmlrpc/test_config_plugin.py b/ipatests/test_xmlrpc/test_config_plugin.py
index 2a9086f258149198a2df91562d1a972b848d92fa..b9992ded895df5aecfa488f9099ededb11291656 100644
--- a/ipatests/test_xmlrpc/test_config_plugin.py
+++ b/ipatests/test_xmlrpc/test_config_plugin.py
@@ -1,7 +1,8 @@
 # Authors:
 #   Petr Viktorin 
+#   Lenka Doudova 
 #
-# Copyright (C) 2010  Red Hat
+# Copyright (C) 2010, 2016  Red Hat
 # see file 'COPYING' for use and warranty information
 #
 # This program is free software; you can redistribute it and/or modify
@@ -151,4 +152,21 @@ class test_config(Declarative):
 ),
 ),
 
+dict(
+desc='Set maximum username length higher than limit of 255',
+command=('config_mod', [], dict(ipamaxusernamelength=256)),
+expected=errors.ValidationError(
+name='maxusername',
+error='can be at most 255'),
+),
+
+dict(
+desc='Set maximum username length equal to limit 255',
+command=('config_mod', [], dict(ipamaxusernamelength=255)),
+expected=dict(
+result=lambda d: d['ipamaxusernamelength'] == (u'255',),
+value=None,
+summary=None,
+),
+),
 ]
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Alexander Bokovoy]

On Thu, 12 May 2016, Martin Babinsky wrote:

We should not allow anything after @ not belonging to the list of
realm domains. We also will need to extend realm domains to include
non-domain-based UPN suffixes. This actually flies close to what I need
to finish in my AD trust UPN patches, so I need to make sure we have the
same approach there.



Does this mean that we would not be able to implement e-mail as 
principal alias [1]?

Why? I have not said that. I have said that you should not be able to
specify UPN with a suffix that does not belong to us. I don't want us to
allow to have Kerberos principals aliased to a trusted forest
namespaces as this is violation of a forest trust.


4. Will this RFE have any impact on AD trust (possibility of cross realm
routing, RFC 6806 section 9)



IIRC there should be no impact on trusts.

We should never allow to specify alias from the realm we don't own. This
means the code needs to look into the namespaces associated with any of
the trusted domains and reject them.



So if I understand correctly we should reject tickets incoming from 
trusted domains if they do not contain canonical principal name (i.e. 
UPN)?

Again, no, this is not what I said. For UPNs from trusted domains I
already have code to detect them and issue correct referral for clients
to go to the proper KDC.
--
/ Alexander Bokovoy

--
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

Re: [Freeipa-devel] Provisioning throughput

[Ludwig Krispenz]

On 05/13/2016 09:42 AM, Petr Spacek wrote:

On 13.5.2016 09:26, Martin Kosek wrote:

On 05/12/2016 04:16 PM, Ludwig Krispenz wrote:

On 05/12/2016 03:45 PM, Ludwig Krispenz wrote:

On 05/12/2016 02:16 PM, Petr Vobornik wrote:

On 05/10/2016 05:50 PM, thierry bordaz wrote:

On 05/05/2016 03:44 PM, Petr Vobornik wrote:

On 05/04/2016 02:20 PM, thierry bordaz wrote:

Hello,

   I have been doing some tests/measures using
https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py.

   The tool creates a set of typical users/hosts/groups... to
import with a
   ldapadd.

   I wrote down some finding in
http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins.


   I still have to do some cleanup around the performance but the
basic of a
   possible improvement is to do provisioning in several steps
(disabling
   plugins, provisioning, enabling plugin, running fixup tasks).

   Before going further in the design I wanted to share those ideas
and know if
   it raise any concern.

   thanks
   thierry


Hi Thierry,

Thanks for the analysis. Very nice.

Knowing this will help us suggesting workarounds also for old releases.

Couple questions:

Have you tested retrCL disabled with memberOf enabled. It seems that it
would eliminate 550K adds and 0.8M searches. What would be the time
improvement?

Do you know what is the time when memberof is enabled but slapi-nis and
retroCL are disabled?

The culprit of the performance issue is very likely related to SRCH
(internal) triggered by memberof.

If retroCL is disabled and memberof enabled, #SRCH is 13.8M.
If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is
14.8
When all of them are enabled the #SRCH is 15M.

You are right if retroCL is disabled the #ADD drops but it has no
significant effect on the duration.

ok, thanks for the analysis


Regarding the duration of the provisioning, values are not really stable
as performance of VM fluctuates. But as soon as memberof is enabled the
provisioning lasts > 4hours where the same provisioning lasts 6mins as
soon as memberof is disabled.

I need to confirm the average time for internal searches but assuming
1ms per SRCH it consumes >90% of the provisioning.



   From the text it was not clear to me, if you find or investigate
possible improvements in memberof plugin which would improve the
performance without stopping and starting DS.

As was discussed at mtg, have you tried if the DS restart is really
necessary?

memberof plugin can be enabled and disabled while the server is running, BUT
to achieve this the "enable-dynamic-plugins" feature has to be turned on. And
then any enable/disable of a plugin would try to do it dynamically an dnot
wait for the restart.
And I think not all plugins are able to handle this, TomasB was once working
on it for IPA plugins, but it was not completed as far as I know

but enabling dynamic plugins can be done without restart, so what can be done 
is.
- enable dynamic plugins
- disable memberof
- do some work
- enable memberof
- disable dynamic plugins

Please see
https://fedorahosted.org/freeipa/ticket/4203#comment:9
I do not think this will be that easy. We would first need to invest into
updating FreeIPA plugins to work with dynamic plugins setting and then we could
do things alike above.

It looks like that for FreeIPA 4.4, we will need to live with DS restart unless
there is some workaround...
couldn't the scenario I outline above with enabling dynamic plugins only 
temporary work, are there any attempts to enable/disable plugins during 
provisioning ? If that would be the case that would also require a restart

One more thing:

How does it affect topologies with replicas?

I might be wrong, but if memberOf is always computed locally then we have to
disable it on *all* replicas.

If we disabled it only on one replica and not others, the chosen replica would
be way faster than rest of the topology and I'm not sure what would happen
later on.
good point. we exclude memberof from replication as it is regenerated on 
every server, so each replica would suffer from the performance problem


Thierry, Ludwig, can you comment on this?



--
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

--
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

Re: [Freeipa-devel] Provisioning throughput

[Petr Spacek]

On 13.5.2016 09:26, Martin Kosek wrote:
> On 05/12/2016 04:16 PM, Ludwig Krispenz wrote:
>>
>> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote:
>>>
>>> On 05/12/2016 02:16 PM, Petr Vobornik wrote:
 On 05/10/2016 05:50 PM, thierry bordaz wrote:
>
> On 05/05/2016 03:44 PM, Petr Vobornik wrote:
>> On 05/04/2016 02:20 PM, thierry bordaz wrote:
>>> Hello,
>>>
>>>   I have been doing some tests/measures using
>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py.
>>>
>>>   The tool creates a set of typical users/hosts/groups... to
>>> import with a
>>>   ldapadd.
>>>
>>>   I wrote down some finding in
>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins.
>>>
>>>
>>>   I still have to do some cleanup around the performance but the
>>> basic of a
>>>   possible improvement is to do provisioning in several steps
>>> (disabling
>>>   plugins, provisioning, enabling plugin, running fixup tasks).
>>>
>>>   Before going further in the design I wanted to share those ideas
>>> and know if
>>>   it raise any concern.
>>>
>>>   thanks
>>>   thierry
>>>
>> Hi Thierry,
>>
>> Thanks for the analysis. Very nice.
>>
>> Knowing this will help us suggesting workarounds also for old releases.
>>
>> Couple questions:
>>
>> Have you tested retrCL disabled with memberOf enabled. It seems that it
>> would eliminate 550K adds and 0.8M searches. What would be the time
>> improvement?
>>
>> Do you know what is the time when memberof is enabled but slapi-nis and
>> retroCL are disabled?
> The culprit of the performance issue is very likely related to SRCH
> (internal) triggered by memberof.
>
> If retroCL is disabled and memberof enabled, #SRCH is 13.8M.
> If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is
> 14.8
> When all of them are enabled the #SRCH is 15M.
>
> You are right if retroCL is disabled the #ADD drops but it has no
> significant effect on the duration.
 ok, thanks for the analysis

> Regarding the duration of the provisioning, values are not really stable
> as performance of VM fluctuates. But as soon as memberof is enabled the
> provisioning lasts > 4hours where the same provisioning lasts 6mins as
> soon as memberof is disabled.
>
> I need to confirm the average time for internal searches but assuming
> 1ms per SRCH it consumes >90% of the provisioning.
>
>
>>   From the text it was not clear to me, if you find or investigate
>> possible improvements in memberof plugin which would improve the
>> performance without stopping and starting DS.
 As was discussed at mtg, have you tried if the DS restart is really
 necessary?
>>> memberof plugin can be enabled and disabled while the server is running, BUT
>>> to achieve this the "enable-dynamic-plugins" feature has to be turned on. 
>>> And
>>> then any enable/disable of a plugin would try to do it dynamically an dnot
>>> wait for the restart.
>>> And I think not all plugins are able to handle this, TomasB was once working
>>> on it for IPA plugins, but it was not completed as far as I know
>> but enabling dynamic plugins can be done without restart, so what can be 
>> done is.
>> - enable dynamic plugins
>> - disable memberof
>> - do some work
>> - enable memberof
>> - disable dynamic plugins
> 
> Please see
> https://fedorahosted.org/freeipa/ticket/4203#comment:9
> I do not think this will be that easy. We would first need to invest into
> updating FreeIPA plugins to work with dynamic plugins setting and then we 
> could
> do things alike above.
> 
> It looks like that for FreeIPA 4.4, we will need to live with DS restart 
> unless
> there is some workaround...

One more thing:

How does it affect topologies with replicas?

I might be wrong, but if memberOf is always computed locally then we have to
disable it on *all* replicas.

If we disabled it only on one replica and not others, the chosen replica would
be way faster than rest of the topology and I'm not sure what would happen
later on.

Thierry, Ludwig, can you comment on this?

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Provisioning throughput

[Martin Kosek]

On 05/12/2016 04:16 PM, Ludwig Krispenz wrote:
> 
> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote:
>>
>> On 05/12/2016 02:16 PM, Petr Vobornik wrote:
>>> On 05/10/2016 05:50 PM, thierry bordaz wrote:

 On 05/05/2016 03:44 PM, Petr Vobornik wrote:
> On 05/04/2016 02:20 PM, thierry bordaz wrote:
>> Hello,
>>
>>   I have been doing some tests/measures using
>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py.
>>
>>   The tool creates a set of typical users/hosts/groups... to
>> import with a
>>   ldapadd.
>>
>>   I wrote down some finding in
>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins.
>>
>>
>>   I still have to do some cleanup around the performance but the
>> basic of a
>>   possible improvement is to do provisioning in several steps
>> (disabling
>>   plugins, provisioning, enabling plugin, running fixup tasks).
>>
>>   Before going further in the design I wanted to share those ideas
>> and know if
>>   it raise any concern.
>>
>>   thanks
>>   thierry
>>
> Hi Thierry,
>
> Thanks for the analysis. Very nice.
>
> Knowing this will help us suggesting workarounds also for old releases.
>
> Couple questions:
>
> Have you tested retrCL disabled with memberOf enabled. It seems that it
> would eliminate 550K adds and 0.8M searches. What would be the time
> improvement?
>
> Do you know what is the time when memberof is enabled but slapi-nis and
> retroCL are disabled?
 The culprit of the performance issue is very likely related to SRCH
 (internal) triggered by memberof.

 If retroCL is disabled and memberof enabled, #SRCH is 13.8M.
 If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is
 14.8
 When all of them are enabled the #SRCH is 15M.

 You are right if retroCL is disabled the #ADD drops but it has no
 significant effect on the duration.
>>> ok, thanks for the analysis
>>>
 Regarding the duration of the provisioning, values are not really stable
 as performance of VM fluctuates. But as soon as memberof is enabled the
 provisioning lasts > 4hours where the same provisioning lasts 6mins as
 soon as memberof is disabled.

 I need to confirm the average time for internal searches but assuming
 1ms per SRCH it consumes >90% of the provisioning.


>   From the text it was not clear to me, if you find or investigate
> possible improvements in memberof plugin which would improve the
> performance without stopping and starting DS.
>>> As was discussed at mtg, have you tried if the DS restart is really
>>> necessary?
>> memberof plugin can be enabled and disabled while the server is running, BUT
>> to achieve this the "enable-dynamic-plugins" feature has to be turned on. And
>> then any enable/disable of a plugin would try to do it dynamically an dnot
>> wait for the restart.
>> And I think not all plugins are able to handle this, TomasB was once working
>> on it for IPA plugins, but it was not completed as far as I know
> but enabling dynamic plugins can be done without restart, so what can be done 
> is.
> - enable dynamic plugins
> - disable memberof
> - do some work
> - enable memberof
> - disable dynamic plugins

Please see
https://fedorahosted.org/freeipa/ticket/4203#comment:9
I do not think this will be that easy. We would first need to invest into
updating FreeIPA plugins to work with dynamic plugins setting and then we could
do things alike above.

It looks like that for FreeIPA 4.4, we will need to live with DS restart unless
there is some workaround...

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

Re: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command

[Martin Basti]

On 12.05.2016 19:48, Rob Crittenden wrote:

Martin Basti wrote:



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



It occurs to me, won't this break the UI somewhat. Isn't Enrolled one 
of the attributes on the default host page. Won't this show all hosts 
as unenrolled?


rob


Hi Rob,

how exactly is webUI broken? I tried host section and it works. IIUC the 
Web UI uses just host-find --pkey-only, which is not affected by this 
change. For additional details webUI call host-show for each listed entry


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