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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York