Re: [Freeipa-devel] [WIP] Thin client

2016-05-17 Thread Jan Cholasta 

On 16.5.2016 16:35, Martin Basti wrote:



On 09.05.2016 14:07, Jan Cholasta wrote:

On 6.5.2016 14:32, Martin Basti wrote:



On 28.04.2016 14:45, Jan Cholasta wrote:

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


I did not test it yet, I just checked the code

* automount: do not inherit automountlocation_tofiles from LDAPQuery *
LGTM

* dns: move all dnsrecord code called on client to a single class *
LGTM

* dns: do not rely on server data structures in code called on client *
1)
you forgot to increment VERSION


This was deliberate, as it will no longer be necessary to bump VERSION
for backward compatible changes after this whole patchset is merged.
But we're not there yet, so fixed.


How we should handle VERSION after your patches?


Otherwise LGTM

* otptoken: fix import of DN *
ACK

* otptoken_yubikey: fix otptoken_add_yubikey arguments *
1)
you forgot to increment VERSION


Fixed.



2)
Did you find out why this was issue?
-del answer['value']# Why does this cause an error if
omitted?
 -del answer['summary']  # Why does this cause an error if
omitted?


The command definition was not complete, it was missing has_output.



Otherwise LGTM

* vault: move client-side code to the module level *
LGTM

* vault: copy arguments of client commands from server counterparts *
1)
you forgot to increment Version


Fixed.



* ipalib: use relative imports for cross-plugin imports *
1) Missing explanation for future generations why this change is needed
in commit message


Fixed.



The other commits I will check later.
Martin^2



Okay. Thanks.



* frontend: remove the unused Command.soft_validate method
LGTM

* frontend: perform argument value validation only on server
LGTM

* frontend: do not forward argument defaults to server
I'm not a fan of returning  None in promt_param function, but I havent
found anything better to use.


It always returned None for unset params.


LGTM

* ipalib: optimize API.txt
this contains a lot of black magic, but because this is mainly copy of
current to proper places, LGTM


It's actually mostly cut-n-paste.



* makeaci: load additional plugins using API.add_module
Looks good, but I miss explanation why is this change needed


The next change would be impossible without this.



* plugable: replace API.import_plugins with new API.add_package
LGTM


* ipalib, ipaserver: migrate all plugins to Registry-based registration
ACK

* ipalib, ipaserver: fix incorrect API.register calls in docstrings
LGTM


* plugable: remove the unused deprecated API.register method
LGTM


* plugable: switch API to Registry-based plugin discovery
LGTM

* frontend: merge baseldap.CallbackRegistry into Command
LGTM

*frontend: move the interactive_prompt callback type to Command
 LGTM

Martin^2





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

[Freeipa-devel] Updated External EPEL CentOS 7 COPR builds are now available . . .

2016-05-17 Thread Matthew Harmsen 

An updated external EPEL CentOS 7 COPR repo is available now available which 
contains Dogtag 10.3.1 builds:

 *

   
https://copr.fedorainfracloud.org/coprs/g/pki/10.3.1/repo/epel-7/group_pki-10.3.1-epel-7.repo

   [group_pki-10.3.1]
   name=Copr repo for 10.3.1 owned by @pki
   
baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.1/epel-7-$basearch/
   skip_if_unavailable=True
   gpgcheck=1
   gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/10.3.1/pubkey.gpg
   enabled=1
   enabled_metadata=1

-- Matt

-- 
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] V4/Sub-CAs review

2016-05-17 Thread Nalin Dahyabhai 
On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote:
> > > 7) 
> > > 
> > > How is a certificate going to be requested from a specific sub-CA using 
> > > the
> > > getcert command?
> > > 
> > I added a preliminary design; add a new certmonger property and
> > corresponding getcert-request(1) option for specifying the target
> > CA.
> > 
> > http://www.freeipa.org/page/V4/Sub-CAs#Indicating_the_target_CA
> 
> LGTM.

Ditto.  I prefer handling it as a separate property over turning the
profile name into a tuple.

Cheers,

Nalin

-- 
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] feature template: "How to test" section renamed to "How to use"

2016-05-17 Thread Petr Vobornik 
New text:

"""
== How to Use ==

Easy to follow instructions how to use the new feature according to the
[[#Use_Cases|use cases]] described above. FreeIPA user needs to be able
to follow the steps and demonstrate the new features.

The chapter may be divided in sub-sections per [[#Use_Cases|Use Case]].
"""

Why this change?

The section was not filled in 46% of design pages in 4.4 release.

The section was always indented to help contributors, other than
developers with deep knowledge of FreeIPA internals, to understand how
the new feature is intended to be used when it is developed.

The name implied content similar to a test plan. My assumption is that
it is one of the reasons why it was not filled.

I also intend to add a comment with target audience to each section.

