On Wed, 2013-02-13 at 21:55 -0500, 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 > >>>>>>> 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). > > > 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.
Penrose. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel