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

[Petr Viktorin]

On 02/14/2013 05:01 PM, Simo Sorce wrote:
> On Thu, 2013-02-14 at 16:29 +0100, Petr Viktorin wrote:
>> Then I recommend doing this. It avoids problems with delegation (the
>> "real" tree permissions are used) and looping (plugin and IPA write to
>> separate trees).
>
> Virtual objects are not free of issues, you are just trading some issues
> for others here, and I do not think you are properly evaluating the
> trade here.
>
> I am dead set against using staging areas, and I want to see proof they
> are a good idea, not handwaving 'fears' of using json in the server to
> forward operations directly to the framework.
>
>>   Other operations (deletes, mods) can be either
>> similarly delegated to the "real" tree,
>
> And *this* is a slippery slope. you are trading delegating one single
> operation to the framework directly, with proper error propagation back
> to the client, with now implementing full virtualized operations for mod
> and delete, and bind ? and search and then ?
>
> You are now basically paving the way for a virtual directory in tree.
>
> Sorry, but no.
>
>> or passed through IPA if we want to do that in the future.
>
>> Problems with replication can be solved by just not replicating the
>> separate tree.
>
> More and more hacks, for this supposedly 'cleaner' or 'simpler'
> solution ... sorry if I don't bite.
>
>> It also doesn't pollute core IPA with special cases, which is what
>> worries me.
>
> What does this mean ?
>
> We *have* a special case, and we are discussing how to handle it.
>
> The situation here (I do not want to call it a 'problem') is that we
> decided to put business logic around user creation in the framework
> because we thought that would be easier to prototype and develop in
> python code rather than in a plugin.
>
> However this special handling *must* be limited. LDAP is our main
> storage, and we must allow LDAP operations against it. Special cases
> needs to be limited to things that are really harder done in plugins
> rather then python code.
>
> For example if we need triggers for some operations in LDAP, they *must*
> be done through a 389ds plugin. Otherwise LDAP quickly becomes a
> read-only interface and interoperability quickly goes out of the window.
>
> I always treated the framework as a *management interface* on top. We
> can do things that are 'convenient', and 'help' admins avoid mistakes,
> but we cannot move core functionality in the framework, it would be a
> grave mistake. User creation *is* a special case, but should remain one
> of very few special exceptions.
>
> This very thread and the need for the interface proposed in this thread
> is a clear example of why we need to be extremely careful not to be too
> liberal with what business logic we move in the framework.
>
> LDAP keeps us honest, so we need to limit what we do in the framework,
> otherwise we'll keep taking shortcuts and soon enough it goes out of
> control and we loose interoperability with anything that is not
> purpose-built to talk to our framework.
>
> This should be an unacceptable scenario because it is like putting
> ourselves in a getto.
>
> We trade greater interoperability and acceptance for small conveniences
> here and there.
>
> We must thread *very* carefully along this line.
>
> Simo.


Ah! This is a point we need to stress more, I didn't get it. All this 
time I thought of it the other way -- IPA being the main interface, with 
LDAP being more of an implementation detail -- the storage, and a 
read-only interface for LDAP consumers.

Thanks for explaining, your solution makes perfect sense then.

However, if there are more people like me, then there's code in IPA that 
assumes IPA is the only interface modifications, and raw LDAP operations 
are hacks that happen to work for now.
IPA's command plugins also seem misguided now, as you pointed out.


I don't like this view much but, well, I can adapt.
Allowing writes by tools that aren't purpose-built to talk to our 
framework, (for example ones that don't honor our schema), still seems 
like something to be wary of.

-- 
Petr³