[Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP

[Dmitri Pal]

On 02/14/2013 09:01 AM, Simo Sorce wrote:
> 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.
>
Neah...
Count this plant dead.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/