Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
On Mon, 31 Oct 2011, Jan Cholasta wrote:
Dne 31.10.2011 13:19, Alexander Bokovoy napsal(a):
On Mon, 31 Oct 2011, Jan Cholasta wrote:
Added finalization for __call__ and the check for CLI. Patch attached.
ACK from my side but see below.
+def __getattribute__(self, name):
+if not name.startswith('_Plugin__') and not
name.startswith('_ReadOnly__') and name != 'finalize_late':
+self.finalize_late()
+return object.__getattribute__(self, name)
Could you get faster than three string comparisons? As
__getattribute__ is fairly often called it would make sense to keep
these operations to absolute minimum.
Is there any noticable slowdown?
Yes. Now I have different patch to solve this issue that avoids using
__getattribute__. Instead, it sets a trap on attributes that are
changed by finalization process and when they are accessed first time,
the trap forces instance to finalize. As result, the attributes get
their proper values and traps are removed, no performance costs
anymore.
For Commands one additional check is done on __call__() method to
verify that we are indeed finalized before execution proceeds. It is a
safety net here.
Performance is not bad:
1. Before the patch
[root@vm-114 ipalib]# time ipa /dev/null
real 0m1.101s
user 0m0.930s
sys 0m0.151s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m3.132s
user 0m0.983s
sys 0m0.135s
2. With patch
[root@vm-114 ipalib]# patch -p2 ~/speedup.patch
patching file frontend.py
patching file plugable.py
[root@vm-114 ipalib]# time ipa /dev/null
real 0m0.563s
user 0m0.438s
sys 0m0.098s
[root@vm-114 ipalib]# time ipa /dev/null
real 0m0.521s
user 0m0.412s
sys 0m0.100s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m1.069s
user 0m0.445s
sys 0m0.111s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m0.840s
user 0m0.425s
sys 0m0.126s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m0.816s
user 0m0.432s
sys 0m0.119s
Patch is attached.
--
/ Alexander Bokovoy
From d28b13f9de7d41b25c51aa7c26ca2b09f8671e6b Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Wed, 2 Nov 2011 12:24:20 +0200
Subject: [PATCH] Perform late initialization of FreeIPA plugins
https://fedorahosted.org/freeipa/ticket/1336
When plugins are loaded, instances of the provided objects and commands
are registered in the API instance. The patch changes finalization process
to apply on first access to the Command instance that would cause either
access to properties (args, options, params) or execution of the command
itself.
The patch gives 2x boost for client-side commands like help and 3x boost
for commands that go to the server side. All performance numbers are
approximate and may vary a lot.
---
ipalib/frontend.py | 20
ipalib/plugable.py |6 ++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index
61e7f493f8a8e30a1a189d06cd6a69893319deaf..a3fed2bbf0fb4631e238fad9892fb8129dbd6ca1
100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -404,6 +404,22 @@ class Command(HasParam):
msg_summary = None
msg_truncated = _('Results are truncated, try a more specific search')
+def __init__(self):
+class Finalizer(object):
+def __init__(self, master, attr):
+self.master = master
+self.attr = attr
+
+def __call__(self):
+self.master.finalize()
+# At this point master.attr points to proper object
+return self.master.__dict__[self.attr]()
+
+self.args = Finalizer(self, 'args')
+self.options = Finalizer(self, 'options')
+self.params = Finalizer(self, 'params')
+super(Command, self).__init__()
+
def __call__(self, *args, **options):
Perform validation and then execute the command.
@@ -411,6 +427,10 @@ class Command(HasParam):
If not in a server context, the call will be forwarded over
XML-RPC and the executed an the nearest IPA server.
+# Plugin instance must be finalized before we get to execution
+if not self.__dict__['_Plugin__finalized']:
+self.finalize()
+
params = self.args_options_2_params(*args, **options)
self.debug(
'raw: %s(%s)', self.name, ', '.join(self._repr_iter(**params))
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index
b0e415656e0428eb164c35a2862fcfbf50883381..ee29929c0a6de776724659e03194973937111868
100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -207,6 +207,7 @@ class Plugin(ReadOnly):
self.label
)
)
+self.__finalized = False
def __get_api(self):
@@ -220,6 +221,7 @@ class
Re: [Freeipa-devel] [PATCH] 029 Page is cleared before it is visible
On 11/01/2011 11:31 PM, Endi Sukma Dewata wrote:
On 11/1/2011 7:37 AM, Petr Vobornik wrote:
1. The new clear() method is called during refresh(), so the facet with
the old data is still shown for a brief moment before it's cleared.
The clear() should be called before show(). However, if the pkey/filter
is unchanged (check using needs_update()) we just need to show() the
facet, no need to clear() and refresh() again. The above logic needs to
be fixed.
Changed.
The we will need to override the needs_update() for search and
association facets because the default one always returns true.
Done
On the second thought, this might not be sufficient to detect the
changes in the list page. Try changing an attribute in an entry, then go
back to the list page, the list page will not show the updated attribute
because the filter is not changed.
I think we should remove the needs_update() from the search facet so it
will always refresh, but we probably can keep it for association facet.
What do you think? Sorry about that.
Changed to refresh always. Clearing always or not clearing at all seems
wrong. When the pkey doesn't change, only small portion of values
can/will change, so it's probably not so wrong to show the previous
list, but when the filter is changed the results will be probably much
different and the clear is needed. What do you think? - Added
needs_clear method which clears if the filter changes (basically renamed
needs_update).
There are probably better solutions, but let's do this separately.
In future we can build a mechanism for subscribing to events from
different facets and doing appropriate actions.
Something like:
var refresh_search_on_save = function(spec) {
var that = {};
that.register = function() {
that.entity = IPA.get_entity(spec.entity);
that.details_facet = that.entity.get_facet(spec.facet ||
'details');
that.search_facet = that.entity.get_facet(spec.search_facet ||
'search');
that.details_facet.on_save.attach(that.on_save, that);
};
that.on_save = function() {
that.search_facet.set_needs_refresh(true);
};
return that;
};
So the facets won't be dependent on each other.
5) Added ID generator, using in radio_widget, same reason as #4.
The get_id() method (might be better called get_next_id() or
generate_id()) doesn't really need to take a widget parameter. The
id_count should be unique enough. If you want, it can take an optional
prefix so the ID will be like 'prefix-id'. It will make it more
usable for other things not just widgets.
changed to get_next_id(prefix).
9. The facet header's clear() calls load() with empty data. The load()
will display the facet group label using facet's pkey. Since this is
called before refresh(), sometimes you'll see 'undefined' or the old
pkey. I think the code in entity.js:351-354 should check if the data is
empty it should clear the label.
Fixed
10. Instead of emptying button label in host.js:731-732, it's probably
better to reset it to its initial value:
var password_label = $('.button-label', that.set_password_button);
password_label.text(IPA.messages.objects.host.password_set_button);
Seems more proper to clean the label. If the label is set to
...host.password_set_button it will always shows before load set OTP
after load it can change to reset OTP which is wrong behavior.
--
Petr Vobornik
From b239957ae77de87bab163f3f43ca337d7f7bee33 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 24 Oct 2011 14:53:29 +0200
Subject: [PATCH] Page is cleared before it is visible
https://fedorahosted.org/freeipa/ticket/1459
Changes:
* added clear method to widgets, section, search, details, association facets
* clear and refresh method in facet are called only if key/filter was changed
* added id generator for widgets
---
install/ui/association.js | 21 ---
install/ui/certificate.js |9 +
install/ui/details.js | 21 ++--
install/ui/entity.js | 28 +---
install/ui/host.js| 12 +++
install/ui/search.js | 20 +--
install/ui/service.js |5 +++
install/ui/user.js|5 +++
install/ui/widget.js | 80 +++--
9 files changed, 173 insertions(+), 28 deletions(-)
diff --git a/install/ui/association.js b/install/ui/association.js
index d3b66132d5043b0dfe60b8847896e9f27f676059..d3d6b124b431414ff04fad05b16dbb972b38c2b7 100644
--- a/install/ui/association.js
+++ b/install/ui/association.js
@@ -871,8 +871,6 @@ IPA.association_facet = function (spec) {
that.facet_create_header(container);
-that.pkey = IPA.nav.get_state(that.entity.name+'-pkey');
-
if (!that.read_only) {
that.remove_button = IPA.action_button({
name: 'remove',
@@ -908,12 +906,13 @@ IPA.association_facet = function (spec) {
Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
On Wed, 2011-11-02 at 12:42 +0200, Alexander Bokovoy wrote:
On Mon, 31 Oct 2011, Jan Cholasta wrote:
Dne 31.10.2011 13:19, Alexander Bokovoy napsal(a):
On Mon, 31 Oct 2011, Jan Cholasta wrote:
Added finalization for __call__ and the check for CLI. Patch attached.
ACK from my side but see below.
+def __getattribute__(self, name):
+if not name.startswith('_Plugin__') and not
name.startswith('_ReadOnly__') and name != 'finalize_late':
+self.finalize_late()
+return object.__getattribute__(self, name)
Could you get faster than three string comparisons? As
__getattribute__ is fairly often called it would make sense to keep
these operations to absolute minimum.
Is there any noticable slowdown?
Yes. Now I have different patch to solve this issue that avoids using
__getattribute__. Instead, it sets a trap on attributes that are
changed by finalization process and when they are accessed first time,
the trap forces instance to finalize. As result, the attributes get
their proper values and traps are removed, no performance costs
anymore.
For Commands one additional check is done on __call__() method to
verify that we are indeed finalized before execution proceeds. It is a
safety net here.
Performance is not bad:
1. Before the patch
[root@vm-114 ipalib]# time ipa /dev/null
real 0m1.101s
user 0m0.930s
sys 0m0.151s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m3.132s
user 0m0.983s
sys 0m0.135s
2. With patch
[root@vm-114 ipalib]# patch -p2 ~/speedup.patch
patching file frontend.py
patching file plugable.py
[root@vm-114 ipalib]# time ipa /dev/null
real 0m0.563s
user 0m0.438s
sys 0m0.098s
[root@vm-114 ipalib]# time ipa /dev/null
real 0m0.521s
user 0m0.412s
sys 0m0.100s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m1.069s
user 0m0.445s
sys 0m0.111s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m0.840s
user 0m0.425s
sys 0m0.126s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m0.816s
user 0m0.432s
sys 0m0.119s
Patch is attached.
Hmm, this looks impressive! It would brings us considerably faster CLI
calls.
And again, I would feel much safer if we do these optimizations only
for CLI and let server do all the initialization right on start.
Unit tests show few errors though. But these may not be the actual
problems in the patch, it may be just wrong test assumptions:
==
FAIL: Doctest: ipalib.crud
--
Traceback (most recent call last):
File /usr/lib64/python2.7/doctest.py, line 2166, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for ipalib.crud
File /home/mkosek/freeipa/ipalib/crud.py, line 19, in crud
--
File /home/mkosek/freeipa/ipalib/crud.py, line 76, in ipalib.crud
Failed example:
list(api.Command.user_add.args)
Exception raised:
Traceback (most recent call last):
File /usr/lib64/python2.7/doctest.py, line 1254, in __run
compileflags, 1) in test.globs
File doctest ipalib.crud[13], line 1, in module
list(api.Command.user_add.args)
TypeError: 'Finalizer' object is not iterable
--
File /home/mkosek/freeipa/ipalib/crud.py, line 78, in ipalib.crud
Failed example:
list(api.Command.user_add.options)
Exception raised:
Traceback (most recent call last):
File /usr/lib64/python2.7/doctest.py, line 1254, in __run
compileflags, 1) in test.globs
File doctest ipalib.crud[14], line 1, in module
list(api.Command.user_add.options)
TypeError: 'Finalizer' object is not iterable
--
File /home/mkosek/freeipa/ipalib/crud.py, line 94, in ipalib.crud
Failed example:
list(api.Command.user_show.args)
Exception raised:
Traceback (most recent call last):
File /usr/lib64/python2.7/doctest.py, line 1254, in __run
compileflags, 1) in test.globs
File doctest ipalib.crud[15], line 1, in module
list(api.Command.user_show.args)
TypeError: 'Finalizer' object is not iterable
--
File /home/mkosek/freeipa/ipalib/crud.py, line 96, in ipalib.crud
Failed example:
list(api.Command.user_show.options)
Exception raised:
Traceback (most recent call last):
File /usr/lib64/python2.7/doctest.py, line 1254, in __run
compileflags, 1) in test.globs
File doctest ipalib.crud[16], line 1, in module
Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
On Wed, 02 Nov 2011, Martin Kosek wrote: Hmm, this looks impressive! It would brings us considerably faster CLI calls. And again, I would feel much safer if we do these optimizations only for CLI and let server do all the initialization right on start. Well, that could be done in API.finalize() as we would know context at that point already. Unit tests show few errors though. But these may not be the actual problems in the patch, it may be just wrong test assumptions: == FAIL: Doctest: ipalib.crud -- Traceback (most recent call last): File /usr/lib64/python2.7/doctest.py, line 2166, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for ipalib.crud File /home/mkosek/freeipa/ipalib/crud.py, line 19, in crud these are examples that doctest extracts and tries to run. I can make Finalizer class iterable and that will solve all these: -- File /home/mkosek/freeipa/ipalib/crud.py, line 76, in ipalib.crud Failed example: list(api.Command.user_add.args) Exception raised: Traceback (most recent call last): File /usr/lib64/python2.7/doctest.py, line 1254, in __run compileflags, 1) in test.globs File doctest ipalib.crud[13], line 1, in module list(api.Command.user_add.args) TypeError: 'Finalizer' object is not iterable -- File /home/mkosek/freeipa/ipalib/crud.py, line 78, in ipalib.crud Failed example: list(api.Command.user_add.options) Exception raised: Traceback (most recent call last): File /usr/lib64/python2.7/doctest.py, line 1254, in __run compileflags, 1) in test.globs File doctest ipalib.crud[14], line 1, in module list(api.Command.user_add.options) TypeError: 'Finalizer' object is not iterable -- File /home/mkosek/freeipa/ipalib/crud.py, line 94, in ipalib.crud Failed example: list(api.Command.user_show.args) Exception raised: Traceback (most recent call last): File /usr/lib64/python2.7/doctest.py, line 1254, in __run compileflags, 1) in test.globs File doctest ipalib.crud[15], line 1, in module list(api.Command.user_show.args) TypeError: 'Finalizer' object is not iterable -- File /home/mkosek/freeipa/ipalib/crud.py, line 96, in ipalib.crud Failed example: list(api.Command.user_show.options) Exception raised: Traceback (most recent call last): File /usr/lib64/python2.7/doctest.py, line 1254, in __run compileflags, 1) in test.globs File doctest ipalib.crud[16], line 1, in module list(api.Command.user_show.options) TypeError: 'Finalizer' object is not iterable -- File /home/mkosek/freeipa/ipalib/crud.py, line 114, in ipalib.crud Failed example: list(api.Command.user_add.output_params) Exception raised: Traceback (most recent call last): File /usr/lib64/python2.7/doctest.py, line 1254, in __run compileflags, 1) in test.globs File doctest ipalib.crud[18], line 1, in module list(api.Command.user_add.output_params) TypeError: 'NoneType' object is not iterable Output params could be run through finalizer as well. -- File /home/mkosek/freeipa/ipalib/crud.py, line 116, in ipalib.crud Failed example: list(api.Command.user_show.output_params) Exception raised: Traceback (most recent call last): File /usr/lib64/python2.7/doctest.py, line 1254, in __run compileflags, 1) in test.globs File doctest ipalib.crud[19], line 1, in module list(api.Command.user_show.output_params) TypeError: 'NoneType' object is not iterable Same here. Errors below are about assumptions that before finalizing args, options == FAIL: Test the ``ipalib.frontend.Command.args`` instance attribute. -- Traceback (most recent call last): File /usr/lib/python2.7/site-packages/nose/case.py, line 187, in runTest self.test(*self.arg) File /home/mkosek/freeipa/tests/test_ipalib/test_frontend.py, line 255, in test_args assert self.cls().args is None AssertionError == FAIL: Test the `ipalib.frontend.Command.get_output_params` method. --
Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
Dne 2.11.2011 11:42, Alexander Bokovoy napsal(a):
On Mon, 31 Oct 2011, Jan Cholasta wrote:
Dne 31.10.2011 13:19, Alexander Bokovoy napsal(a):
On Mon, 31 Oct 2011, Jan Cholasta wrote:
Added finalization for __call__ and the check for CLI. Patch attached.
ACK from my side but see below.
+def __getattribute__(self, name):
+if not name.startswith('_Plugin__') and not
name.startswith('_ReadOnly__') and name != 'finalize_late':
+self.finalize_late()
+return object.__getattribute__(self, name)
Could you get faster than three string comparisons? As
__getattribute__ is fairly often called it would make sense to keep
these operations to absolute minimum.
Is there any noticable slowdown?
Yes. Now I have different patch to solve this issue that avoids using
__getattribute__. Instead, it sets a trap on attributes that are
changed by finalization process and when they are accessed first time,
the trap forces instance to finalize. As result, the attributes get
their proper values and traps are removed, no performance costs
anymore.
For Commands one additional check is done on __call__() method to
verify that we are indeed finalized before execution proceeds. It is a
safety net here.
Performance is not bad:
1. Before the patch
[root@vm-114 ipalib]# time ipa/dev/null
real 0m1.101s
user 0m0.930s
sys 0m0.151s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m3.132s
user 0m0.983s
sys 0m0.135s
2. With patch
[root@vm-114 ipalib]# patch -p2~/speedup.patch
patching file frontend.py
patching file plugable.py
[root@vm-114 ipalib]# time ipa/dev/null
real 0m0.563s
user 0m0.438s
sys 0m0.098s
[root@vm-114 ipalib]# time ipa/dev/null
real 0m0.521s
user 0m0.412s
sys 0m0.100s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m1.069s
user 0m0.445s
sys 0m0.111s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m0.840s
user 0m0.425s
sys 0m0.126s
[root@vm-114 ipalib]# time ipa user-find/dev/null
real 0m0.816s
user 0m0.432s
sys 0m0.119s
Patch is attached.
I see a number of problems with the patch:
* Only Command subclasses are finalized (that might be the reason why
it is so fast)
* You assume that the first operation on a plugin instance is a call
on the args/options/params namespaces, but there is no guarantee that it
will be
* The whole approach is error-prone, as it requires the programmer to
carefully setup the attributes so that the plugin can be properly
finalized (this should be done automatically, so that every plugin is
guaranteed to be finalized without complicated setup)
Honza
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
On Wed, 02 Nov 2011, Jan Cholasta wrote: I see a number of problems with the patch: * Only Command subclasses are finalized (that might be the reason why it is so fast) * You assume that the first operation on a plugin instance is a call on the args/options/params namespaces, but there is no guarantee that it will be * The whole approach is error-prone, as it requires the programmer to carefully setup the attributes so that the plugin can be properly finalized (this should be done automatically, so that every plugin is guaranteed to be finalized without complicated setup) Perhaps you need to look at why finalize() is there at all. We have certain properties that are set only during finalize() method execution. If something cannot be performed without accessing those properties, it cannot be done before finalize() is performed. Anything else is allowed. So it boils down to being able to intercept the access to those properties that change their value in effect of finalize() call. What this all means is if a plugin writer has something in mind when changing properties in his/her re-implementation of finalize() method, it is simple to mark up those properties as such and this patch gives you a simple process and means to do so. Callable instances are a consequence of the above -- Command.__call__() does use properties that are changed due to finalize() being run. In fact, there are so many places in FreeIPA where we simply expect that foo.args/params/output_params/output is both iterable and callable instance that it is not even funny. Now, the process established by the proposed patch is actually dependent only on the fact that bound instance has finalize() method. This is quite generic and can be used for all other types of objects. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
Dne 2.11.2011 16:11, Alexander Bokovoy napsal(a): On Wed, 02 Nov 2011, Jan Cholasta wrote: I see a number of problems with the patch: * Only Command subclasses are finalized (that might be the reason why it is so fast) * You assume that the first operation on a plugin instance is a call on the args/options/params namespaces, but there is no guarantee that it will be * The whole approach is error-prone, as it requires the programmer to carefully setup the attributes so that the plugin can be properly finalized (this should be done automatically, so that every plugin is guaranteed to be finalized without complicated setup) Perhaps you need to look at why finalize() is there at all. We have certain properties that are set only during finalize() method execution. If something cannot be performed without accessing those properties, it cannot be done before finalize() is performed. Anything else is allowed. So it boils down to being able to intercept the access to those properties that change their value in effect of finalize() call. What this all means is if a plugin writer has something in mind when changing properties in his/her re-implementation of finalize() method, it is simple to mark up those properties as such and this patch gives you a simple process and means to do so. Callable instances are a consequence of the above -- Command.__call__() does use properties that are changed due to finalize() being run. In fact, there are so many places in FreeIPA where we simply expect that foo.args/params/output_params/output is both iterable and callable instance that it is not even funny. Now, the process established by the proposed patch is actually dependent only on the fact that bound instance has finalize() method. This is quite generic and can be used for all other types of objects. The real problem is in the API class so it should be fixed there, not worked around in Plugin subclasses. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 029 Page is cleared before it is visible
On 11/2/2011 8:33 AM, Petr Vobornik wrote:
On the second thought, this might not be sufficient to detect the
changes in the list page. Try changing an attribute in an entry, then go
back to the list page, the list page will not show the updated attribute
because the filter is not changed.
I think we should remove the needs_update() from the search facet so it
will always refresh, but we probably can keep it for association facet.
What do you think? Sorry about that.
Changed to refresh always. Clearing always or not clearing at all seems
wrong. When the pkey doesn't change, only small portion of values
can/will change, so it's probably not so wrong to show the previous
list, but when the filter is changed the results will be probably much
different and the clear is needed. What do you think? - Added
needs_clear method which clears if the filter changes (basically renamed
needs_update).
OK. The search page feels more responsive this way. The term
needs_clear() is a bit confusing because during facet.refresh() it also
calls table.empty() which essentially the same as table.clear(). How
about clear_before_show()? It's not important, we can do this later.
There are probably better solutions, but let's do this separately.
In future we can build a mechanism for subscribing to events from
different facets and doing appropriate actions.
Something like:
var refresh_search_on_save = function(spec) {
var that = {};
that.register = function() {
that.entity = IPA.get_entity(spec.entity);
that.details_facet = that.entity.get_facet(spec.facet || 'details');
that.search_facet = that.entity.get_facet(spec.search_facet || 'search');
that.details_facet.on_save.attach(that.on_save, that);
};
that.on_save = function() {
that.search_facet.set_needs_refresh(true);
};
return that;
};
So the facets won't be dependent on each other.
Yes, that would be better, but I'd put the registration somewhere inside
the entity class (to be created). This is also going to force early
creation of the facets as opposed to lazy loading.
9. The facet header's clear() calls load() with empty data. The load()
will display the facet group label using facet's pkey. Since this is
called before refresh(), sometimes you'll see 'undefined' or the old
pkey. I think the code in entity.js:351-354 should check if the data is
empty it should clear the label.
Fixed
I think displaying no label at all would be better than showing
incomplete label (without primary key), but we can do this later.
10. Instead of emptying button label in host.js:731-732, it's probably
better to reset it to its initial value:
var password_label = $('.button-label', that.set_password_button);
password_label.text(IPA.messages.objects.host.password_set_button);
Seems more proper to clean the label. If the label is set to
...host.password_set_button it will always shows before load set OTP
after load it can change to reset OTP which is wrong behavior.
I see your point. It might be better to just hide the button, but we can
do this later.
Question about this one:
4) Changed direct/indirect radio names in association facets - radios
form different facets were interfering.
Did you notice any problem with the old radio name? The name was
supposed to be used locally by the facet itself so it should not
interfere with radios in other facets, whereas ID is global so it needs
to be unique.
Regardless, ACK and pushed to master.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Nesting widgets
This sounds pretty good. I think it is the right approach.
On 11/01/2011 09:11 PM, Endi Sukma Dewata wrote:
So I decided to try to get an IP Address widget working. See the
attached patch. It was fairly trivial.
However, this widget is not really all that useful by itself. It
would
need to work as a part of a multivalued_text widget in order to
replace
the widget used on the dnsrecord page. And looking at the
multivalued
text widget, I think you will agree that is going to be tricky.
I think we can create an extend point for validation logic (EG
validator object in field's spec) instead of inheriting the widget.
To summarize the recent discussion on IRC and other threads, we're
planning to split the existing widget concept into (logical) fields
and (visual) widgets. See: https://fedorahosted.org/freeipa/ticket/2040
The new widgets will be used mainly for input/output like the existing
widgets, but they can also be any other UI components such as header
or separator.
The widgets will support nesting. For example, the multivalued widget
will become a composite widget which has an Add and Undo All links and
can contain other widgets:
widgets: [
{
factory: IPA.multivalued_widget,
name: 'fullName',
widget: IPA.text_widget
}
]
The widgets can be arranged inside a section, which is also a
composite widget that has a header and is collapsible.
widgets: [
{
factory: IPA.section_widget,
name: 'identity',
widgets: [
{
factory: IPA.text_widget,
name: 'fullName'
}
]
}
]
For IP address we could either use a text widget with an IP address
validator, or we could also implement a custom IP address widget.
Either solution can be used inside multivalued widget.
widgets: [
{
factory: IPA.multivalued_widget,
name: 'ipaddress1',
widget: {
factory: IPA.text_widget,
validator: IPA.ipaddress_validator
}
},
{
factory: IPA.multivalued_widget,
name: 'ipaddress2',
widget: IPA.ipaddress_widget,
},
]
Interesting concept. Yes, this would work too, and solve the issue for
IP addresses validation. But there are places where we may want to
validate only a single IP address, and we may end up with code
duplication, although more likely they will both just call the same
utility function.
Since the multivalued widget is completely separate, we can reuse the
IP address widget for a single valued attribute.
widgets: [
{
factory: IPA.ipaddress_widget,
name: 'ipaddress'
}
]
In order to make the widget scheme more nestable, the section
section.load and save can do more work, such as scoping down the
piece
of the request record to just that portion required by the widget.
Bascially, it can do what widget.load does, just externally
I don't think this would help. This would limit the widget. Currently
most widget works with the record.[widget name]. But we can override
load and save method to break the 1:1 mapping between widget and
record. Widget can consist of several widgets and supply them custom
record object (it can assume that the simple widget would fetch the
value of its name. The name is defined by the master widget (no
problem here).)
The concept you mentioned could be beneficial if we abandon flat
records and introduce structured ones. But I think there is no will
for it. Event then I don't know if sections should be responsible for
this. It's not their purpose.
Records are already structured, just that by the time we get to the
individual fields, they tend to be flat. But the record is JSON and
is a
tree structure.
But I like what you are saying. I agree that the interface for Widget
and Section should be the same. Right now Section is:
that.save = function(record) {};
that.load = function(record) {);
and load is
that.load = function(record) {};
that.save = function() {};
It is this last function that needs to be changed, but it will have
far
reaching effects. We use save to extract the value or values from the
field for many uses. I think we can do this: For all widgets, rename
save() to get_value(); and then add a save(record) method that calls
get_value(); Then widget and record have the same interface, which
is a
big first step.
The fields will be used to load/store attributes. Each field usually
will have a corresponding widget, except hidden fields:
fields: [
{
name: 'krbprincipalname' // hidden
},
{
name: 'cn',
widget: 'identity.fullName' // widget inside a section
},
{
name: 'mail',
widget: 'contact.email' // multivalued widget
}
]
During load the fields will be used to get the attributes from the
records returned
Re: [Freeipa-devel] [PATCH] 029 Page is cleared before it is visible
On 11/02/2011 04:41 PM, Endi Sukma Dewata wrote: On 11/2/2011 8:33 AM, Petr Vobornik wrote: Question about this one: 4) Changed direct/indirect radio names in association facets - radios form different facets were interfering. Did you notice any problem with the old radio name? The name was supposed to be used locally by the facet itself so it should not interfere with radios in other facets, whereas ID is global so it needs to be unique. In sudo and hbac rule enable radio button. Radios with same name are interfering on whole page. If you click at one, others gets unset. This wasn't an issue before because we have always reloaded the data. Radios in single facet wasn't interfering because they had different names. Gathering data wasn't a problem, because jquery selector was constraint to widget's container. Regardless, ACK and pushed to master. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
On Wed, 02 Nov 2011, Jan Cholasta wrote: Callable instances are a consequence of the above -- Command.__call__() does use properties that are changed due to finalize() being run. In fact, there are so many places in FreeIPA where we simply expect that foo.args/params/output_params/output is both iterable and callable instance that it is not even funny. Now, the process established by the proposed patch is actually dependent only on the fact that bound instance has finalize() method. This is quite generic and can be used for all other types of objects. The real problem is in the API class so it should be fixed there, not worked around in Plugin subclasses. Please explain why you do think real problem is in API class. Finalize() is needed purely to being able to split plugins' property initialization into stages before loading plugins and after due to the fact that each and every plugin could contribute commands and additions to the same objects. While these stages are separate, plugins can access properties and commands they want and it is duty of a plugin to get its property working right. We have finalize() method exactly for this purpose. API class' attempt to call finalize() on each plugin's instance at once is a poor replacement to detecting access to not-yet-initialized properties. We can implement that access like you have proposed with __getattribute__ but it has additional cost for all other properties that don't need post-initialization (finalization) and, what's more important, they incur these costs irrespective whether initialization has happened or not. That's bad and my patch shows it is actually noticeable as the performance difference, for example, of 'ipa dnsrecord-find example.com' between the two patches is about 2x in favor of my patch (1.624s vs 0.912s). Regarding other objects, here is the list of places where we define specific finalizers: $ git grep 'def finalize' ipalib/cli.py:def finalize(self): ipalib/frontend.py:def finalize(self): ipalib/plugable.py:def finalize(self): ipalib/plugable.py:def finalize(self): ipaserver/rpcserver.py:def finalize(self): ipaserver/rpcserver.py:def finalize(self): ipaserver/rpcserver.py:def finalize(self): tests/test_ipalib/test_cli.py:def finalize(self): tests/test_ipalib/test_config.py:def finalize_core(self, ctx, **defaults): tests/util.py:def finalize(self, *plugins, **kw): As you can see, there NO plugins that define their own finalizers, thus, all of them rely on API.finalize(), help.finalize(), and Plugin.finalize()/Command.finalize(). ipaserver/rpcserver.py finalizers are fine as well, I have checked them. Updated patch is attached. It addresses all comments from Martin. [root@vm-114 freeipa-2-1-speedup]# time ipa dnsrecord-find ipa.local /dev/null real0m0.883s user0m0.504s sys 0m0.136s [root@vm-114 freeipa-2-1-speedup]# time ipa user-find /dev/null real0m0.887s user0m0.486s sys 0m0.141s [root@vm-114 freeipa-2-1-speedup]# time ipa group-find /dev/null real0m0.933s user0m0.446s sys 0m0.169s [root@vm-114 freeipa-2-1-speedup]# time ipa help /dev/null real0m0.624s user0m0.479s sys 0m0.133s [root@vm-114 freeipa-2-1-speedup]# time ipa group /dev/null real0m0.612s user0m0.475s sys 0m0.126s [root@vm-114 freeipa-2-1-speedup]# time ipa user /dev/null real0m0.617s user0m0.472s sys 0m0.131s -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1 Do lazy initializiation ipalib
(actual patch attached!) On Wed, 02 Nov 2011, Alexander Bokovoy wrote: On Wed, 02 Nov 2011, Jan Cholasta wrote: Callable instances are a consequence of the above -- Command.__call__() does use properties that are changed due to finalize() being run. In fact, there are so many places in FreeIPA where we simply expect that foo.args/params/output_params/output is both iterable and callable instance that it is not even funny. Now, the process established by the proposed patch is actually dependent only on the fact that bound instance has finalize() method. This is quite generic and can be used for all other types of objects. The real problem is in the API class so it should be fixed there, not worked around in Plugin subclasses. Please explain why you do think real problem is in API class. Finalize() is needed purely to being able to split plugins' property initialization into stages before loading plugins and after due to the fact that each and every plugin could contribute commands and additions to the same objects. While these stages are separate, plugins can access properties and commands they want and it is duty of a plugin to get its property working right. We have finalize() method exactly for this purpose. API class' attempt to call finalize() on each plugin's instance at once is a poor replacement to detecting access to not-yet-initialized properties. We can implement that access like you have proposed with __getattribute__ but it has additional cost for all other properties that don't need post-initialization (finalization) and, what's more important, they incur these costs irrespective whether initialization has happened or not. That's bad and my patch shows it is actually noticeable as the performance difference, for example, of 'ipa dnsrecord-find example.com' between the two patches is about 2x in favor of my patch (1.624s vs 0.912s). Regarding other objects, here is the list of places where we define specific finalizers: $ git grep 'def finalize' ipalib/cli.py:def finalize(self): ipalib/frontend.py:def finalize(self): ipalib/plugable.py:def finalize(self): ipalib/plugable.py:def finalize(self): ipaserver/rpcserver.py:def finalize(self): ipaserver/rpcserver.py:def finalize(self): ipaserver/rpcserver.py:def finalize(self): tests/test_ipalib/test_cli.py:def finalize(self): tests/test_ipalib/test_config.py:def finalize_core(self, ctx, **defaults): tests/util.py:def finalize(self, *plugins, **kw): As you can see, there NO plugins that define their own finalizers, thus, all of them rely on API.finalize(), help.finalize(), and Plugin.finalize()/Command.finalize(). ipaserver/rpcserver.py finalizers are fine as well, I have checked them. Updated patch is attached. It addresses all comments from Martin. [root@vm-114 freeipa-2-1-speedup]# time ipa dnsrecord-find ipa.local /dev/null real0m0.883s user0m0.504s sys 0m0.136s [root@vm-114 freeipa-2-1-speedup]# time ipa user-find /dev/null real0m0.887s user0m0.486s sys 0m0.141s [root@vm-114 freeipa-2-1-speedup]# time ipa group-find /dev/null real0m0.933s user0m0.446s sys 0m0.169s [root@vm-114 freeipa-2-1-speedup]# time ipa help /dev/null real0m0.624s user0m0.479s sys 0m0.133s [root@vm-114 freeipa-2-1-speedup]# time ipa group /dev/null real0m0.612s user0m0.475s sys 0m0.126s [root@vm-114 freeipa-2-1-speedup]# time ipa user /dev/null real0m0.617s user0m0.472s sys 0m0.131s -- / Alexander Bokovoy -- / Alexander Bokovoy From be4fc63a16e9fdd5fa1c58aa5a5267b8e06e44ce Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Wed, 2 Nov 2011 12:24:20 +0200 Subject: [PATCH] Perform late initialization of FreeIPA plugins https://fedorahosted.org/freeipa/ticket/1336 When plugins are loaded, instances of the provided objects and commands are registered in the API instance. The patch changes finalization process to apply on first access to the Command instance that would cause either access to properties (args, options, params) or execution of the command itself. The patch gives 2x boost for client-side commands like help and 3x boost for commands that go to the server side. All performance numbers are approximate and may vary a lot. --- ipalib/frontend.py | 50 ipalib/plugable.py | 12 ++--- tests/test_ipalib/test_frontend.py |7 +++-- 3 files changed, 62 insertions(+), 7 deletions(-) diff --git a/ipalib/frontend.py b/ipalib/frontend.py index 61e7f493f8a8e30a1a189d06cd6a69893319deaf..22d77372b8cb58bb2e922b3fb158ee1025b0d242 100644 --- a/ipalib/frontend.py +++ b/ipalib/frontend.py @@ -64,6 +64,44 @@ def entry_count(entry): return num_entries +class _MirrorTrap(object): + +_MirrorTrap is a special class to
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/01/2011 10:08 AM, Ade Lee wrote: On Tue, 2011-11-01 at 12:49 -0400, Simo Sorce wrote: On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote: - Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? Currently not as we use completely separate instances, but we will be able to use different suffixes for some stuff. I would suggest that if we use the same database, then we use different suffixes. For one thing, we will want to be able to set ACIs so that the information here is not publicly browsable. It will also be much easier to limit the pki users ability to touch the rest of the db, and visa versa. It also makes it less likely that upgrade scripts will stomp on each other. We really should use separate suffixes/backends for the reasons above in addition to other benefits. Replication is at the suffix level, so this adds the ability to not replicate PKI data is that is something we ever decide we need to do. Indexes are also configured at the suffix/backend level, so we can have separate indexes defined for the PKI and IPA user trees. 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. If we confirm this conflict this will become a requirement before we can proceed. What is this conflict? Many of our plug-ins have this ability already, and we should add it where it is missing. The RHDS documentation shows that the attribute uniqueness plug-in can be configured by subtree already. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. It's a matter of trust for me. I do not want to trust PKI to have free reign on all data. I want it to be confined to only what it needs. So we can use ldapi and user mapping, but we wouldn't map the user to DM anyway. Agreed. If the roles were reversed, we would not want IPA to be able to have free reign on the PKI data. It makes sense to have separate admin roles and only use DM where absolutely necessary. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. If we use separate suffixes/backends, we can configure the indexes differently. The problem here is finding out and how to make sure pki vs ds/ipa install and upgrade scripts do not stomp on each other. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? See my other mail, we need DS to support setting defaultNamingContext in rootdse. Is there a RFE opened against 389 for this already? It should be pretty easy to add the ability to configure a default naming context to be displayed in the rootDSE. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. The problem here is much bigger, PKI simply do not have enough information to create a proper IPA user, so it should not be allowed to. This is an example of why I want to tightly control through ACIs what PKI can do and prevent it from causing issues. If we do this integration, then I'm OK with IPA creating the users. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert As an added bonus, we get user certs. One discussion we've had on the side is about scalability. As the Databases increase in size, it might become impractical to fully synchroize the user database over to a machine that is dedicated to Certificate operations. For example, we might have a public facing machine in the DMZ that is servering CRLs and OCSP to the world. This machine would only need the subset of users that can act as PKI admins. In this case, we might build a custom script for replicating a subset of the IPA data one direction only: from one of the fully replicated instance to the DMZ instance. This is not something we foresee doing in a near term release, but should be discussed and fleshed out. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well For clarification, cmsuser is just an object that is defined in the PKI schema, not the actual admin user created in the install itself. It may be advantageous to actually pre-create this user when applying schema LDIFS and just have pkisilent add the user certs. 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. Pre-creating this user may solve this problem. You can pre-create a user with all the required IPA and PKI attributes and just have pkisilent add the user cert needed. As we will be running as directory manager in this case, we will permissions to do this. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. This of course involves setting up the relevant ACIs. We may want to consider the reverse. That only certain IPA accounts should have access to the PKI data. 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. Not needed if we pre-populate as mentioned above. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. As an added bonus, we get user certs. One discussion we've had on the side is about scalability. As the Databases increase in size, it might become impractical to fully synchroize the user database over to a machine that is dedicated to Certificate operations. For example, we might have a public facing machine in the DMZ that is servering CRLs and OCSP to the world. This machine would
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote: On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. Unfortunately it looks like the cmsuser objectclass is of type structural, which means it cannot be added to existing records. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. I wonder if we can convince PKI to use a different schema to reprsent this information. We can use Roles or Groups to tell what type of user a user is, not sure about the state as that schema file has exactly the same comment for both usertype and userstate, seems a bug. IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? What is description used for ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
