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

[Nathan Kinder]

On 02/13/2013 09:16 AM, Petr Viktorin wrote:
> On 02/13/2013 05:57 PM, Simo Sorce wrote:
>> On Wed, 2013-02-13 at 11:44 -0500, Rob Crittenden wrote:
>>> Simo Sorce wrote:
>>>> On Wed, 2013-02-13 at 16:12 +0100, Petr Viktorin wrote:
>>>>> Our own post-callback assumes the user is already in LDAP, and who
>>>>> knows what user-supplied callbacks will do. Keep in mind IPA is
>>>>> plugable; at least for outside plugins' sake (if not our own 
>>>>> sanity's)
>>>>> we should keep the number of code paths to a minimum.
>>>>
>>>> True which is why my proposal is to not use the standard user-add RPC
>>>> call, but have a separate one.
>>>>
>>>> This separate call would only call the core business logic to 
>>>> create the
>>>> user account add operation, but none of the external plumbing.
>>>>
>>>> Ideally we spit the framework flow like this:
>>>>
>>>> Normal user -> Real user-add --- . . . . . . . . .  --- LDAP add
>>>>                                   \                  /
>>>>                                    -- common logic --
>>>>                                   /                  \
>>>> 389ds plugin -> Mock user-add -- . . . . . . . . .  --- json reply
>>>>
>>>>
>>>> custom plugins should be called in the custom logic an operate on the
>>>> object before the ADD is attempted.
>>>>
>>>> If  we do it this way then most of the code path will be in common 
>>>> which
>>>> is what we want, and only the mechanical operation of adding the 
>>>> actual
>>>> object to ldap will be different.
>>>>
>>>> Simo.
>>>>
>>>
>>> There is one missing a few steps. A plugin execution looks like:
>>>
>>> Normal user -> Real user-add --- pre-op call(s) --- execute (LPAP add
>>> record) --- post-op call(s) which may do additional add/modify
>>>
>>> It is the postop calls that would be the problem. They assume that the
>>> entry has already been written (so, for example, it has a valid
>>> UID/GID/ipaUniqueId, etc).
>>
>> Why are they done after the add ? It seem dangerous.
>
> This comment from the user-add post-op plugin should explain:
>
> # Fetch the entry again to update memberof, mep data, etc updated
> # at the end of the transaction.
>
> Some processing happens in DS plugins, we can't get the data if the 
> object isn't added yet.
You are referring to the fact that an 'ipa user-add' is actually 
multiple LDAP operations performed by the framework in IPA, right? I 
know at a minimum, the IPA framework performs 3 operations against DS 
when adding a user:

- ADD operation to create the user entry (triggers a bunch of stuff in 
DS plug-ins)
- SRCH operation to read the user entry with all of the dynamic stuff 
that was performed by the DS plug-ins
- MOD operation to 'ipausers' group to add the new user as a group member

With 389-ds-base 1.3.0, the pre/post-op DS plug-ins that IPA is 
concerned with are now betxn plug-ins, so that at least guarantees that 
the search operation will find everything it needs.  The search could be 
eliminated if we add support for the 'Post-Read' control in DS as 
described in RFC 4527, which might be a good idea in the future (though 
I don't think it would really help us here).  That still leaves the 
problem of an 'ipa user-add' being composed of multiple write operations 
against LDAP.

With the DS plug-in approach that calls into the IPA framework with a 
'mock add' to form the resulting entry at the pre-op stage, we could 
take care of the initial ADD operation of the user entry.  We would 
still need to have a way to trigger the additional write operations that 
the IPA framework performs.  The proposed DS plug-in could do an 
internal search operation after the add, then it could perform the 
additional write operations that are needed.  This logic would need to 
be in the DS plug-in, or we would need another way to get the details 
from the IPA framework via JSON.  The approach begins to get a bit messy.
>
>> What happens id the first ldap add succeed and the post op fails ?
>>
>> We should exceute the ldap call after the post ops are perfomed imho.
>>
>
>