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

[John Dennis]

On 02/13/2013 10:40 PM, Nathan Kinder wrote:
> 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.

Messy is one word for it :-) Herein lies the problem. user-add is 
actually a simple case where in this particular version of our code we 
know the LDAP operations that occur and in what order. But there is 
nothing in our coding guidelines that guarantees this, it just happens 
to be true today. Pre and post callbacks are free to do as they please. 
The logic in our ldap module can change (in fact it's undergoing a 
rewrite as we speak). We've committed to supporting an extension 
mechanism (plugins) that ties into the framework operations and who 
knows what might occur in that code. At the moment it's not used, but 
hopefully it will be.

Then comes the question, where do we draw the line? Do we say only 
user-add with no additional options is supported because we know what 
occurs during it's processing and hence we feel safe emulating user-add 
outside the framework?

We all know this is a slippery slope, as soon as you support user-add 
this way we'll be getting requests to support other commands or other 
options. And after we make framework changes (which we do frequently) 
are we going to test these out-of-band operations continue to emulate 
the ever changing framework?

It's a slippery slope that can expose us to problems we don't need.

Jenny, do you want to test an entirely different mechanism or do you 
want to limit it to our defined API?

We have a defined API, I really think that's the only thing we should 
support. Backdoor shortcuts that sidestep our framework should be off 
the table IMHO, it's just inviting too many problems.


-- 
John Dennis <jdennis at redhat.com>

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