On Thu, 2013-02-14 at 09:33 -0500, John Dennis wrote: > On 02/14/2013 09:05 AM, Simo Sorce wrote: > > So as I proposed we can call ipa user-add from LDAP from a > > non-transactional pre-op plugin. We just need to be careful about when > > we allow that to avoid loops, but besides that problem it seem > > relatively easy and does not require crazy things like playgrounds or > > even full LDAP proxies. > > I think I need a clarification because perhaps I didn't fully understand > your proposal. > > Is the idea with a non-transactional pre-op plugin it invokes user-add > and then the pre-op returns *without* having modified ldap? In effect it > acts as a trigger?
Yes. > That still implies there has to be a separate tree where the foreign > entity writes (and the pre-op plugin watches) No. > because otherwise how > could the pre-op plugin distinguish between framework writes and foreign > writes? The idea I flaunted around is that the pluggin triggers only if a special objectclass is used. The framewrok would never try to create a user with this special objectclass so loops are avoided. > If there is a separate tree where is the looping issue? You still > haven't explained this. No separate tree, the plugin intercepts the Add operations, and calls the framework. The framework does the real user creation and then returns. At that point the pre-op plugin returns immediately with the error code from the framework discarding the actual add operation. > Also, under the scenario that a foreign entity writes something into > LDAP (somewhere) and it triggers us to call user-add via some mechanism > then what happens when errors occur? We return back an error. > The foreign entity will not know we rejected the operation nor why. This is the problem if you use a staged approach, and one of the reasons I do not consider it as viable, and therefore reject any proposal that imply staged writes and separate operations. > Also, don't forget they want to delete users, remove group membership, > add group membership, add groups, remove groups etc. Some of these > operations are dependent upon logic in our framework. Which ones. Only user creation is really special. Deleting a user should not depend on the framework, nor adding group members. Adding a user is a special case, and should be limited to that. > I don't see how > some of these operations can be reliably managed by a foreign entity > simultaneously performing LDAP operations. I do not see what your concerns are. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