Comments welcome!

http://www.freeipa.org/page/Feature_template#How_to_Test
-- 
Petr Vobornik

-- 
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] [WIP] Thin client

2016-05-17 Thread David Kupka 

On 28/04/16 14:45, Jan Cholasta wrote:

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



Hi,
I have fought my way through the patch set up to "frontend: allow 
commands to have an argument named `name`" (including).
The code looks good to me but I haven't dive into parts that was pure 
Cut I assume that when it worked before it will still work.


Some problems pop out in tests:

user_plugin: http://paste.fedoraproject.org/367502/34888591/
This can be fixed with simple patch: 
http://paste.fedoraproject.org/367503/14634889/


With patch applied there are still some errors: 
http://paste.fedoraproject.org/367519/49007414/


--
David Kupka

--
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] V4/Sub-CAs review

2016-05-17 Thread Fraser Tweedale 
On Tue, May 17, 2016 at 01:28:15PM +0200, Jan Cholasta wrote:
> On 10.5.2016 12:36, Fraser Tweedale wrote:
> > Honza, thanks for the review.  Comments inline.
> > 
> > Copy Nalin, re certmonger discussion at the very bottom.
> > 
> > On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:
> > > Hi,
> > > 
> 
> 8<--
> 
> > > 2) 
> > > 
> > > It should be mentioned here that the primary CA is also handled by this
> > > plugin.
> > > 
> > > I would like to propose two additional fields:
> > > 
> > >   * subject (required) - subject name of the CA, to be able to look up
> > > sub-CA that issued a certificate from its issuer name.
> > > 
> > >   * issuer_ca (optional) - name of the sub-CA which issued certificate for
> > > this CA, to have information about the sub-CA hierarchy. If there is no
> > > sub-CA entry for the issuer, it would be unset.
> > > 
> > These data exist in the Dogtag database.  Adding them to IPA might
> > be useful for avoiding round trips so it is probably worth doing,
> > but are you aware of use cases that would absolutely require them?
> 
> As for subject, we are adding the ability to look up information about
> arbitrary certificates to cert-{show,find} as part of
> . Part of this information
> should be whether the certificate was issued by our CA and what CA it was,
> so that the web UI can present an appropriate "revoke certificate" button
> for the certificate.
> 
> As for issuer CA, I believe we need it to fix automatic CA certificate
> renewal. The current renewal code uses virtual "profiles" to handle CA
> certificate renewal, but that turned out to be an issue, especially with
> externally signed CA certificates:
> . Instead it could use
> the issuer CA information from LDAP to figure out what needs to be done.
> (Note that during the renewal, Dogtag is offline.)
> 
> Also, both the attributes should be included for compatibility with external
> CAs. At this point, I think it's only a matter of time when support for them
> will be added (there were already several requests for such a feature), and
> I would very much prefer to have to maintain only a single code path for the
> generic stuff (which includes both of the attributes), instead of one for
> Dogtag and one for external CAs.
> 
OK, I'll add issuer DN and subject DN attributes to the ipaCa
objectClass.

> > 
> > > 
> 
> 8<--
> 
> > > 4) 
> > > 
> > > """
> > > For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
> > > implements the KeyRetriever interface. It invokes a Python script that
> > > performs the retrieval, reusing existing FreeIPA Custodia client code.
> > > """
> > > 
> > > Will this be distributed with Dogtag or with IPA?
> > > 
> > It's shipped in Dogtag.
> > 
> > > The Python script bit sounds like an implementation detail rather than an
> > > actual design. Ideally the whole thing would be done in Java, right?
> > > 
> > I removed the script from the design page (it had changed, though
> > not dramatically).  It is written in Python so that we can reuse the
> > CustodiaClient.
> 
> I figured as much. My point is that whether you are executing an external
> binary or using native code is an implementation detail, so it should not be
> in the "Design" section, but rather the "Implementation" section.
> 
Fair point; I'll move what remains the Implementation section.

> > 
> > > """
> > > The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
> > > and shall be executed as pkiuser.
> > > """
> > > 
> > > Could you please use a subdirectory? Like /usr/libexec/pki (if the script 
> > > is
> > > going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
> > > going to be distributed with IPA).
> > > 
> > What is the rationale - is it a packaging guideline or just common
> > sense?
> 
> I'm not sure if it's an actual guideline, but IMHO it's definitely common
> sense - I don't think littering the global namespace (i.e. /usr/libexec) is
> ever preferable to keeping your stuff in your own namespace.
> 
I'll drop the script in a subdir.  While I'm at it, I think I will
move it to the IPA codebase, to improve locality of the Python code.
e.g. if CustodiaClient API or any other IPA Python API changes, the
code in pki repo will be too easily missed.

