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 think
we can avoid the json reply and let the framework do the actual final
ldap add.
Could you elaborate on your looping and deadlock concerns? I don't see
where they would arise if what we're watching is entirely independent of
our LDAP tree.
I do not understand what you are 'watching' ?

Simo.

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

Simo.

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
Couple assumptions:
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).

-NGK


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to