On 14.2.2013 03:55, Dmitri Pal wrote:
On 02/13/2013 09:48 PM, Nathan Kinder wrote:
On 02/13/2013 06:18 PM, Dmitri Pal wrote:
On 02/13/2013 02:08 PM, Simo Sorce wrote:
On Wed, 2013-02-13 at 13:30 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2013-02-13 at 12:59 -0500, John Dennis wrote:
On 02/13/2013 12:53 PM, Simo Sorce wrote:
If we can solve the looping and potential deadlocking concerns I
we can avoid the json reply and let the framework do the actual
Could you elaborate on your looping and deadlock concerns? I
where they would arise if what we're watching is entirely
our LDAP tree.
I do not understand what you are 'watching' ?
I think he means have a persistent search to watch for new entries and
then act upon them.
I think a 2 step approach is misguided, so I've written it off from the
This all thread smells like rewriting winsync by using internal plugin
and IPA framework.
Is there any chance we can use existing winsync solution to do what we
need but sync from staging instance rather than AD?
Then the flow will be:
HR system -> staging DS instance -> dirsync -> IPA
a) We are satisfied with the security of the existing winsync solution
and authentication used there. I do not see why it should be different
here as it is a very similar use case.
b) I expect we can sync from 389 to 389 with minor config changes and
effectively no code changes
This is not the case. Winsync uses the AD Dirsync control, which 389
does not support. The Winsync code also expects the AD schema on the
entries coming in from the Dirsync response. Even if 389 supported
the Dirsync control, there would be a fair amount of code changes to
deal with whatever schema we would need to expect.
c) The users created via winsync now are created in a proper way so IPA
accepts then as IPA users
This solves the problem of add and delete of the users.
I know that winsync already supports group add/delete but we never
qualified it in IPA. So may be it is time, at least for this use case.
I would really think that this might be a lower cost solution than
writing yet another custom plugin.
Let us try to reuse what we already have.
I think a custom plug-in would be easier (though I do have concerns
about the performance impact of the JSON approach).
I really think that we rather have an external solution and not the one
hot wired into the IPA internals via the proposed plugin.
Something like an external proxy or gateway rather than the approach
Simo proposed even if it would be more work. This work would be reusable.
We already have several use cases for the LDAP proxy. This can be one
more. A bit more and there will be enough need to build one anyways.
The main value is that it is optional and external and acts as an
ecosystem level solution that can be developed and tested on a separate
schedule rather than being internal to IPA.
In my Fedora 17 I found package python-ldaptor. It seems to offer nice support
for writing own event-based LDAP servers. For simple LDAP proxy it could be
$ yum install python-ldaptor
Freeipa-devel mailing list