> > 
> > > """
> > > pkiuser does not have read access to either of these locations, so a new
> > > service principal shall be created for each Dogtag CA instance for the
> > > purpose of authenticating to Custodia and retrieving lightweight CA 
> > > private
> > > keys. Its principal name shall be dogtag-ipa-custodia/@REALM. 
> > > Its
> > > keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser 
> > > and
> > > mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab

Re: [Freeipa-devel] [PATCH] 0001 (update 2) provide more information for "ipa cert-revoke -h"

2016-05-17 Thread Gabe Alford 
Patrice,

Can you please send rebased version of this patch?

Thanks,

Gabe

On Fri, May 6, 2016 at 6:45 AM, Martin Basti  wrote:

>
>
> On 04.05.2016 14:30, Gabe Alford wrote:
>
> On Wed, May 4, 2016 at 1:35 AM, Patrice Duc-Jacquet < 
> patdu...@gmail.com> wrote:
>
>> Hi everyone
>>
>> this is a second update that take into account review feedback.
>>
>> In case the proposal fix is K what are the next step to commit this
>> change. I'm not sure to really understand the process. Thanks and regards
>>
>
> If the fix is good, you receive an ack and a core member of the FreeIPA
> team will take your ack'ed patch and push it to the official git repository.
>
> ACK from me
>
> Gabe
>
> Pat
>>
>>
>> --
>> 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
>>
>
>
>
> Hello, I agree with ACk, but I cannot apply the patch using git am -3, can
> you please send rebased version?
>
> 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] [DESIGN-REVIEW] V4/Manage_replication_topology_4_4

2016-05-17 Thread Oleg Fayans 
Sorry, I forgot to list the tickets themselves

On 05/16/2016 03:48 PM, Oleg Fayans wrote:
> Hi,
> 
> The design is OK, the onlz thing that is missing is a HowToTest section
> in track tickets [1] and [2] about clean-dangling-ruvs and
> abort-clean-ruv respectively. It would really help if these tickets had
> detailed steps to test (in case of dangling RUV's - steps to generate them)
> 
[1] https://fedorahosted.org/freeipa/ticket/5411
[2] https://fedorahosted.org/freeipa/ticket/5396

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
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] V4/Sub-CAs review

2016-05-17 Thread Jan Cholasta 

On 10.5.2016 12:36, Fraser Tweedale wrote:

Honza, thanks for the review.  Comments inline.

Copy Nalin, re certmonger discussion at the very bottom.

On Mon, May 09, 2016 at 08:54:32AM +0200, Jan Cholasta wrote:

Hi,



8<--


2) 

It should be mentioned here that the primary CA is also handled by this
plugin.

I would like to propose two additional fields:

  * subject (required) - subject name of the CA, to be able to look up
sub-CA that issued a certificate from its issuer name.

  * issuer_ca (optional) - name of the sub-CA which issued certificate for
this CA, to have information about the sub-CA hierarchy. If there is no
sub-CA entry for the issuer, it would be unset.


These data exist in the Dogtag database.  Adding them to IPA might
be useful for avoiding round trips so it is probably worth doing,
but are you aware of use cases that would absolutely require them?


As for subject, we are adding the ability to look up information about 
arbitrary certificates to cert-{show,find} as part of 
. Part of this information 
should be whether the certificate was issued by our CA and what CA it 
was, so that the web UI can present an appropriate "revoke certificate" 
button for the certificate.


As for issuer CA, I believe we need it to fix automatic CA certificate 
renewal. The current renewal code uses virtual "profiles" to handle CA 
certificate renewal, but that turned out to be an issue, especially with 
externally signed CA certificates: 
. Instead it could 
use the issuer CA information from LDAP to figure out what needs to be 
done. (Note that during the renewal, Dogtag is offline.)


Also, both the attributes should be included for compatibility with 
external CAs. At this point, I think it's only a matter of time when 
support for them will be added (there were already several requests for 
such a feature), and I would very much prefer to have to maintain only a 
single code path for the generic stuff (which includes both of the 
attributes), instead of one for Dogtag and one for external CAs.








8<--


4) 

"""
For FreeIPA, Dogtag will provide the IPACustodiaKeyRetriever class, which
implements the KeyRetriever interface. It invokes a Python script that
performs the retrieval, reusing existing FreeIPA Custodia client code.
"""

Will this be distributed with Dogtag or with IPA?


It's shipped in Dogtag.


The Python script bit sounds like an implementation detail rather than an
actual design. Ideally the whole thing would be done in Java, right?


I removed the script from the design page (it had changed, though
not dramatically).  It is written in Python so that we can reuse the
CustodiaClient.


I figured as much. My point is that whether you are executing an 
external binary or using native code is an implementation detail, so it 
should not be in the "Design" section, but rather the "Implementation" 
section.





"""
The Python script shall be installed at /usr/libexec/pki-ipa-retrieve-key
and shall be executed as pkiuser.
"""

Could you please use a subdirectory? Like /usr/libexec/pki (if the script is
going to be distributed with Dogtag) or /usr/libexec/ipa (if the script is
going to be distributed with IPA).


What is the rationale - is it a packaging guideline or just common
sense?


I'm not sure if it's an actual guideline, but IMHO it's definitely 
common sense - I don't think littering the global namespace (i.e. 
/usr/libexec) is ever preferable to keeping your stuff in your own 
namespace.





"""
pkiuser does not have read access to either of these locations, so a new
service principal shall be created for each Dogtag CA instance for the
purpose of authenticating to Custodia and retrieving lightweight CA private
keys. Its principal name shall be dogtag-ipa-custodia/@REALM. Its
keytab and Custodia keys shall be stored with ownership pkiuser:pkiuser and
mode 0600 at /etc/pki/pki-tomcat/dogtag-ipa-custodia.keytab and
/etc/pki/pki-tomcat/dogtag-ipa-custodia.keys respectively.
"""

Don't forget to update this paragraph with the new principal name.


Thanks, I updated it.



5) 

"""
A CA object for the top-level CA will initially be created, with DN
cn=.,ou=cas,cn=ca,$SUFFIX.
"""

I would rather not use punctuation for the short name, as it can be easily
overlooked (think logs). (Also it should be '/' if anything, not '.', which
usually means "current".)

Above you stated that the subject name will be derived from the short name
of the sub-CA. The top-level CA has subject name of the form "CN=Certificate
Authority,$SUBJECT_BASE", so its short name should be "Certificate
Authority".



This section was also part of the old design.  The entry for the
host authority has ``ipaUniqueId=...`` as rightmost RDN,

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

2016-05-17 Thread Petr Spacek 
On 13.5.2016 13:50, Stanislav Laznicka wrote:
> 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.

Could you be more specific?

AFAIK LDAP protocol allows this. Where is the problem?

Petr^2 Spacek

> 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] [PATCH] 0002 Incorrect message when KRA already installed

2016-05-17 Thread Patrice Duc-Jacquet 
Hi everyone

Please see attached candidate patch for ticket

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

Thanks and regards

Pat
From b87f48165361199d140be7bea96f07390d7d500f Mon Sep 17 00:00:00 2001
From: Patrice Duc-Jacquet 
Date: Tue, 17 May 2016 10:35:42 +0200
Subject: [PATCH] Incorrect message when KRA already installed

When trying to install a second time KRA, in case domain-level=0 the error lessage is not correct. It mentions :

 "ipa-kra-install: error: A replica file is required."

Note that this behavior is not observed if domain-level=1
The subject of the fix consist in checking that KRA is not already installed before going ahead in the installation process.

Tests done: I have made the following  tests in bot domain-level=0 and domain-level=1 :
 - Install KRA (check it is correctly installed),
 - Install KRA a second time (check that the correct error message is raised)
 - uninstall KRA (check that it is correctly uninstalled)
 - Install KRA again (check that it is correctly installed)
---
 ipaserver/install/ipa_kra_install.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ipaserver/install/ipa_kra_install.py b/ipaserver/install/ipa_kra_install.py
index 33c1072db87d0f93a9acc59a88272e56332cbc04..9cb5f0fcc45d0c6ddb68456ee0b6d9a1fb2a2de1 100644
--- a/ipaserver/install/ipa_kra_install.py
+++ b/ipaserver/install/ipa_kra_install.py
@@ -158,6 +158,11 @@ class KRAInstaller(KRAInstall):
 raise RuntimeError("Dogtag CA is not installed. "
"Please install the CA first")
 
+# check if KRA is not already installed
+_kra = krainstance.KRAInstance(api)
+if _kra.is_installed():
+raise admintool.ScriptError("KRA already installed")
+
 # this check can be done only when CA is installed
 self.installing_replica = dogtaginstance.is_installing_replica("KRA")
 self.options.promote = False
-- 
2.5.0

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

Re: [Freeipa-devel] Provisioning throughput

2016-05-17 Thread thierry bordaz 



On 05/13/2016 10:18 AM, Ludwig Krispenz wrote:


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


Right, that is a very good point.
Provisioning will be slow (through direct update or replicated update) 
as soon as memberof is enabled.
An option is to disable memberof only on the server receiving direct 
upates, provisioning will be fast, then let the topology converge with 
slow replication of the provisioned entries (fixup updates will not be 
replicated).
An other option is to disable memberof on all replica, do the 
provisioning. Then run fixup on all the replicas. That means we have a 
mechanism to detect that all provisioned entries have been replicated 
before running fixup.




Thierry, Ludwig, can you comment on this?





--
Manage your subscription for the Freeipa-devel mailing list: