On 02/13/2013 07:11 PM, Simo Sorce wrote:
On Wed, 2013-02-13 at 10:57 -0700, Rich Megginson wrote:
is there potential from deadlocking here due to the new transaction
stuff ? Or can we single out this plugin to run before *any*
is started ?
If you do this in a "regular" pre-op, not a "betxn" pre-op, then it
should be fine.
Ok in this case we should be able to create a regular pre-op plugin to
intercept the ldap add call and then use the following flow:
client --(LDAP)--> 389DS --(HTTP/json)--> framework --(LDAP)--> add
So no deadlocks will happen, the remaining issue is how to make sure we
do not loop by mistake in the second add.
One way could be to have loop detection so that if more then two (1.
original, 2. framework) adds for the same DN come in we just return
errors. Another way is to use a special objectclass as I proposed in the
thread and make sure the framework explictly blacklists it so that it
can never try to send an add with the special oc even by mistake or user
And a third way is a separate LDAP tree.
I'm not familiar with what DS plugins can do. Can we craft one that
intercepts all read operations on "cn=HR tree,$SUFFIX" and does them on
"cn=users,cn=accounts,$SUFFIX" instead (using that tree's permissions),
and forwards all write operations on "cn=HR tree" to IPA via JSON?
A fourth way is a proxy/gateway, essentially the same but with a
Freeipa-devel mailing list